MCP OAuth Token Security: Preventing Credential Theft

Your MCP server is holding OAuth tokens for Google Workspace, GitHub, Slack, and Jira at the same time. That is the new high-value target in AI agent security: not a single credential, but a credential aggregator.

The Model Context Protocol has become the standard integration layer for enterprise AI agents. But MCP OAuth token security has not kept pace with adoption. Only 8.5% of MCP servers implement OAuth at all. The other 91.5% rely on static API keys or long-lived personal access tokens that never expire, never rotate, and carry far more access than any single task requires. This guide covers why MCP creates a credential concentration risk, how attackers exploit OAuth flows in MCP deployments, and the specific controls that reduce that risk.

Why MCP Creates an OAuth Single Point of Failure

Traditional OAuth security is scoped to one service. You authenticate to GitHub, receive a GitHub token, and that token is bounded to GitHub. If it is stolen, the attacker has GitHub access and nothing else.

MCP changes this architecture fundamentally. An MCP server acts as a credential broker. It holds active OAuth tokens for every service it connects to: Google Workspace, GitHub, Jira, Slack, internal APIs, databases. When an AI agent asks the MCP server to perform a task, the server presents the appropriate credential for each downstream service. This creates operational efficiency. It also creates a single point of failure that no traditional OAuth security model was designed to address.

Compromise one MCP server and you gain:

• Every OAuth token the server holds for every connected service
• The ability to make authenticated API calls against all those services simultaneously
• In multi-agent pipelines, potential lateral movement to other agents sharing the same credential store
• Persistent access for as long as any token remains valid, which for static API keys is indefinitely

The risk is not theoretical. Research by Astrix Security found that 53% of MCP implementations use static API keys or long-lived personal access tokens rather than OAuth. Those tokens carry indefinite access until manually revoked. A successful attack against one such server provides persistent, multi-service access with no expiration clock.

This credential aggregation pattern is what the OWASP MCP Top 10 classifies as MCP01: Token Mismanagement, the highest-severity category in the framework. It is the root condition that makes every other MCP attack class more damaging: tool poisoning has more impact when the compromised agent holds tokens for twelve services rather than one.

Three Attack Patterns Against MCP OAuth Credentials

Understanding how attackers actually exploit MCP OAuth helps prioritize the right defenses. Three patterns dominate current threat intelligence.

Pattern 1: OAuth Flow Interception (CVE-2025-6514)

The mcp-remote proxy package, with over 437,000 downloads, contained a critical vulnerability (CVSS 9.6) that allowed token theft during the authentication handshake itself. By controlling or injecting a malicious authorization_endpoint, an attacker could redirect the OAuth token exchange to an attacker-controlled server, capturing access tokens and refresh tokens before the legitimate MCP session was established.

This attack requires no post-authentication activity and produces no tool call logs. From the agent's perspective, the authentication attempt simply failed. From the attacker's perspective, the token was captured cleanly.

The affected packages include clients used with Cloudflare, Hugging Face, and Auth0 MCP integrations. The vulnerability has been patched, but it demonstrated that the OAuth flow itself is an attack surface in MCP, a surface that PKCE is specifically designed to close.

Pattern 2: Supply Chain Credential Harvesting

In early 2026, the Sandworm_Mode campaign targeted AI coding assistants through npm typosquatting. Malicious packages mimicking popular utilities installed rogue MCP servers that exfiltrated SSH keys, AWS credentials, npm tokens, and OAuth refresh tokens through prompt injection into Claude Code, Cursor, and Windsurf. The attack worked because MCP clients loaded the rogue server automatically on startup, granting it MCP session access before any approval flow ran.

This mirrors the pattern from the LiteLLM supply chain compromise of March 2026, where compromised PyPI publish credentials allowed attackers to upload malicious packages (v1.82.7 and v1.82.8) containing credential harvesters that hit 119,000 downloads in 40 minutes. In MCP deployments, the analogous risk is a compromised package that either installs a rogue MCP server or modifies a legitimate server to exfiltrate the OAuth tokens it holds.

The defense is not purely technical: vetting MCP server packages before installation, pinning dependencies by cryptographic hash, and monitoring for unexpected new packages in agent startup configurations all reduce supply chain exposure.

Pattern 3: Long-Lived Session Token Abuse

MCP sessions are often long-lived. A session started at the beginning of a workday may carry the same OAuth tokens through multiple workflows, tools, and agent handoffs. In multi-agent pipelines, those sessions can be shared across tool invocations with no re-authentication.

Attackers who gain a foothold in a running MCP process through tool poisoning or prompt injection do not need to steal credentials directly. They can use the existing session tokens to call downstream services as the legitimate agent. The API calls originate from the correct service account, they carry valid tokens, and they pass authentication controls that would block a stolen credential arriving from a new IP or user-agent string.

This is why session token lifetime matters as much as credential storage. A 15-minute access token limits what an attacker can do before it expires. A token with no expiration provides unlimited time to exploit the access.

OAuth Scope Minimization for Common MCP Integrations

