Codex yolo mode removes both approvals and sandbox boundaries

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Certiv's blog post: Codex --yolo collapses approval prompts and sandboxing into a single unsafe operating mode that lets the agent act with the developer's effective access.

Why it matters: This matters to IAM and AI security teams because agent governance fails when decision approval and execution boundary controls are removed at the same time.

Context

The core governance gap is the assumption that a human prompt alone can contain an AI agent's runtime authority. In practice, approval and sandboxing solve different problems: one governs whether a command should run, the other constrains what the process can reach if it does run.

When those controls are separated, the model can still be wrong while the operating environment remains constrained. That distinction matters for agentic AI programmes, because the control point has to cover both delegated decision-making and the filesystem, network, and secret exposure that follow from it.

Certiv's example is not an edge case. It reflects a common operational temptation to trade policy friction for speed, then assume routine tasks will remain routine.

Key questions

Q: What should teams do when an AI agent needs network and filesystem access?

A: Teams should decide whether the agent needs both privileges for the task and, if so, contain each one separately. Restrict filesystem read access to only the files the job requires, limit egress to approved destinations, and add monitoring for unusual reads or outbound transfers. Without those controls, the sandbox becomes a convenient exfiltration layer.

Q: What are the signs that approval prompts are not enough to secure agentic workflows?

A: Approval prompts are weak when the risky action happens after the initial prompt or when the agent is trusted by default. Warning signs include background execution, automatic connector access, hidden instructions in retrieved content, and workflows where one consent step unlocks broad privileges. If the system can still exfiltrate data or run tools unattended, the prompt is not a real control.

Q: How does a sandbox limit what an AI agent can do?

A: A sandbox limits an AI agent by constraining the runtime, tools, data, and network paths it can access. Practically, that can mean read-only filesystems, isolated containers or VMs, allowlisted APIs, no direct shell access, and scoped tokens. The sandbox reduces the blast radius if the agent is mistaken, prompt-injected, or otherwise misused.

Q: What is the difference between approval policy and sandboxing for agents?

A: Approval policy controls when an agent must ask a human before acting, while sandboxing controls what the agent can technically reach and change. Approval policy is a decision gate for high-risk actions such as spending, deletion, or privilege escalation. Sandboxing is an execution boundary that limits tools, credentials, files, and network access even when approval is already granted.

Technical breakdown

Approval policy versus sandbox enforcement

Approval policy and sandboxing are complementary controls, not duplicates. Approval policy governs when an agent pauses for human review before acting outside a permitted scope, while sandboxing constrains the process at the operating-system layer even when no one is watching. In agentic workflows, the first control addresses decision authority and the second addresses execution authority. If either one is absent, the agent can still make a harmful choice or reach a harmful resource. The risky mistake is to treat a prompt as equivalent to containment. That assumption breaks as soon as a task needs network access, broad file access, or access to developer credentials. See the OpenAI Codex Security Guide. See the OpenAI Codex Security Guide.

Practical implication: Keep approval gating and execution confinement as separate policy layers so one failure does not remove both human review and runtime containment.

Why danger-full-access turns an agent into a privileged insider

Danger-full-access removes the file and network boundary that normally limits agent reach. Once that boundary is gone, the agent can read whatever the developer account can read, write wherever that account can write, and contact whatever hosts that machine can reach. In identity terms, the agent is acting as a non-human principal with the developer's practical privilege set, even if the intent is only to speed up a local task. That is why the threat is not just malicious code execution. It is privilege concentration without reliable lifecycle control, which makes secrets, SSH keys, and local configuration files part of the attack surface. See the [[L4|OWASP Agentic Top 10 ASI05 Guide]]. See the OWASP Agentic Top 10 ASI05 Guide.

Practical implication: Treat unrestricted agent execution as privileged access and place explicit controls around secrets, network egress, and writable scope.

Prompt fatigue creates a governance failure mode

Repeated approval prompts erode human attention, so the review control becomes procedural rather than effective. This is not a usability complaint alone. It is a control reliability problem, because a human reviewer who approves dozens of harmless commands will eventually stop distinguishing harmless from risky. The article's deeper point is that friction pushes operators toward settings that feel efficient, even when those settings remove the very boundaries that keep a misread command from escaping its intended scope. In security architecture terms, the failure begins before the agent acts. It begins when the operating model assumes people can remain high-fidelity reviewers across long command chains.

Practical implication: Design agent workflows so routine actions do not rely on continuous human attention as the only barrier to unsafe execution.

Threat narrative

