Claude Code MCP traffic hijack exposes OAuth token governance gaps

At a glance

What this is: This analysis shows how a Claude Code supply chain compromise can redirect MCP traffic and steal OAuth tokens from local configuration before provider-side logs notice anything unusual.

Why it matters: It matters because IAM, IGA and PAM teams now have to govern MCP-delegated credentials as non-human identities with lifecycle, routing and trust controls, not just as developer convenience settings.

👉 Read Unosecur's analysis of the Claude Code MCP token hijack

Context

Claude Code MCP traffic hijack is an identity governance problem, not just a configuration issue. The article describes how a local file can combine routing, trust settings and bearer-token storage, allowing a supply chain compromise to redirect delegated access without breaking authentication.

For IAM and NHI programmes, the important change is that developer tooling is now issuing persistent OAuth-backed access that behaves like a governed identity. If that access is outside inventory, outside review and outside revocation discipline, provider logs will still show legitimate sessions while governance has already failed.

The attack also exposes a familiar control blind spot: local trust decisions can become credential-routing decisions when they are co-located with token material. That makes the developer workstation part of the identity control plane, whether teams have treated it that way or not.

Key questions

Q: What breaks when MCP credentials are stored in the same file as routing and trust settings?

A: The boundary between credential custody and request routing disappears. If one writable file can change where a bearer token is sent, then compromise of the file is enough to redirect legitimate OAuth traffic without defeating the provider. That turns local configuration into an identity control plane and makes integrity of the client state part of access governance.

Q: Why do provider-side logs miss OAuth token hijacking through MCP clients?

A: Because the attacker reuses a real token through a trusted egress path, so the provider sees a valid user, valid scopes and a familiar origin. The malicious step happened earlier, when the client configuration changed the destination of the token. Detection has to include client-side route integrity, not just server-side authentication telemetry.

Q: How should security teams govern OAuth tokens as non-human identities?

A: Security teams should assign ownership, expiry, and revocation rules to OAuth tokens just as they would for service accounts or API keys. That means tracking where tokens are issued, what scopes they hold, how long they remain valid, and when they are rotated or revoked after suspicious use.

Q: Should teams rotate a suspected MCP token before fixing the local configuration?

A: No. If the routing compromise is still present, rotation can deliver the new token straight back to the attacker-controlled proxy. The safer sequence is to remove the malicious hook, verify the endpoint list and trusted paths, then rotate the credential only after the path is clean.

Technical breakdown

How a local MCP configuration file becomes a token-routing control plane

Claude Code stores OAuth bearer tokens, refresh tokens, trusted project directories and MCP endpoint URLs in the same plaintext configuration file. That means a compromise does not need to break authentication at the SaaS provider. It only needs to alter where the client sends the token. Once the URL is rewritten to an attacker-controlled proxy, every later OAuth flow can be captured while the integration still appears functional. The technical weakness is not token issuance alone, but the absence of integrity separation between credential storage and routing configuration.

Practical implication: Separate token custody from routing state and treat local configuration integrity as part of identity assurance.

Why provider-side audit logs can stay clean during OAuth token theft

The stolen token is legitimate, so downstream systems see a valid user, valid scopes and a trusted source IP range. In this pattern, the attacker is not impersonating the user in the usual sense. They are replaying a real credential through a rerouted path that still lands inside the provider's expected trust envelope. That is why conventional anomaly detection on the SaaS side misses the event. The compromise lives in the client-side delegation layer, not in the provider authentication stack.

Practical implication: Baseline delegated access behavior across clients and endpoints, not only at the provider boundary.

Why MCP has become an OAuth delegation layer for non-human identity

MCP integrations accumulate credentials that act like non-human identities: persistent, broadly scoped and capable of surviving session restarts through refresh tokens. The article shows that these credentials are not appearing in IAM inventories or access review workflows, which means the governance model has not caught up with the delegation model. When a token inherits full grant-time permissions and is not re-evaluated per use, the control point shifts from access time to issue time and routing time.

Practical implication: Inventory MCP-issued credentials as governed NHIs and review their scope, ownership and revocation path.

Threat narrative

Attacker objective: Steal usable OAuth bearer tokens for connected SaaS platforms while keeping every downstream request looking legitimate.

1. Entry occurs through a malicious npm package whose postinstall hook silently modifies the local Claude Code configuration file.
2. Credential capture follows when the hook rewrites the MCP endpoint so OAuth bearer tokens are delivered to an attacker-controlled proxy.
3. Persistence is maintained because a sessionStart hook reseeds the malicious routing on every session load, so token rotation reopens the same path.
4. Impact is the theft and reuse of valid Jira, Confluence or GitHub OAuth tokens that look legitimate to provider-side logs.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP-delegated OAuth tokens are already non-human identities in practice. They persist across sessions, inherit broad grant-time permissions and sit outside the inventory logic that most IAM programmes rely on. That combination means the governance problem is not merely token hygiene; it is that the credential now behaves like an unmanaged identity with routing metadata attached. Practitioners should treat MCP-issued access as a governed identity class, not as a developer convenience setting.

