Executive briefThe agent needed one method and received the whole server

A customer-resolution agent needed to prepare one refund. The platform granted access to the support tool server, whose apparently convenient interface included customer search, case editing, outbound messages and a general payment operation. The credential behind it could reach every tenant. The product team called the agent read-mostly because its prompt said to inspect a case before acting. Nothing in the receiving systems enforced that description.

The mistake was not only excessive permission. The grant had the wrong unit. A server, connector, role or method name is too coarse to express one business action. Even a method called “read” can disclose millions of records, cross a tenant boundary or return fields irrelevant to the case. A narrow-looking “refund” method can accept an arbitrary customer, amount and destination. Authority exists in the combination of method, resource, object, parameters, data, side effects, transaction limits, time and current state.

Least authority also changes during a workflow. Once the relevant record is read, the read budget should contract. After a draft is approved, the preparation credential should not become the commit credential. After a payment commits, retry authority may be zero even if the model believes the call failed. A static role cannot represent this progression without additional state.

This paper proposes a fourteen-field Tool Capability Contract, a monotonic Capability Budget and a six-stage Proposal-Authorisation Split. Together they bound the maximum effect of an incorrect, confused or compromised model. The same design reduces damage from ordinary bugs, race conditions and excessive retries because enforcement does not depend on diagnosing why the proposal is wrong.

The strongest rival: fine-grained policy can become the problem

Thousands of ephemeral tokens and conditions can create latency, policy sprawl, fragile dependencies and denial of service. If engineers cannot explain which policy made a decision, they route around it. A universal policy layer can also centralise failure while giving a false impression that every downstream system is mediated.

The answer is not maximum policy detail everywhere. Prefer a small set of purpose-built operations with constrained parameters, protected facts and explicit receipts. Reuse a policy engine where it clarifies consistent decisions, but move stable invariants into the resource and data model. When a general tool cannot be bounded without an unmanageable rule set, replace it with a simpler service or keep the task human-operated.

Capability sliceA method name is only the beginning of the grant

The business task supplies the reason for authority. “Resolve duplicate charge in case C-4481” has a completion boundary, affected customer and source facts. “Use the support tools” does not. Once the outcome is named, the platform can decide whether the model needs to read selected fields, prepare an adjustment, seek approval or commit a transaction. Capabilities that do not advance that outcome are absent.

Tool and method are exact. A version change can alter parameters or effects, so a contract is not automatically portable across versions. Resource and object identify the tenant, account, record, document, environment, counterparty or transaction. Parameter bounds restrict recipient, destination, quantity, format and prohibited combinations. These checks use canonical identifiers resolved from authoritative state, not model-supplied display text.

Data exposure is part of authority. Read access carries confidentiality, purpose and volume consequences. Field-level minimisation prevents a research task from seeing customer identifiers it does not need. Row, date and case bounds prevent a nominally read-only query from becoming bulk extraction. Return values and error messages are bounded too, because they can disclose sensitive facts or invite adaptive enumeration.

Side effects include more than database writes. A tool can send an email, trigger a webhook, publish an event, reserve inventory, reveal that a record exists or create a downstream task. The contract enumerates direct, secondary and external effects. If the team cannot identify them, it cannot claim that a method is harmless.

Tool Capability ContractFourteen fields define the maximum permitted effect

The contract is issued after task authority is established and before a model can request the capability. It can be represented through policy data, attenuated credentials, a signed token and resource-side configuration rather than one universal format. The receiving service must understand the fields that govern its effect. Anything merely copied into natural-language context is advisory.

A contract can narrow but must not widen its parent mandate. Caveated credentials, token exchange and typed policy systems provide useful patterns for attenuation. Workload identity establishes the caller; the contract supplies resource and action bounds. Transaction approval supplies a separate authority where consequences warrant it. None should be inferred from the model's explanation.

Capability BudgetEvery permitted call consumes the workflow's remaining authority

A per-action limit can be defeated by repetition. Ten permitted messages may become harassment. One hundred authorised reads may become bulk extraction. A series of small refunds may exceed a daily loss ceiling. The Capability Budget therefore covers the complete task trajectory: maximum steps and tool invocations, total data, financial and customer effect, distinct resources and counterparties, elapsed time and compute, and failed, retried or compensated actions.

Consumption is monotonic. A call reserves budget before execution and settles it after the receiving system reports the actual effect. If the result is unknown, the reservation remains consumed until reconciliation. This prevents a timeout from becoming free retry authority. A rejected proposal may consume rate or failed-attempt budget even though it consumes no financial effect.

Compensation changes state but does not automatically restore authority. Reversing a calendar invitation cannot make every recipient forget the disclosure. Refunding a mistaken debit does not erase inconvenience, regulatory duties or loss of trust. Deleting a message may not remove copies. An accountable authority can replenish a budget after examining residual harm, but the model cannot infer that technical rollback reset the world.

