# OpenClaw Enterprise Security: What the Codex Preset Does Not Enforce

OpenAI's deployment write-up is useful, but an editable preset and a running agent do not prove that the same protections are active in your environment.

By Paras Madan | 2026-11-13


OpenAI published its approach to securing persistent OpenClaw agents on November 12. For teams adopting OpenClaw Enterprise, the practical question is whether the deployed runtime enforces the intended permissions. The standard Codex preset helps configure that runtime, but it is not an administrator-enforced security ceiling or a firewall for the entire workload.

That distinction matters before connecting a persistent agent to company systems. A convincing demonstration shows that the agent can finish a task. A deployment review must also establish what it cannot access, which controls it cannot change, and what happens when one of those controls fails.

## Separate OpenAI's deployment from the public preset

In its [deployment write-up](https://developers.openai.com/blog/securing-persistent-agents-like-openclaw-at-openai), OpenAI describes separating trusted control services from agent execution, restricting filesystem and network access, brokering credentials, and enforcing model-based review. Each agent has its own identity associated with a ChatGPT service account. Agent turns and configuration changes are logged with restricted access.

These are OpenAI's reported controls, not results from testing the public preset here. OpenClaw Enterprise remains in a pilot phase, with a 1.0 release planned for the end of the year. A planned release is not a production-readiness guarantee.

The important procurement question is therefore narrower than whether a familiar company uses the project: which of those controls can your team demonstrate in its own deployment? Ask for evidence from the runtime rather than accepting a screenshot of a configuration page.

## Check the boundary around the agent's files

OpenClaw Enterprise's [remote-harness documentation](https://docs-enterprise.openclaw.org/guides/topics/remote-harness/) separates the Gateway, which handles routing and access policy, from the Harness, which runs model execution and native tools. Their private storage is separate. Remote execution does not require separate clusters; ordinary Kubernetes deployment uses separate Pods, service accounts and storage in the same tenant namespace.

The native OpenClaw worker path is experimental, while dedicated Codex is supported on Kubernetes. Separate native worker directories do not give every session its own sandbox. Persistent files also do not guarantee that an interrupted turn resumes.

For a first deployment, I would keep the workload small enough to describe its data needs in one paragraph. A repository-maintenance agent might need a checkout and temporary build outputs. It does not automatically need the Gateway's channel credentials or other agents' working files. Give the deployment reviewer that data inventory before asking them to approve a broader pilot.

## Why an allowed GitHub hostname can still return 403

The [standard Codex preset guide](https://docs-enterprise.openclaw.org/guides/topics/standard-codex-preset/) documents a specific trap: with Codex 0.160.0, limited network mode permits GET, HEAD and OPTIONS. Git over HTTPS uses a POST to `git-upload-pack`, so even an allowlisted GitHub host can produce a 403 during clone or `git ls-remote`.

Treat that as a method-policy problem to diagnose, rather than immediate evidence that the hostname is missing. Turning off restrictions to make a clone work would change the security decision as well as the symptom. Record the installed runtime version, the rejected operation and the effective policy, then have the operator decide how that workload should be supported.

The same guide warns that its preset is an editable copy, not an enforced ceiling. Its tool restrictions do not establish Pod-wide isolation: Kubernetes currently grants public TCP/443 egress for model transport, including for processes outside the native sandbox. The default reviewer is the user, unlike OpenAI's described automatic-review deployment. **Installing the preset does not reproduce OpenAI's internal security architecture.**

## A small acceptance test before adding real access

Use an isolated test environment with synthetic files and an operator-controlled destination. The following is a proposed review checklist, not a test I have run or a claim that the project passed it.

| Question | Evidence to collect |
| --- | --- |
| Can the agent do the intended job? | One representative task, with its required files and destinations recorded. |
| Is a disallowed destination actually blocked? | A policy-denial record for a known reachable test host, not just a timeout. |
| Are unrelated files protected? | A harmless access check against a synthetic file outside the approved workspace. |
| Who reviews a permission request? | The effective runtime setting and the observed approval path. |
| Can an operator stop the agent's access? | A documented credential and deployment shutdown procedure exercised in the test environment. |

Keep the expected result next to the observed result. A missing log entry is an unresolved check, not a pass. Repeat the relevant checks after changing the runtime, permissions or deployment driver, because the useful evidence describes a particular configuration rather than the product name.

If the pilot needs broader access to function, make that tradeoff explicit before enabling it. The right boundary is the narrowest one that supports the approved job, with a named owner for each exception. An agent that can run all night needs controls that remain in force when nobody is watching the conversation.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help enterprise AI teams explain deployment choices, permission boundaries and technical tradeoffs clearly to developers and buyers.

[Book a 30-minute call](https://cal.com/paras-madan/30min).