Claude Code MCP token theft shows why runtime auth matters

At a glance

What this is: This is an analysis of how Claude Code MCP token theft works when local routing is rewritten and OAuth bearer tokens are intercepted for replay.

Why it matters: It matters because IAM teams must govern agent tool calls at execution time, not assume that token scope and SaaS logs are enough to prove safe access.

Context

Claude Code MCP token theft is a runtime authorisation problem, not just a secrets problem. When an AI coding agent can have its local MCP routing rewritten, the identity question is no longer only whether a token is valid, but whether the tool call is still reaching the intended policy boundary.

The article argues that long-lived OAuth tokens and downstream SaaS audit logs do not tell the full story once local configuration or endpoint routing is compromised. For teams governing non-human identities in agentic workflows, that shifts the control point from credential possession to per-call policy enforcement.

This is a practical issue for AI coding agents, MCP-connected tools, and the identity controls that sit between the developer workstation and the SaaS service. The article's starting position is not unusual: it reflects a common trust assumption in early agent deployments that valid credentials are sufficient to authorise action.

Key questions

Q: What breaks when local MCP routing can be rewritten by code running on a developer workstation?

A: The trust assumption that a valid token is reaching the intended service breaks first. If local routing can be altered, token validity no longer proves that the call path is trustworthy or that the agent is talking to the right endpoint. Teams need to treat local configuration integrity as part of the authorisation boundary, not as a separate operations issue.

Q: Why do valid OAuth tokens still create risk for AI coding agents and MCP tools?

A: Because a token proves capability was granted, not that each call is safe now. AI coding agents can operate across many tools quickly, so a captured token can be replayed before ordinary monitoring spots the difference. The risk rises when scopes are broad and when the trust decision happens only at issuance time.

Q: What are the signs that runtime authorisation is missing from an agent tool chain?

A: Common signs include tool calls that succeed solely because a token exists, approval checks that happen only once at setup, and logs that record actions but not the policy decision behind them. Another indicator is that a local config change can redirect requests without any blocking control firing. That means the governance layer is too late.

Q: How should security teams respond when an AI coding agent's local configuration is compromised?

A: Contain the workstation first, verify MCP routing and related config integrity, then revoke and re-issue credentials after the path is restored. If rotation happens before the routing layer is cleaned up, the attacker can simply capture the replacement token as well. The response order matters because the path is the compromise point.

Technical breakdown

How MCP routing becomes the control-plane target

Model Context Protocol connections rely on local configuration to decide where tool traffic goes, which makes the routing layer part of the identity trust chain. If a malicious package can alter files such as ~/.claude.json or related server definitions, it can redirect traffic before the SaaS application ever sees the call. The result is a man-in-the-middle style pattern at the integration boundary, where the credential itself may remain valid while the path carrying it has been subverted. That is why this is more than token theft. It is a compromise of the decision path that connects the agent to the tool provider.

Practical implication: treat local MCP config integrity as part of the authorisation surface, not just workstation hygiene.

Why valid OAuth bearer tokens do not equal safe agent access

OAuth bearer tokens prove that access was granted at some point, not that each tool invocation is still policy-compliant. In this attack pattern, the token remains structurally valid while the request path has already been redirected, so downstream systems see ordinary authentication artefacts. That creates a false sense of security in environments that rely on scope checks alone. For AI coding agents, the problem is compounded by high-frequency automation across multiple SaaS tools, where a captured token can be replayed quickly and repeatedly. Runtime context is therefore essential to distinguish possession from legitimacy.

Practical implication: pair token validation with per-request policy checks that evaluate user-agent context and action intent.

Why runtime authorisation must sit in front of tool execution

A policy decision point in front of tool execution changes the security model from credential-only trust to contextual approval. Instead of asking what a token can theoretically do, the system asks whether this specific tool call should occur now for this agent, this human, and this resource. That boundary can block destructive actions, enforce allowlists, and require approval for sensitive calls even when the credential is real. For AI coding agents, that is the difference between perimeter trust and execution-time governance. The architecture matters because token scope is static, while agent behaviour is situational and can be manipulated mid-session.

Practical implication: place runtime policy in the tool-call path so compromise of a token does not automatically become compromise of action.

Threat narrative

Attacker objective: The attacker wants to steal usable bearer tokens and turn them into authorised-looking SaaS API access without tripping normal downstream authentication checks.

1. Entry begins when a malicious npm package executes an install hook and modifies local Claude Code MCP configuration on the developer workstation.
2. Credential capture follows when redirected MCP traffic sends OAuth bearer tokens to attacker-controlled infrastructure during normal tool operations.
3. Abuse continues as the attacker replays those tokens against SaaS APIs, while downstream services see apparently legitimate requests.

