Claude Code MCP traffic hijack exposes OAuth token governance gaps

At a glance

What this is: This is an analysis of how Claude Code MCP traffic can be hijacked through a local configuration file to steal OAuth tokens and hide the theft inside legitimate provider logs.

Why it matters: It matters because MCP-delegated credentials behave like unmanaged NHI assets, so IAM, PAM and access review programmes need visibility into where tokens live, how they route, and whether they can be revoked before use.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read Unosecur’s analysis of Claude Code MCP traffic hijacking and OAuth token theft

Context

Claude Code’s MCP flow shows how a local configuration file can become an identity control plane when it stores both credentials and the routing rules that determine where those credentials are sent. In practice, that turns a developer workstation into part of the trust boundary for OAuth delegation, even though most IAM programmes do not model it that way.

The governance gap is not just secret exposure. It is the absence of separation between token storage, endpoint trust, and lifecycle control, which means a change to one can silently alter the others. For NHI teams, that is the same class of problem that appears whenever credentials exist outside inventories, reviews, and revocation workflows.

Key questions

Q: How should security teams handle MCP-delegated OAuth tokens in developer tools?

A: Treat them as governed non-human identities, not as hidden configuration. That means inventorying every token, tying it to a clear owner and purpose, limiting scope to the minimum necessary, and ensuring revocation is possible before the next refresh cycle. If the token cannot be found, reviewed and revoked, it is already outside governance.

Q: Why do MCP integrations complicate enterprise access control?

A: MCP integrations complicate access control because they create many new tool connections that each need a clear identity, scope, and audit trail. Without those bindings, an agent can inherit broad access through a single connector. That turns a protocol convenience into a governance issue and increases the chance of privilege drift.

Q: What breaks when credential storage and endpoint routing share the same file?

A: A single local change can compromise both the token and the path it follows, so integrity and confidentiality fail together. That makes the file itself part of the trust boundary. Once routing can be rewritten without validation, the credential can be delivered to an attacker without any authentication failure.

Q: Who is accountable when a stolen MCP token is replayed through a trusted SaaS origin?

A: Accountability sits with the team that governed the delegation path, not just the SaaS provider. If the token was stored locally, never reviewed and never separated from routing controls, then the identity programme failed before the replay happened. Downstream logs may look clean, but governance still owns the exposure.

Technical breakdown

How MCP routing becomes an OAuth delegation layer

Model Context Protocol is designed to connect an AI-enabled client to tools and data sources, but in this workflow it also becomes the path through which OAuth bearer tokens are issued and reused. When the local configuration file holds both the mcpServers endpoints and the token material, the client trusts whatever URL is present at runtime. A malicious change to that file does not need to break authentication. It only needs to redirect the flow so the token passes through an attacker-controlled proxy before reaching the real service.

Practical implication: treat MCP endpoint configuration as identity-sensitive control data, not as ordinary developer preferences.

Why plaintext local storage breaks credential governance

Storing bearer tokens, refresh tokens, trust flags and routing instructions in one plaintext file removes the boundary between credential secrecy and routing integrity. That is a structural weakness because the same write operation can alter both where the token goes and who can renew it. Once a refresh token is present, the attacker does not need repeated compromise of the endpoint. They only need the configuration to remain in place long enough for the next OAuth renewal cycle to deliver a fresh credential.

Practical implication: isolate routing controls from secret storage and monitor local files for unauthorised endpoint changes.

Why provider-side logs miss the compromise

The stolen token is still valid, still scoped, and still presented from what appears to be a trusted egress path. That means the SaaS provider sees an authenticated session with expected origin metadata, not an obvious intrusion. This is why the attack is invisible to normal perimeter and authentication telemetry. The only reliable evidence sits on the endpoint, in the configuration state that determined how the token was routed and refreshed.

Practical implication: build endpoint-level detection for configuration drift, not just cloud-side anomaly detection.

Threat narrative

Attacker objective: The attacker’s objective is durable access to broadly scoped SaaS credentials that can be reused without triggering provider-side suspicion.

1. Entry occurs when a malicious npm package uses a postinstall hook to modify the developer’s Claude Code configuration without visible prompts or warnings.
2. Credential theft follows when the hook rewrites the mcpServers endpoint so future OAuth flows deliver bearer tokens through an attacker-controlled proxy.
3. Impact occurs when the attacker reuses persistent tokens for Jira, Confluence or GitHub while provider audit logs still show legitimate origin and session details.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Code’s MCP token problem is an NHI governance problem, not a product bug. The article makes clear that the vulnerable asset is a delegated credential living outside IAM inventory, review, and lifecycle control. Once a token is both persistent and broadly scoped, the security issue becomes governance of the identity itself, not just the application that used it.

