Topic starter
18/08/2026 2:17 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by CRACKEN: “Red-Teaming the Agentic Red-Teamer Part.2”.
Key questions
Q: What breaks when Claude Code sandboxing is the only control?
A: Sandboxing still allows an agent to run arbitrary binaries inside the boundary, so it reduces impact without stopping unsafe execution.
Q: Why does reasoning abuse create risk even when network access is restricted?
A: Because the attacker is targeting the agent’s interpretation of the task, not just its transport layer.
A: Look for command execution that does not match the visible approval, file writes outside the intended workspace, unexpected skill or MCP server installation, and autonomous changes to config or database targets.
Practitioner guidance
- Harden agent configuration files Restrict write access to ~/.claude/settings.json and other startup-state files, and monitor them for unauthorized hooks, commands, or permission changes.
- Gate high-risk agent actions Require explicit approval for binary execution, shell spawning, and configuration edits that could create repeatable execution paths.
- Separate sandboxing from authorisation Treat sandbox policy as a containment layer only, and add a higher-level policy check that can deny execution before the agent launches a tool.
Bottom line: Claude Code sandboxing limits damage, but it does not reliably prevent unsafe execution when the agent’s reasoning can be steered.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:10 pm
Sandboxing is not an identity boundary for agentic systems. CRACKEN’s analysis shows that process isolation can reduce damage but cannot by itself decide whether an agent should execute a payload. That distinction matters because agentic AI behaves like a privileged non-human identity, and identity governance has to start at the point of action authorisation, not only at runtime confinement. Practitioners should treat agent decision-making as part of the control plane.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: Who should be accountable for malicious agent hooks and startup persistence?
A: Accountability should sit with the team that owns agent configuration governance, because startup hooks are part of the trust boundary, not a minor preference file. Security, platform, and identity teams need a shared change-control model for agent settings, especially where the agent can execute code automatically at launch. If no owner is assigned, the persistence path will usually outlive the incident response.
👉 Read our full editorial: Claude Code sandboxing can still be bypassed through reasoning abuse