MCP tokens need an audience
MCP tokens need an audience because one token can cross too many boundaries when every server accepts it. The MCP authorization specification points token checks at the resource server that receives the request. AgentTrust ID uses workload identity, sender-constrained requests, sessions, and action checks to keep runtime authority tied to the right agent and server.
The MCP security best practices call out token passthrough and confused-deputy risks. The same issue appears in agent systems when a tool server forwards a credential to another service without a fresh authorization decision.
Token audience
A token audience says which resource is allowed to accept the token.
For MCP, that resource is the MCP server or protected resource receiving the request. The server validates issuer, expiry, scope, and audience before it accepts the credential.
Audience binding keeps a token from becoming a general-purpose pass. It gives each server a way to reject a token that was issued for a different boundary.
How token passthrough happens
Token passthrough happens when one service receives a token and forwards it to another service as if the second service had issued or expected it.
That creates a confused-deputy path. The downstream service may treat the token as proof of a user, agent, or scope that was never meant for that service.
Agents make this easier to miss because tool calls can chain. One tool reads a document. A second tool sends a message. A third tool opens a ticket. If the same bearer credential follows each hop, the audit trail loses the boundary between those actions.
Example
A support agent calls an MCP server for ticket search. The ticket server receives a token with an audience for mcp://tickets.
The agent later asks a mail server to send a summary. The mail server needs a token for mcp://mail, plus an action check for email.send.
The second server gets a separate authorization decision. It records a separate action. The ticket-search token stays tied to the ticket server.
Business impact
Token passthrough makes incident review harder. A team may see that a token was accepted, while the useful question is which agent used it, which server accepted it, and which action ran.
Audience checks reduce that ambiguity. They make each service prove that the token was meant for that service.
They also reduce blast radius. A leaked token for one MCP server has less room to move when other servers reject its audience.
Prevention
Bind tokens to the server that accepts them. Validate issuer, expiry, scope, audience, and proof-of-possession where required.
Use separate credentials for separate resource servers. Avoid forwarding a token from one tool server to another.
Record the action after authentication. A valid token identifies a caller. The runtime still needs to decide whether this agent can take this action in this session.
Solving this with AgentTrust ID
AgentTrust ID separates identity proof from action authorization.
WIMSE workload identity proves which workload is calling. DPoP-bound runtime requests tie a request to the agent's key when sender-constrained tokens are required. Sessions carry source, mode, scope ceiling, approval state, and expiry.
The action check then evaluates the requested tool and effect. That keeps MCP authentication, agent identity, and per-action authorization in the same runtime path.
To keep MCP token use tied to the right server and action, start with the SDK guide. To talk through MCP authorization for your tool servers, join the waitlist.