Notifications
Clear all
Topic starter
23/06/2026 7:25 pm
TL;DR: A malicious npm package can rewrite local Claude Code MCP routing, capture OAuth bearer tokens, and replay them against SaaS services, according to PermitIO's analysis of the Mitiga-reported chain. The incident shows that valid scopes and clean SaaS logs are not enough when runtime tool-call authorization is missing.
NHIMG editorial — based on content published by PermitIO: Claude Code MCP Token Theft Shows Why OAuth Tokens Need Runtime Tool-Call Authorization
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams implement runtime authorisation for AI coding agents?
A: Start by placing a policy decision point in front of every sensitive tool call, not just at login or token issuance.
Q: Why do valid OAuth scopes still fail to protect AI tool integrations?
A: Because scopes describe potential capability, not the trustworthiness of the current execution path.
Q: What breaks when local MCP configuration can be rewritten by untrusted code?
A: The organisation loses trust in the endpoint path that carries bearer tokens to the service.
Practitioner guidance
- Monitor local MCP routing integrity Baseline approved endpoint definitions in files such as ~/.claude.json and alert on any host, protocol, or URL drift.
- Correlate install hooks with agent tool calls Review preinstall and postinstall package execution paths in developer environments, then correlate them with subsequent MCP tool usage and SaaS API activity.
- Replace standing OAuth scope with runtime policy checks Put a policy decision point in front of high-risk tool calls so identity context, action type, and target resource are evaluated at execution time.
What's in the full article
PermitIO's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step mapping of the malicious npm install-hook chain and local MCP config rewrite path
- Concrete examples of which files, hosts, and endpoint changes to baseline in AI IDE environments
- Detailed guidance on policy decision points, consent gates, and tool allowlists at execution time
- Investigator workflow for correlating workstation drift, package events, and SaaS audit logs
👉 Read PermitIO's analysis of Claude Code MCP token theft and runtime authorisation →
Claude Code MCP token theft: are your controls keeping up?
Explore further
25/06/2026 3:24 am
Runtime authorisation, not bearer possession, is now the decisive control boundary for AI coding agents. Claude Code MCP token theft shows that a valid token can coexist with a compromised execution path. The identity event is not simply stolen secret use, but stolen secret use after the local trust chain has already been rewritten. Practitioners should treat tool-call authorisation as an execution-time control problem, not a credential-issue problem.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which shows how often identity hygiene depends on inconsistent human behaviour.
A question worth separating out:
Q: Who is accountable when an AI agent uses a stolen token to access SaaS data?
A: Accountability sits across the human operator, the agent platform, and the organisation that failed to protect the call path. The practical question is whether governance covered local config integrity, token scope, and runtime authorisation together. If any one of those layers was missing, the control failure is on the programme, not just the user.
👉 Read our full editorial: Claude Code MCP token theft shows why runtime auth matters