The most effective single control for MCP OAuth security is scope minimization: grant each MCP server only the specific OAuth permissions required for the tools it exposes. This limits the impact of any credential theft to the minimum set of actions the stolen token can authorize.

Google Workspace

Use service accounts with domain-wide delegation rather than user OAuth tokens. Each MCP server should have a dedicated service account scoped to the minimum required APIs:

• Document reading only: https://www.googleapis.com/auth/documents.readonly
• Calendar read access: https://www.googleapis.com/auth/calendar.readonly
• Gmail sending: https://www.googleapis.com/auth/gmail.send

Never grant https://www.googleapis.com/auth/drive (full Drive access) when the tool only reads specific files. Never share a service account key across multiple MCP servers. Separate service accounts for separate servers means a compromise of one server does not automatically expose Google Workspace access from other servers.

GitHub

Use fine-grained personal access tokens (PATs) rather than classic PATs or OAuth Apps with broad repository permissions:

• Scope to specific repositories rather than all repositories
• Grant contents:read rather than the broad repo scope where write access is not required
• Set explicit expiration dates, 30 days maximum for production MCP integrations
• Use actions:read only if the tool reads workflow status; never grant actions:write without explicit justification

Slack

Use Slack App tokens with event subscriptions rather than OAuth tokens with full workspace access:

• channels:read instead of channels:history unless message history is required
• chat:write scoped to specific channels rather than workspace-wide posting
• users:read.email only if the tool needs to resolve user identities by email

Jira

Use project-scoped API tokens rather than global Jira access:

• Scope to specific projects rather than organization-wide Jira access
• Read-only access for search and issue retrieval tools
• Separate tokens for read operations versus write operations; a search tool should never hold create or delete permissions

The underlying principle is the same across all integrations: a tool that reads documents should not hold tokens that can delete them. The principle of least privilege applied to AI agents extends to OAuth scope level, not just to what the agent is instructed to do. Scope minimization limits the damage when the agent is compromised or manipulated into calling a service it should not reach.

Short-Lived Token Architecture for MCP

Static credentials are the wrong foundation for MCP OAuth security. The architecture that actually reduces credential theft risk combines three controls: PKCE for authorization flows, refresh token rotation, and vault-backed credential storage.

PKCE for Authorization Code Flows

PKCE (Proof Key for Code Exchange, RFC 7636) prevents authorization code interception by requiring the client to prove possession of a secret generated at the start of the flow. The implementation for MCP clients is straightforward:

Before initiating the OAuth flow, generate a cryptographically random code_verifier (43-128 characters from a high-entropy source)

Compute code_challenge = BASE64URL(SHA256(code_verifier))

Send code_challenge and code_challenge_method=S256 in the authorization request

When exchanging the authorization code for tokens, include the original code_verifier

The authorization server verifies that SHA256(code_verifier) matches the stored code_challenge before issuing tokens

An attacker who intercepts the authorization code without the code_verifier cannot exchange it for tokens. The code alone is worthless. This directly closes the CVE-2025-6514 attack surface for any MCP implementation using Authorization Code flows.

Refresh Token Rotation

Configure OAuth clients to rotate refresh tokens on every use. Each time a refresh token is exchanged for a new access token, the authorization server issues a new refresh token and invalidates the previous one. If a refresh token is stolen and used by an attacker, the legitimate client's next refresh attempt will fail with an invalid_grant error, triggering detection.

Access tokens should have TTLs of 15 minutes or less for production MCP integrations handling sensitive data. Refresh tokens should expire within 24 hours for most enterprise workflows. For integrations touching financial systems, HR data, or code deployment pipelines, implement just-in-time (JIT) access: tokens issued for a single task invocation and revoked immediately upon task completion, regardless of expiry time.

Vault-Backed Credential Storage

Store MCP server OAuth credentials in a dedicated secrets management system rather than environment variables, configuration files, or hardcoded values:

• HashiCorp Vault with dynamic secrets generates short-lived credentials on demand; the MCP server never stores a long-lived credential
• AWS Secrets Manager with automatic rotation handles scheduled credential renewal without manual intervention
• Google Secret Manager with IAM-based access control prevents unauthorized reads by other processes on the same host
• Azure Key Vault with managed identities eliminates the credential bootstrapping problem: the MCP server authenticates to the vault using its Azure managed identity, which has no static credential to steal

For environments running multiple MCP servers, use per-server vault namespaces or separate vault paths with distinct access policies. If one MCP server is compromised, its vault access should not provide a path to credentials for any other server.

Detecting OAuth Token Abuse in Agent Pipelines

Signature-based detection does not catch OAuth token abuse in agentic pipelines. The tokens are legitimate. The API calls are authenticated. The accounts exist. Standard SIEM rules built for human user behavior generate excessive noise on agent activity. Detection requires behavioral baselines built specifically for agent patterns.

Establish Per-Agent Baselines

For each agent service account and associated OAuth client, document the expected behavioral envelope:

