MCP Token Hijacking

1. The Misidentified Vulnerability

What the Research Actually Shows

The Mitiga Labs demonstration used a malicious npm package with a postinstall lifecycle hook to rewrite the MCP configuration file (~/.claude.json). This is a well-understood supply chain attack class. The research is technically sound, but the attack chain has two distinct phases that deserve separate treatment:

• Phase 1, Configuration manipulation: The endpoint address in the MCP config file is altered to point to attacker-controlled proxy infrastructure. This is the initial compromise.
• Phase 2, Token harvesting: On every subsequent MCP session or OAuth refresh, the bearer token transits the attacker's proxy. This is the persistent, damaging attack.

These phases are causally linked in the demonstration but architecturally independent. Phase 2 does not care how Phase 1 was achieved.

The Plain Text Addressability Problem

MCP requires that server endpoint URLs be stored in human-readable, plain text configuration. This is not an implementation oversight, it is a functional requirement. The protocol must be able to read these addresses to route traffic. Encryption at rest would break the feature.

This means the attack surface is not an npm vulnerability, not a Claude Code vulnerability, and not a supply chain vulnerability. It is a property of the MCP specification itself, present in every compliant implementation. Any of the following achieves the identical downstream result as the npm attack:

• Social engineering a developer into editing their config file
• A malicious repository whose project-level MCP config overrides user config
• A separate malware infection with user-level file write access
• Physical access to an unlocked developer workstation
• A misconfigured deployment script that overwrites the config
• A compromised IDE plugin or editor extension

Why Token Rotation Does Not Help

Standard incident response for a compromised OAuth token is to rotate it. In this attack, rotation actively benefits the attacker. Because the malicious hook reasserts the proxy endpoint on every session start, the newly rotated token is captured on its first use. The attacker receives a fresh, valid token while the defender believes the incident is resolved.

This inverts the normal security model. The defensive action becomes an offensive gift. Effective response requires removing the hook and restoring the endpoint configuration before rotating credentials, a sequencing requirement that most incident response playbooks do not account for.

2. Why This Attack Is Invisible to Conventional Detection

The attack's most operationally dangerous property is its forensic cleanliness. Consider what each observer sees:

The anomaly exists exclusively at the device layer. Every other observer is downstream of the proxy, receiving traffic that has already been laundered through legitimate infrastructure. Only the device knows that the session's cryptographic continuity has been broken.

3. The Pulse CA Architecture and Its Role

Component Overview

Pulse CA is a certificate authority and identity assurance platform for agentic AI environments. Its architecture relevant to this attack comprises two primary components:

• Pulse CA Core: Issues device certificates and manages the OIDC provider that governs all token exchanges within the environment.
• Sentinel: A background service installed on the OIDC client device, the device hosting the agentic AI session. Sentinel provides continuous device identity assertion and active proximity verification as an ongoing condition of session validity.

It is important to distinguish Sentinel from Microsoft Sentinel, which is an unrelated SIEM product. Pulse CA's Sentinel is a device-resident service component with no relationship to Microsoft's product.

FIDO2-DA: The Supporting Control

Pulse CA's Sentinel incorporates FIDO2-DA (device assertion), a cryptographic device identity mechanism that satisfies the OIDC provider's authentication requirement at token refresh boundaries without requiring human user interaction.

FIDO2-DA contributes to the defense as follows: when a token refresh is attempted, the OIDC provider requires a cryptographic assertion from a Sentinel-enrolled device. An attacker's proxy infrastructure cannot generate this assertion. The refresh fails, and the captured token's useful life is bounded by its original TTL.

This is meaningful protection. However, its limitation is that it operates only at refresh boundaries. Between issuance and the next refresh cycle, a captured token remains usable. For long-lived tokens or high-value operations, this window matters.

Active Proximity Verification: The Primary Control

Sentinel's active proximity verification operates continuously, not at transaction boundaries. It maintains an ongoing cryptographic assertion of device identity as a live condition of session validity. When that assertion fails, because the session is being routed through infrastructure that is not the enrolled device, the session is torn down immediately.

This is the control that closes the window that FIDO2-DA leaves open. Its properties:

• Immediacy: Session invalidation occurs at the moment of detection, not at the next refresh cycle.
• Device-initiated: The failure signal originates on the enrolled device, not from provider-side anomaly detection that is blind to this attack.
• Proxy-proof: Attacker infrastructure cannot satisfy a proximity assertion. There is no credential to steal that would allow a proxy to impersonate proximity.
• Rotation-independent: Because the control is continuous rather than token-lifecycle-based, token rotation is irrelevant to its effectiveness.

4. Scope: All MCP-Enabled Agents

The vulnerability described in this paper is not specific to Claude Code. It is a property of the MCP specification and applies to any agent framework that implements MCP for SaaS integration. This includes:

• OpenAI agent tooling with MCP integrations
• LangChain and LangGraph MCP server support
• Microsoft Copilot Studio MCP connectors
• Google Gemini agentic MCP implementations
• Open source frameworks including AutoGen and CrewAI

