Review Delegated Agent OAuth

An agent may act for a user through an MCP server, which then calls another API. Each hop needs a clear authority source. A user approving the first client does not automatically approve every downstream service or every operation the agent can imagine. OAuth scopes, token audiences, and resource-owner consent must line up with the actual action.

Map the chain from the human to the client, the MCP resource, and the upstream API. Record where a token is issued, where it is validated, and whether an exchange or separate service credential is used. The MCP authorization specification governs HTTP MCP authorization; OWASP's OAuth guidance covers the broader flow. Do not forward a token across audiences.

Delegation chain

The effective permission is the narrowest allowed action across the chain. If the upstream credential is broader than the user's grant, the MCP server must enforce the user's boundary before calling it. If the tool cannot identify the user, do not claim delegated access; call it a service action with its own review and limits.

Reconsent and denial tests

In an owned fixture, approve a read tool for one synthetic user and one upstream resource. Confirm an owned record is returned. Then try a write, a second resource, and another user's record. Each must fail before the upstream effect. Change the client identity or requested scope and require a new consent decision.

Test revocation timing. Remove the user's grant, then repeat the call with a still-unexpired client token. The server must check the current grant or use a documented short lifetime that meets the team's risk rule. Keep a trace of decisions, not raw bearer tokens. If a provider cannot express the needed delegation, use a narrower workflow rather than implying that OAuth alone makes the agent's actions authorized.