Trust assumptions built for human-paced approval flows fail when credentials can be reseeded automatically. The sessionStart hook can restore attacker routing every time the client loads, which means a one-time remediation step can become part of the delivery mechanism. That is exactly the kind of lifecycle failure OWASP-NHI is meant to surface: credentials that survive longer than the controls meant to contain them.

Plaintext co-location of secrets and routing is the named concept here: credential-routing coupling. When one file controls both token storage and endpoint selection, compromise of the file is equivalent to compromise of the delegation path. Practitioners should treat that as a broken identity design assumption, because access review processes cannot correct a routing decision that was never separated from the credential in the first place.

Provider-side legitimacy does not equal governance legitimacy. The attack is designed so every downstream log looks normal, which means IAM teams cannot rely on origin metadata or authenticated-session checks as proof of control. In NHI terms, a valid session is not the same thing as a governed session, and the distinction matters when credentials are inherited across tool chains.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• Our research also found that 28% of secrets incidents now originate outside code repositories, in Slack, Jira and Confluence, and are 13% more likely to be critical than code-based leaks.
• For teams mapping this risk to governance, Top 10 NHI Issues provides the broader identity controls that should frame local secret handling and delegated access.

What this signals

Credential-routing coupling: once a local file controls both token storage and endpoint selection, the control problem shifts from secret protection to trust-boundary design. Teams running developer-facing AI tools need to decide whether those local configs are now governed identity artefacts, because the next compromise is likely to look like normal traffic until the endpoint is inspected.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the environment around developer tooling is already saturated with credential exposure pressure. That scale makes endpoint drift, refresh-token persistence and unmanaged MCP delegation a programme issue, not an isolated incident.

The practical response is to extend NHI discovery into developer workstations and AI-enabled client configs, then connect that visibility to review and revocation workflows. If a token is not in inventory, cannot be revoked cleanly and can be silently reseeded by configuration, it is not under identity control.

For practitioners

• Inventory MCP-delegated credentials as governed NHIs Identify every Claude Code or similar MCP integration that stores bearer or refresh tokens locally, then add those credentials to the same inventory and review process used for other non-human identities.
• Separate routing state from token storage Move endpoint trust decisions out of plaintext local files where possible, and flag any configuration that lets the same write operation alter both mcpServers URLs and secret material.
• Detect configuration drift before token rotation Search for sessionStart hooks, localhost proxy rewrites and unexpected changes to trusted project paths before rotating any connected OAuth token, because rotation alone can refresh attacker access.
• Baseline provider access by endpoint and behaviour Review SaaS logs for requests that appear legitimate but do not match the developer’s normal use pattern, then correlate them with endpoint state on the workstation rather than relying on provider-origin trust.

Key takeaways

• This attack works because an MCP configuration file collapses credential storage, trust routing and persistence into one ungoverned identity surface.
• The scale of the risk is defined by durable, broadly scoped OAuth tokens that remain valid even when provider logs look normal.
• Teams need endpoint-level governance, inventory and revocation for MCP-delegated credentials before rotation becomes part of the attacker’s delivery path.

Key terms

• Mcp Delegated Identity: A delegated identity created when an AI-enabled client obtains access to external services through MCP and OAuth. It behaves like a non-human identity because the credential can persist, refresh and operate outside normal human session controls, even when it originated from a developer action.
• Credential-Routing Coupling: A design flaw where the same configuration object controls both where a credential is sent and how that credential is stored or renewed. This removes integrity boundaries and makes a single file change enough to redirect access, which is especially dangerous for local AI tooling.
• Refresh-Token Persistence: The condition where a stolen credential can be renewed repeatedly without repeated compromise of the endpoint. In NHI programmes, persistence matters more than initial theft because it extends the lifetime of access beyond the point where the original compromise was discovered.
• Provider-Side Legitimacy: The appearance of normality in downstream logs when a request is authenticated, scoped and sourced from a trusted egress path. It is not the same as governance legitimacy, because a valid session can still be the product of a compromised routing path or unmanaged delegation flow.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The exact ~/.claude.json fields that need to be checked on developer machines, including mcpServers and sessionStart hooks.
• The step-by-step remediation order for removing malicious hooks before rotating connected OAuth tokens.
• The provider-side log patterns and endpoint artefacts that help distinguish legitimate OAuth use from proxy-based interception.
• The product-specific controls Unosecur describes for governing MCP-delegated identities and per-agent scope.

👉 Unosecur’s full post covers the attack chain, local file artefacts and the remediation order that avoids re-feeding the attacker.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.