Capability Tokens for AI Agents

Tool access is too blunt for serious agent systems.

An agent either has the tool or it does not. It can call the customer API, edit the repository, query the warehouse, send the email, or deploy the service. Prompts may tell it to be careful, but the authority is already present.

That model is convenient for prototypes and dangerous for products.

A better pattern is to grant capability tokens: narrow, temporary, auditable permissions tied to a specific step, resource, operation, and purpose. The agent does not “have production access.” It receives a token to read service health for incident INC-1042 for the next ten minutes. It does not “have email.” It receives permission to create a draft reply for case CS-8831, not send it.

Capability tokens make authority small enough to reason about.

They also change how we design agent workflows. The model can still propose actions. The harness decides whether a proposed action can be converted into a real capability.

Authority Should Follow the Work

Human systems often assign standing roles: admin, editor, reviewer, operator. Agents tempt teams to do the same. Create an agent identity, attach scopes, and let the prompt constrain behavior.

The problem is that agent work is step-shaped.

The same workflow may need broad read access during investigation, narrow write access during execution, and no write access during verification. A planning step can discuss options without any consequential authority. An execution step may need exactly one approved mutation. A reviewer step should usually read the artifact and evidence without being able to change either.

Capability tokens let authority follow the step rather than the persona. The system grants what the current transition requires and nothing more.

This keeps the agent flexible at the reasoning layer and constrained at the effect layer.

Tokens Need Semantics

A useful capability token is not just an API key with a shorter expiration.

It should describe:

• the resource it applies to
• the operation it permits
• the purpose for which it was issued
• the evidence or approval that justified it
• the time window in which it can be used
• whether the operation is read-only, reversible, or consequential
• how the result will be verified

These fields make the token part of the audit trail. They also let the harness detect mismatches. If the model tries to use a support-case draft token to send a customer message, the call fails before reaching the provider. If the token expired because the state changed, the agent must refresh evidence or escalate.

The token is a compact contract between intent and effect.

Capability Issuance Is a Gate

The most important control point is not the tool call. It is token issuance.

Before issuing authority, the harness can check the runbook, user role, source evidence, risk tier, current system state, prior approvals, and task identity. The model can ask for a capability, but the issuance gate decides whether the request is justified.

This creates a useful rhythm:

1. The model explains the action it wants to take.
2. The harness evaluates whether the action is allowed now.
3. A capability token is issued, denied, or routed for approval.
4. The tool executes only if the token matches the call.
5. Verification reads the resulting state.

That rhythm is more reliable than giving the model a powerful tool and asking it to self-police every condition.

Denial Should Be Informative

When a capability request is denied, the agent should learn why.

“Forbidden” is sometimes the right external message. Internally, the workflow needs more precision: missing evidence, expired approval, wrong owner, risk tier too high, resource locked, conflicting state, operation outside scope, or human review required.

Precise denials help the agent make the next responsible move. It can gather missing evidence, request approval, narrow the action, wait for a lock, or stop with a useful handoff.

This is how security becomes collaboration rather than a wall. The system does not merely block. It explains the condition under which the next step could become legitimate.

Tokens Support Safer Parallelism

Multi-agent systems create authority problems quickly.

Two agents may work on the same account. A planner may delegate to an executor. A reviewer may inspect output while another worker is still modifying it. Without scoped authority, it is difficult to know who can touch what and when.

Capability tokens can encode leases, resource locks, and operation identity. One worker may hold the write token for a file range or customer record. Others can hold read tokens. A reviewer can receive a token to inspect a frozen artifact rather than the live mutable object.

This reduces accidental interference and makes handoffs explicit. The question becomes “which capability was transferred?” rather than “which agent is in charge?”

Audit the Capability Trail

Agent observability should include capability events.

What did the model request? Which evidence supported issuance? Who approved it? Which token was used? What did the tool do? How was the effect verified? Which requests were denied?

This trail is often more useful than the raw transcript. It shows the boundary between reasoning and consequence. It lets reviewers see whether the system followed policy even when the model produced verbose intermediate text.

For high-consequence workflows, capability traces should become part of incident response and release evaluation. A model improvement that increases task completion while requesting broader authority may not be an improvement at all.

Design Capabilities Before Tools

Teams usually start by listing tools. Search, database, email, repository, browser, ticketing system. The list grows because every missing tool feels like a product limitation.

A capability-first design asks a narrower question: what effect should this workflow be allowed to produce?

Read account status. Draft a response. Attach a reviewed artifact. Create a pull request. Label a ticket. Request deployment approval. Each capability can then map to one or more underlying tools with consistent semantics.

This keeps the product boundary stable even when integrations change. The agent does not need to understand every provider permission. It receives the product capability that the workflow has earned.

Small Authority Makes Agents More Useful

Least privilege is often framed as a constraint. For agents, it is also an enabler.

When authority is narrow, teams can allow more automation with less fear. They can run agents in more workflows, collect better evidence, and expand responsibility one capability at a time. The system becomes easier to evaluate because each token represents a bounded promise.

The future of agent security will not be one enormous permission prompt. It will be many small, meaningful grants.

Capability tokens turn “can the agent use tools?” into a better question:

What exactly is this agent allowed to do, right now, for this task, based on this evidence?