Rolling out Claude Code or Codex in a regulated company

Your developers are about to get Claude Code or Codex. Each agent runs on the developer’s own device with the developer’s own access: the checkout, the shell, the cloud credentials, the Model Context Protocol (MCP) servers. In a regulated company, an auditor will ask who decided to run a given command, under which policy, and whether the control was on. Here is what changes, what regulators already expect, ten things to require before every developer gets an agent, and where MoorAI fits.

What changes when a developer gets an agent

A coding agent reads files, runs commands, edits code and calls tools on its own initiative, many times in one task, and it does all of it as the developer. To the identity provider and the device’s process log, a command the agent chose looks like one the developer typed. A data-loss tool watching the laptop sees an approved process on an approved device. As usually deployed, neither records that a model proposed the action, what policy applied to it or whether anyone approved it. The controls you already run see the agent’s actions, but not as agent decisions, and that is the gap an auditor will find.

Both vendors give administrators a first layer, and a regulated rollout starts there. Claude Code reads managed settings, delivered as a managed-settings.json file, an MDM profile or from the claude.ai admin console, and Anthropic’s documentation is plain about their precedence: “Nothing in your own settings files or --settings overrides a managed key.” Claude Code’s PreToolUse hooks run before a tool call executes and can block it, and allowManagedHooksOnly lets administrators block user, project and local hooks so only managed ones run.

Codex runs local commands in a sandbox the operating system enforces, under an approval policy that decides when it must stop and ask. OpenAI’s guide notes that by default “the agent runs with network access turned off.” Its requirements.toml holds what OpenAI calls “admin-enforced constraints that users can’t override”: approval policy, sandbox mode, web search mode, managed hooks and which MCP servers users can enable.

Those settings decide by rule: which tools, commands, paths, domains and MCP servers are allowed. Checking what a call carries, such as a card number in a command or a secret in a file the agent is about to read, and keeping a record of each decision somewhere the agent cannot write, takes a control that runs on every call. That is what to require next.

What regulators already expect

No new rulebook is needed to bring a coding agent into scope. When the PCI Security Standards Council announced its information supplement on AI security in September 2026, it said that when AI is used, “it should be considered no different from any other form of technology” when scoping the PCI requirements. Read plainly, an agent that runs commands on a host in the cardholder data environment is scoped like any other tool on that host.

For EU financial entities, Article 9(4)(c) of the Digital Operational Resilience Act (DORA) requires policies that limit logical access to information and ICT assets “to what is required for legitimate and approved functions and activities only”. An agent holding all of a developer’s access for a task that needs a fraction of it is a least-privilege question under that article.

In US healthcare, the HIPAA Security Rule’s audit-controls standard (45 CFR 164.312(b)) asks for mechanisms that “record and examine activity in information systems” that contain or use electronic protected health information. An agent working in a repository or on a host that holds patient data is part of that activity.

For defence, government and critical infrastructure, ISO/IEC 27090 is ISO’s guidance on the security threats specific to AI systems, and it gives security and audit teams a shared vocabulary for them. ISO/IEC 27090 for AI agents on the device maps its threat families to controls where the agent runs.

None of these texts tells you which product to buy. Together they tell you what you will be asked to show: that access was limited to the task, that each action was decided under a policy, and that a record of it exists.

Ten things to require before broad rollout

Start with a pilot group, and widen it only when each of these is true and you have seen it work on a real device.

