Scoped credentials for agents: short-lived, narrowly-scoped, per-action — and nothing else.
Once you have decided how the agent identifies itself (covered in agent-identity), the next question is how it holds the power that identity grants. The answer is: with credentials that are short-lived, narrowly-scoped, and re-derived per action — not with a human-grade API key. This essay walks the failure mode of human-grade credentials at agent scale, the three properties scoped agent credentials need, the implementation patterns that compose them, the shortcuts teams take and what they cost, and what auditing the scope itself looks like.
Why human-grade credentials fail at agent scale.
A human-grade credential — a personal API token, a long-lived OAuth refresh token, an SSH private key — has properties that make sense for a human and are exactly wrong for an agent:
- Long-lived. A token valid for 90 days lets a single moment of compromise (the agent worker mis-logs a secret, a prompt injection extracts the credential, a developer's laptop is stolen) translate into 90 days of attacker access.
- Broadly-scoped. A token scoped to "all of this user's data" or "everything this service account can do" gives every individual tool call the union of every capability the agent is supposed to have. A compromised agent does not have to escalate; it is already at maximum scope.
- Coarsely-revocable. Revoking a human-grade credential typically means rotating it everywhere it is configured — across worker pools, staging, developer machines, CI. The pain of rotation is exactly why teams put it off.
- Not contextual. A bearer credential carries no information about what the agent is trying to do right now; the authorization system has to authorize the maximum, because the minimum is invisible.
Combine these with an agent's blast radius — prompt injection from prompt-injection can hand the entire credential's authority to attacker-controlled text — and a human-grade credential in an agent's environment is a loaded weapon waiting for a trigger.
The three properties scoped agent credentials need.
A credential that is safe for an agent to hold has three properties; missing any one of them collapses the safety guarantee of the other two:
- Short-lived. Lifetimes measured in minutes, not days or hours. The token expires faster than an attacker can iterate; revocation becomes the absence of refresh rather than an active rotation. Token lifetime is the only thing standing between an extracted credential and a long incident.
- Narrowly-scoped. The token authorizes a specific resource and a specific action — "create-refund on order-12345 for user-678 up to $50" — not a class of capability. The blast radius of the credential is exactly the action it was issued for.
- Per-action. A new credential is derived for each tool call (or close to it), not once per session and reused. Per-action issuance makes the audit log truthful: every credential maps to the action it authorized, and the action it authorized maps to a credential.
No "admin just for this run." A long-lived broadly-scoped credential issued "just temporarily" outlives the temporariness; the cleanup ticket gets buried, the token gets reused, and you have re-introduced the human-grade failure mode under a different name. If you cannot do the operation under a properly-scoped token, the operation is wrong, not the scope.
Implementation patterns that compose the three properties.
The three properties do not implement themselves — they require infrastructure that sits between the agent and the tool. The patterns that hold up in production:
- STS-style temporary credentials. AWS STS, GCP service account impersonation, Azure managed-identity temporary tokens. The agent presents a long-lived but tightly-scoped identity (verified once); the STS issues a short-lived credential for a specific role and resource. The short-lived credential is what travels to the tool call.
- OAuth with per-tool scopes. Scopes are not just user-level; they are tool-level. The agent requests "read:orders" for a read tool and "write:refunds-under-50" for a write tool, with separate short-lived tokens per scope. Composition of scopes is explicit, not aggregated into a single mega-token.
- JWTs with audience and action claims. A JWT signed by an issuer the tool trusts, carrying claims for audience (which tool), action (what it permits), resource (what it acts on), and a short expiry. Stateless on the wire, verifiable without a round-trip to an authorization server.
- An authorization layer between the agent and the tool. A policy-decision point (PDP) that issues per-action credentials based on policy — the agent never holds the underlying capability, only the per-action token the PDP derived. Implemented well, this is the cleanest version of the pattern and the easiest to audit.
None of these is a model concern; all of them sit outside the agent loop, enforced as policy. The policy-enforcement material is the engineering surface this rests on.
The shortcuts — and what each one costs.
Most of the patterns above take real engineering work. Under deadline, four shortcuts beckon, and each turns a one-time engineering investment into a recurring, compounding risk:
- A single all-powerful API key. One token, broad scope, lives forever. Every tool the agent calls authenticates with it. The day this token leaks is the day your maximum-loss scenario realizes; the maximum is exactly what the token authorizes.
- Long-lived OAuth refresh tokens. "Short-lived access tokens, refreshed from a long-lived refresh token" looks like a scoped-credential pattern; it is not, because the refresh token is the actual long-lived secret and an attacker who steals it gets indefinite access. Refresh tokens for agents need their own lifetime and scoping discipline, or you are paying for the pattern without getting the property.
- "We'll add scoping later." The token shipped without scoping; the team got busy; nine months later the audit report says all agent actions are logged as a single super-user. Retrofitting scoping onto a deployed system is far harder than building it in, because the tools have already grown to expect the broad token.
- "Just give the agent admin for this run." The most expensive shortcut. The grant outlives the run because the cleanup got deprioritized; the next prompt injection inherits admin; the postmortem finds the temporary that was not.
Auditing the scope itself.
Scoped credentials are only meaningful if the scope is verifiable — both at the moment a credential is issued and after the fact when you reconstruct what happened. The two observability properties:
- Every credential issuance is logged with its scope. Issuer, requester (the agent's identity from agent-identity), the scope granted, the principal on whose behalf, the expiry, the request that triggered it. This is the credential side of the audit-trails story.
- Every tool call is logged with the credential that authorized it. Joinable by run_id and credential id to the issuance log. The audit answer "what authority did the agent act under to do X" is one join away, not a forensic reconstruction.
The composite property the scoping discipline buys you is the most useful version of the audit story: every action in the system has a named issuer, a named principal, a named credential, a named scope, and a bounded lifetime — none of which were "the agent has admin." The agent is just the actor; authority belongs to scoped, short-lived, audited tokens that the authorization layer issued for the action that happened, and only that action. The day a prompt injection lands, you will be glad you paid for the pattern instead of the shortcut.