Claude Code vulnerabilities show why agentic AI needs runtime controls

At a glance

What this is: Akto’s analysis shows Claude Code’s disclosed vulnerabilities, source-code leak and reverse-shell proof of concept all point to one issue: agentic coding tools can transform ordinary repository content and permissions into runtime attack paths.

Why it matters: This matters because IAM, PAM and security teams cannot rely on static review alone when an AI tool can read, write and execute in the same reasoning loop as its trust decisions.

Context

Agentic coding tools change the security problem because they do not just suggest code. They can read repository content, write files, run commands and interact with external services, which means the control boundary moves from code review into runtime behaviour.

That creates a governance gap for IAM, PAM and NHI programmes because the risky object is not only the model output but also the tool account, API keys, shell access and delegated permissions the agent uses while working. Static review can inspect artefacts, but it cannot reliably govern what the agent will execute after it has ingested untrusted content.

Key questions

Q: What breaks when agentic coding tools are allowed to trust repository content by default?

A: Trust breaks because repository files can behave like instructions once an agent reads them in context. A README, manifest, hook, or error message can redirect execution, trigger commands, or expose secrets. Security teams should assume content may influence behaviour at runtime and prevent automatic command execution in untrusted projects.

Q: When does runtime enforcement matter more than static permissions for AI agents?

A: Runtime enforcement matters whenever an agent can make contextual tool calls or change behavior after provisioning. Static permissions tell you what the agent could do in theory, but runtime policy tells you whether it should do it now. That is essential when the task changes, the context shifts, or privileges drift beyond the original scope.

Q: What are the signs that an AI coding tool is being abused for code execution?

A: Look for unexpected writes to .vscode, shell startup files, task definitions, or repository-local binaries, especially when those changes follow reads from external content. Another signal is child-process creation from the AI tool or editor where no explicit configuration change was approved. Those patterns indicate the tool is crossing from assistance into execution.

Q: Should organisations block automated scans of forked repositories by default?

A: Yes, unless the repository is treated as untrusted input and approved manually first. Forks can contain indirect prompt injection in comments, docs or build files that an agent will read as instructions. If the scan tool can execute actions, the repository owner may be controlling the scanner’s behaviour, not just its input.

Technical breakdown

How Claude Code turns repository content into execution paths

Claude Code behaves more like a terminal-using operator than a passive assistant. It can read files, write files, invoke shell commands, manage Git operations and call out to external services through MCP servers. That means repository artefacts such as READMEs, dependency manifests, hooks and error messages are not just text. They can become instructions inside the agent’s reasoning loop, especially when the tool is allowed to act on what it reads without a separate trust boundary.

Practical implication: Treat repository content as executable input when an agent can act on it, and do not assume code review alone establishes safety.

Why static analysis misses agentic AI abuse

Static analysis is designed to match patterns in code that already exists. The problem in these Claude Code cases is that the malicious action can emerge only at runtime, after the agent has read untrusted content and decided to execute a command, redirect an API call or follow a malicious fix path. In other words, the risky behaviour is behavioural and contextual, not just syntactic. That is why linter-style review misses payloads that are fetched, inferred or assembled during execution.

Practical implication: Shift detection to runtime telemetry and behavioural policy enforcement when the exploit depends on what the agent does, not just what the repository contains.

How runtime controls constrain agentic tool misuse

Runtime controls watch the agent’s actual actions: which tools it calls, what it sends over the network, which shells it opens and whether it deviates from the intended task. This is the right control layer for agentic AI because the permission decision, the content being evaluated and the resulting action all occur in the same loop. The control objective is not to trust the model more carefully. It is to constrain the consequences of a bad trust decision when the agent already has execution authority.

Practical implication: Use runtime allowlists, behavioural anomaly detection and environment isolation to limit tool abuse before it becomes code execution or credential theft.

Threat narrative

Attacker objective: The attacker wants to turn the coding agent’s legitimate runtime privileges into shell access, credential theft or controlled execution on the developer’s machine.

