Claude Code sandboxing exposes the real gap in agent governance

At a glance

What this is: This is an analysis of Claude Code sandboxing and why agent governance breaks down once organisations run multiple coding agents across different IDEs and controls.

Why it matters: It matters because IAM and security teams need a fleet-level governance model for coding agents, not just isolated runtime containment for one tool or one developer.

Context

Claude Code sandboxing is the practice of placing a coding agent inside an isolated runtime so it can read files, run commands, and call tools without unrestricted access to the host or network. The article’s core point is that this containment model works for one agent, but most organisations are now running several agents with different settings, approvals, and trust assumptions.

That creates a governance gap, not just a runtime problem. The question for IAM, PAM, and security architecture teams is who owns policy across the whole agent estate, how tool access is supervised, and how auditability is maintained when agents operate inside multiple IDEs and MCP-connected services.

Key questions

Q: What breaks when coding agents are governed one tool at a time?

A: Governance becomes inconsistent, because each agent or IDE ends up with its own approvals, settings, and logs. That fragmentation prevents security teams from enforcing one policy, comparing behaviour across tools, or proving what happened during an incident. The result is not just operational complexity, but an audit gap across the fleet.

Q: Why do MCP servers create governance risk when agents scale across an enterprise?

A: MCP servers create governance risk because scale introduces duplicate servers, scattered credentials, unclear ownership, and inconsistent policy enforcement. When agents can connect to many tools without a central registry, platform teams lose visibility into who uses which server and under what conditions. That makes compliance, incident response, and access review much harder.

Q: How do security teams know if coding agent monitoring is actually working?

A: Monitoring is working when it can correlate session behavior, file access, tool use, and network attempts into a single investigative trail. Useful signals include taint tracking after sensitive file access, anomaly detection after external content ingestion, and alerts on writes to restricted paths. If those patterns are visible, the program can distinguish intended work from manipulated behavior.

Q: Should organisations sandbox AI coding agents before expanding their permissions?

A: Yes. Sandbox containment should come before broader permissions because it limits blast radius when the agent misfires, hits a malicious dependency, or follows a poisoned prompt. In practice, the sandbox provides the controlled place to test trust assumptions before the agent is allowed to touch production-aligned repositories or deployment paths.

Technical breakdown

How sandboxing contains one coding agent

A sandbox constrains what a coding agent can reach at runtime. In the article’s model, the agent can read files, execute shell commands, and call tools, but filesystem permissions, network egress controls, and credential isolation limit what those actions can touch. That is effective when the attack path depends on the agent crossing an OS or network boundary. The important distinction is that sandboxing controls execution environment, not organisational governance. It can stop a command from leaving the machine, but it cannot tell a security team that the attempt happened across the fleet.

Practical implication: treat sandboxing as a runtime containment layer, not as the fleet governance model for coding agents.

Why MCP servers expand the trust boundary

The Model Context Protocol gives agents access to external tools, data sources, and internal systems. That makes the MCP server part of the trust boundary, because tool names, descriptions, and returned output can influence agent behaviour even when the prompt itself looks harmless. The article’s warning is that a compromised or badly configured MCP server can steer the agent toward data access or exfiltration without needing malware in the traditional sense. In other words, the agent is not only reading instructions from the user but also from connected tooling metadata.

Practical implication: inventory and govern MCP servers as privileged supply-chain components, not as ordinary integrations.

Why central policy matters more than per-agent settings

Per-agent approval prompts and local configuration knobs do not scale once developers use several assistants across several IDEs. The article describes a governance pattern where one policy engine evaluates actions consistently, regardless of whether the developer is using Cursor, Claude Code, Copilot, or Gemini CLI. That is a fleet-control problem. Without central policy, teams end up with fragmented logs, inconsistent approval thresholds, and no reliable way to replay or compare agent behaviour across environments. Governance weakens precisely where operational diversity increases.

Practical implication: define one policy model for coding-agent actions and apply it consistently across all developer environments.

Threat narrative

Attacker objective: The attacker wants the coding agent to locate credentials or sensitive data and exfiltrate them through tool use or allowed network paths.

1. Entry occurs when a developer clones a repository that contains prompt injection in a README or similar project file, causing the agent to ingest hostile instructions as context.
2. Credential access follows when the agent searches for environment files and credential-bearing code paths, then prepares to use that material in later tool calls.
3. Escalation to exfiltration happens when the agent attempts to post sensitive material to an attacker-controlled endpoint or through an allowed external path.
4. Impact is the exposure of secrets or internal data, unless the sandbox or policy layer blocks the action before it leaves the environment.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• 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.

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

