Claude Code sandboxing exposes the real gap in agent governance

At a glance

What this is: This is a vendor analysis of Claude Code sandboxing that argues isolated runtimes are necessary but insufficient for governing a mixed fleet of coding agents.

Why it matters: It matters because IAM and security teams now need consistent controls for non-human identities that read files, call tools, and reach production systems across multiple development environments.

By the numbers:

• Anthropic’s classifier catches roughly 83% of overeager actions before execution and cuts approval prompts by 84%.
• 17 minutes.
• Only 44% of developers are reported to follow security best practices for secrets management.

👉 Read Highflame's analysis of Claude Code sandboxing and fleet-wide agent governance

Context

Claude Code sandboxing is the practice of isolating a coding agent so it can read files, run shell commands, and use tools without unrestricted access to the host system or network. The governance problem is not whether one sandbox can block one command, but whether security teams can apply one policy across every coding agent, IDE, and MCP-connected workflow in the fleet. In environments where developers adopt multiple agents quickly, the primary IAM issue is consistency of control, not the presence of another point solution.

The article frames a familiar identity problem in a new runtime: non-human identities are now executing instructions inside development workflows, but each tool arrives with its own approval prompts, settings, and trust boundary. That means repository content, tool descriptions, and MCP servers all behave like inputs to be governed, not just code to be scanned. The typical starting position is already fragmented, which is why the control question is organisational rather than purely technical.

Key questions

Q: What breaks when teams rely on sandboxing to secure coding agents?

A: The assumption that container isolation limits real damage breaks down as soon as the agent holds valid GitHub, cloud, or browser credentials. The sandbox may protect the host, but it does not stop authorized misuse of trusted APIs. Teams end up with a hardened runtime and an overpowered identity.

Q: Why do coding agents increase risk when they can read repositories and call tools?

A: They turn ordinary project content into executable guidance. A poisoned README, config file, or tool description can steer the agent toward credential discovery, data collection, or exfiltration using its own legitimate permissions. The risk comes from delegated action, not from malware in the traditional sense.

Q: What are the warning signs that an MCP server is too trusted?

A: The main signs are broad tool descriptions, remote servers that can change behaviour after approval, risky local STDIO wrappers, and outputs that can shape later agent decisions. If the server can reach production systems or return instruction-like text, it should be treated as a delegated access path, not a harmless connector.

Q: How should security teams verify AI-generated code across multiple coding agents and IDEs?

A: Security teams should apply one independent verification layer across every coding tool, IDE, and agentic workflow. The goal is to enforce the same quality and security standards as code is generated, not after it reaches CI. That reduces drift, catches issues earlier, and prevents different tools from creating different trust boundaries inside the same codebase.

Technical breakdown

How coding agent sandboxes enforce runtime isolation

A coding-agent sandbox constrains what the agent can touch at the operating-system layer. The article describes Seatbelt on macOS, bubblewrap on Linux, filesystem mount modes, and proxy-based egress control as deterministic boundaries that stop a process from freely reading, writing, or exfiltrating data. This matters because prompt injection and model mistakes are probabilistic, while sandbox controls are enforceable. The key design point is that the sandbox sits below the model, so it can block a harmful action even when the model still attempts it.

Practical implication: treat filesystem and egress isolation as the non-negotiable base layer for any coding agent that can reach secrets or production endpoints.

Why prompt injection in repositories becomes an execution problem

The article’s poisoned README example shows that prompt injection is not just a text problem. Once the agent ingests malicious instructions from a repository, it can use legitimate tools such as ls, grep, and curl to carry out the attacker’s objective. Malware scanning does not help because the payload is behavioural, not binary. This is the same NHI pattern seen in other agentic systems: the identity is manipulated through context, then translated into tool use through its own privileges and runtime permissions.

Practical implication: scan cloned repositories as adversarial input before an agent consumes them, and keep secrets out of the runtime entirely.

Why MCP servers are a supply-chain control point

Model Context Protocol servers are the bridge between agents and external tools such as GitHub, Slack, databases, and internal APIs. The article notes that the dangerous part is not only the tool call itself but the metadata, descriptions, and returned text that guide the agent’s next decision. A compromised or poorly configured MCP server can therefore steer actions, inject instructions, or expand blast radius quietly. For IAM teams, MCP is where delegated access, tool trust, and identity-bound permissions converge.

Practical implication: audit MCP servers as third-party code with live reach, not as harmless integrations.

Threat narrative

Attacker objective: The attacker wants the coding agent to locate secrets and exfiltrate them through a legitimate-looking workflow.

1. Entry occurs when a developer clones a repository containing a prompt injection hidden in a README file, giving the agent adversarial instructions through normal context ingestion.
2. Escalation happens when the agent uses its own file and shell privileges to search for environment files, credentials, and data paths that can be abused.
3. Impact follows when the agent attempts a curl POST to an attacker-controlled endpoint, turning tool use into attempted data exfiltration.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

One sandbox per agent is a control boundary, not a governance model: Anthropic can secure Claude Code because it owns the model, runtime, sandbox, and network path end to end. Most enterprises do not have that condition, because developers are running multiple coding agents with different approvals and settings across different IDEs. The implication is that fleet-wide agent governance must be external to any one runtime.

