Claude Code source leak exposes AI agent governance blind spots

At a glance

What this is: Backslash Security’s analysis shows that a packaging mistake exposed Claude Code’s source architecture, revealing how deeply AI coding agents can access files, APIs, hooks, and memory before security teams can inspect them.

Why it matters: IAM, PAM, and NHI teams need to treat AI coding agents as governed identity actors, because leaked implementation details and hidden permissions change how access, monitoring, and trust controls should be designed.

By the numbers:

• Developers approve 93% of permission prompts.
• The leak was discovered 20 minutes after it was published.

👉 Read Backslash Security's analysis of the Claude Code source leak and AI agent exposure

Context

Claude Code is an AI coding agent, which means its security posture is not just about model output. It is also about the files, tools, permissions, hooks, and memory systems that shape how the agent behaves on developer machines. The primary governance problem is that these runtime components were not visible to security teams until the source leak exposed them.

For IAM, PAM, and NHI programmes, the issue is broader than one leaked codebase. When an AI agent can load configuration, call APIs, and operate across multiple context and memory layers, security teams need to govern the identity and access pattern around the agent, not only the prompts it receives. That is the control gap this incident makes plain.

Key questions

Q: What breaks when AI coding agents can act before a trust prompt appears?

A: The security boundary breaks because the human approval step is no longer the first meaningful control. If the agent can load configuration, call APIs, or send data before consent, then prompt-based approval becomes advisory rather than preventative. Teams need controls that operate before execution begins, not after the agent has already touched sensitive resources.

Q: Why do AI coding agents create different governance risks from normal developer tools?

A: AI coding agents combine code execution, context persistence, external tool access, and memory across sessions. That makes them governed identity actors with a wider blast radius than a standard editor or plugin. The risk is not just what they generate, but what they can read, retain, and trigger on behalf of the developer.

Q: What do security teams get wrong about permission dialogs for AI agents?

A: They often treat the dialog as the control itself. In practice, it is only a checkpoint if the agent has already been prevented from making dangerous calls, loading risky context, or accessing secrets beforehand. Effective governance starts with execution order, not with the approval button.

Q: How should organisations govern context poisoning in agentic development tools?

A: They should treat repository content and cloned project data as untrusted inputs that can influence agent decisions. That means separating source-of-context controls from prompt safety, logging which files and instructions shaped each action, and blocking trusted-state promotion from unverified sources.

Technical breakdown

Why AI coding agents need identity governance, not just content controls

Claude Code is structured as an operating environment for an AI agent, not a single-purpose chatbot. The leaked code shows a large query engine, a tool system with many permission-gated modules, context management, and multi-layer memory. That combination matters because the agent does not merely generate text. It loads configuration, persists knowledge, and drives actions through code paths that can touch APIs, files, and hooks. In identity terms, that is a governed runtime actor with access boundaries, not just a user interface problem.

Practical implication: teams need to inventory every tool, hook, and configuration path the agent can invoke before treating it as safe to deploy.

Permission prompts are not a durable security boundary

The article says Claude Code can execute actions before the trust dialog appears, and it cites a CVE where API keys were sent to attacker-controlled servers before the developer saw a prompt. That is a boundary failure, not a usability issue. If an agent can begin loading project state or making network calls ahead of consent, then the approval dialog becomes advisory rather than controlling. Security teams should read that as evidence that timing and execution order are part of the identity control surface.

Practical implication: enforce pre-execution controls around network access, secret handling, and hook invocation instead of relying on user prompts alone.

Context poisoning turns repository content into a governance problem

Context poisoning happens when a malicious instruction in a repository survives summarisation and is promoted into trusted agent context. The article frames this as a design issue, which is the right lens. Once repository content can shape agent decisions across sessions, the trust boundary has moved from the model response to the surrounding development environment. That means monitoring has to sit outside the agent and observe the inputs it consumes, not only the outputs it produces.

Practical implication: monitor repository-derived instructions and context sources separately from model output so malicious prompts do not become trusted directives.

Threat narrative

Attacker objective: The attacker objective is to learn the agent’s internal control structure well enough to find exploitable execution paths, hidden capabilities, and trust weaknesses.

1. Entry occurred through a packaging error that published Claude Code source code to npm, exposing the full architecture and internal controls to anyone who downloaded it.
2. Credential or capability abuse becomes more likely once attackers can study the leaked tool system, hidden feature flags, and pre-consent execution paths to identify where sensitive access can be triggered.
3. Impact follows when attackers use that knowledge to target AI coding agents, probe hidden permissions, or weaponise forked copies that may already contain malicious components.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

AI coding agents are now governed identity actors, not just software features. The leaked Claude Code architecture shows a tool-rich runtime that can load configuration, call APIs, manage context, and persist memory across sessions. That means the security question is no longer whether the model is safe to chat with, but which identity boundaries govern its actions. Practitioners should treat agent runtime paths as access-bearing surfaces, not application internals.

