Authority Budgets: The Missing Control Surface Between an Agent and Its Tools

The instruction layer is not a control surface

When an agent is given a tool, the prompt often carries a set of constraints: do not send more than a few emails, do not modify production records, do not exceed a spend threshold. These constraints are advisory. They are tokens in a context window, and a model that can call a tool can call it in ways the prompt did not anticipate. The model may generalise a permitted action into an unpermitted one, chain tools in an unexpected order, or simply fail to track a constraint across a long trajectory. The prompt does not enforce; it suggests.

Authority, by contrast, is enforced below the model. It lives in the credential, the scope of the token, the rate limit on the endpoint, and the attestation required to renew access. These are not instructions the model can reinterpret. They are constraints the runtime applies. If an agent holds a credential that can delete a database, the prompt saying "do not delete the database" is a hope, not a boundary. The practical unit of control is not allowed or not allowed. It is how much, how often, and under what attestation.

This distinction matters more as agents move from single-turn tool use to long-running loops. In a loop, the model's behaviour is shaped by what it can do, not by what it was told. The control surface is the set of capabilities it holds and the limits on those capabilities. That is the authority budget.

Why prompts cannot carry authority

A prompt is a request. A credential is a capability. When an agent calls a tool, the tool does not read the prompt. It checks the token, the scope, the quota, and the policy attached to the caller. If the token is broad, the tool will comply. The prompt is invisible to the enforcement point.

Consider a common pattern: an agent is instructed to summarise support tickets and is given a tool that can also update ticket status. The prompt says "read only." The tool's API accepts a write parameter. The model, pursuing the goal of resolving the ticket, may set that parameter. The prompt did not grant write authority, but the credential did. The failure is not a prompt failure; it is an authority design failure.

The same applies to rate and volume. A prompt might say "use the search tool sparingly." The endpoint has no quota. The agent can call it thousands of times. The prompt cannot enforce sparingness. Only a quota can.

This is why agent safety is better modelled as a spendable authority allowance. Each capability is a grant with a scope, a quota, an expiry, and a renewal condition. The model can spend the grant. It cannot exceed it. The enforcement point is the tool, the gateway, or the credential issuer, not the prompt.

Designing an authority budget

An authority budget expresses each capability as a bounded grant. A grant has four parts:

• Scope: what the capability can act on. Not "email" but "send to internal recipients in the support domain." Not "database" but "read rows in the tickets table."
• Quota: how much and how often. A number of calls, a volume of data, a rate per minute, a total spend against a resource. Quotas are enforced at the gateway.
• Expiry: when the grant lapses. Short-lived grants reduce the window in which a compromised or misaligned agent can act. Expiry forces renewal, which is an opportunity for attestation.
• Attestation: what evidence is required to renew or expand the grant. This could be a human approval, a second agent's signature, a check against a policy engine, or a proof that the previous quota was spent within scope.

The budget should be visible to the planner. If the agent can see that it has three writes remaining and two hours until expiry, it can reason about depletion. It can prioritise, defer, or request renewal. If the budget is invisible, the agent discovers limits as errors, which leads to retries, workarounds, and unpredictable behaviour. Visibility turns a hard stop into a planning constraint.

Separate authority by kind. Read authority is low-risk and can be renewed automatically within a session. Write authority is higher-risk and should require a narrower scope and a shorter expiry. Irreversible authority, such as sending an external communication, deleting data, or transferring funds, should require explicit attestation for each draw or a very small quota with a human in the loop. The renewal paths should differ accordingly: read grants can be refreshed by the orchestrator; write grants by a policy check; irreversible grants by a human or a quorum.

A concrete mechanism: an authority gateway sits between the agent and the tools. The agent presents a grant token. The gateway validates the token, checks the scope against the requested action, decrements the quota, and logs the draw. If the quota is exhausted or the scope is exceeded, the gateway returns a structured denial that the orchestrator can interpret. The token is issued by a credential service that encodes scope, quota, expiry, and attestation requirements. The model never sees the underlying credentials; it sees only the grant and its remaining budget.

This is not a new idea. It is how cloud IAM, API rate limiting, and capability-based security already work. The contribution is to treat the agent's authority as a first-class, spendable resource that the planner can reason about and the runtime can enforce.

Operational consequences

When authority is a budget, incident response changes. Instead of rewriting a system prompt and hoping the model complies, operators revoke a grant. Revocation is immediate and enforceable. The agent loses the capability, not just the instruction. The incident is contained at the credential layer, which is where the damage would occur.

Audit output becomes a ledger of draws against budgets. Each line records the grant, the scope, the action, the quota remaining, and the attestation. This ledger is legible to non-ML reviewers: security, compliance, and operations can read it without understanding model internals. They can see what the agent did, under what authority, and whether it stayed within bounds. They can also see when a grant was renewed and on what evidence.

Budget exhaustion becomes a first-class agent state. The orchestration layer must handle it explicitly: pause, request renewal, degrade to a lower-authority mode, or terminate. Treating exhaustion as an error to be retried is a recipe for circumvention. Treating it as a state to be managed keeps the agent within its authority.

The trade-off is overhead. Authority budgets require a gateway, a credential service, and a ledger. They add latency to tool calls and complexity to the orchestration layer. They force teams to define scopes and quotas up front, which is work that prompts do not require. For a prototype, this may be unnecessary. For a production agent with write access to real systems, the overhead is the price of a control surface that actually controls.

A second trade-off is flexibility. A tightly scoped grant may block a legitimate action the agent needs to complete a task. The agent must then request renewal, which may require human approval. This slows the loop. The alternative is a broad grant that permits the action and everything else. The design choice is where to place the boundary between autonomy and oversight. Authority budgets make that choice explicit and enforceable, rather than leaving it to the model's interpretation of a prompt.

Conclusion

Prompts describe intent. Authority bounds behaviour. In a loop, the model will use what it can use, not what it was told to use. The missing control surface is the authority budget: a spendable allowance with scope, quota, expiry, and attestation, visible to the planner and enforced at the gateway. This shifts safety from the instruction layer to the credential layer, where it can be revoked, audited, and reasoned about. It is less convenient than a prompt. It is also the difference between hoping an agent behaves and ensuring it cannot do otherwise.

---

Cover photo: Vladimir Srajber / Pexels.