Repository content is now adversarial input for coding agents: A README that instructs an agent to locate credentials and post them elsewhere is not a rare trick, it is the runtime version of prompt injection. This means code review, malware scanning, and developer trust assumptions do not fully cover the threat surface. Practitioners need to treat cloned project content as something an agent can obey, not just read.

MCP creates a new identity trust boundary around tool metadata: Tool names, descriptions, and outputs are part of the control plane the agent uses to decide what to do next. A compromised MCP server can steer behaviour without looking like a malicious command, which makes the trust problem fundamentally different from traditional API access. The practitioner conclusion is that MCP governance belongs in the identity and access model, not only in application security.

Central policy matters more than per-tool knobs when the fleet is heterogeneous: Cursor, Claude Code, Copilot, Gemini CLI, and internal agents each expose different approvals and controls, so local configuration cannot produce consistent governance at scale. This is a policy fragmentation problem, not a tooling preference problem. Security teams should view one centrally owned policy surface as the control that makes agent oversight auditable across the estate.

Agent governance is now an access review problem for NHI estates: The same discipline used for service accounts applies here, but the subject is a software identity that reads, decides, and acts in the development workflow. The problem is not just preventing exfiltration, it is proving which agents exist, what they can reach, and which tools they are allowed to call. That is the control plane IAM teams should own.

From our research:

• Anthropic’s classifier catches roughly 83% of overeager actions before execution and cuts approval prompts by 84%, according to Analysis of Claude Code Security.
• A separate NHI finding shows attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, which is why runtime containment alone is never enough.
• Ultimate Guide to NHIs , 2025 Outlook and Predictions is the next step for teams that need to connect agent governance to broader lifecycle control.

What this signals

Claude Code sandboxing is a useful runtime pattern, but the governance gap sits above the sandbox. Security teams now need to know which agents exist, which tools they can call, and which data sources they can touch across the whole development estate. That is an identity governance problem first and a containment problem second.

Tool trust has become part of the non-human identity lifecycle. When an agent inherits permissions from repositories, MCP servers, and IDE settings, offboarding and recertification need to include those delegated paths, not just user accounts. The practical question is whether your programme can revoke tool reach as cleanly as it revokes access for a service account.

With 6 distinct secrets manager instances on average, fragmentation is already normal in the secrets layer, according to The State of Secrets in AppSec. That fragmentation becomes more dangerous when coding agents can read from multiple repos and connectors at once, because policy drift multiplies faster than teams can review it. The answer is central policy, not more per-tool exceptions.

For practitioners

• Inventory every coding agent in use Build a register of all external and internal agents running in developer workflows, including IDE plugins, CLI tools, and MCP-connected services. Track who can launch them, what data they can reach, and which repos they are allowed to open.
• Treat cloned repositories as hostile inputs Insert pre-ingestion scanning and content inspection before an agent reads a new repository, README, or project config. Block credentials, suspicious instructions, and tool-guidance patterns that could redirect agent behaviour.
• Govern MCP servers as delegated access paths Review every MCP server for tool scope, returned text, and risky STDIO or remote configurations. Pin trusted servers, restrict their network reach, and revoke any integration that can change behaviour after approval.
• Keep secrets out of agent runtimes Prevent environment files, API keys, and session tokens from entering the agent’s working context. If the secret never reaches the sandbox, prompt injection and tool misuse have far less to exploit.
• Centralise policy across every IDE and agent Move approval logic, deny rules, and escalation paths into one security-owned policy layer that applies consistently across Cursor, Claude Code, Copilot, Gemini CLI, and internal assistants.

Key takeaways

• Coding agent sandboxes are necessary, but they only solve one layer of the governance problem.
• Prompt injection, repository content, and MCP metadata now function as identity attack surfaces for non-human actors.
• Fleet-wide policy ownership is the control that turns scattered agent use into something security teams can actually govern.

Key terms

• Coding Agent Sandbox: An isolated runtime that limits what a coding agent can read, write, or reach while it processes files and uses tools. It reduces blast radius when the agent is tricked or makes a harmful choice, but it does not replace governance across multiple agents or tools.
• 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.
• Agent Fleet Governance: The practice of applying one security-owned policy across many non-human identities, tools, and IDEs so approvals, logging, and access decisions stay consistent. It is the control model that keeps agent use auditable when a workforce adopts multiple assistants at once.
• Deterministic Boundary: A deterministic boundary is a security control that enforces behaviour without relying on an AI model to interpret policy correctly. Domain matching, item scoping, lock state, and confirmation prompts are examples because they constrain action regardless of prompt content or model output.

What's in the full article

Highflame's full analysis covers the operational detail this post intentionally leaves for the source:

• A deeper breakdown of the sandbox-runtime controls Anthropic uses on macOS and Linux.
• Action-by-action scoring examples showing how the poisoned repository attack is evaluated across the session.
• Specific notes on MCP server auditing, tool-output inspection, and risky STDIO configurations.
• Coverage comparison guidance for teams using Cursor, Claude Code, Copilot, Gemini CLI, and internal agents.

👉 The full Highflame post covers the attack sequence, runtime controls, and policy coverage gaps in more detail.

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 building or maturing an IAM programme, it is worth exploring.