Breaches seen in the wild

• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
• GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.

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

NHI Mgmt Group analysis

Runtime authorisation, not token possession, is now the control that matters for agent tool use. The article shows that a bearer token can be technically valid while the request path has already been compromised. That means the decisive governance question is no longer only who holds the secret, but whether the call itself is still permitted under current policy. Practitioners should treat the tool-call boundary as an authorisation surface in its own right.

Local MCP routing is part of the identity trust chain, not an implementation detail. If local configuration can redirect tool traffic before SaaS enforcement, then the integrity of the endpoint configuration becomes a prerequisite for trustworthy access. This is a classic identity governance mistake: assuming the credential is the boundary when the path carrying it is actually the weak point. The implication is that workstation-level config drift must be governed alongside token lifecycle and SaaS permissions.

Runtime tool-call authorisation is a named control gap this article exposes. OAuth scopes answer what an agent could do in principle, but they do not answer whether a specific call should proceed now. That assumption was designed for stable request flows where the token and the path are trustworthy. It fails when the actor is an AI coding agent operating through mutable local routing because the trust decision can be displaced upstream of the SaaS service. The implication is that policy must move to execution time, not stay at issuance time.

Identity blast radius expands when agents can inherit broad SaaS permissions through one captured token. This article shows how a single compromise can combine local routing tampering with replayable bearer access across multiple services. That is not just a secrets issue. It is a governance problem about how much action one credential can unlock once an agent can call tools at machine speed. Practitioners should view scope reduction and per-call control as complementary, not interchangeable.

Permission-aware agent governance needs a policy boundary that survives endpoint compromise. Once the local path is poisoned, downstream logs may still look normal even though the initiating context was not trustworthy. That means investigators and control owners need evidence that binds human identity, agent session, tool call, and policy decision together. The practitioner takeaway is simple: access governance for AI coding agents has to be evaluated at the point of action, not inferred after the fact from SaaS telemetry.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Runtime authorisation has become the governance line that separates safe agent activity from replayable credential abuse. Access review processes assume a privilege persists long enough to be certified, but an MCP tool call can be rerouted before any downstream control sees it. For that reason, programme owners should move some decision points to issuance time and some to execution time, then correlate both with endpoint integrity.

Identity blast radius is the more useful concept than token count for agentic workflows. Once a single bearer token can touch multiple services through agent tooling, the practical question is how much action that credential can unlock before policy interrupts it. That makes scope design, approval boundaries, and logging correlation the controls that determine whether one compromise stays local or becomes multi-system.

Runtime policy must be evaluated alongside local config integrity, not instead of it. If ~/.claude.json or related MCP settings can be rewritten, the agent may still appear to behave normally while traffic is already flowing through attacker-controlled infrastructure. The programme implication is clear: validate the path, then validate the call, then trust the result.

For practitioners

• Audit MCP routing integrity Monitor ~/.claude.json and related MCP server files for endpoint, host, and protocol drift, and tie any change back to the process that made it.
• Control install-time execution paths Restrict or review package lifecycle scripts such as preinstall and postinstall, especially on developer workstations that can reach production tools.
• Enforce runtime policy at tool execution Place a policy decision point in front of agent tool calls so allowlists, denies, and approval gates evaluate each request in context.
• Reduce token blast radius Replace broad persistent OAuth scopes with shorter-lived grants where possible, and separate read-only access from write or admin operations.
• Correlate identity, config, and SaaS logs Join agent session logs, endpoint configuration changes, and SaaS API activity so a valid token cannot hide a tampered request path.

Key takeaways

• The article shows that MCP token theft is really a routing and authorisation problem, because a valid token can still be delivered through a compromised local path.
• The practical risk is token replay across SaaS services, which makes downstream logs look legitimate even when the initiating tool call was hijacked.
• The control that changes the outcome is runtime authorisation at the tool boundary, backed by endpoint integrity monitoring and tighter OAuth scope design.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• MCP routing integrity: The assurance that tool traffic reaches the intended endpoint without local tampering or silent redirection. In AI coding environments, routing integrity is part of the identity trust chain because the agent’s credentials are only as trustworthy as the path that carries them.
• Bearer token replay: Reuse of a captured token by an attacker to make authorised-looking API calls. The token may still be structurally valid, which is why replay prevention depends on path integrity, short lifetimes, and context-aware enforcement rather than token format alone.
• Agent-tool boundary: The point where an AI agent selects and invokes an external tool or capability. In practice, this is where identity, policy, and request scoping have to override model preference, because unsafe tool choice can turn a linguistic prompt into an operational action.

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.