Governing Codex with Alyria
Codex enterprise security ships as OS-enforced sandbox modes (read-only, workspace-write, danger-full-access), an approval policy, an optional network proxy, and admin-managed requirements.toml constraints. OpenAI's documentation is specific about the boundary: the command network proxy does not filter MCP server connections, web search, connector tool calls or browser and computer-use activity. Alyria Beacon adds the endpoint layer around it: one inventory, one written policy and one signed audit chain across the CLI, other agents and the rest of the machine.
Start with the vendor's own controls.
Each control below is named the way OpenAInames it, and links to the vendor's documentation. Deploy them: they are the fastest path to a working baseline.
Sandbox modes
macOS uses Seatbelt, Linux uses bwrap plus seccomp, Windows supports MXC. workspace-write defaults to no network access until enabled with [sandbox_workspace_write] network_access = true; .git, .codex, .agents and .aws stay read-only inside writable roots.
Agent approvals and securityApproval policy
on-request, never or a granular policy (sandbox escalations, exec policy rules, MCP elicitations, skill approvals); approvals_reviewer = "auto_review" routes eligible approvals through a reviewer agent that fails closed on parse errors.
Agent approvals and securityNetwork proxy
features.network_proxy constrains workspace network access with allowlist-first domain rules and deny-wins semantics. A global * is valid only as an allow rule, and the proxy blocks external destinations when no allow rule is present. Local and private network targets are blocked by default, with a DNS-rebinding guard. OpenAI's permissions documentation states plainly what the proxy does not filter: web search, app or connector tool calls, MCP server connections, browser activity, or the client's model requests.
Agent approvals and securityManaged configuration
Admin-enforced requirements.toml: allowed_approval_policies, allowed_sandbox_modes, allowed_web_search_modes and feature flags, delivered from /etc/codex/requirements.toml on Linux and macOS, the ProgramData path on Windows, or cloud-fetched as a configuration bundle.
Managed configurationOpenTelemetry export
Opt-in [otel] blocks in config.toml export tool decisions, results and streams to your own collector, with log_user_prompt = false to keep prompt text out unless policy allows it.
Configuration referenceMCP servers for Codex
MCP servers are registered with mcp_servers configuration. OpenAI's permissions documentation states that local and remote MCP servers run in their own process or transport, outside the code sandbox, and are controlled by that configuration, managed server allowlists and your own controls for each server.
Codex permissionsWhat the native controls leave uncovered.
Drawn from what OpenAI states about its own limits, not from us.
The boundary is defined around the command sandbox
OpenAI's approvals and security page scopes the protection: the network proxy filters scripts and subprocesses inside the command sandbox and does not filter MCP server connections or connector tool calls. Full access is a documented flag (--dangerously-bypass-approvals-and-sandbox), and the docs note that a malicious project inside a container may exfiltrate everything the devcontainer can reach.
Managed requirements bind Codex only
requirements.toml constrains Codex clients on machines you reach. Other agents and CLIs on the same laptop, and every MCP server configured in them, are outside the managed configuration, so inventory across the fleet needs endpoint tooling.
Telemetry is opt-in and local by default
OTel export ships off by default, which is the right local-privacy default and leaves the audit record of tool decisions an admin task to turn on and wire to your own collector.
A practical starting point.
A starting config.toml for day-to-day work, from OpenAI's own settings:
# Codex config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "disabled"
[sandbox_workspace_write]
network_access = true
[features.network_proxy]
enabled = true
# Allowlist-first: a host with no allow rule is blocked. A global * is valid
# only as an allow rule, and hostnames resolving to local or private
# addresses stay blocked behind the default guard.
domains = { "api.openai.com" = "allow", "registry.npmjs.org" = "allow" }What OpenAI's controls cover, and what the endpoint adds
| Area | Codex native controls | Endpoint governance with Alyria |
|---|---|---|
| MCP servers | Managed requirements constrain which MCP servers managed Codex setups may run. OpenAI's permissions documentation states that local and remote MCP servers use their own process or transport, outside the command sandbox, so allowlisting approves access but is not command-level confinement. | Inventory of every configured server across every AI client, including Codex, with monitor-first Lyra policy on each call at the endpoint. |
| Secrets and files | Workspace sandbox with protected read-only paths (.git, .aws, .codex); danger-full-access removes the boundary by design. | Written policy across agents for reading and sending secrets; Umbra leases mean the agent gets a short-lived credential, not the standing key. |
| Network egress | Sandbox-bound network proxy with allow-list-first domain rules (a global * is only ever an allow rule); OpenAI notes it does not filter MCP connections or connectors. | Sequence policies such as after reading a secret, block network egress, evaluated where the call originates for every tool. |
| Audit trail | Opt-in OTel with codex.tool_decision and codex.tool_result events to your own collector. | A signed, tamper-evident audit chain from day one, including decisions on every MCP call, exportable to your SIEM. |
| Beyond Codex | Out of scope: managed configuration binds Codex clients. | One policy and one audit chain across Claude Code, Cursor, Codex and GitHub Copilot. |
What Alyria Beacon adds.
Governance at the endpoint, not the gateway: the same policy, secrets and audit whether the agent is Codex or something ships next quarter.
- Alyria Beacon runs as a signed, user-space agent beside Codex, not as a wrapper around it: no kernel driver, read-only install, monitor mode first.
- It inventories every AI tool on the machine and the MCP servers each one is wired to, then flags unpinned servers and secrets in config.
- Lyra policy runs locally on every model and tool call, including the MCP calls that OpenAI's own feature scoping names as outside the network proxy filter.
- Every decision lands in one signed, hash-chained audit record; Spectra streams it over OpenTelemetry to your SIEM.
- Umbra replaces standing credentials with short-lived leases injected at the moment of use.
Questions security teams ask about Codex and Alyria.
Does Alyria need a sandbox mode of Codex?
No. Keep Codex's sandbox and approvals where they are: they are good per-agent controls. Alyria Beacon sits outside, inventories and policy-checks the whole endpoint, and records the decisions, including the MCP calls that Codex's own feature scoping puts outside the command network proxy.
What is the Codex equivalent of an MCP allowlist?
Managed requirements configure approved servers for Codex, and the feature that constrains outbound traffic by domain covers commands inside the sandbox. OpenAI documents that connector tool calls, web search and MCP server connections are not filtered by the network proxy; if the whole call should face one policy across tools, that is the endpoint layer.
We run Codex Cloud and local CLIs. Does that change anything?
Cloud runs under OpenAI's cloud policies, and your local machines get requirements.toml. Alyria Beacon covers the endpoint side: everything installed, everything configured, every local call, all on the same audit chain.
- Native controls
- Sandbox modes, approvals, network proxy, requirements.toml
- MCP enforcement
- Approved servers in managed requirements
- Endpoint layer
- Alyria Beacon: signed, user-space, no kernel driver
- Rollout
- Read-only install, monitor mode first
- Audit
- Signed, hash-chained chain; OTel export via Spectra
See what your agents are wired to.
Start in monitor mode: inventory the AI tools, versions and MCP servers on every endpoint, see what enforcement would decide, and turn on enforcement when you are ready.