Claude Code vulnerabilities show why agentic AI needs runtime controls

At a glance

What this is: This is an analysis of Claude Code vulnerabilities, showing how agentic execution, shell access, and untrusted repository content create real exploitation paths.

Why it matters: It matters because security teams now need to govern AI agents, MCP connections, and secrets exposure with the same discipline they apply to privileged identity and runtime access.

By the numbers:

• In March 2026, the @anthropic-ai/claude-code 2.1.88 package included a 59.8 MB JavaScript source map and a 1,906-file, 513,300-line unobfuscated TypeScript source file.
• 2.0.65 (January 2026).
• Anthropic has reported seeing a 30 to 40 percent reduction in security-related PR comments after implementing its free Claude Code Security plugin.

👉 Read Akto's analysis of Claude Code vulnerabilities and runtime defense paths

Context

Claude Code is an agentic AI coding tool that can read, write, and execute inside a developer workflow, which means its attack surface is defined by runtime permissions as much as by code quality. For Claude Code security, the core problem is that untrusted repository content, shell access, environment variables, and MCP connections can all be interpreted as operational inputs, not just data.

That creates an identity and governance problem, not only a software defect problem. AI agents that can reach tools, keys, and network endpoints need controls for privilege, delegation, and trust boundaries, because the line between a prompt, a configuration file, and an executable instruction becomes too thin to rely on manual review alone.

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: Why do AI coding environments create more secret exposure risk than standard developer tools?

A: They can inspect repository context, read dotfiles, and infer where credentials are stored, then act on that information through commands or file changes. That means secrets can be exposed both by reading them and by persisting changes that keep access alive. Teams should assume workstation-local state is part of the secret attack surface.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: Who is accountable when an autonomous assistant exfiltrates secrets or runs destructive commands?

A: Accountability sits with the team that granted the assistant its tool access, data access, and execution paths. For governed environments, that responsibility also extends to the controls that failed to separate instruction content from runtime authority. If the agent can act without a control gate, the governance gap is structural.

Technical breakdown

How untrusted content becomes execution in agentic coding tools

Claude Code’s risk comes from the way it treats repository content as part of the working context while also holding permission to run commands, edit files, and reach external services. In that model, a README, hook, package manifest, or error message is not just text. It can influence the agent’s next action loop. That is why indirect prompt injection matters here: the attacker does not need to change the user’s prompt, only the content the agent reads before deciding what to do. Static review misses this because the harmful action is created at runtime, not in the source tree itself.

Practical implication: treat untrusted repositories and dependencies as executable until runtime controls verify their behaviour.

Why secrets and environment variables are exposed through tool use

An agentic terminal tool can inherit the developer’s environment, which often includes API keys, cloud credentials, and tokens. Once a malicious repository or injected instruction causes the agent to call shell commands or redirect network traffic, those secrets can be exfiltrated without any obvious code change in the repository. This is an identity problem because the agent is effectively operating with borrowed credentials and delegated authority. In practice, the blast radius is determined by what secrets are present in the session, what the agent can send over the network, and whether those credentials are scoped to a single task or to an entire workspace.

Practical implication: reduce the standing value of every development session by scoping secrets tightly and isolating agent runtime access.

Why runtime detection beats static review for agentic AI security

The article’s central technical point is that some failures only exist when the agent runs, not when the code is scanned. A reverse shell triggered from a DNS response, a consent bypass hidden in configuration, or a trust-dialog flaw that executes before approval all demonstrate the same pattern. In agentic systems, security controls need to observe tool calls, network egress, command chains, and abnormal loops while the task is in motion. That is the difference between reviewing a prompt and governing an autonomous execution path.

Practical implication: add behavioural monitoring and policy enforcement at runtime, not only pre-merge or pre-release checks.

Threat narrative

Attacker objective: The attacker wants command execution and credential theft from a trusted developer environment so they can reuse those privileges elsewhere.

1. Entry occurs when a developer opens an untrusted repository or when a package, hook, or project file is loaded into the agent’s working context.
2. Credential access follows when the agent executes attacker-influenced commands or redirects traffic, exposing environment-held secrets such as API keys and cloud tokens.
3. Impact occurs when the attacker obtains shell execution or stolen credentials that can be reused against the developer’s workspace and connected services.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Agentic coding tools have become non-human identities with delegated execution power. Claude Code does not merely assist with code suggestions. It can operate terminal commands, move through files, and call external services, which gives it an identity-like role inside the development environment. That makes governance questions about who or what is authorised to act, under what scope, and with what review boundary. Practitioners should treat tool-using AI systems as controlled identities, not as chat interfaces.