• Which OAuth scopes are used, at what frequency, for which operations
• Time-of-day patterns for API activity (many agents run only during business hours)
• Source VPC, IP range, or private endpoint for API calls
• Typical token request rates and refresh cycles per hour
• Which downstream services the agent contacts and in what sequence

This baseline is the reference against which deviations are measured. Without it, distinguishing a compromised agent from an agent handling a large batch is guesswork.

Alert Thresholds

Flag these patterns for immediate investigation:

• Any OAuth scope used that is not in the documented baseline, a new scope appearing in token usage
• API call volume exceeding 5x the hourly baseline for any service
• Token used from a source IP outside the agent's expected network range
• Off-hours activity from an agent with documented business-hours patterns
• Cross-service access chains not observed before: a GitHub token used immediately before a Slack message to an external workspace
• Refresh token rotation failures, which indicate a stolen refresh token was used before the legitimate client could use it

Log Sources and SIEM Integration

Route MCP OAuth events to your SIEM from four sources:

Authorization server token issuance logs: capture token creation, scope, client ID, and expiry for every token issued

Service-level API logs from Google, GitHub, Slack, Jira, and internal services: correlate API calls to specific OAuth tokens

Vault audit logs: record which MCP server retrieved which credential and at what time

Agent runtime logs: capture each tool call with the OAuth scope used

The MITRE ATLAS framework provides the threat vocabulary for agentic credential abuse. Map detection rules to AML.T0054 (LLM Prompt Injection, which can trigger unauthorized OAuth operations), AML.TA0015 (Command and Control for AI agents), and the standard ATT&CK T1528 (Steal Application Access Token) for OAuth-specific token theft patterns.

For MCP-specific tool change detection, compute SHA-256 hashes of complete tool definitions including parameter schemas and store them as baselines. Any tool definition change that touches OAuth-related parameters, authorization flows, or callback URLs should trigger a security review before the new definition is accepted.

Enterprise MCP Credential Governance Checklist

Technical controls require operational governance to remain effective. This checklist maps to NIST SP 800-53 access control (AC) and identification and authentication (IA) control families. A "yes" to every item means your MCP OAuth posture is defensible. Each "no" is a risk to address.

Inventory and Ownership

• [ ] Complete NHI inventory including all MCP server OAuth clients and service accounts
• [ ] Every MCP server credential has an assigned owner responsible for rotation and scope review
• [ ] MCP server inventory reviewed quarterly; decommissioned server credentials revoked within 24 hours of retirement

Scope and Privilege

• [ ] Each MCP server OAuth client holds only the minimum scopes documented in a credential register
• [ ] No OAuth tokens shared across multiple MCP servers
• [ ] Read-only tokens used wherever write access is not required for the deployed tools
• [ ] Static API key migration timeline in place with a target completion date

Token Lifecycle

• [ ] Access token TTL set to 15 minutes or less for production integrations handling sensitive data
• [ ] Refresh token rotation enabled and tested: a used refresh token is invalidated before the new one is issued
• [ ] JIT access implemented for high-privilege operations (financial systems, HR data, code deployment)
• [ ] Vault-backed credential storage configured for all production MCP servers

Detection and Response

• [ ] Behavioral baselines documented per agent service account, covering scope usage, call frequency, and source patterns
• [ ] Alerting configured for out-of-baseline OAuth scope usage and token volume anomalies
• [ ] Refresh token rotation failures trigger immediate automated alert
• [ ] MCP credential revocation is the documented first step in the AI incident response procedure

Review Cycle

• [ ] Monthly: Rotate all MCP OAuth credentials; compare scope usage logs against documented baselines
• [ ] Quarterly: Full NHI audit; remove unused or zombie credentials; verify scope grants match current tool requirements
• [ ] On personnel change: Revoke MCP server credentials that were under the departing team member's ownership immediately

For a structured assessment of your current MCP credential posture, BeyondScale's AI security assessment covers OAuth architecture review, scope analysis, token lifecycle controls, and behavioral baseline implementation across your MCP deployment.

Conclusion

MCP OAuth token security is not a future concern. CVE-2025-6514 demonstrated that tokens can be stolen during the authentication flow itself, before a single tool call is made or logged. The Sandworm_Mode supply chain campaign showed that attackers specifically target MCP credential stores through package compromise. And the architecture of MCP, aggregating multiple service credentials into a single server process, means that a single breach produces multi-service access that no traditional OAuth security model was designed to contain.

The technical controls are available: PKCE per RFC 7636, short-lived tokens with rotation, vault-backed storage, and behavioral detection built on agent-specific baselines. The gap is implementation. With 53% of MCP servers still relying on static credentials and only 8.5% implementing OAuth at all, most enterprise deployments are one misconfigured server away from a credential sprawl incident that spans a dozen services simultaneously.

MCP OAuth token security starts with inventory: know exactly what credentials your MCP servers hold, what scopes they carry, and when they expire. Scope them to minimum required access. Set them to expire. Rotate them automatically. Monitor for deviations from baseline behavior. Contact BeyondScale to assess your current MCP credential architecture and identify the highest-risk exposures before they are exploited.