Codex CLI sandbox escapes show why model behaviour is not control

At a glance

What this is: Pillar Security shows that Codex CLI’s safe-command allowlist can be abused to turn git show into an arbitrary file-write path that leads to code execution.

Why it matters: For IAM, PAM, and NHI practitioners, this is a reminder that agentic tools running with user privileges need invocation-level controls, not assumptions that model refusal or command names provide safety.

👉 Read Pillar Security's analysis of the Codex CLI sandbox escape and allowlist gap

Context

AI coding agents create a trust problem when they can execute commands, process untrusted content, and act with the user’s privileges. The primary security gap in this article is not the model itself, but the way deterministic controls such as sandboxes and command allowlists fail when they defer to command names or assume the model will refuse unsafe instructions.

That matters to identity and access governance because the agent is operating inside a privilege boundary, not outside it. Once an AI tool can write to files, alter configuration, and trigger later execution, the question becomes whether the runtime identity, command scope, and approval model actually constrain what that identity can do.

Key questions

Q: What breaks when AI coding agents rely on command allowlists for safety?

A: Allowlists break when a command’s arguments can change it from harmless to dangerous. A trusted binary name does not prove a trusted outcome if flags can redirect output, overwrite configuration, or trigger later execution. Security teams should assess the full invocation path, not just the command label, and remove any tool from the safe path if its parameters can alter file state or runtime behaviour.

Q: Why do AI agents create new privilege risk for enterprises?

A: AI agents can chain actions across tools, inherit delegated access, and execute at machine speed without a person confirming each step. That creates a privilege problem when task scope is not tightly bounded. The main risk is not only misuse, but over-authorization that lets one agent action become a wider system compromise.

Q: What do security teams get wrong about model refusal as a safeguard?

A: They confuse a possible refusal with a reliable control. A model may reject one malicious instruction and accept the next, so refusal cannot be the boundary that protects sensitive files or execution paths. The control must be external to the model and must hold even when the model complies with an unsafe instruction.

Q: Who is accountable when an AI agent triggers code execution through a trusted tool?

A: Accountability sits with the team that defined the tool’s trust boundary, approval model, and runtime policy. If a safe path allows file writes or indirect execution, the control design failed. Governance should assign ownership across platform, security, and identity teams so that command scope, file scope, and approval scope are reviewed together.

Technical breakdown

Why allowlists fail when command arguments change behaviour

A command allowlist treats a binary name as if it were a stable security boundary, but many developer tools change from read-only to write-capable depending on flags. In this case, git show is considered safe because it normally reads history, yet git show --output can redirect output into an arbitrary file. The key failure is that the allowlist trusts the subcommand while ignoring the argument surface that actually determines impact. Once attacker-controlled content reaches a file like .git/config, later tooling can execute it indirectly. The security issue is invocation semantics, not just command identity.

Practical implication: Practitioners should review allowlists for flags that turn benign tools into write-capable paths and block them explicitly.

How sandbox escapes happen when approval flows are bypassed

Sandboxes and approval prompts only help when they sit on the full execution path. Here, the safe command path bypassed both sandbox restrictions and user approval, so nothing inspected the dangerous argument combination before execution. That means the model was not the control point. The control point was the command classification logic, and that logic had a blind spot. This is a common failure mode in AI-enabled tooling: deterministic guardrails are narrowly scoped, while the actual attack uses a legitimate command in an unexpected way. If the guardrail does not evaluate the full invocation, it cannot constrain the outcome.

Practical implication: Move enforcement to the full command invocation and require approval for subcommands that can write, reconfigure, or trigger code execution.

Why model refusal is not a security control

A model refusing an instruction is only a probabilistic outcome, not a dependable security property. The article makes that distinction clearly: an attack may fail nine times and still succeed on the tenth run. Security design cannot assume the model will consistently reject malicious instructions, because the acceptable risk threshold is defined by what happens when it complies. In identity terms, this is equivalent to trusting user intent instead of enforcing policy. In AI agent governance, the policy layer must contain damage even when the model chooses an unsafe action, because human-like refusal is not a control.

Practical implication: Treat model refusal as a signal, not a safeguard, and design runtime controls that remain effective when the model follows malicious guidance.

Threat narrative

Attacker objective: The attacker wants arbitrary code execution on the developer’s machine using the agent’s trusted command path as the delivery mechanism.

1. Entry occurs when malicious content is placed in documentation or other untrusted input that the coding agent reads during a normal workflow.
2. Credentialed execution happens when the agent invokes a trusted git command on its safe allowlist, letting attacker-controlled arguments write into .git/config without approval.
3. Impact follows when a later git diff execution loads the injected external diff tool and runs the payload with full user privileges.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Model behaviour is not a control boundary: the article shows that security architecture cannot depend on a model to refuse malicious instructions. Probabilistic refusal is useful for reducing risk, but it does not replace enforcement at the command, file, or runtime identity layer. For AI agent governance, the control must survive when the model complies, because that is the only test that matters.