Budget dimensions need not be collapsed into one number. A task can have time remaining but no recipient budget, or data capacity remaining but no retries. Each dimension has its own unit, source of truth and threshold. A request is allowed only if it fits every controlling dimension and the task contract remains live.

Authority contracts as work progresses

After the research agent reads its case-bound fields, it may lose further read authority and retain only summarisation. After the calendar proposal is prepared, the model has no invitation authority unless a reviewer approves an exact external recipient list. After a payment commits, the commit capability is revoked and only receipt or authorised compensation paths remain. The budget makes this contraction explicit rather than relying on the agent to remember which stage it reached.

Proposal-Authorisation SplitKeep decision authority off the model's path

First, the model proposes. It works with unprivileged context and emits a closed action object containing operation, resource, parameters, purpose, cited facts and requested effect. Second, a deterministic service resolves current state. It replaces display names with protected identifiers and fetches case, customer, balance, approval and workflow facts from recognised systems.

Third, policy evaluates the request. It checks workload subject, principal mandate, purpose, resource, parameters, side effects, transaction envelope, time, delegation and every Capability Budget dimension. Typed policy languages can validate request and entity shapes, but policy syntax is not the control by itself. The organisation must govern authoritative data, tests, deployment and resource integration.

Fourth, transaction-specific approval is supplied where required. A human or service principal approves the exact action object, not a generic session. Fifth, a broker issues a narrow credential. Audience, resource, lifetime and sender constraint reflect the decision; the model does not choose the scope or receive a reusable secret. Sixth, the executor rechecks and receipts. It validates current state, reserves budget, performs the effect and records what actually happened.

OAuth token exchange offers actor and subject semantics for producing a downstream token. Resource indicators reduce confused-audience exposure. Proof-of-possession mechanisms constrain replay. SPIFFE can identify the workload. Macaroon caveats illustrate attenuation. These technologies support the split, but none supplies the business task, transaction limit or recovery semantics automatically.

MCP and A2A can advertise tools, tasks and authentication requirements. Discovery is not permission. A tool description may be stale, self-reported or broader than one task. A remote agent can be authenticated while lacking any delegated right to the resource. Every protocol boundary maps to the Tool Capability Contract and the receiving resource enforces its part.

Separation and recoveryRetries and compensation require their own authority

Prepare, approve, commit and compensate are different effects. One standing role across all four lets a model create the object, approve its own facts, perform the transaction and erase evidence through an apparent correction. Separate identities and credentials make each boundary visible. Lower-consequence tasks may combine duties under policy, but the combination is an explicit exception tied to a bounded envelope.

Idempotency is part of authorisation. A request has a canonical action identity and key that the resource accepts once. The response distinguishes committed, rejected, failed-before-effect and unknown. The client does not invent a fresh key because the first call was slow. Concurrency control prevents two individually valid actions from both seeing the same remaining budget or precondition.

Compensation is another proposed and authorised action. It states the target effect, reversal method, evidence, owner and residual harm. Some actions are irreversible: disclosure, human communication, market signalling and customer distress cannot be fully undone. A recovery plan therefore separates technical state restoration, business reconciliation, affected-party identification, correction and redress.

Receipts join requested and actual effects. A model-generated tool transcript is not enough. The receiving service records object, parameter, principal, workload, policy, approval, credential, idempotency key, external effect, budget consumption and terminal state. Denials, partial effects and quarantined actions also receive durable records.

Complete mediationThe receiving resource makes the final decision

Host-side checks are useful but insufficient. A compromised agent host can bypass them, and another client may call the same service. The database, messaging system, calendar or payment service must enforce the resource, object, parameter, state, idempotency and budget rules that protect its effect. A central decision point can advise, but the resource needs a fail-safe path when that point is unavailable or stale.

Policy decisions are only as sound as their inputs. Cedar illustrates typed entities, requests and policy validation; OPA evaluates declarative policy over structured input and data. Those patterns help separate decision logic from model prose. They do not make an ungoverned customer identifier, outdated budget or spoofed purpose authoritative. Policy data requires owners, schemas, versioning, tests, distribution controls and freshness rules.

Each resource recognises a narrow credential audience and verifies the workload proof. It resolves the business object from protected identifiers, checks current preconditions and atomically reserves budget with execution. The agent host cannot declare that another tool already compensated the action or that remaining limits have increased. Cross-tool workflows share a canonical case and action ledger.

Fail-safe design matters operationally. If policy is unavailable, low-risk read paths may use a deliberately cached, short-lived rule with stricter exposure. Consequential writes deny or remain drafts. Emergency access belongs to an accountable human process with a separate identity and retrospective review, not a model-controlled bypass flag.

Measure maximum effect, not policy count

A mature implementation can answer: under full model compromise, how many records can be read, which fields can leave, which people can be contacted, what value can move, how many resources can change, how long the capability lasts and what remains irreversible? A large policy inventory is not evidence of a small blast radius. Test the actual executor and receiving system with worst-case proposals.

Ten worked casesCalculate the contract, budget and compromise effect

1. Case-bound research