1. Managed settings the developer cannot override. Deliver the agent’s own configuration through the vendor’s managed channel (Claude Code managed settings, Codex requirements.toml) and your MDM. The security control’s policy and trust anchors should come from a signed or root-owned source, never from a file in the developer’s home folder or the repository. Test it: edit the user settings file and confirm nothing weakens.
2. A decision on every tool call, outside the model, before it runs. Each command, file read, file write, web fetch and MCP call should be judged by a check the model cannot edit, before it executes. A model’s account of what it intends is not a control. Test it: ask the agent to read a .env file and watch what happens.
3. Least privilege and allow-listed egress. Declare what each agent, repository or service may use: tools, paths, MCP servers and destination hosts. Give agent hosts and CI runners default-deny or allow-listed egress, so a new destination is a decision, not a default.
4. An MCP server allow-list. MCP servers extend what the agent can reach, often with credentials of their own. Approve servers by name, deny the rest, and notice when an approved server’s tools change after approval.
5. Secrets and regulated data caught before they reach the model. Credentials, card numbers and protected health information should be stopped or masked where the agent reads or sends them, without copying that content to another service to have it checked.
6. Human approval for high-risk actions. Deploys, identity and permission changes, money movement, bulk exports and destructive commands should wait for a named approver group, and the approval itself should be on the record.
7. Records the auditor can use, with no code or prompt in them. Each decision should leave a record of which agent, which class of action, which policy and which verdict, and when. The record should carry no source code, prompt or file content, so it can go to the SIEM without becoming another copy of regulated data.
8. Proof the control was on all period. Auditors ask about the whole period, not today. Require evidence that the control was present and current wherever an agent ran, and a finding when it was missing, switched off or bypassed, for example by a permission-bypass mode or a sandbox turned off.
9. Offline operation and a console inside your boundary. Where data cannot leave, enforcement has to work with no network, and the management console has to run in your own environment, air-gapped if necessary.
10. A deliberate fail-closed choice. In Claude Code, a pre-tool hook that times out does not block the call unless it is set to, and OpenAI warns that an error or timeout in a Codex managed hook can fail without blocking. Decide, per surface, whether a control that cannot reach a verdict lets the call through or stops it, and keep that choice out of the developer’s reach.

Where MoorAI fits

MoorAI for Agents, free and open source under MIT, puts a decision in the agent’s hooks on the device, and the MoorAI Management Server governs the fleet with signed policy. Here is each item against what agent v1.41.0 and Management Server v0.99.0 do, with the bounds stated where they apply. A device coaches until it is enrolled in a console; blocking, holds for approval and fail-closed apply once it is.

1 · Managed settings

On a managed device the hook reads the root-owned machine config (/etc/moorai/config.json, or ProgramData on Windows) before the user’s own; a user file naming another console is refused and reported, and the device never drops back to coaching. A policy is enforced only when its signature verifies, and a settings file in the user’s home or the repository cannot set MoorAI’s trust anchors. moorai-native-settings compiles the same policy into Claude Code’s managed settings and Codex’s requirements.toml, and its check reports when either file drifts. Under allowManagedHooksOnly, MoorAI’s Claude Code plugin runs only when managed settings force-enable it, and the console flags the setting when MoorAI is not managed.

2 · A decision on every call

In Claude Code, MoorAI’s PreToolUse hook judges Bash, PowerShell, Read, Write, Edit, WebFetch, sub-agent and MCP calls on the device before they run, and answers allow, ask or deny; Glob and Grep are not registered. Codex CLI gets the same engine through a pre-tool hook adapter, described below.

3 · Least privilege and egress

An entitlement envelope declares each agent’s tools, path prefixes and MCP servers; an action outside it is reported as entitlement drift, or blocked. Workload profiles declare tools, MCP servers and destination hosts per service or repository. Egress rules say which binary may reach which host or address range, port, method and path, with a default for everything else. The rules are judged from what the call names; a script that opens its own socket is seen by moorai-egress-proxy, which becomes the boundary when network policy makes it the only way out.

4 · MCP allow-list

Servers move from discovered to approved or denied in the console, and with the approval gate on, a server not yet approved is denied. An empty allow-list blocks nothing. With mcpToolDrift set to block, a tool whose description or schema changed after approval, or that was added after it, is removed and refused until an administrator re-approves the server.

5 · Secrets, cards and PHI