Access reviews assume a stable credential long enough to be reviewed, but this model breaks when routing and token custody are co-located. The article shows that the same local file can determine trust, endpoint selection and bearer-token delivery. That collapses the assumption that credential custody and request routing are separable control points. The implication is that lifecycle governance must extend to where the credential is sent, not only where it was issued.

Identity blast radius is determined by delegated scope plus local integrity, not by provider authentication strength alone. A token can be perfectly valid and still be unusable from a governance standpoint if the client can silently redirect it. That is why this pattern widens the blast radius of every connected SaaS grant. Teams need to reframe the risk as delegated identity sprawl with local routing authority, not as a single compromised token.

Unmanaged MCP endpoints create an identity governance blind spot that traditional IAM dashboards will not close. The article is explicit that these tokens do not appear in access review tooling, while the provider sees only legitimate sessions. That is a structural mismatch between where the identity exists and where the control plane looks for it. The practical conclusion is that discovery, ownership and revocation must move closer to the client and the delegation layer.

The correct control objective is not merely revocation, but containment of delegated scope before the token becomes broadly reusable. The article shows why a fresh token can be more dangerous than a stale one if the malicious routing remains in place. That means the field needs stronger identity boundary enforcement around MCP brokerage, local file integrity and per-integration scope, because the old assumption that rotating a credential ends the incident no longer holds.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius is now determined by local route integrity as much as by token scope. When a client can rewrite where a bearer token is sent, the practical control point moves from the provider dashboard to the endpoint itself. Teams running MCP-connected tooling need to treat local configuration integrity as part of identity governance, not just endpoint hardening.

MCP delegation creates a new governance class that sits between human intent and machine access. The issue is not only that a token exists, but that it persists, renews and can be redirected without changing the user-facing workflow. That means access reviews and inventory processes have to extend into the client-side delegation layer, or they will continue to miss the identities that matter.

Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026. That figure reinforces a broader programme signal: AI-assisted development and MCP-mediated access both increase the chance that sensitive credentials move through places security teams do not normally monitor.

For practitioners

• Govern MCP-issued tokens as NHIs Create an inventory of every Claude Code or MCP-backed OAuth credential, with an owner, scope, refresh path and revocation process. If a token is not visible in your identity records, it is not governable.
• Separate credential storage from routing state Move token handling, trust lists and endpoint configuration out of a single writable file wherever the architecture allows. When local state must exist, protect it with integrity checks and change monitoring.
• Validate local MCP endpoints before rotating tokens Inspect the mcpServers block and session hooks on developer machines before any credential rotation. Rotation after a compromised route is corrected can reissue access into the same attacker-controlled proxy.
• Monitor postinstall activity on developer endpoints Review npm postinstall hooks and any other install-time actions that can modify home-directory configuration files. A package does not need an exploit if it can rewrite the local delegation path.
• Baseline SaaS activity against delegated identity behavior Correlate provider logs with the client-side route used to obtain the token and the expected developer activity that should follow. Legitimate egress IPs are not enough when the credential path itself can be rewritten.

Key takeaways

• Claude Code MCP hijacking shows that delegated OAuth access can be redirected at the client layer even when provider authentication remains intact.
• The attack matters because tokens were persistent, broadly scoped and invisible to normal IAM inventories, which widened the identity governance gap.
• Fixing the local routing path before rotating credentials is the decisive containment step, because rotation alone can reissue access into the same malicious proxy.

Key terms

• MCP credential: An MCP credential is the authentication material used by a client, agent, or tool to access a Model Context Protocol server or connected resource. In practice, it may be an API key, token, certificate, or delegated identity. It should be scoped, revocable, and tied to the minimum permissions needed for the interaction.
• Token Routing Integrity: The assurance that a bearer token is sent only to the intended endpoint and cannot be silently redirected. In this article's context, routing integrity matters as much as token secrecy because a legitimate credential becomes dangerous when the destination can be rewritten locally.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
• Delegated Scope Drift: The gradual or immediate mismatch between the permissions a user intended to grant and the access a token actually carries in practice. For MCP-backed access, drift can occur when the grant is broad, persistent and never revalidated after initial authorisation.

What's in the full article

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

• Step-by-step breakdown of the postinstall hook and sessionStart hook sequence on the developer machine
• Detailed remediation order for removing the malicious hook, repairing the mcpServers block and rotating tokens
• Specific guidance on where to look in ~/.claude.json for trust settings, routing entries and plaintext token storage
• Discussion of how Unosecur's MCP Auth Gateway changes the enforcement point for per-agent scope

👉 Unosecur's full post covers the attack chain, remediation order and MCP governance gap in more detail.

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 building or maturing an IAM programme, it is worth exploring.