The task is to compare policy clauses for one investigation. The capability reads an approved view containing document title, clause text and source date for that case, capped at 40 rows and two megabytes. It has no customer fields, write, export or outbound communication. The budget allows three queries in twenty minutes. A compromised model can produce a bad analysis and exhaust the read allowance, but cannot cross the case or disclose through a tool. Outcome: grant a field-minimised read capability.

2. Calendar preparation

The agent may propose one event in the user's calendar, with title and internal participants drawn from the case. External recipients and invitations require an exact approval. The preparation identity cannot send. The budget permits two drafts and one final proposal. Under compromise, the model can create an unsuitable draft, not contact anyone. Outcome: grant prepare-only authority without commitment.

3. Customer refund

The contract binds case, verified customer, original payment rail, eligible reason and £240 maximum. It also sets five refunds and £600 cumulative daily exposure, one retry key and a ten-minute approval. The fourth £200 request is locally eligible but would cross the remaining daily value budget, so policy denies it. Outcome: grant bounded execution with transaction-specific authorisation.

4. Payment workflow

A preparer reads the invoice and produces a signed payment object. A different principal approves supplier, account and amount. The payment service commits with a one-use credential. Compensation belongs to treasury recovery and cannot be invoked by the preparing model. Four receipts share one action identity. Outcome: split the workflow across independent duties and credentials.

5. Broad read-only database

The database exposes a generic query method that can join customer, employee and transaction tables. Calling it read-only does not limit extraction. The task cannot be expressed safely through prompt instructions or a row count alone. A purpose-built view enforces tenant, approved fields, predicates and volume; until it exists, the general method is withheld. Outcome: do not expose this tool; use a bounded service or human path.

6. Repeated customer messages

Every single message uses an approved recipient and template. After five contacts, the cumulative customer-effect budget reaches its ceiling. The sixth proposal is denied despite passing local schema and recipient rules. The receipt shows remaining recipient budget as zero. This is the negative control where all individual calls are authorised but the workflow is not. Outcome: grant bounded execution with transaction-specific authorisation.

7. Planner delegates too much

A planner may ask a specialist agent to inspect two named records. It attempts to pass the whole case tool capability, including update. Delegation is non-default and attenuation intersects the subtask with the recipient's workload policy. The worker receives two field-minimised reads and no onward delegation. Outcome: grant a field-minimised read capability.

8. Non-idempotent retry loop

A fulfilment method creates a shipment each time it is called. The executor requires a canonical order action and idempotency key, reserves one creation from the budget and returns the original receipt to duplicates. A timeout leaves the reservation pending until reconciliation; the agent cannot manufacture new keys. Outcome: grant bounded execution with transaction-specific authorisation.

9. Compensation with residual harm

A mistaken booking is cancelled and inventory returns, but the customer has received a notice and lost an alternative. Technical state is restored; customer and operational effects remain. Compensation consumes separate authority and opens a redress task. It does not replenish the original booking budget automatically. Outcome: split the workflow across independent duties and credentials.

10. General shell or browser

A general shell inherits file, network and cloud credentials; a browser can navigate arbitrary sites with a live session. Parameter filtering at the agent host cannot enumerate their secondary effects or ensure resource-side mediation. The acceptable task is rebuilt as a service with closed inputs and a receipt. Until then, the model receives neither capability. Outcome: do not expose this tool; use a bounded service or human path.

Interactive decision artefactLeast-Authority Tool Gate

The gate chooses a capability architecture and exposes the reason broader authority is denied. It has no least-privilege score and never returns a model-controlled credential.

Operating cadenceManage capability as inventory that expires

At design, owners decompose each business task into reads, preparations, approvals, commitments, compensations and receipts. They enumerate direct and secondary effects, define the fourteen contract fields and set every Capability Budget dimension. A full-compromise test establishes the maximum effect.

At tool onboarding, platform and resource teams inspect the real downstream identity, data access, methods, parameters, side effects, error disclosures and version-change behaviour. Tool discovery never grants the server. General operations are wrapped or replaced with bounded services before exposure.

At issuance, the task mandate, workload identity, policy version and initial budget produce an expiring contract. Delegation is disabled unless a named subtask needs it, and any downstream contract is an intersection that narrows. Credentials remain outside model-generated content.

At every action, protected facts resolve parameters; policy checks the action and cumulative trajectory; approval binds the transaction; the resource atomically reserves budget, executes once and records the effect. Unknown terminal state blocks blind retry. Completion revokes unused authority.

During operation, teams monitor server-level grants, stale methods, broad reads, unused scopes, recipient growth, repeated permitted actions, race conflicts, idempotency failures, budget exhaustion, missing receipts and recovery gaps. They test resource enforcement rather than accepting host configuration.

On incident or change, selective revocation stops the capability, in-flight effects are reconciled and compensation uses separate authority. Method, schema, resource, policy, provider, side-effect or recovery changes trigger contract review. Retired tools lose credentials and routes, not merely documentation.