Runtime trust collapse is the specific failure mode this article exposes: the agent cannot reliably separate instructions from content once repository artefacts enter context. That means hooks, environment variables, MCP definitions, and error files can become covert command channels. The governance lesson is not that developers need more caution. It is that the control model must assume content can alter behaviour at execution time. Practitioners should design for instruction-content ambiguity.

Static review is losing relevance as a primary control for agentic workflows. Code scanning is still useful, but it is incomplete when the harmful payload is generated or fetched at runtime. This is where NIST AI RMF governance and OWASP Agentic AI Top 10 concerns converge with identity governance: authority, delegation, and runtime observability now matter more than repository hygiene alone. Practitioners should add behavioural controls that watch what the agent actually does.

Secrets exposure becomes a session-level governance problem once agents inherit developer credentials. The article’s examples show that one compromised repository can turn a normal workspace into a credential harvesting opportunity. That is why secret scope, session isolation, and tool-level permissions need to be managed as a single policy surface. Practitioners should narrow what any agent can see, run, and export.

Claude Code security is really a control-plane question for AI-driven development. The more the tool can read, write, execute, and delegate through MCP, the more the environment needs policy boundaries that follow the task. This aligns with workload identity and privileged access thinking, even in a developer tool context. Practitioners should govern agent behaviour as an access problem, not only as an application security problem.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, despite 92% agreeing that governing them is critical to enterprise security.
• OWASP Agentic AI Top 10 is the next resource for mapping these runtime failures to control priorities.

What this signals

Runtime privilege control is becoming the decisive control point for agentic development. The practical problem is no longer only whether an agent can generate code, but whether it can reach commands, secrets, and network paths that security never intended it to use. As AI agents expand into developer workflows, programmes need to align policy, telemetry, and isolation around the session rather than the repository.

Instruction-content ambiguity is a governance gap, not a user error. Once agents read untrusted material and treat it as context, the boundary between information and instruction starts to fail. That pushes teams toward behavioural policy enforcement, stronger workload identity controls, and tighter separation between approval, execution, and export.

AI agent identity management will sit beside secrets governance and application security. The article points toward a future where every agent, MCP server, and automated workflow needs an inventory, an owner, and a constrained permission set. Organisations that do not build that control plane now will continue to discover the risk only after a key or shell has already been exposed.

For practitioners

• Isolate agent execution from trusted developer environments Run agentic coding tools in containers or VMs with tightly scoped filesystem, network, and credential access. Keep high-value tokens out of the default shell environment, and separate build, test, and internet access so one compromised task cannot reach everything.
• Treat repositories and dependencies as untrusted inputs Block automatic execution of hooks, bootstrap scripts, and build-time commands in newly cloned or third-party repositories until they pass explicit review. Require allowlisted commands for agent-driven tasks, especially when configuration files can alter endpoints or execution flow.
• Monitor tool calls and network egress during runtime Add behavioural detections for abnormal shell usage, unexpected outbound requests, repeated loops, and agent actions that diverge from the task prompt. Runtime policy should stop or quarantine activity before secrets leave the session.
• Scope secrets to the smallest possible session boundary Use short-lived credentials, separate workspace tokens, and task-specific secret injection so compromise of one agent session does not expose broader cloud or source-control access. Revoke and replace exposed keys immediately after any suspected runtime abuse.
• Inventory shadow AI and MCP endpoints continuously Discover all AI agents, MCP servers, and LLM-integrated tools across developer laptops, CI pipelines, and shared platforms. Continuous inventory is necessary because unmanaged agent paths create hidden access channels that security teams cannot otherwise govern.

Key takeaways

• Claude Code security failures show that agentic AI can turn routine developer workflows into execution and exfiltration paths.
• The evidence is not theoretical: a source leak, disclosed CVEs, and a reverse-shell proof of concept all point to runtime abuse, not just code defects.
• The control that matters most is runtime governance, because static review alone cannot reliably stop AI agents from acting on hostile content.

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.
• 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.
• 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.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

Akto's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of CVE-2025-59536 and CVE-2026-21852 exploitation paths
• Repository, hook, and MCP abuse patterns that show how prompts become command execution
• Runtime defense examples for blocking tool misuse, abnormal loops, and credential export
• Practical notes on validating protections in CI/CD rather than only during code review

👉 The full Akto post covers exploitation paths, reverse-shell behaviour, and runtime controls in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to connect identity controls to real operational risk across modern security programmes.