Everything is checked on the device, and secrets, PII and source code are never sent anywhere to be checked. The hook stops a secret being read into the agent’s context, such as a .env file, as well as typed into a prompt. Detectors cover provider credentials, payment cards (#1, Luhn-checked) and protected health information (#44: diagnoses, medical record numbers, ICD-10 codes, NPI and DEA numbers, insurance identifiers). Local secret values are fingerprinted as keyed one-way hashes, so a real secret leaving in a command is caught even when encoded. A policy can mask a span instead of blocking: the value becomes a tag and the call goes ahead. Masking rewrites calls in Claude Code, where it is built from the hooks reference and has not been observed in a live session; in the other agents’ adapters it falls back to the configured action.

6 · Human approval

Just-in-time approval routing sends selected blocks and asks to an approver group. The call is denied at once with a request id, one content-free APPROVAL_REQUESTED alert goes to the console, and the identical call is allowed only after an approval arrives inside the signed policy, once or until it expires. Holds happen in the Claude Code hook; the decision reaches the device on its first call after the 60-second policy cache expires, and with the console down the call stays held. The model proxy, MCP gateway and egress proxy do not hold calls for approval.

7 · Content-free records

The console receives a category, a risk level and a keyed one-way hash, never the prompt, the file or the matched text. Every alert names the policy that decided and the branch that decided it, and a control that never ran is recorded as UNEVALUATED, never as a pass. Login names and hostnames are replaced with keyed pseudonyms when they arrive. Decisions can also stream to any OpenTelemetry collector or SIEM as spans that carry the tool name, category, risk, decision and an argument hash, with no content.

8 · Coverage integrity

The hook sends a daily content-free heartbeat per agent host with the settings that weaken protection, and the desktop app reports when each agent was last used, independently of any hook. The console raises a finding for an agent in use with no MoorAI hook traffic, a weakened setting (Claude Code bypassPermissions, Codex approval_policy = "never" or danger-full-access, hooks switched off) and a hook removed or stale. Alerts carry a per-device sequence number, so gaps are visible. The evidence pack shows that controls operated over a window of up to 366 days.

9 · Offline and self-hosted

Enforcement needs no network: a device whose console is unreachable enforces its cached policy, then its last-known-good verified policy, then the offline default, and queues alerts until the console answers. A device that never reaches it hands its alerts over in a bundle file that the console verifies and imports. The Management Server runs as a Docker container in your environment, free to self-host with no user limit, and with no outbound route, enrolment, signed policy delivery and alert ingest all work. Escalation to an AI provider and the OCR provider fallback stay off in an air-gapped deployment.

10 · Fail closed, by the administrator

The fail mode is set per surface in the signed policy or the root-owned machine config; no environment variable or user file can turn a closed surface open. When the hook cannot decide (an engine error, its 15-second budget, unreadable input), a closed hook denies the pre-tool call and raises one content-free FAIL_CLOSED alert; prompt, post-tool and stop events still fail open. If the hook process itself crashes, Claude Code and Codex let the call through.

Codex, precisely

moorai-agent-hook codex install registers a pre-tool hook and a prompt hook in ~/.codex/hooks.json. It blocks before the tool runs once the user has trusted the hook in Codex’s /hooks; the console reports an untrusted or removed hook. Codex has no “ask”, so a MoorAI ask becomes a deny with a message, and approval holds apply to Claude Code only. web_search runs on OpenAI’s side and never reaches a hook. An apply_patch is judged file by file. The adapter is built from Codex’s documentation and the hook schemas it publishes, and is tested against fixture payloads; no live Codex agent turn has been run through it. Codex cloud is not supported, because its hooks page says command hooks do not run under cloud orchestration.

One switch for a regulated posture

In the console, Policy → Governance mode → Regulated sets the posture in one step. It blocks 35 of the 50 threat ids an agent enforces, including data leakage, injection, destructive actions, secrets, installs and exfiltration, and asks on intellectual property, personal data and PHI. It arms the MCP and model-endpoint allow-lists from the servers and endpoints you enter, allows egress only to the hosts you enter, asks before money, identity and destructive business actions, blocks bulk data export, and sets the fail mode to closed. Apply in observe turns every block into an alert first, which suits a pilot; in observe the allow-lists and fail-closed are held back, because they have no report-only form.

What the auditor receives

The console builds a signed evidence pack per framework and window: the controls, the evidence items that show they operated, a printable report and a VERIFY.txt that checks the signature with OpenSSL alone. The mapped frameworks include SOC 2, ISO/IEC 27001, NIST CSF, NIST AI RMF, ISO/IEC 42001, ISO/IEC 27090 and the EU AI Act. PCI DSS, DORA and HIPAA are not among them; the records and the pack are the raw material your assessor maps to those. A mapping is evidence, not a certification. The compliance crosswalk lists what MoorAI offers for each framework, the MITRE ATLAS coverage study reads AI-security vendors against the ATLAS agentic techniques, and the comparison sets MoorAI beside other vendors capability by capability. For the use case in one page, see AI agent security for regulated and defense teams; for the coding-agent hooks, see AI coding agents.

A pilot that produces evidence

Enroll the pilot group’s devices through MDM. The deploy scripts write the root-owned machine config and the user’s own token file, so the device is managed from its first call.
Apply the Regulated mode in observe. Read the alerts and the coverage findings for a few weeks: which agents ran, which settings were weakened, which MCP servers and destinations appeared.
Write the allow-lists from what you observed. MCP servers, model endpoints and egress hosts, then route the high-risk classes to an approver group.
Switch to enforce and choose the fail mode. Then widen the rollout, and generate an evidence pack for the pilot window to check that it answers your auditor’s questions before the audit does.

Questions regulated teams ask

Do Claude Code managed settings and Codex requirements.toml make another control unnecessary?

They are the first layer, and a regulated rollout should use them. They decide by rule which tools, commands, paths, domains and MCP servers are allowed. Checking what a call carries, such as a card number in a command or a secret in a file about to be read, and keeping a record of each decision where the agent cannot write, takes a control that runs on every call. MoorAI runs in the hooks and also compiles its policy into both files and reports when they drift.

Does MoorAI cover Codex as fully as Claude Code?

Not in every respect. In Codex CLI, MoorAI blocks before the tool runs once the user has trusted its hook in Codex. Codex has no ask, so a MoorAI ask becomes a deny, and approval holds, masking and the post-tool scans of command output are Claude Code features. Web search runs on OpenAI’s side and never reaches a hook, and Codex cloud is not supported. The Codex adapter is tested against fixture payloads and Codex’s published hook schemas; no live Codex agent turn has been run through it.

What does the auditor actually receive?

Content-free records, each with a category, a risk level, a keyed one-way hash, the policy that decided and the verdict, plus coverage findings for agents that ran without MoorAI. The console exports a signed evidence pack per framework and audit window that verifies offline with OpenSSL. No prompt, file or code is in any of it.

Can we run it with nothing leaving our network?

Yes. The hook decides on the device and needs no network, and the Management Server runs as a Docker container in your own environment with no internet access: enrolment, signed policy delivery and alert ingest all work with no outbound route. A device that never reaches its console can hand its alerts over in a bundle file that the console verifies and imports.

Sources

Anthropic. Settings files and precedence and Hooks reference, Claude Code documentation: managed settings precedence, PreToolUse, allowManagedHooksOnly and hook timeouts.
OpenAI. Agent approvals & security and Managed configuration, Codex documentation: sandbox, approval policy, requirements.toml and managed hook failure behaviour.
PCI Security Standards Council. Just Published: Security Considerations for AI Systems, PCI Perspectives blog, 15 September 2026.
European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), Article 9(4)(c).
US Department of Health and Human Services. 45 CFR 164.312, technical safeguards, (b) audit controls.
MoorAI. MoorAI on GitHub, agent v1.41.0: README sections “What it does”, “Other agents”, “Air-gapped deployment”, “Fail open or fail closed: the administrator decides”, “Just-in-time approval routing”, “One policy, each agent’s own settings files” and “Keeping up with the agent hosts”; Management Server v0.99.0 documentation, “Coverage integrity”, “Evidence pack”, “Governance modes” and “Air-gapped deployment”.