TL;DR: Claude Code can be pushed from safe-seeming sandboxed execution into unsafe behaviour through indirect prompt injection, payload adaptation, and configuration persistence, with containment limiting impact but not stopping malicious execution, according to CRACKEN. The result is a cognitive attack surface where agent reasoning, not just runtime isolation, becomes the control boundary that matters most.
NHIMG editorial — based on content published by CRACKEN: Agentic AI Red-Teaming the Agentic Red-Teamer, Part 2
By the numbers:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: What breaks when an AI agent is compromised during active execution?
A: What breaks is the human incident response model.
Q: Why do agentic AI systems complicate identity governance more than traditional service accounts?
A: Traditional service accounts usually follow fixed workflows, while agentic systems can choose actions and sequence them at runtime.
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.
Practitioner guidance
- Implement execution approval gates for risky agent actions Require explicit approval or policy evaluation before agents can run binaries, modify configs, or invoke shell commands outside a narrow allowlist.
- Monitor agent configuration drift as privileged change Treat ~/.claude/settings.json, hooks, plugin settings, and startup commands as high-risk configuration assets with change alerts and periodic review.
- Separate task completion from trust decisions Design workflows so an agent cannot infer authorization from task context alone.
What's in the full article
CRACKEN's full blog covers the experimental detail this post intentionally leaves for the source:
- Step-by-step reproduction of the sandboxed and non-sandboxed Claude Code runs, including the permission settings that changed the outcome.
- The exact payload adaptation techniques used to influence agent reasoning and bypass containment assumptions.
- Configuration-hook examples that show how persistence was embedded into startup behaviour.
- The code-level sandbox detection logic and proxy-handling flow used in the test environment.
👉 Read CRACKEN's analysis of Claude Code sandbox bypass and persistence techniques →
Claude Code sandboxing and persistence gaps: what teams are missing?
Explore further
Cognitive compromise is now an identity control issue. When an agent can be steered into unsafe execution, the failure is not only in the sandbox. It is in the assumption that runtime policy alone can govern a system that interprets instructions and selects actions. That means agent identity, prompt trust, and execution authority need to be managed as one boundary, not three separate controls. Practitioners should treat agent reasoning paths as part of the access model.
A question worth separating out:
Q: Who is accountable when an AI agent persists through startup hooks or configuration changes?
A: Accountability should sit with the team that owns the agent runtime and its approval model, not just the model provider or platform team. Persistent hooks are privileged changes, so they need the same ownership, logging, and review discipline as service account management or PAM-controlled configuration changes.
👉 Read our full editorial: Claude Code sandboxing can still be bypassed through reasoning abuse