MCP OAuth Security
MCP Agent Identity & Delegation: OAuth Security Tests
Test the MCP OAuth boundaries the protocol already defines, then separately test your application's parent-to-child delegation policy. The runnable fixtures cover wrong audiences, token passthrough, scope escalation, revocation, and replay without presenting a custom grant format as an MCP standard.
TL;DR (October 2026):
- Model the human or tenant, parent agent, child agent, MCP client, MCP server, and downstream service as separate identities or trust decisions.
- The MCP Authorization Security Considerations require audience-bound tokens for the server and prohibit token passthrough to upstream APIs.
- Delegation must narrow authority. A child agent should not gain tools, resources, duration, or execution rights that its parent did not have.
- Test the final action at the point that holds the credential or performs the side effect. Identity evidence alone is not an allow decision.
- The MCP roadmap still describes agent identity and delegation as work to define. Do not treat a custom header or metadata field as a protocol-standard delegation proof.
Multi-agent systems turn one authorization question into a chain. A person may authorize an application. The application may ask a parent agent to plan work. That agent may delegate a subtask to a worker. The worker may call an MCP tool that reaches a database or external API. If the final server sees only a shared API key, it cannot infer who the original user was or what the child was allowed to do.
Separate the authorization layers
The current MCP authorization model is primarily a client-to-server boundary for HTTP-based authorization. Its security requirements include validating that an access token was issued for the MCP server that receives it. The server must not take the token received from the MCP client and pass it to an unrelated upstream API. The server should obtain a separate credential that is intended for the upstream resource.
That model is necessary, but it does not automatically describe every agent-to-agent relationship inside an application. Authentication answers which principal presented a credential. Delegation answers which authority that principal received from another principal and what limits apply. Tool authorization answers whether the requested action is allowed now. Execution enforcement ensures the exact authorized action is the one that reaches the credential or side effect.
Record these concepts separately:
- Human or tenant principal: the user or organization that owns the data or requested the work.
- Parent agent: the agent instance that received a task and may delegate a limited subtask.
- Child agent: the specific worker instance that makes a tool call. A model name or generic service account is not a unique agent identity.
- MCP client and server: the protocol participants and the OAuth relationship, where the HTTP authorization model applies.
- Downstream resource: the database or API whose data or state may be affected by the tool.
A single system may collapse some of these identities for operational reasons, but write down what has been collapsed and why. If every agent runs under one long-lived service credential, the server may see the application but not which agent or user initiated a particular action. That can be acceptable for a tightly scoped read-only service. It is a weak basis for high-impact actions across multiple tenants.
What is standardized and what remains application policy
The MCP specification's authorization guidance includes concrete requirements around OAuth tokens, resource indicators, audience validation, secure token handling, and preventing token passthrough. Those requirements govern a credential accepted by an MCP server. They do not mean that arbitrary fields such as agent name, parent ID, tenant ID, or delegation scope are automatically authenticated or enforced by the protocol.
The MCP maintainers' 2026 roadmap describes agent identity and enterprise security as an active area, including work on proof of possession, workload identity federation, ID-JAG, and token exchange. That is a direction of work, not a reason to assume that every deployed client and server already shares one stable delegation format. If your product adds custom claims or message metadata for a delegation chain, document the issuer, signature, lifetime, audience, revocation behavior, and fail-closed behavior yourself.
The current protocol authorization guide says servers must accept only tokens intended for the server, and must reject a token that is not audience-bound to it. It also says that when the MCP server calls an upstream API, the upstream access token is separate and must not simply be the token received from the MCP client. Test this boundary directly. A token valid for the MCP server should not become a universal credential for every service the agent can reach.
Design the permission chain to narrow
Start with an authorization record created by a trusted issuer. It should identify the requesting principal, the agent or workload that may act, the parent or delegator, the allowed tool set, the permitted resources or tenant, the time limit, and any required human approval. The record must be verifiable by the component that makes the final authorization decision. An unsigned JSON field supplied by the model or caller is only input, not proof.
When work moves to a child agent, the child should receive a subset of the parent's authority. A useful rule is monotonic attenuation: the child may have fewer tools, a narrower resource set, a lower cost ceiling, a shorter lifetime, or a stricter approval requirement, but it cannot remove a parent restriction. If the system cannot represent a delegated limit in a way the tool enforcement point understands, it should deny or require a human decision rather than silently broadening the request.
Bind permission to concrete invocation details when an operation can change state. At minimum, evaluate the identity, tool name, normalized arguments, target resource, tenant, current policy, and approval state. A child that was permitted to create one draft should not automatically be allowed to publish it, target another tenant, or alter the arguments after approval. If policy is evaluated in one component and execution happens in another, bind the decision to the exact call with a short-lived authorization record or a stable invocation identifier.
The enforcement point must control access to the real credential or side effect. A policy service that returns ALLOW is advisory if the agent can bypass it and call the database with an ambient credential. Keep credentials in a dispatcher or service boundary that requires an authorization decision. For high-impact operations, add a separate approval or confirmation step and verify the resulting state after execution.
Identity propagation test matrix
| Test | Safe test setup | Expected result |
|---|---|---|
| Missing identity | Call a protected tool without an authenticated user or workload identity. | The call is denied before a sensitive resource is read or changed. |
| Forged identity metadata | Send a client-controlled agent or tenant label that names a more privileged principal. | The server ignores the label for authorization or verifies it against a trusted signed identity. |
| Child scope widening | Give a parent a read-only test grant, then have a child request a write tool or broader resource. | The child is denied. Delegation cannot add authority absent from the parent grant. |
| Sibling substitution | Replay a request identity from one child agent in another child's session. | Identity proof is bound to the correct workload key, audience, and invocation context. |
| Argument change after approval | Approve a harmless test update, then change the target tenant or resource before execution. | The final enforcement point rejects the changed call or requires fresh authorization. |
| Wrong token audience | Present a test token intended for a different MCP server or upstream API. | The recipient rejects the token. Credentials are not accepted merely because they are signed by a familiar issuer. |
| Token passthrough | Inspect the outbound request to a test upstream API after an authenticated MCP call. | The MCP access token is not forwarded; the server obtains a separate token for the upstream resource. |
| Revocation and expiry | Revoke a parent grant or expire it between planning and tool execution. | The tool boundary re-checks validity and denies the stale child authority. |
| Replay | Replay a captured test proof against a different tool, argument set, server, or invocation. | The evidence cannot authorize the altered request or be consumed twice if the policy requires single use. |
| Bypass path | Attempt the same test operation through a direct database or API credential path. | The agent cannot reach the side effect without the policy enforcement point. |
| Audit reconstruction | Execute one denied and one approved test call across a parent-child chain. | The record joins user, parent, child, delegation, decision, tool call, downstream result, and effect. |
Use dedicated test principals and a disposable resource. The test should prove both sides of the decision: the denied call did not reach the side effect, and the allowed call used only the intended scope. For token audience and passthrough checks, capture request metadata in a test environment with secrets redacted. Never put production bearer tokens in a packet capture or article example.
Run the delegation regression fixtures
The runnable Python fixture exercises wrong-audience denial, parent-to-child scope escalation, revoked grants, single-use sensitive-operation replay, and separate downstream credentials. It uses only the Python standard library:
cd examples/mcp-delegation-tests
python3 -m unittest -vThis fixture is an application-policy example, not an MCP delegation protocol implementation. Its in-memory grants do not verify signatures or replace an OAuth authorization server. Use it to make your own policy invariants executable, then test the real token verifier and enforcement point in an isolated environment.
Make audit data useful without treating it as authorization
Log a correlation ID that survives the parent task, child invocation, MCP call, downstream request, and result. Record the verified identities and the policy decision reference, but do not store raw access tokens. Include enough detail to answer who initiated the work, which agent acted, what authority it received, which tool and resource were selected, what decision was made, and whether the intended effect occurred.
Audit evidence is valuable after the fact, but a log entry does not block an unauthorized operation. Likewise, a signed delegation chain can prove provenance and scope without proving that the exact operation is appropriate in the present context. Separate identity proof, policy decision, execution authorization, and effect verification. They should be linked for review but should not be mistaken for interchangeable controls.
Roll out safely
Inventory every agent that can invoke tools and every downstream credential it can use. Find shared service identities, long-lived tokens, implicit tenant context, and code paths where a child can call a service directly. Rank tools by impact. Start with read-only tools and synthetic tenants, then add high-impact tools only after their authorization boundary has negative tests and audit coverage.
When you change a delegation format or identity provider, test old and new tokens during the rollout. Decide how key rotation, parent-agent replacement, child-agent retirement, and policy revocation work. If a verifier cannot resolve a signing key or policy version, fail closed for sensitive operations and emit an actionable event. Provide a clear recovery process so operators can restore legitimate work without granting a blanket bypass.
Acceptance criterion: a reviewer can verify the caller and delegation chain, prove that each handoff narrowed authority, see a fresh policy decision bound to the actual tool and arguments, and confirm that the same boundary controlled the real side effect.
FAQ
- Does MCP standardize agent-to-agent delegation?
- The current authorization requirements cover key client-to-server token boundaries. As of October 2026, the MCP roadmap still describes agent identity and delegation as work to define. Treat custom delegation fields as application-specific until their semantics and enforcement are standardized and implemented across your clients and servers.
- Can an MCP server forward the client's access token to a downstream API?
- No. MCP authorization guidance says the server must accept tokens intended for itself and must not pass the token it received from the MCP client through to an upstream API. The server should obtain a separate credential for the upstream resource.
- Does a signed agent identity prove that a tool call is allowed?
- No. Identity can establish which workload is acting. A policy decision must still check the tool, arguments, tenant, resource, purpose, current authorization, and any required approval at the enforcement point.
Related reading
- NIST AI agent security controls for pentesting: identity, privilege boundaries, and incident response tests.
- Spring AI MCP server security: OAuth2 authentication, per-tool scopes, and tenant ownership checks in a concrete server.
- Amazon Bedrock AgentCore session isolation: a two-user test for binding runtime sessions to authenticated users.
- Auditing MCP servers in 2026: protocol-level server controls and a broader audit checklist.
- Tool poisoning and MCP attack paths: why tool metadata and outputs need their own trust checks.
The current MCP authorization rules are in the project's Authorization Security Considerations.