MCP Authentication, Explained: Inbound Identity, Outbound Credentials, and Delegation

The token that identifies a caller to a gateway and the credential used to reach a downstream service solve different problems. Secure MCP systems preserve that distinction.

Authentication is not one hop

An MCP request can cross several trust boundaries before a business system sees it. A person or service authenticates to an application. An agent may act as a separate software principal. The client authenticates to MCP Gateway. The gateway decides whether that caller can use a server or tool. Then the gateway authenticates to the downstream MCP server, which may call another authoritative service.

Using the word “token” for every credential makes these boundaries disappear. The inbound credential answers who is calling the gateway. Access policy answers what gateway resources that identity may use. Outbound authentication determines whose credentials and permissions the downstream server receives. Those answers can be intentionally different.

TrueFoundry’s documentation separates the architecture into inbound authentication, access control, and outbound authentication. That separation is the right starting point for reasoning about delegation, attribution, and confused-deputy risk.

The gateway is intentionally split into three checks. Successful inbound authentication identifies a caller, but access policy still selects allowed tools and outbound authentication still determines the principal seen by the MCP server.

Inbound authentication resolves the gateway caller

TrueFoundry documents several inbound methods: a personal access token for users with TrueFoundry accounts, a virtual-account token for service-to-service callers, an identity-provider token for customers or services using an organization’s JWT issuer, and TrueFoundry OAuth for compatible IDE clients.

After validating the credential, the gateway resolves a TrueFoundry identity and applies access control to MCP servers and individual tools. The relevant identity may be a user, team, or virtual account. Agent Identity, documented as beta, adds a separate registered agent actor for agent-originated calls. That is different from a virtual account, which represents a service or application without a human behind it.

Identity resolution should validate issuer, audience, signature, time bounds, and the claim mapping used to select the subject. A validly signed token for the wrong audience is not authority for the gateway. Mappings should be specific enough that two services cannot accidentally resolve to the same agent identity.

Outbound authentication selects the downstream principal

The gateway may authenticate to an MCP server using per-user OAuth authorization code, application-level OAuth client credentials, the documented Okta token-exchange/OBO configuration, shared or individual API keys, no authentication for public services, token passthrough, token forwarding, or AWS SigV4 for supported AWS endpoints.

These modes encode different authority. Per-user OAuth lets each person authorize their own third-party account. Client credentials represent the application and usually expose shared service permissions. Token exchange or OBO asks an identity system to mint a downstream token derived from the caller’s identity and targeted to another audience. A shared API key collapses all callers onto one upstream principal even if the gateway preserves internal attribution.

Choosing the easiest integration can silently change the authorization model. If a Gmail MCP server uses one shared service credential, the upstream does not see each employee’s personal mailbox authority. If an internal MCP server validates the organization’s IdP token directly, passthrough may preserve the subject—but only if issuer, audience, and scopes are accepted deliberately.

The diagram groups modes by authority semantics rather than protocol labels. Per-user and OBO flows can preserve subject context, while client credentials and shared keys represent application authority unless the downstream service applies additional subject-aware controls.

Passthrough and forwarding are not synonyms

In TrueFoundry’s documented terminology, token passthrough forwards the same token used for inbound authentication to the MCP server. The server must be able to validate that TrueFoundry or identity-provider token. Token forwarding carries separate server-specific credentials supplied by the client in dedicated headers. The outbound credential is not the inbound bearer.

This distinction matters for logging, redaction, revocation, and threat modeling. Passthrough preserves one credential across the gateway boundary and therefore requires correct downstream audience trust. Forwarding introduces another secret that the client must obtain and protect. Neither automatically proves that a final business API saw the intended human and agent relationship.

OAuth token exchange and OBO provide a different pattern: the gateway or identity layer obtains a new audience-specific token representing delegated authority. That can reduce bearer-token reuse and let downstream systems enforce scopes designed for their resource. The exact guarantees depend on the identity provider, claims, validation, and downstream application.

Model the principals, not just the headers

Prevent the confused deputy

A gateway becomes a confused deputy when it has broad downstream authority and uses it for a caller that lacks equivalent permission. Inbound authentication can be perfectly valid while the composed action is still over-authorized. The gateway must join caller identity, agent identity, requested server and tool, outbound credential mode, and downstream scope.

For shared credentials, the MCP server or backing application should receive enough trusted context to reapply subject-aware authorization, or the tool must expose only resources safe for every allowed caller. Do not rely on the model to filter results after a broad query. For per-user credentials, verify that authorization is tied to the intended subject and cannot be substituted by another user through overrides.

