How should security teams handle third-party credentials in MCP-based agent workflows without exposing secrets to the client?

The safest pattern is to keep credential collection and token storage on the server, not inside the MCP client. Use browser-based OAuth or another trusted redirect flow, then let the server validate state, enforce scopes, and store the resulting token. That prevents token exfiltration, confused deputy issues, and client-side privilege escalation in multi-user production environments.

Why MCP credential handling has to stay server-side

In MCP-based agent workflows, third-party credentials should be treated as server-held trust material, not as something the client should ever see. The client can initiate consent and pass through a user-authenticated redirect, but the server should complete token exchange, validate state, and store the resulting credential. That keeps secrets out of the browser and limits the blast radius of a compromised client.

When teams push tokens into the client layer, they usually inherit three failures at once: secret exposure, scope confusion, and weak separation between user intent and tool access. Browser storage, logs, extensions, and injected scripts all become potential leakage points, while the server loses the ability to enforce a single policy boundary for third-party access.

For agent workflows, that boundary matters even more because the agent may act on behalf of a user across multiple tools. If the client can see the third-party token, a stolen session or malicious extension can turn a convenience pattern into delegated access abuse. A server-side pattern preserves the distinction between authentication, consent, and downstream authorization.

How the OAuth handoff should be structured

The safest implementation is a trusted redirect flow, usually browser-based OAuth, where the user authenticates with the third party and the server receives the callback. The server should verify the state parameter, exchange the authorization code, scope the token as narrowly as possible, and keep the credential in a protected backend store. If the workflow needs ongoing access, refresh handling should also remain server-managed.

This design is especially important when an MCP server is serving more than one user or tenant. The server must bind each credential to the correct user context, distinguish per-user grants from shared service access, and reject any attempt to reuse a token outside its intended audience. That prevents one agent session from becoming a universal credential cache.

For additional implementation detail, the Model Context Protocol authorization specification and the OAuth 2.0 Authorization Framework both support a server-mediated model rather than token passthrough to the client.

What breaks when credentials leak into the client path

Client-side token handling creates a confused deputy problem because the interface that asks for consent is no longer cleanly separated from the component that can spend the credential. In practice, that can let an attacker reuse a token outside the user’s intended action, especially when the workflow includes multiple plugins, tabs, or agent tools with different trust levels.

It also weakens incident response. If the credential is exposed to the client, teams often cannot reliably tell whether the token was merely observed, copied into logs, or actively replayed. By contrast, server-side storage allows revocation, audit, and scope review from one control point, which is far easier to manage when a third-party integration has to be shut off quickly.

For related credential abuse patterns, the API Key Management Guide, the Secrets Management Guide, and the Guide to the Secret Sprawl Challenge all reinforce the same operational lesson: credentials are safest when they are centralised, scoped, and rotated outside the client surface.

Risk and Threat Considerations

Third-party credentials in MCP workflows are attractive to attackers because they often unlock real business systems, not just a single tool. If a client can access the token, so can browser malware, malicious extensions, session hijackers, or anyone who gains foothold on the endpoint. In multi-user environments, that can quickly turn one exposed token into cross-account data access.

Failure mechanism: the client becomes an unintended credential broker, so token theft, replay, or misuse can occur before the MCP server can enforce scope, audience, or revocation.

Impact: attackers may obtain delegated access to third-party SaaS, perform actions as the user or agent, and persist until the token is rotated or revoked, which can expand both data exposure and operational blast radius.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API2 — Broken Authentication	MCP token handling depends on secure auth handoff and token use
Recommendation — Keep bearer tokens server-side and validate OAuth state before exchanging or storing them.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	The question centers on issuing, storing, and rotating third-party credentials safely
	AC-6 — Least Privilege	Server-side scoping is needed to limit what third-party credentials can do
Recommendation — Manage credential lifecycle on the server and revoke exposed tokens immediately. Restrict each third-party token to the minimum scopes required for the workflow.
ISO/IEC 27001:2022	A.5.17 — Authentication information	OAuth tokens and secrets are authentication information that must be protected
Recommendation — Protect authentication information from client exposure and unintended disclosure.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	The core risk is exposing third-party credentials to the client
Recommendation — Keep secrets out of the client path and centralize storage and rotation on the server.

Practitioner Guidance

What to prioritise: keep the token exchange and secret storage on the server boundary first, then audit whether any client component still receives bearer material, even temporarily. If the client can inspect it in memory, local storage, logs, or a callback handler, the design is still too exposed.

What to verify: confirm that state validation, audience binding, scope enforcement, and revocation all happen server-side, and that each credential is tied to a specific user or tenant context. For production agent workflows, also verify that refresh tokens are never forwarded to the client as a shortcut.

Common mistake: treating the browser as a harmless handoff layer. In MCP systems, the browser is part of the attack surface, so any secret placed there should be assumed retrievable by the user environment unless it is strictly ephemeral and never reusable.

Practitioner takeaway: the right control objective is not “hide the token better in the client,” but “design the workflow so the client never needs possession of the token at all.”