OpenAI recently published a deep-dive technical article on how they created a safe and effective sandboxing environment for their Codex coding agent on the Windows platform. The problem statement is straightforward: Codex, which can run from a CLI or an IDE extension, operates with user privileges by default. Before the sandbox was introduced, Windows users had two poor options: either manually approve almost every single command or enable the risky “Full Access mode.” This situation was untenable for an enterprise-grade tool.
The case study perfectly illustrates how a seemingly simple security requirement—running an agent in a constrained environment—hides deep engineering challenges, especially on the most common enterprise operating system.
Do you have a question about AI security? You can reach us here:
The Windows-Specific Challenge: Why Built-in Tools Fall Short
While macOS (Seatbelt) and Linux (seccomp, bubblewrap) have robust, built-in tools for process isolation, Windows requires a different approach. The OpenAI team investigated several native Windows technologies, but none proved suitable for Codex’s unique needs.
- AppContainer: Although a native Windows sandbox, it was found to be too restrictive for Codex’s open-ended developer workflows.
- Windows Sandbox: This technology creates a disposable, lightweight virtual machine. The main issues were its unavailability on Windows Home editions and its complete isolation from the user’s actual development environment, which harms usability.
- Mandatory Integrity Control (MIC): This solution uses integrity levels to control access. However, the proposed implementation would have risked making the user’s entire workspace low-integrity, opening an unacceptable security hole on the host system.
From an AIQ standpoint, this point highlights a critical vulnerability in corporate AI adoption: platform-specific security limitations. A solution that is secure on Linux can pose a major headache in a Windows environment. This also relates to the OWASP LLM Top 10 points LLM06: Excessive Agency and LLM08: Excessive Permissions, where an agent might gain more privileges than necessary due to platform constraints.
The First Attempt: A Prototype Without Privilege Elevation
The main goal of the first prototype was to avoid the need for administrator privileges (elevation) during installation. The solution used Windows Security Identifiers (SIDs) and write-restricted tokens to control filesystem access. They created a synthetic SID named ‘sandbox-write’ and used Access Control Lists (ACLs) to grant write permissions within the workspace.
However, restricting network access proved to be a weak point. The prototype only attempted to prevent unwanted network communication by modifying environment variables (e.g., HTTPS_PROXY) and the PATH. This protection is merely “advisory” and can be easily bypassed by malicious code.
In a corporate context, this means that such a solution carries an unacceptable risk of data exfiltration. GDPR and the EU AI Act impose strict data sovereignty and security requirements that such weak network controls cannot satisfy. During an AIQ audit, a mechanism like this would immediately receive a high-risk rating.
The Final Architecture: Dedicated Users and a Firewall
The final, currently used implementation, the “elevated sandbox,” requires administrator privileges for installation. This trade-off allowed for the construction of a much more robust security model. The main components of the solution are:
- Dedicated local users: The installer creates two separate local user accounts,
CodexSandboxOfflineandCodexSandboxOnline. - Firewall rules: Strict Windows Firewall rules are applied to the
CodexSandboxOfflineuser, blocking all outbound network traffic. - Secure credential management: Credentials for these user accounts are stored encrypted using the Windows Data Protection API (DPAPI).
- Privilege level management: A separate binary,
codex-command-runner.exe, is responsible for ensuring that processes launched by Codex run in the correct, restricted user context (either offline or online).
This four-layer architecture (codex.exe, the setup executable, the command runner, and the child process) provides a complex but effective method for constraining the agent’s capabilities in a Windows environment.
Takeaways for the EU Corporate Market
The primary takeaway from OpenAI’s case study is that running AI agents effectively and securely in an enterprise environment on the Windows platform requires complex, custom security solutions. From AIQ’s perspective, companies must consider the following:
- EU AI Act Compliance: For high-risk AI systems, the regulation mandates robust, traceable, and secure operation. The technical depth demonstrated by OpenAI exemplifies the level of control needed to prove compliance. A simple “let’s run it in Docker” approach is not sufficient.
- OWASP LLM Top 10 Risks: The entire project is about mitigating the risks of Excessive Agency and Excessive Permissions. Agents are inherently designed for autonomy; the job of security professionals is to keep that autonomy within a strictly controlled framework.
- Vendor Audits: When a company adopts a third-party AI tool, a thorough technical audit is essential. Relying on marketing materials is not enough. You must investigate how the provider handles process isolation, network access, and privilege management on your specific operating system. OpenAI’s case study serves as an excellent benchmark for the kinds of questions that need to be asked.
In conclusion, the Codex Windows sandbox is an impressive piece of engineering, but it is also a cautionary tale. The secure integration of AI agents into existing corporate infrastructure is a non-trivial task that requires deep, platform-specific expertise.