A proxy can authenticate correctly to an upstream provider and still misuse that authority for a downstream client. The interesting question is not whether the proxy holds a valid token. It is whether the requesting client, user, resource, and downstream grant are bound together in a way that preserves consent and scope.
MCP makes this boundary especially important because a server may expose convenient tools over several third-party services. To the agent, the result looks like one tool surface. Underneath, separate authorization servers, account connections, and token audiences may be involved. An implementation that flattens those distinctions can create authority that nobody intended to delegate.
Established behavior and the threat hypothesis
The MCP security guidance describes a confused-deputy risk in proxy authorization flows, including interactions between a shared upstream client, downstream client registration, and reused consent [1]. The MCP authorization specification separately defines how protected resources and access tokens participate in the protocol [2]. These are implementation obligations, not evidence that every proxy has the same weakness.
Our hypothesis is operational: a deployment becomes difficult to defend when the consent record and execution binding are less specific than the capability exposed through the proxy. The attacker benefits when approval for one client or account can be reused for a different client, resource, or connection.
This risk is distinct from a model following malicious instructions. A prompt may initiate the path, but OAuth flow handling, token validation, and connection ownership are deterministic security boundaries. They should remain correct even if the agent chooses the worst possible request.
Preconditions for the illustrative scenario
Assume an MCP proxy can access an organization's document provider through a shared application registration. Several MCP clients connect to the proxy. Users have already authorized ordinary access, and the proxy stores provider connections for later use. An attacker can introduce a new downstream client or influence a request to select an unintended connection.
The attacker does not need to break token cryptography in this scenario. The failure would be a missing relationship check: consent associated with one client is accepted for another, a provider token is accepted in the wrong audience, or a connection identifier is resolved without checking tenant ownership.
Each precondition matters. A server that enforces exact client binding and connection ownership does not become vulnerable merely because it proxies an API. A server using a different authorization model requires a separate analysis. Avoid turning an architectural pattern into an unsupported product accusation.
Follow the authority transition
At the first boundary, the MCP service authenticates the caller and resolves the intended protected resource. At the second, it determines which downstream client and user have consented to which capability. At the third, it selects the provider account and invokes an API operation under that connection.
The security property is continuity: the identity checked at the first boundary must remain associated with the consent and account used at the last. Trusted server-side state should establish this relationship. Tool arguments, display names, and model-generated organization labels are insufficient substitutes.
Reject a provider token presented as though it authenticated the caller to an unrelated MCP resource. Keep the caller's access token and the downstream provider credential conceptually and operationally separate. Validity at one service does not imply validity at another.
| Boundary | Required binding | Suspicious observation |
|---|---|---|
| Client to MCP resource | Issuer, audience, caller, resource | Token accepted for an unintended resource |
| Consent to downstream client | User, client, requested capability | New client inherits unrelated consent |
| Agent to provider connection | Tenant, agent grant, provider account | Connection substitution crosses an owner boundary |
| Decision to dispatch | Normalized action and policy revision | Executed account differs from reviewed account |
Telemetry that can support an investigation
Log stable client, user, tenant, resource, connection, and policy identifiers with the authorization outcome. Record requested and granted scopes without token values. Preserve the provider account used for execution and its request identifier where available.
Useful detections include a newly introduced client using an established connection, a connection selected outside the agent's normal binding, unexpected scope expansion after reconnect, and mismatches between reviewed and executed account identity. These are investigation leads, not proof of exploitation. Legitimate onboarding and administrative migrations can produce similar patterns.
Avoid logging raw authorization codes, access tokens, refresh tokens, or full sensitive callback URLs. Evidence should let an analyst trace authority without creating a credential repository in the logging platform. Protect the consent and connection audit trail from ordinary workload edits.
Proposed validation cases
Use dedicated test accounts and clients. Establish a legitimate connection, then introduce a second client with no consent record. Confirm that the second client cannot reuse the first client's approval. Change the redirect target and verify that registration and callback validation reject the mismatch.
Present tokens intended for a different protected resource and confirm rejection. Attempt to reference a connection owned by another tenant and another agent in the same tenant. Test revoked connections, changed provider accounts after reconnect, and scope expansion that exceeds the approved grant.
At dispatch, compare the actual provider account and operation with the normalized request that policy evaluated. A proxy returning an authorization error is not enough if a background task still reaches the provider. Inspect the provider audit fixture to establish whether any effect occurred.
These cases are proposed assurance checks, not reported experiment results. Passing them supports the tested implementation and configuration. It does not prove immunity to all authorization flaws, registration variants, or provider-specific behavior.
Mitigation priorities and limits
First preserve identity and resource boundaries in the OAuth implementation. Then bind per-client consent and connection selection to authenticated ownership. Finally enforce the business action independently: an authorized connection does not automatically authorize bulk export, a new destination, or a privileged change.
Use well-maintained OAuth components and evaluate their integration points against RFC 9700 [3]. Keep policy decisions outside model-generated text. A language-model detector may help identify a malicious instruction, but it cannot repair a missing audience check or tenant-binding defect.
The broader conclusion is a design requirement: a proxy must carry the reason it has authority all the way to the resource it changes. When that chain is explicit, consent, agent policy, and execution can be reviewed together. When it is implicit, a valid token can become the wrong answer to the authorization question.