Every hop should also preserve an audit correlation identifier without copying bearer tokens into logs. Record credential mode, resolved identity, issuer, audience, scope class, policy version, and downstream response metadata. Secret values belong in protected stores, not transcripts or traces.

The chain carries both a human subject and a software actor through the gateway decision. The outbound mode may preserve, exchange, or collapse that identity context; the downstream system still performs the final resource-and-action authorization.

A worked example: customer-support CRM access

A support agent receives a request from an authenticated employee. The application sends the employee’s identity-provider token to MCP Gateway and separately presents the registered agent identity. Gateway policy allows that user-agent pair to call the CRM search tool.

Assume the deployment uses TrueFoundry’s documented Okta OBO configuration. The gateway exchanges the inbound user token for a CRM-audience token with read-only case scope. The CRM validates the new token and applies its own row-level authorization. The agent can retrieve the employee’s permitted cases but cannot modify them. A separate update tool requires a narrower downstream scope and approval.

If the deployment instead uses a shared API key, the architecture must compensate. The CRM-facing service receives a trusted resolved-subject attribute from the gateway, validates it, and filters records server-side. If the service cannot enforce subject context, the shared key is unsuitable for data with user-specific authorization.

Choose outbound auth by authority semantics

• Use per-user authorization when the upstream resource is owned or permissioned by each person.
• Use client credentials for genuinely application-owned resources, not as a shortcut around user authorization.
• Use token exchange or OBO when the downstream needs a delegated, audience-specific user token.
• Use passthrough only when the downstream deliberately trusts and validates the inbound token.
• Use forwarding when the MCP server has a separate credential scheme and accept the resulting client secret-handling burden.
• Treat no-auth servers as public capabilities; do not place sensitive data or mutation behind them.

Failure tests for the auth chain

• Replay a valid token with the wrong audience, issuer, tenant, or mapped subject.
• Hold the user constant and change the agent identity; verify effective tool reach changes as designed.
• Hold the agent constant and change the user; verify downstream data follows the human subject where required.
• Substitute an individual credential through another user’s auth override.
• Revoke a gateway grant and an upstream OAuth grant independently; verify their different effects.
• Call the MCP server outside the gateway; verify network and server policy prevent a bypass when required.
• Inspect logs, traces, errors, and model context for leaked bearer tokens or forwarded secrets.

Credential lifecycle is part of the data path

Authentication design continues after a token is accepted. Credentials expire, refresh, rotate, and are revoked at different systems. TrueFoundry’s documentation notes, for example, that its “Revoke all tokens” action deletes stored credentials from AI Gateway but does not revoke grants at the upstream OAuth provider. Operators need separate procedures for the gateway credential, identity-provider session, upstream authorization, and any cached downstream token.

Define which component refreshes each credential, what subject the refreshed token represents, and what happens when refresh fails midway through an agent task. A paused authorization flow should not silently fall back to an application credential with broader access. When the user reconnects an account, the new grant should be correlated with the intended subject and server before the agent continues.

Rotation creates another test boundary. Shared API keys may need a dual-key period; per-user OAuth tokens may be invalidated independently; OBO tokens may be cached until expiry while the inbound token must remain current for re-exchange. Store credential-mode and token-family identifiers in protected operational metadata so responders can find affected calls without exposing secrets.

Revocation should be verified from the outside in. Remove the gateway collaborator, revoke the upstream grant, disable the downstream account, and test each effect separately. A complete incident procedure knows which action stops new gateway calls, which invalidates direct access, and which only deletes a local copy.

Token handling should also be absent from model-visible context. Agents can reason over stable identity labels, authorization outcomes, and reconnect instructions without receiving bearer material. Errors returned from providers should be normalized so debug output does not leak headers, refresh tokens, client secrets, or signed request components into the transcript.

The operational rule

Secure MCP authentication starts by naming every principal and hop. Inbound identity, gateway access, outbound credential, and business authorization are related but non-interchangeable controls. The safest design makes any change of principal or audience explicit.

TrueFoundry MCP Gateway provides documented mechanisms for each gateway-facing layer, and Agent Identity—documented as beta in the governance availability map—can distinguish the software actor from the human subject. The downstream application still owns its domain authorization and the organization still owns credential minimization. That boundary is not a limitation in the explanation; it is what makes the security model testable.

References

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

Editorial disclosure. This article reflects TrueFoundry’s engineering interpretation of the cited public materials as of September 17, 2026. Product capabilities are scoped to linked documentation. Examples and operating defaults are illustrative; they are not legal advice, an audit opinion, an independent benchmark, or a guarantee of security, safety, or compliance.

‍