Sandboxing is necessary, but it is not governance: A runtime boundary can stop one agent from reaching the host or network, yet it says nothing about how dozens of agents are configured, approved, and audited across an organisation. The article shows that the deterministic boundary matters, but the governance failure is fleet-wide consistency. The implication is that security teams must distinguish containment from control-plane ownership.

MCP servers are a delegated trust layer, not a neutral transport: The article correctly treats tool metadata and tool output as a security boundary because agents act on what those descriptions tell them to do. That means compromise can arrive through ordinary-looking connector behaviour rather than through overt malware. Practitioners should treat MCP governance as part of identity and privilege management for agents, not as a minor integration concern.

One policy per agent is operational debt: When each IDE and coding agent carries its own settings, approvals, and logs, governance fragments faster than teams can standardise it. That fragmentation creates blind spots in auditability, response, and privilege review. The practical conclusion is that the control problem is not which agent is safest, but how to make policy portable across the whole fleet.

Fleet-wide agent governance is becoming the real control surface: The article sharpens a useful concept here, the agent governance gap, meaning the distance between local containment and enterprise-wide control. As the number of developer assistants grows, that gap becomes the place where secrets exposure, policy drift, and audit failure accumulate. Teams should model the control plane first, then decide which sandboxes to trust under it.

Access review logic does not map cleanly onto distributed coding agents: Human-centric review cycles and per-tool approvals assume a stable administrative boundary and a small number of named systems. A multi-agent environment breaks that assumption because the effective actor is now a fleet of tools, prompts, and connectors. The implication is that governance needs to move from static approval to continuous policy enforcement across all agent sessions.

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.
• Read next: AI Agent Authorisation Guide

What this signals

The governance problem here is not confined to Claude Code or to one vendor stack. As coding agents spread into IDEs, CLIs, and internal workflows, the control question shifts from whether a sandbox can stop a single bad action to whether the organisation can enforce a single policy across every agent session.

Agent governance gap: The useful concept in this article is the distance between local runtime containment and enterprise-wide policy ownership. Security teams should expect that gap to widen as more developer assistants and MCP-connected tools enter day-to-day use, which means agent inventory, policy consistency, and audit replay need to be designed together.

Teams that still manage agents as isolated tools will struggle to prove that secrets never entered the runtime, that MCP servers were reviewed consistently, or that action decisions were enforced the same way across products. The practical shift is from per-agent approval to policy-as-control-plane for the whole developer estate.

For practitioners

• Inventory every coding agent in use Build a current register of assistants, IDE plugins, CLI agents, and internal agents, then map who can enable them and what each one can reach.
• Classify MCP servers as privileged integrations Review every MCP server for tool scope, output handling, and change control, and treat remote servers as third-party code with delegated access.
• Centralise action policy across IDEs Use one policy model for prompts, tool calls, and shell actions so Cursor, Claude Code, Copilot, Gemini CLI, and internal agents follow the same decision rules.
• Keep secrets out of agent runtimes Prevent credentials from entering prompts, local files, or sandboxed environments unless they are explicitly required for a scoped task, then revoke them after use.
• Turn agent actions into auditable evidence Retain replayable logs for prompt, tool call, policy decision, and output so investigators can reconstruct what an agent attempted and why it was blocked or allowed.

Key takeaways

• Sandboxing can stop a single agent from crossing a runtime boundary, but it does not solve enterprise governance across multiple coding assistants and IDEs.
• MCP servers and project-local content expand the trust boundary because agents act on tool metadata and repository text as part of normal operation.
• The control that changes outcomes is fleet-wide policy, supported by inventory, audit replay, and connector oversight, not isolated runtime containment alone.

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 Governance: Agent governance is the set of policies, controls, and evidence required to manage autonomous software as a non-human identity. It covers consent, tool access, lifecycle review, audit logging, and revocation so that an agent remains bounded as its workflows change.
• Fleet Policy Enforcement: Fleet policy enforcement is the process of detecting and responding to behavior that violates operational rules for vehicles, drivers, or usage. It depends on monitoring, analytics, and alerting that turn raw fleet data into decisions. In connected fleets, this can include misuse, fraud attempts, theft signals, and risky driving behavior.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.