Agent Credentials Are a Policy Problem, Not a Prompt Problem

The failure mode is not the model, it is the ambient credential

When an agent is wired into a human's OAuth session, it does not inherit the human's intent. It inherits the human's scope. A system prompt that says "do not send email" is a suggestion to a stochastic process; it is not a constraint enforced by the authorisation server. The model can be aligned, the prompt can be careful, and the agent can still issue a request that the credential is legally entitled to make.

The practical consequence is that prompt injection and privilege escalation stop being separate categories. An injected instruction does not need to break the model. It only needs to reach a tool call that the ambient token already authorises. The model becomes a routing layer for an authority that was granted before the conversation began.

This is why "do not send email" is not an access control primitive. Access control primitives are scopes, audiences, expiry times, and resource constraints. They live in the token and in the broker, not in the instruction text. A prompt is a policy expression with no enforcement point. When it fails, there is no audit event, no denial, and no revocation.

The blast radius differs by credential class. A leaked agent token with a narrow, short-lived scope can read a bounded resource set until expiry. A leaked user session can act as the human across every service that trusts the identity provider, including password reset, billing, and data export. The agent token is a bounded instrument; the user session is a master key. Systems that collapse the two inherit the master key's blast radius on every agent turn.

The industry conversation has started to reflect this. Recent coverage of agent security incidents and credential handling points in the same direction: the interesting question is not whether the model can be tricked, but what the credential permits after it is tricked (one, two).

Authority budgets as a first-class artefact

An authority budget is a declarative description of what an agent may do, expressed in units the runtime can enforce. It is not a prompt and it is not a role description. It is configuration that ships with the agent, is versioned in the same repository as the agent code, and is reviewed by the same people who review the tool bindings.

A useful budget has at least four dimensions:

• Spend: a per-task and per-window ceiling on monetary operations, expressed as a hard limit the broker refuses to exceed.
• Message volume: a cap on outbound messages, invitations, or notifications per window, so a compromised agent cannot use the mailbox as an amplifier.
• Write operations: a count and a resource scope for mutations, separated from reads.
• External calls: an allow-list of destinations, with per-destination rate limits, so data exfiltration requires a destination that was already approved.

The budget must separate read authority from write authority and from irreversible authority. Reading a calendar is not the same class of action as deleting an event. Sending a draft is not the same as sending a message. Posting to a channel is not the same as transferring funds. Each class gets its own grant, its own expiry, and its own checkpoint policy.

A concrete mechanism: the agent process never holds a long-lived secret. At task start, it presents its identity and the requested capability set to a broker. The broker validates the request against the agent's registered budget, mints a short-lived token scoped to exactly those capabilities and resources, and returns it. The token carries an audience, an expiry measured in minutes, and a budget identifier. Every downstream call presents that token. The broker logs the grant, not only the call.

The honest trade-off is latency and complexity. A broker round-trip sits on the critical path of every task, and the budget file becomes another artefact that can drift from reality. Teams that skip the broker for "simple" agents usually reintroduce ambient credentials later, under incident pressure, when the simple agent has grown a mailbox and a payment method.

Rules of engagement before the first tool call

Registration is the right moment to declare rules of engagement. At registration, the agent declares its allowed tools, allowed targets, and required human checkpoints. The broker stores this declaration and enforces it at grant time. A tool that is not declared is not callable, regardless of what the model emits.

Human checkpoints belong in the same declaration. An irreversible operation can require a second grant with a human approver identity attached. The approval is a signed artefact, not a chat message, so it can be replayed in review.

Mediation layer design follows from this. Three properties matter:

1. The agent never holds the raw secret. It holds a reference to a grant.
2. The broker exchanges the reference for a short-lived scoped token. The exchange is the enforcement point.
3. Logging captures the grant: who requested it, for which capability, against which resource, with which budget, and which approver signed it. Call logs alone cannot reconstruct intent; grant logs can.

A grant log entry is the difference between "the agent sent an email" and "the agent requested send authority for recipient X under budget B, and the broker granted it because the declaration permitted it." The second statement is reviewable. The first is a rumour.

There is a real cost here: grant logging produces a second event stream that must be retained, indexed, and correlated with call logs. It is more storage and more query surface. The alternative is an incident review that cannot distinguish a misconfigured budget from a successful injection.

Revocation and the operational cost of getting it wrong

Rotation latency dominates incident severity. If revoking an agent's authority takes hours, the incident window is hours, regardless of how quickly the model is patched. If revocation is a single broker operation that invalidates a grant family and its derived tokens, the window collapses to the token expiry plus propagation time.

This makes revocation a design constraint, not a runbook step. The broker must support:

• Grant revocation: invalidate a specific grant and all tokens minted from it.
• Budget revocation: invalidate every grant under a budget identifier.
• Agent revocation: invalidate every grant for an agent identity.
• Key rotation: reissue broker signing keys without a full redeploy.

Revocation paths belong in the evaluation harness, not only in production runbooks. A harness can assert that after a revocation event, a previously valid token is rejected within a bounded number of requests, and that the rejection is logged with the grant identifier. This is a testable property. Treating it as a runbook item means it is tested for the first time during an incident.

The residual risk is social engineering, and it does not disappear with scoping. A scoped agent can still be manipulated into using its legitimate authority against the user's interest: sending a plausible message to an approved recipient, reading a document it is allowed to read and summarising it to an attacker-controlled destination on the allow-list. Scoping reduces the blast radius; it does not eliminate the need for content-level review, recipient confirmation, or rate anomalies.

The design conclusion is narrow and load-bearing. The unit of design is the capability grant. Prompts describe behaviour; grants constrain it. Systems that treat the grant as configuration, version it, review it, and test its revocation path will survive injection attempts that would otherwise become privilege-escalation incidents. Systems that treat the prompt as the control plane will keep discovering that the credential was the policy all along.

---

Cover photo: Brett Sayles / Pexels.