Capability Tokens for AI Agents: Kill Ambient Authority Before It Kills Your Security

Most agent security designs are upside down. They give a long-lived API key to a process, then ask a prompt to behave.

A prompt is not an authorization boundary. A capability token is closer: a narrow, unforgeable grant that says which operation may run, against which resource, under which limits, and until when.

Start With the Authority the Task Actually Needs

An invoice agent that must draft one refund should not inherit the finance service’s ability to refund every customer. A deployment agent preparing a preview should not receive production credentials. Give the job the smallest useful capability.

{
  "action": "refund.create",
  "resource": "payment_84ea",
  "max_amount": 4200,
  "currency": "USD",
  "expires_at": "2026-08-11T06:15:00Z",
  "nonce": "single-use-id"
}

The executor—not the model—validates the signature, audience, expiry, resource, amount, and nonce. Natural-language intent can help produce a proposal. It cannot widen the grant.

Separate Planning, Granting, and Executing

Use three components. The planner proposes an action. A deterministic policy service evaluates identity, task scope, risk, and limits. A tool gateway consumes the resulting capability and executes only the encoded operation.

This separation contains prompt injection. Retrieved text might convince the planner to ask for a dangerous action, but it still cannot mint authority. The policy service works from authenticated context and structured facts, not instructions embedded in documents.

Do not let the same agent hold a credential that can create its own grants. That collapses the entire design into ambient authority with extra JSON.

Bind Tokens to Exact Effects

Tool names are too broad. storage.write could create a harmless draft or overwrite a production configuration. Encode the resource path, operation, content hash, size limit, environment, and allowed side effects.

For external messages, bind recipient and payload hash. For shell commands, prefer a purpose-built tool over arbitrary command text. For database access, expose parameterized operations instead of a generic SQL capability.

Single-use tokens and idempotency keys prevent replay. Short expiry limits theft. Audience restriction prevents a token minted for a preview service from being accepted by production.

Add Delegation Without Creating a Permission Explosion

Agents often delegate. A parent capability may allow attenuation: a child can receive less authority, never more. If the parent can read one repository for ten minutes, it may grant a child access to one directory for three minutes. It cannot add write access.

Record the delegation chain. Auditors should be able to answer who requested the capability, which policy approved it, which job consumed it, and what the tool actually changed.

Revocation matters for longer jobs. Short-lived capabilities can simply expire; durable tasks may need a revocation list or online introspection. Choose the mechanism based on damage window, not architectural fashion.

Test the Attacks Your Demo Ignores

Test expired tokens, modified payloads, wrong audiences, duplicate consumption, path aliases, symlinks, Unicode lookalikes, partial execution, and retries after timeouts. Test whether a lower-privilege child can trick the parent into using its broader token.

Log decisions without logging secrets. A capability identifier, policy version, resource, effect, and verification result are usually enough. The raw bearer token should not appear in traces or model context.

The point is brutally simple: an agent should not be trusted with whatever its process can reach. Give each action a narrow envelope of authority, make the gateway enforce it, and make every grant die quickly.