A token should know where it is going

Agents make credentials travel. A user authorizes a client, the client calls a tool server, the server consults an upstream API, and another service may complete the work. The shortest implementation is to pass one token along the chain. It is also the implementation that erases where authority was supposed to stop.

OAuth has a direct answer to part of this problem. RFC 8707 Resource Indicators lets a client name the protected resource for which it requests access. The authorization server can then issue a token whose audience is restricted to that resource. A token obtained for one destination should fail at another.

This is more than a token-format detail. It is a statement about delegation: permission is not a substance that flows unchanged through the network. It is a relationship among a principal, a client, a resource, a scope, and a time. Change the destination and the relationship must be evaluated again.

Passthrough turns a boundary into a corridor

A tool server often sits between an agent client and an existing API. If it forwards the client's token upstream, the upstream service may accept authority that was issued for the intermediary. The intermediary also loses the ability to distinguish its own policy decision from the caller's possession of a credential.

The current MCP authorization specification forbids this token-passthrough pattern. An MCP server must validate that an incoming token was issued for itself. When it calls an upstream API, it acts as a separate client and uses a separate token issued for that upstream resource.

That requirement creates an evidentiary seam. The inbound call says the client was permitted to ask the MCP server for something. The outbound call says the MCP server was permitted to ask the upstream API for something. The server's policy connects the two. Without separate credentials, the connection is implicit and later review cannot tell whether the intermediary narrowed, expanded, or merely relayed authority.

A delegated token should become less useful as it moves away from the resource that justified its issuance.

Audience restriction also limits theft. A logged or intercepted bearer token remains dangerous, but its usefulness is bounded by the audience that will accept it and the scopes encoded or associated with it. The ideal token is short-lived, narrowly scoped, and cryptographically or operationally useless to every service except the intended one.

Discovery must not choose authority silently

RFC 9728 Protected Resource Metadata gives resources a standard way to publish their identifier, supported scopes, authorization servers, and related metadata. The MCP specification uses this mechanism so clients can discover how a protected server expects authorization to occur.

Discovery improves interoperability, but it creates a decision point. A resource may advertise multiple authorization servers. Metadata can be cached. Signed metadata may identify its issuer, while unsigned fields still arrive over HTTPS. The client must decide which authority it trusts to issue a credential for the resource and must verify that the returned resource identifier exactly matches the one it queried.

The record should preserve that choice. Which protected-resource metadata was retrieved? Which authorization server was selected? Which resource indicator and scopes were requested? Which audience was present when the server accepted the token? These facts explain the authority chain more precisely than “OAuth succeeded.”

Incremental consent deserves the same specificity. MCP's November 2025 revision added scope guidance through authentication challenges so clients can request additional access when an operation requires it. A step-up should attach to the operation that justified it. Otherwise a narrow need can become a broad credential that remains available to unrelated later tasks.

Make every hop issue its own account

A multi-service agent action should be reconstructable hop by hop. At each boundary, record the calling identity, target resource, requested operation, scopes, policy decision, credential audience, and result. Link the records with task and causation identifiers, but do not merge them into one undifferentiated success.

The negative cases matter. A rejected token shows that a boundary worked. A challenge for a narrower or broader scope shows that the service did not silently reinterpret existing authority. A downstream token request that was never made can establish that an intermediary stopped before propagation. Logging only accepted calls rewards the happy path and erases the controls that constrained it.

Credential caches need explicit ownership too. Reusing a correctly audience-bound token can be efficient, but reuse must not outlive the user's delegation, the task's purpose, or a policy change. The record should show whether a token was newly issued or reused and what revocation signal the cache honored. Otherwise short token lifetimes can coexist with effectively long-lived power.

This reveals where power changed. The user may authorize the agent client to access a tool. The tool may be authorized to query a database. The database may return rows filtered by its own policy. Each service can say what it accepted and what it refused. No participant has to pretend that the original user token directly authorized every downstream act.

The approach also improves revocation and incident containment. A resource can reject its own audience without invalidating unrelated tokens. An intermediary can lose upstream access while remaining available for harmless operations. A compromised client token cannot automatically impersonate the intermediary to every API it knows.

Agent protocols make new paths possible. Audience-bound credentials keep those paths from becoming tunnels through the institution's authority boundaries. The token should know where it is going because every service along the way must know where its responsibility begins.

— Dispatches · Summit Cognitive