Attacker objective: The practical objective is to obtain the same level of access and reach as the developer account, then use that access to delete, alter or exfiltrate sensitive files and secrets.

1. Entry occurs when a developer runs an AI coding agent in a mode that removes both approvals and sandbox boundaries.
2. Credential and file exposure follow because the agent can read anything the developer account can read, including keys, tokens and local configuration.
3. Impact occurs when the agent executes a harmful command or reaches a network or filesystem target that normal sandboxing would have blocked.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

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

Codex --yolo is a control collapse, not just a convenience setting. It removes the review point and the runtime boundary in one move, which means the same operator decision now authorises both the command and the environment it can touch. That combination is what turns a routine developer workflow into a delegated insider problem. Security teams should treat combined approval-plus-sandbox removal as a privileged mode, not a productivity preference.

Agentic governance fails when the human prompt is treated as the primary control. A prompt can stop a command, but it cannot contain the side effects of a command that is already allowed to run. The real control question is where authority ends: at the decision layer, the execution layer, or both. Programmes that only measure prompt frequency are missing the actual governance boundary.

The named concept here is approval-boundary collapse. That is the point at which human review and OS-level containment are dropped together, leaving only trust in the agent's interpretation of the task. Once that happens, ordinary developer actions can become broad filesystem or network operations with no independent brake. The practitioner lesson is to move enforcement outside the agent and outside the operator's momentary judgment.

AI agents create an identity problem before they create a tooling problem. The moment an agent can act with the developer's effective reach, the programme is no longer just managing software behaviour. It is managing delegated authority, secret exposure, and revocation of access in a runtime context that can change every command. That requires governance patterns closer to privileged access than to simple automation oversight.

Run-time containment matters more than post hoc review for these workflows. Once an unrestricted agent has acted, the damage may already be in the workspace, the home directory, or the network. That is why policy decisions must happen before execution and why externally enforced boundaries matter even when a command appears harmless. The correct posture is to make unsafe modes difficult to enable and easy to detect.

What this signals

Approval-boundary collapse: agent programmes fail when teams let convenience remove both the human review step and the operating-system boundary at the same time. The better operating model is to assume that prompt fatigue will happen and to move enforcement into controls the operator cannot casually override.

For identity and access teams, the bigger shift is to treat agent sessions as delegated privilege with strict runtime scope rather than as ordinary developer tooling. That means secrets minimisation, endpoint policy enforcement and revocation paths need to be designed for non-human execution, not bolted on after a workflow becomes popular.

For practitioners

• Separate approval and containment controls Keep human approval policy and sandbox enforcement as independent controls so a single setting change cannot remove both governance layers.
• Block unrestricted agent execution on endpoints Use external policy enforcement on the workstation or in a hardened container or VM so agent settings alone cannot grant broad filesystem or network access.
• Restrict agent access to secrets and developer home directories Deny agent processes access to SSH keys, cloud credentials, environment files and other sensitive locations unless the task has a tightly scoped need.
• Write explicit project rules for approved commands Use project-level policy files to whitelist routine actions while keeping the rest of the command set behind approval prompts and sandbox limits.

Key takeaways

• Running an AI coding agent with both approvals and sandboxing removed creates a delegated insider problem, not just a more convenient developer workflow.
• The critical control failure is the collapse of decision gating and runtime containment into a single toggle that operators can disable too easily.
• Practitioners should enforce agent boundaries outside the agent itself and keep secrets, network access and writable scope tightly constrained.

Related NHI Mgmt Group resources: OpenAI Codex Security Guide · OWASP Agentic Top 10 ASI05 Guide · Sentry MCP Agentjacking 2026

Key terms

• Approval Policy: An approval policy is a governance rule that requires one or more human reviews before an infrastructure change can execute. In Terraform workflows, it adds a control point before apply runs, helping teams slow down risky changes and keep high impact modifications visible and accountable.
• Sandbox: A sandbox is a controlled execution environment that isolates an agent's runtime from the rest of the estate while still allowing defined actions and tool use. For identity teams, the sandbox is part of the trust boundary because it carries the agent's access, state, and audit trail.
• Danger-full-access: Danger-full-access is a mode in which an AI agent can act with very broad permissions and few or no runtime restrictions. It usually means the agent can call many tools, reach sensitive data, and perform changes without step-by-step approval, so the human owner must rely on stronger oversight, logging, and revocation controls.
• Approval-boundary Collapse: Approval-boundary collapse is the failure mode where an approval check no longer separates low-risk from high-risk agent actions. It happens when the agent can bypass, reinterpret, or over-extend a human authorisation prompt, turning a narrow approval into broader delegated authority than intended.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.