Invocation semantics create a new identity risk surface: AI coding tools operate with real user privileges, so command arguments become part of the effective access model. A binary name is not the identity of the action, and allowlisting the name while ignoring the flags leaves a governance gap. This is where agentic AI security intersects with PAM and NHI thinking: constrain what the runtime identity can actually do, not just which tool it calls.

Allowlist trust is the named failure mode: this incident exposes a gap we can call allowlist trust collapse, where a deterministic guardrail confuses a trusted command label with a trusted outcome. That assumption breaks as soon as a command can switch from read to write or from read-only to executable via parameters. Practitioners should treat command allowlists as incomplete policy unless they evaluate argument-level impact.

Sandboxing without argument inspection creates false confidence: the sandbox only works if dangerous pathways are still inspected before execution. When a safe list bypasses both sandbox and approval, the model can move attacker content into sensitive files with no intervention. The field should stop treating sandbox presence as proof of containment and instead measure whether the full invocation path is actually enforced.

Agentic AI governance must move toward runtime determinism: the practical lesson is that governance needs controls that are explicit, inspectable, and repeatable across every invocation. That means policy on commands, flags, file targets, and post-write execution triggers. For practitioners, the direction of travel is clear: if the control cannot explain the exact failure mode, it is not yet governing the agent.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to 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.
• For a governance model that maps these findings to policy and control design, OWASP Agentic AI Top 10 is the next place to look.

What this signals

Allowlist trust collapse: this article names a failure mode that will keep recurring in agentic tooling. When security controls trust command labels instead of command effects, they create a false boundary that looks deterministic but is actually porous. Teams should evaluate AI toolchains for any place where a benign action can become a write, reconfigure, or execute path through parameters alone.

The broader programme implication is that agentic AI governance has to look more like runtime privilege management than prompt management. That means scoping the toolset, constraining file destinations, and checking for post-write execution hooks, especially where the agent interacts with developer repositories or automation pipelines. The right lens is control determinism, not model intent.

For teams mapping this to external guidance, the NIST AI Risk Management Framework is useful for governance structure, while OWASP Top 10 for Agentic Applications 2026 helps frame tool misuse and identity abuse in operational terms.

For practitioners

• Audit command allowlists for write-capable flags Review every allowlisted developer command for options such as --output, --format, or similar parameters that change a read-only action into file writes or execution triggers. Remove the command from the safe path if the security team cannot reason about the full argument surface.
• Require approval for trust-boundary changes Treat commands that can modify repository state, configuration, or execution hooks as privileged actions even when they appear operationally routine. Approval should apply to the full invocation, not just the command name.
• Block indirect execution through config files Prevent AI tools from writing attacker-controlled content into files such as .git/config unless the destination is explicitly scoped and monitored. Add runtime checks for external diff tools, shell hooks, and similar config-driven execution paths.
• Design for model compliance, not model refusal Assume the model may follow an injected instruction on any given run and make sure the surrounding control plane still prevents harm. This is the correct test for sandboxing and approval workflows in AI coding tools.
• Map agent actions to privilege boundaries Classify the agent’s effective permissions the same way you would a high-risk service account, including write scope, configuration scope, and post-execution triggers. That gives IAM and PAM teams a concrete way to review what the agent identity can actually affect.

Key takeaways

• This incident shows that agent safety cannot depend on model refusal, because runtime controls must still hold when the model follows a malicious instruction.
• A trusted command name is not a trusted outcome when flags can write files, change configuration, or trigger later code execution.
• Practitioners should move from command-name allowlists to invocation-level policy, with explicit handling for write-capable arguments and indirect execution paths.

Key terms

• Allowlist Trust Collapse: A failure mode where a security control treats a trusted command name as proof of safety, even though command arguments can change the action’s effect. In agentic tooling, this creates a false boundary that looks deterministic but can still lead to writes, reconfiguration, or execution.
• Invocation Semantics: The security-relevant behaviour of a command as defined by its full set of arguments, flags, and execution context. In practice, invocation semantics matter more than the binary name because they determine whether an action reads, writes, triggers hooks, or executes code.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.

What's in the full report

Pillar Security's full research covers the operational detail this post intentionally leaves for the source:

• The exact git flag combination used to turn a trusted read operation into an arbitrary file write.
• The patch logic and version-level remediation guidance for Codex CLI v0.95.0.
• The disclosure timeline, reproduction path, and proof-of-concept behaviour described by the vendor.
• The code examples showing how to block dangerous flags and override external diff execution.

👉 The full Pillar Security post covers the attack chain, reproduction details, and mitigation examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps security practitioners build practical control models for identities that execute, delegate, and interact with runtime systems.