Permission prompts do not equal control when execution begins before consent. Backslash Security’s description of pre-dialog actions and API-key exposure shows that timing is part of the control model. If an agent can act before the user approves, the review point has already shifted too late. Security teams should stop assuming the human approval step is the security boundary and instead examine where the actual execution boundary begins.

Context poisoning is a named governance failure, not a model quality issue. A malicious instruction can be promoted from repository content into trusted agent context even after summarisation. That means the environment surrounding the agent can rewrite its decision inputs without defeating the model itself. The implication is that agent governance must include source-of-context controls, not just content moderation.

Feature-flag opacity creates identity blast radius because hidden capabilities are part of the trust surface. The article notes more than 20 features behind internal flags, including background observation and stealth behaviour. Hidden features may not be active in every deployment, but their existence expands the uncertainty around what the agent can do if enabled or repackaged. Practitioners should treat undisclosed capability as a governance variable, not a product curiosity.

Runtime visibility must extend beyond the agent to every connected control plane. The article points to hooks, plugins, and connected services as part of the exposure path. That is the correct lens for NHI and AI agent programmes: an agent’s real authority is distributed across adjacent systems that can amplify its access. Practitioners should govern the chain of identity, not only the primary agent process.

From our research:

• Developers approve 93% of permission prompts, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• That same research found that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• For a broader breach-pattern view, see The 52 NHI breaches Report, which helps teams map identity exposure to real-world attack paths.

What this signals

Permission density is becoming a governance signal. If developers approve 93% of prompts, the approval experience is clearly not acting as a hard control. Security teams should therefore measure whether agent actions are blocked before execution, not whether users are asked politely after the fact. The right question is whether the programme can stop an action at the policy layer, not whether a dialog appeared.

AI coding agents expand the identity perimeter into developer workflows. Their access to configuration, hooks, and memory means security controls need to follow the workflow, not the application banner. Teams that already govern machine identity should extend those patterns into agent runtime visibility, especially where repository content can influence subsequent decisions.

Context poisoning will push programmes toward source-of-context governance. The practical change is to classify files, cloned repositories, and external instructions as identity-relevant inputs. That requires logging, isolation, and review paths that are separate from prompt moderation, because the trust failure happens before the model output is even produced.

For practitioners

• Map the agent control surface before deployment Inventory every configuration file, hook, plugin, API path, and memory store the agent can touch. Classify which components can alter execution before a user approves an action, then remove or isolate those paths where possible.
• Separate consent from execution Treat user prompts as a usability layer, not a trust boundary. Enforce policy checks before network calls, secret access, file writes, and repository-derived instruction processing.
• Monitor context inputs outside the agent Track where repository instructions, cloned projects, and external context are sourced from so poisoned content can be detected before it becomes trusted agent state.
• Review hidden features and internal flags as governance risk Build a release review step for undocumented or internal-only capabilities, especially when they alter permissions, background observation, or contribution behaviour.

Key takeaways

• Claude Code’s source leak exposed an AI agent runtime that behaves like a governed identity actor, not just an application feature set.
• The article’s strongest evidence is the 93% prompt-approval rate, which shows that user dialogs are not functioning as a reliable security boundary.
• The control gap is execution-order governance: teams need pre-consent policy enforcement, source-of-context controls, and visibility into hidden capabilities.

Key terms

• AI Coding Agent: An AI coding agent is software that can read project context, call tools, and take actions inside a development workflow. In governance terms, it behaves like a non-human identity with access-bearing capabilities, so teams must manage permissions, execution order, and telemetry around it.
• Context Poisoning: Context poisoning is the injection of malicious or misleading instructions into the data an AI agent treats as trusted context. It matters because the agent may promote untrusted repository content into decision-making input, creating a governance failure outside the model itself.
• Permission Prompt: A permission prompt is a user-facing approval step that asks whether an agent should proceed with an action. It is not a control boundary on its own if the agent can already load files, access secrets, or call external services before the prompt appears.
• Source-of-Context Control: Source-of-context control is the practice of governing which files, repositories, instructions, and external inputs an AI agent is allowed to treat as trusted. It is essential when agent decisions can be shaped by content outside the model, especially in developer environments.

What's in the full article

Backslash Security's full blog post covers the implementation detail this analysis intentionally leaves at the architectural level:

• A breakdown of the leaked Claude Code architecture, including the 46,000-line query engine and 29,000-line tool system
• Examples of hidden features and internal flags that expand the agent's effective control surface
• The specific CVE and prompt-timing behaviour that show why approval dialogs are not enough
• Security team actions suggested by the source, including visibility into connected components and runtime behaviour

👉 Backslash Security's full post covers the leaked architecture, hidden features, and the operational risk signals for security teams

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.