Guide
What's the best way to govern AI coding agents across an enterprise?
Updated
Short answer
Govern coding agents with four things: an inventory of which agents run where, one policy that applies to all of them, enforcement on every action before it runs, and Records you can show an auditor. Enforcement has to sit outside the agent. Roll it out watch-only through the MDM you already run, and give exceptions an owner and an expiry date.
Governance is four jobs#
Most governance plans stop at a policy document and a settings file. That covers the first week. It doesn't cover the agent your team installed last Tuesday.
Here's the shape that holds up:
- Inventory: which agents run on which machines, with which credentials.
- One policy: a single set of rules that means the same thing in every agent.
- Enforcement: every command, file edit and push checked before it runs.
- Records: a log of what was allowed, blocked and asked, that an auditor can read.
Miss one and the others stop working. A policy you can't enforce is a wiki page. Enforcement you can't audit is a promise.
Start with inventory#
You can't set policy for agents you don't know about. A developer can install a new one without procurement ever hearing about it.
Ask three questions per machine: which agents are installed, which extensions and MCP servers they load, and what credentials sit within reach (cloud keys, SSH keys, tokens in dotfiles). Your MDM and EDR already have part of this. For the rest, see your shadow AI problem is an inventory problem and how to vet agent extensions and plugins.
Decide who owns what#
Security owns the policy and the exceptions. Engineering owns the workflow and the speed.
The split matters because the two sides want different things. The AI or platform leader wants agents running unattended for hours; the security leader wants to say yes without being the one blamed when an agent does something bad. A shared policy, owned by security and tuned with engineering, gets both.
Write down three names: who approves a new agent, who approves a policy exception, and who reads the weekly Records review.
Why per-vendor settings fragment#
The major agents ship admin controls, and they work. Claude Code's managed settings apply above every other level, so no user, project, local or --settings value overrides them. Cursor admins can push a permissions file through Jamf, Kandji, Intune or any other device management tool.
Codex has requirements that constrain what users and tasks can do. Copilot has enterprise policies, including a toggle that blocks the cloud agent.
Use all of them. They're the right baseline.
The catch: each is a separate file format, a separate vocabulary and a separate set of switches. "No force-push to main" gets written four ways, enforced four ways, and logged (or not) four ways.
So you end up with four policies that drift. The security team can't answer "what did agents do last week?" without four exports.
Why enforcement has to sit outside the agent#
Controls that live with the agent fail in ordinary ways. A long session compacts its context and drops an instruction, an injected line in a README reads like a task, or a tired human clicks approve.
That last one is measured. Anthropic reports that users accept 93% of manual permission prompts anyway. In its controlled study of 1,053 testers, people caught the dangerous command just 13.6% of the time.
So the check has to be something that doesn't tire out and doesn't live in the agent's context. It runs at the agent's pre-execution hook, where each action is evaluated before it executes. For what hooks can and can't enforce, see Claude Code hooks: what they enforce.
Roll out watch-only, through the MDM you already run#
Don't start by blocking. Start by looking.
- First: push the control to a pilot group in log-only mode. Read what agents actually do.
- Next: turn on blocks where the action itself is the evidence: secrets reaching a network call, a private key read, a recursive delete at the root, curl piped to a shell.
- After that: widen to actions that need session context, and expand to the rest of engineering.
MDM puts the same policy on every laptop without asking developers to configure anything. The staged version of this plan is in rolling out Claude Code to 1,000 engineers.
Review exceptions on a schedule#
Exceptions are where governance quietly dies. One team needs production access for a migration, so a rule gets loosened and never tightened again.
Treat each exception as a ticket with an owner, a reason and an expiry date. Review the list monthly.
Anything without an expiry gets one. Anything nobody can explain gets removed.
Read the blocks too, not just the exceptions. A block that fires every day on the same harmless command is a policy bug. A block that fires once on a secret leaving the laptop is the control doing its job.
Where Harden fits#
Harden Agentic Integrity Foundation (AIF) is the enforcement and Records layer in this plan. It runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Every command, file edit and push is checked against the session's intent before it runs.
Decisions are made locally, with verdicts in about 28 ms, and nothing leaves the machine. One policy applies across the agents your developers use.
It starts watch-only and is pushed by the MDM you already run. Every decision is recorded, and Records can be exported to a SIEM.
It's a layer, not a perimeter. It doesn't replace least privilege, scoped credentials or egress policy, and a sandbox still bounds reach. For the security-team view, see Harden for security teams.
FAQ
Related questions
Are built-in managed settings enough to govern coding agents?
They're the right baseline and you should deploy them. But each agent has its own format and switches, so policy drifts between agents, and you get no single record of what all your agents did.
Who should own coding agent governance, security or engineering?
Security owns the policy and the exceptions. Engineering owns the workflow and flags what's blocking real work. Name one approver for new agents and one for exceptions.
Why start in watch-only mode?
It shows you what agents actually do before you block anything, so your first blocks are based on evidence and don't break developer workflows. It also builds trust with the engineering sponsor.
What Records does an auditor need for coding agents?
A log of each action the agent attempted, the decision (allow, block, ask, redact or log only), the reason, and who changed the policy. Exporting it to your SIEM keeps it with your other security evidence.
How do I handle policy exceptions?
Give each exception an owner, a reason and an expiry date, and review the list monthly. Remove anything nobody can explain.