TL;DR: Default sandboxes in Claude Code, Gemini CLI, and Codex failed under real testing, leaking credentials through permission rules, process isolation gaps, and kernel boundary weaknesses, according to Novee’s DefCon 2026 research. The result is that unattended AI agents expose a containment problem, not just a prompt-injection problem: the controls assumed a human could still arbitrate risk.
At a glance
What this is: Novee’s research shows that default containment models in three AI agent tools failed to stop credential leakage across permission, process, and kernel boundaries.
Why it matters: IAM, PAM, and NHI teams need to treat agent containment as an identity and access control problem because unattended agents can reach secrets the same way any other privileged executor can.
By the numbers:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope.
👉 Read Novee's research on breaking Claude Code, Gemini CLI, and Codex sandboxes
Context
AI agent sandboxes are intended to contain tool use, file access, and command execution when an agent runs without direct human oversight. This article shows why that containment model fails when the sandbox’s policy, process, or kernel boundaries do not actually match the environment the agent can reach, especially in agentic AI identity and NHI governance programmes.
The primary issue is not prompt injection alone. When an agent is unattended in CI, cron, or background automation, the harness becomes the effective access control layer, which means IAM, PAM, and secrets governance must account for the identity the agent is acting as, the permissions it can inherit, and the paths it can still touch.
Key questions
Q: What breaks when AI agent sandboxes rely on a human approval model?
A: The approval model breaks when the agent runs unattended and there is no human available to answer an ask prompt. In that setting, broad preapproved tool access can override the intended containment policy, so the sandbox no longer enforces a real decision boundary. The result is that the harness behaves like a convenience layer rather than a control.
Q: Why do process-isolated AI agents still expose credential risk?
A: Process isolation reduces exposure, but it does not automatically remove access to shared runtime state. If the child process can still infer or reach sensitive material through parent processes, /proc, inherited descriptors, or workflow artefacts, credentials can leak even when environment variables are sanitised. Containment has to cover the full runtime boundary, not only the spawned shell.
Q: How do security teams know if an AI agent sandbox is actually working?
A: A working sandbox should stop execution, block privilege expansion, and prevent the agent from touching sensitive context even when the model is manipulated. If the agent can still download files, run code, access credentials, or write back into its own queue, the sandbox is only containment in name, not in effect.
Q: When should organisations treat AI agent containment as an IAM problem?
A: Treat it as an IAM problem whenever the agent can read secrets, write to trusted workflow paths, or invoke tools without direct human approval. At that point, the harness is making authorisation decisions on behalf of the organisation, so access scope, delegated authority, and offboarding matter as much as they do for service accounts and privileged users.
Technical breakdown
Permission rules in Claude Code and why ask becomes allow
Claude Code relied heavily on permission decisions such as deny, ask, and allow. In interactive use, ask works because a human can inspect the operation and decide. In unattended automation, the same model breaks if tooling converts ask into broad allow lists for practicality. The article shows that tool-level permissions can be bypassed when the policy engine treats broad approval as equivalent to per-request authorisation. That creates a containment gap between intent and actual enforcement, especially when file tools and shell tools are governed differently.
Practical implication: review whether your agent harness turns human approval into blanket tool approval anywhere in the path.
Process isolation and why sanitised environments still leak
Gemini CLI used process isolation by spawning child processes with a sanitised environment while the parent retained sensitive material. That design assumes the child process cannot reach the parent’s secrets through shared system state such as /proc, inherited file descriptors, or observable workflow artefacts. The article demonstrates that sanitising environment variables is not the same as eliminating access to ambient process data. The model is only as strong as the enforcement boundary, not the intention behind it.
Practical implication: verify that your process boundary prevents reads from parent state, not just environment-variable inheritance.
Kernel enforcement, sandbox escape paths, and trusted output files
Codex pushed containment down to the kernel with Landlock, bubblewrap, and seccomp, but the article still found write and exfiltration paths because the parent process retained authority outside the sandbox. That matters because a sandbox can prevent direct network access and still be vulnerable if a trusted parent writes attacker-influenced bytes to a file that later affects workflow execution or visibility. In other words, a read-only sandbox can still become a write or exfiltration problem when the handoff back to the parent is weak.
Practical implication: validate every parent-child handoff path, especially trusted output files and workflow variables.
Threat narrative
Attacker objective: The attacker wants to convert agent execution into secret exposure, host-level write capability, or workflow compromise without needing to break the underlying model directly.
- Entry occurred through untrusted agent input such as prompts, issues, or workflow content that the agent was allowed to process inside its own runtime.
- Credential access followed when the agent could still reach secrets through permission overrides, shared process state, or trusted output paths that were not fully contained.
- Impact was credential leakage and host-side write or exfiltration, including paths that let attacker-influenced content escape the sandbox boundary.
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
Agent sandboxes are identity controls, not just runtime controls: The article shows that once an AI agent can act unattended, containment becomes part of identity governance, not merely application hardening. The effective question is who or what is authorised to touch secrets, write files, and trigger downstream actions when no human is present. Practitioners should treat the harness as an access enforcement layer, not a convenience wrapper.
The core failure is assumption collapse, not just a missing safeguard: The assumption that a human will review risky actions was designed for interactive use. That assumption fails when the actor is autonomous enough to run in CI, cron, or background workflows because approval is no longer available at execution time. The implication is that access governance must stop assuming a stable human reviewer behind every action.
Runtime containment gap: A sandbox can only enforce the boundaries it actually knows how to model, and these examples show that file access, environment state, and parent-process authority are often outside that model. That means the visible policy may look strict while the real authority still lives elsewhere in the delegation chain. Practitioners should audit where the true decision point sits, not where the tool claims containment exists.
AI agents expose an NHI governance problem with a new shape: The same controls used for service accounts and workloads now need to account for tool use, delegated execution, and transient access paths inside agent runtimes. This is where OWASP-NHI and zero-trust access assumptions intersect with agentic AI. The practical conclusion is that identity scope must be traced through the harness, not just through the account.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to the AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- Use OWASP Agentic AI Top 10 to map agent containment failures to concrete governance and threat categories before deployment expands further.
What this signals
With 80% of organisations already reporting AI agents acting beyond intended scope, the governance gap is no longer hypothetical. Agent sandboxes need to be managed as delegated access controls, with explicit ownership across IAM, PAM, and platform teams, not left as an application-layer afterthought.
Runtime containment gap: the next wave of agent risk will not come only from prompt injection, but from weak handoffs between the agent, its parent process, and the workflow system that trusts its output. That makes trusted output paths and privileged parent writes high-value review points in any agent programme.
Practitioners should align this problem space with OWASP Top 10 for Agentic Applications 2026 and apply the same discipline used for NHI lifecycle controls to agent runtimes that can read, write, and delegate within one execution boundary.
For practitioners
- Audit the harness as an access control layer Map which agent actions are governed by explicit deny rules, which collapse into broad allow behaviour, and which rely on a human review step that disappears in unattended execution.
- Separate parent authority from child execution Identify every path where the parent process, runner, or workflow controller still holds secrets or write privileges after sandbox startup, then treat those paths as part of the agent’s effective access boundary.
- Test output-handling for write-through abuse Check whether trusted files, workflow variables, or step summaries can be replaced, redirected, or reused so attacker-influenced bytes escape the sandbox through a privileged parent write.
- Trace credential exposure through shared runtime state Look beyond environment-variable redaction and test /proc, inherited descriptors, and other host artefacts that can still reveal secrets to agent-driven processes.
- Reclassify agent sandboxes under NHI governance Assign ownership for agent harnesses to identity, PAM, and platform security teams so containment failures are reviewed as delegated access failures, not only application bugs.
Key takeaways
- Default AI agent sandboxes failed across three containment layers, which shows that policy, process, and kernel controls can all miss the real authority path.
- The most important risk is delegated access without reliable containment, because unattended agents can still reach secrets or trusted workflow outputs.
- Security teams should treat agent harnesses as identity enforcement points and test them like privileged access paths, not like ordinary application wrappers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent containment and tool misuse | The article is about agent sandbox failure and tool-use boundaries. |
| Recommendation — Map sandboxed agent behaviours to agent containment requirements and restrict tool reach to the minimum viable set. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Management | Credential leakage is the primary outcome across all three sandbox failures. |
| Recommendation — Apply NHI-03 controls to prevent agent runtimes from reaching credentials through files, environment state, or workflow outputs. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The article centres on whether the agent is actually authorised to reach what it can touch. |
| Recommendation — Review access permissions for agent harnesses and remove any authorisation path that exceeds the intended trust boundary. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Broken sandboxes showed that overbroad permissions and inherited authority are the central issue. |
| Recommendation — Enforce AC-6 so agent runtimes cannot inherit broader access than each task requires. | ||
| NIST Zero Trust (SP 800-207) | 3e — Continuous verification and policy enforcement | The article shows static trust assumptions failing once the agent executes unattended. |
| Recommendation — Apply zero-trust verification to every agent action path and revalidate trust at each tool boundary. | ||
Key terms
- Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
- Sandbox containment: Sandbox containment is the practice of limiting what an executing workload can do after trust has already been extended to it. In AI coding agents, it reduces blast radius, but it does not make the input trustworthy or remove the need to control secrets, mounts, and egress.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Parent-Child Trust Gap: The parent-child trust gap is the difference between what a sandboxed child process is supposed to be able to do and what the parent process still can do on its behalf. This gap often creates leakage paths through shared state, output files, or inherited privileges.
What's in the full article
Novee's full research covers the operational detail this post intentionally leaves for the source:
- Exact code paths and permission checks that let ask collapse into allow in Claude Code.
- Step-by-step reproduction of the Gemini CLI process-isolation failure and its secret-exposure path.
- Codex sandbox escape mechanics, including the parent write-through behaviour and symlink abuse.
- Command-line examples and disclosure details for the two Claude CVEs and the Codex escape paths.
👉 The full Novee article covers the exploit chains, proof points, and code-level boundary failures.
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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org