Before Businesses Adopt Codex, Define Its Permission Model

Before a business rolls Codex into regular engineering or operations work, it needs a plain answer to a boring question: what should the agent be allowed to access for this task?

That decision should happen before the prompt, not after the first risky command appears. The useful principle is least privilege per task. Review work, implementation work, network-backed work, and full local access should not all run with the same permissions.

The current OpenAI Codex permissions documentation supports that operating model with built-in profiles, named custom profiles, filesystem rules, and network rules. For Digital Meld, the business value is not the setting itself. The value is turning agent access into a reviewable policy that lives in files instead of chat history.

Why permissions come before prompts

Most teams start by asking what prompt will make the agent productive. That is backwards for business adoption. A good prompt can still be unsafe if the task runs with unnecessary filesystem access, broad network access, credential visibility, or permission to mutate the wrong environment.

The access model should match the work. A review task should not need write access. A normal implementation task usually needs workspace edits and local checks, not unrestricted network. A task that needs current documentation, package managers, GitHub state, public APIs, or browser smoke tests belongs in a different mode. Full local access should be the exception, with a reason stated before the run starts.

That gives builders speed while giving reviewers and security-minded stakeholders something concrete to inspect.

A small SOP is enough

The SOP does not need to be heavy. Four modes cover most practical work:

Review, audit, planning, or explanation only: read.
Normal repo implementation: work.
Repo work that needs package managers, docs, GitHub, public APIs, or browser smoke tests: work-net.
Full local access: only for machine cleanup, multi-repo maintenance, release/signing flows, or a sandbox-proven blocker; state why first.

This is intentionally simple. The point is to make the permission decision visible before the work starts, so the team is not relying on whatever the operator happened to remember that day.

Make the policy executable

The SOP should be backed by configuration. A practical starting point looks like this:

default_permissions = "work"

[permissions.read]
description = "Read-only review, audit, planning, and explanation work."
extends = ":read-only"

[permissions.work]
description = "Default repo work: edit the workspace without network access."
extends = ":workspace"

[permissions.work-net]
description = "Workspace work with public internet for package managers, docs, GitHub, public APIs, and browser smoke tests."
extends = ":workspace"

[permissions.work-net.network]
enabled = true

[permissions.work-net.network.domains]
"*" = "allow"

That broad work-net profile can be reasonable for a single experienced operator optimizing for speed. A business team should usually narrow it quickly. The common approved paths might include GitHub, package registries, public product docs, and explicit local browser targets.

[permissions.work-net.network.domains]
"github.com" = "allow"
"api.github.com" = "allow"
"registry.npmjs.org" = "allow"
"developers.openai.com" = "allow"
"127.0.0.1" = "allow"

The exact domain list should come from real workflows. Start with the common paths. Add more when work proves the need.

What this does not solve

Codex permission profiles govern local command execution. They do not replace rules for browser sessions, MCP servers, cloud consoles, GitHub permissions, production credentials, connector scopes, or public posting workflows.

That distinction matters. A team can have a well-scoped local workspace profile and still need separate approval gates for deployment, data export, external messages, credential changes, or production mutations. Permission profiles are one control surface, not the whole security program.

How Digital Meld applies the pattern

Digital Meld treats agentic AI adoption as an operating-model problem first. The pattern is straightforward: name the work mode, give it the minimum access it needs, deny sensitive paths where possible, verify the configuration, and leave a written trail that another person can inspect later.

For Codex, that means putting the SOP in AGENTS.md, putting profiles in config.toml, and verifying the setup before relying on it:

codex --strict-config doctor

It also means writing task handoffs that name the expected mode. A review should say it runs in read-only mode. A repo implementation should say it runs in workspace mode. A network-backed task should explain why external access is needed. A full-access task should state the blocker that requires it.

This is not extra process for its own sake. It is how businesses keep the speed of agent-assisted work without turning every run into an ad hoc trust decision.

The practical takeaway

Before building a bigger agent process, define three or four permission profiles. Keep them boring. Keep them reviewable. Keep secrets and production mutations out of the default path. Widen access only when the task proves it needs more.

Good agent operations do not start with a bigger prompt library. They start with a clear work mode, a narrow permission boundary, a verification step, and a human who knows when to stop.