As MCP consolidates as the standard connectivity layer for agentic AI, the functional equivalent of HTTP for the web, the value of this attack scales proportionally. Pulse CA's defense operates at the device and session layer, below and independent of any specific agent framework. It covers the full MCP ecosystem by architecture, not by integration.

5. Detection and Prevention: What Pulse CA Provides

Prevention Path

When Sentinel is operational on the device hosting the agentic AI session, the attack's token harvesting phase is prevented in two ways:

• FIDO2-DA refusal: Token refresh requests that lack a valid device assertion are rejected by the OIDC provider. The attacker's proxy cannot obtain a fresh token.
• Proximity invalidation: If a session's traffic is diverted through a proxy, Sentinel's continuous proximity verification detects the break in device-side session continuity and invalidates the session before sustained harvesting can occur.

In environments where Sentinel is running and the Pulse CA OIDC provider governs all token exchanges, the attack's persistent access phase does not materialize.

Detection Path

In environments where Pulse CA is present but operating in a monitoring or partial enforcement posture, Sentinel generates actionable signals:

• Proximity assertion failures correlated with active MCP sessions
• FIDO2-DA refresh rejections that do not correspond to expected session lifecycle events
• Session continuity breaks that precede or coincide with SaaS API activity

These signals are device-originated and do not depend on provider-side anomaly detection. They surface the attack at its earliest possible point, the moment session continuity is broken by proxy insertion, rather than after credential abuse has already occurred.

What Pulse CA Does Not Address

For completeness, the following are outside Pulse CA's scope in this context:

• Prevention of the initial configuration file manipulation. Hardening against supply chain attacks, malicious repositories, or file integrity requires separate controls.
• Detection of token misuse on devices where Sentinel is not installed. The device-side signal is only available where Sentinel is present.
• Recovery or forensics after a successful exfiltration. Pulse CA detects and prevents active session abuse; it does not reconstruct historical token use.

6. Recommendations

For Organizations Deploying MCP-Enabled AI Agents

• Treat MCP configuration files as high-value credential stores. Apply file integrity monitoring. Alert on unauthorized modifications.
• Recognize that token rotation alone does not remediate this attack. Endpoint restoration must precede rotation.
• Understand that provider-side audit logs will not surface this attack. Monitoring must include device-layer signals.
• Evaluate device-resident session continuity controls, not perimeter or provider controls, as the primary detection surface.

For Security Architects

• Recognize that MCP's plain text addressability is a specification property, not a fixable implementation flaw. Defense must account for it as a permanent feature of the landscape.
• Design detection architectures that include device-side signal sources. This attack class is invisible without them.
• Apply defense-in-depth: FIDO2-DA provides a time-bounded token usefulness limit; proximity verification provides immediacy. Neither alone is sufficient; both together close the attack window.

7. Conclusion

The MCP token hijacking attack is best understood not as a supply chain problem but as a consequence of a structural property in the MCP specification: the plain text storage of endpoint addresses. This property cannot be eliminated without breaking MCP. Any control that only hardens the delivery mechanism leaves the underlying exposure intact.

Once a token is captured, conventional defenses are blind. The attack is indistinguishable from legitimate traffic at every observer layer except one: the device hosting the compromised session. Pulse CA's Sentinel exploits this uniquely privileged vantage point through continuous active proximity verification, providing session invalidation at the moment of proxy insertion rather than at the token's expiry or after damage has occurred.

As MCP becomes the standard connectivity layer for agentic AI across all frameworks and vendors, device-layer session continuity verification will become a foundational requirement for any organization operating AI agents with access to sensitive SaaS infrastructure. Pulse CA's architecture addresses this requirement today.

A final note on scope: while MCP is the focus of both the Mitiga Labs research and this paper, the underlying condition it exposes, plain text storage of OIDC and SAML configuration including endpoint addresses, client identifiers, and provider metadata, is not unusual to MCP. It is the norm across the industry. MCP is the context in which this property has been most visibly exploited in an agentic AI setting. It is not the only context in which it creates exposure, and the detection and prevention principles described here have broader applicability wherever device-resident session continuity can be asserted.

Appendix A: Indicators of Compromise

The following indicators are relevant to detection of active token harvesting in MCP environments. Note that all of these are device-side or configuration-side signals, none are reliably visible in provider or network logs.

• Unauthorized modifications to ~/.claude.json or equivalent MCP config files
• Presence of localhost, non-standard, or unexpected proxy URLs in MCP server endpoint fields
• npm packages with postinstall hooks that access MCP configuration files
• Repeated OAuth token refreshes at intervals inconsistent with session lifecycle
• MCP session initialization events not correlated with user-initiated agent activity
• Sentinel proximity assertion failures coinciding with active MCP sessions
• FIDO2-DA refresh rejections outside expected session boundaries

Appendix B: Terminology

---

---