1. Entry occurs when the agent opens an untrusted repository or processes malicious content embedded in README files, hooks, manifests or error messages.
2. Credential and command abuse follow when the agent treats attacker-controlled instructions as legitimate fixes and invokes shell commands, MCP tools or redirected network calls.
3. Impact is achieved through code execution, reverse shells or API key exfiltration, with the agent’s own privileges used against the development environment.

Breaches seen in the wild

• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

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 control is now the governing boundary for agentic AI. Claude Code shows that the decisive security question is no longer whether a repository is clean at scan time, but whether an agent can be influenced into executing harmful actions after it has read untrusted content. Static review still has value, but only as a precondition check. Practitioners should treat execution-time policy as the primary control plane.

Agentic AI creates a trust collapse between content and command. In a traditional application, text in a repository is usually data. In an agentic coding workflow, that same text may become instruction, configuration and trigger. That collapse means governance must distinguish between what a human can inspect and what an autonomous tool can operationalise. Teams that do not make that distinction will miss the real attack surface.

Claude Code illustrates a named concept: runtime trust leakage. The tool inherits trust from repository content, then leaks that trust into shell execution, network calls and credential use before any human can intervene. That is not a patchable edge case. It is a structural failure mode for tool-using AI when approval happens too late in the flow.

NHI and PAM controls need to move closer to issuance and invocation. The relevant risk is not only the existence of an API key or shell token, but the fact that the agent can use those secrets in ways the operator did not intend. Governance should therefore focus on when the credential is presented to the tool, what scope it receives and whether that scope can be constrained at runtime.

Security teams should expect agentic development workflows to expand shadow AI risk. Claude Code is one visible example, but the pattern applies to any coding assistant that can read, write and execute with delegated access. The control problem grows quickly when multiple tools, MCP servers and local automation chains share the same workstation or CI context. Practitioners should inventory those pathways before they become the organisation’s default development norm.

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.
• Half of companies using generative AI will deploy agentic AI by 2027, according to Deloitte's 2025 Technology Predictions.
• Read next: Agentic AI Identity Guide

What this signals

Runtime trust leakage is the pattern security teams need to watch for as agentic coding tools become normalised. The governance challenge is not simply exposed secrets or bad code, but the moment when a tool turns untrusted context into authorised action before the operator can intervene. That shifts assurance from pre-commit review to invocation-time control, which is a material change for IAM, PAM and developer security programmes.

Agentic AI development workflows should now be treated as privileged execution environments, not just productivity tools. Once an assistant can read repositories, run commands and call external services, the relevant control question becomes whether its actions are observable, constrained and reversible under policy. Runtime policy, not static scanning, becomes the practical line between experimentation and unsafe automation.

For practitioners

• Disable auto-execution in untrusted contexts Turn off YOLO-style modes for repositories, forks and downloaded projects until a human has reviewed the content and its execution path.
• Isolate agent runtime permissions Run agentic coding tools in containers or VMs with tightly bounded shell access, network egress and filesystem write scopes.
• Harden project-load and startup flows Review trust dialogs, initialisation hooks and project-load behaviour so that configuration files cannot trigger execution before approval.
• Treat exposed API keys as compromised Rotate any Anthropic API key or other secrets used on a vulnerable version, and assume workspace-scoped access may already have been exposed.
• Inventory every agent and MCP path Discover all agentic tools, MCP servers and LLM integrations across laptops, CI pipelines and developer environments before setting policy.

Key takeaways

• Claude Code’s disclosed weaknesses show that agentic coding tools can convert untrusted repository content into executable behaviour, which is a runtime governance problem rather than a code-quality problem.
• The article’s most important evidence is a combination of CVEs, a public source-code leak and a reverse-shell proof of concept, all of which demonstrate that static review does not fully capture agentic risk.
• The most effective control shift is toward runtime visibility, constrained tool permissions and tighter handling of secrets, shells and MCP-connected workflows.

Key terms

• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
• Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Tool Abuse: Tool abuse occurs when an AI assistant is manipulated into making actions through connected APIs, plugins, or workflows that the user did not intend. The risk is not only incorrect output, but execution of legitimate systems with attacker-chosen inputs or destinations.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and agentic AI identity for practitioners building control around privileged automation. It helps security and identity teams translate runtime risk into operational policy across their programmes.