Governance for AI coding tools is narrower and more tractable than "AI governance" in general. The seven controls are model allowlists, data-handling and residency rules, audit logging, seat lifecycle, agent action boundaries, secrets handling, and spend caps. Each is enforced somewhere specific: a managed settings file on the device, an identity provider, a gateway in the request path, or nothing at all if the developer holds their own key. Regulatory exposure is real but narrower than vendors imply: EU AI Act transparency duties under Article 50 applied from 2 August 2026, while high-risk obligations for standalone Annex III systems were deferred to 2 December 2027 by the Digital Omnibus.
- Seven controls, each with a specific enforcement point. A control with no enforcement point is a paragraph in a document.
- Managed settings beat policy documents. Claude Code reads an immutable managed file at a fixed OS path that no user setting can override.
- Model allowlists need
enforceAvailableModels, not justavailableModels. A list without enforcement is a suggestion. - EU AI Act high-risk duties moved. Annex III standalone systems now apply from 2 December 2027; Article 50 transparency still landed 2 August 2026.
- A coding agent is almost never a high-risk AI system. Do not buy a governance suite to solve a paragraph that does not apply to you.
Governance for coding tools is a smaller problem
"AI governance" as a category covers model risk management for systems that make consequential decisions about people. An AI coding assistant is not that. It writes code that a human reviews and a pipeline tests, inside an organization that already has change management, code review, and access control.
That means most of the generic AI governance apparatus is the wrong shape here, and the parts that matter are unglamorous: who can use which model, what leaves the building, what gets logged, and who still has a seat after they left.
The seven controls, and where each is enforced
| Control | Enforced where | Fails when |
|---|---|---|
| Model allowlist | Managed settings on the device, or a gateway | The developer holds their own API key |
| Data handling and residency | Provider account settings and inference geo flags | Someone signs in with a personal account |
| Audit logging | Provider admin APIs, gateway logs, local agent logs | Traffic bypasses the logged path |
| Seat lifecycle | Identity provider plus vendor seat API | Long-lived tokens outlive the seat |
| Agent action boundaries | Permission rules in managed settings, sandboxing | Skip-permission modes are available |
| Secrets handling | Host keychain, per-repo scoping, deny rules | Keys sit in a committed .env |
| Spend caps | Only a system in the request path | BYOK, always |
Read the right-hand column as the design brief. Six of the seven fail the same way, which is a developer holding a credential that does not go through anything you control. Governance for AI coding is, to an uncomfortable degree, credential governance.
What enforcement actually looks like
Concrete example, because this is the part that gets waved at. Claude Code reads a managed settings file that sits at the top of the precedence order and cannot be overridden by a user, project, or local setting, nor by a command-line flag.
| Platform | Path |
|---|---|
| macOS | /Library/Application Support/ClaudeCode/managed-settings.json |
| Linux and WSL | /etc/claude-code/managed-settings.json |
| Windows | C:\Program Files\ClaudeCode\managed-settings.json |
{
"permissions": {
"allow": ["Bash(npm run test *)", "Bash(git status)"],
"deny": ["Bash(curl *)", "Read(./.env*)", "Read(./secrets/**)"],
"defaultMode": "default"
},
"availableModels": ["sonnet", "haiku"],
"enforceAvailableModels": true,
"allowManagedPermissionRulesOnly": true,
"allowedMcpServers": [{ "serverName": "github" }],
"allowManagedMcpServersOnly": true,
"disableSideloadFlags": true,
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": "your-org-uuid",
"cleanupPeriodDays": 7,
"env": { "CLAUDE_CODE_ENABLE_TELEMETRY": "1" }
}Note the honest limit: this governs the CLI on a managed device. It does nothing about a developer running the same tool on a personal laptop with a personal subscription, which is the actual gap in most organizations and is an identity problem rather than a settings problem.
The regulatory layer, practically
Three instruments come up in every enterprise AI governance conversation. Here is what each one actually asks of an engineering organization using coding agents.
EU AI Act
General-purpose AI model obligations took effect on 2 August 2025 and fall on the model providers, not on you as a deployer. Article 50 transparency duties, including disclosing when a person is interacting with an AI system, landed on 2 August 2026 and were not deferred. High-risk obligations moved: under the Digital Omnibus on AI, which entered into force on 27 July 2026, standalone Annex III high-risk systems apply from 2 December 2027, and AI embedded in regulated products under Annex I from 2 August 2028.
NIST AI RMF
Voluntary, US-origin, released as version 1.0 on 26 January 2023, structured around four functions: Govern, Map, Measure, Manage. NIST added a Generative AI Profile, NIST-AI-600-1, on 26 July 2024. Its practical value here is as a checklist vocabulary rather than a compliance obligation. If an enterprise customer asks whether you follow a framework, this is the cheapest honest yes.
ISO/IEC 42001
The first international AI management system standard, published in 2023, with 38 controls across 9 objectives and a Statement of Applicability in which you justify to an auditor both what you adopted and what you excluded. Certification runs Stage 1 and Stage 2 audits, is valid three years with annual surveillance, and typically costs $20,000 to $60,000 over four to nine months, less if you already hold ISO 27001. Pursue it when customers are asking for it in procurement, not before.
Governance suites versus built-in controls
The vendor landscape splits, and the split matters more than the feature lists.
- Governance suites (model registries, risk catalogues, policy workflow) are built for organizations that ship AI models into regulated decisions. They document. They do not sit in the request path, so nothing they say is enforced.
- Gateways enforce because they are in the path: model routing, per-key budgets, and request-level rules. Portkey puts granular budget and rate limits behind its Enterprise tier; the open-source core is free to self-host.
- Built-in organization controls in the coding tool itself are the shortest path for the controls on this page, because the tool already knows which member ran which session on which model.
- Device management is the delivery mechanism for everything file-based. Without it, a managed settings file is a document you emailed people.
The incident playbook nobody writes until they need it
Four scenarios worth having an answer for before the day you need one.
A credential leaked into a prompt
Rotate first, investigate second. Then check whether the provider retains prompts under your current plan and data-retention setting, whether your observability tool logged the request body (Claude Code redacts prompts unless OTEL_LOG_USER_PROMPTS is set), and whether a transcript sync stored it. The blast radius is every system that logged the turn, not just the model.
An agent ran a destructive command
Recover from version control, then close the class rather than the instance. Add the command to the managed deny list, verify allowManagedPermissionRulesOnly is set so a project file cannot re-allow it, and check whether the session was running in a permission-skipping mode that made the approval prompt unreachable.
Spend spiked overnight
Look at the rate of change, not the total. Find the API key, then find whether it is attached to a human or to automation. Runaway loops are the usual answer and they are a retry-policy bug, not a usage problem.
Someone left and still has access
Removing them from the identity provider is step one of several. Long-lived tokens are the gap: a token minted by claude setup-token is valid for a year and lives wherever it was pasted. Revoke tokens, remove the vendor seat, unpair devices, and rotate any shared key the person held.
Questions people ask
What is enterprise AI governance?
Enterprise AI governance is the set of controls that decide which AI systems an organization may use, on what data, by whom, with what oversight and what limits. For engineering teams using AI coding tools it reduces to seven enforceable controls: model allowlists, data handling and residency, audit logging, seat lifecycle, agent action boundaries, secrets handling, and spend caps.
Do we need an AI governance platform?
Only if you deploy AI into consequential decisions about people, or if procurement is demanding evidence of a formal management system. For an engineering organization whose AI usage is coding assistants, the controls that matter are enforced by managed settings files, an identity provider, and a gateway, none of which a governance suite provides. Governance suites document. They do not sit in the request path.
Does the EU AI Act apply to AI coding assistants?
Barely. General-purpose AI model obligations from 2 August 2025 fall on model providers. Article 50 transparency duties applied from 2 August 2026 and concern disclosing AI interaction to people. High-risk obligations were deferred by the Digital Omnibus, which entered into force on 27 July 2026, to 2 December 2027 for standalone Annex III systems. A coding assistant used internally is not an Annex III system, so the exposure is in what you build, not what you code with.
How do I restrict which models developers can use?
Deploy a managed settings file through your device management tooling with both availableModels and enforceAvailableModels set to true; the list alone is only a default. Pair it with allowManagedPermissionRulesOnly so project settings cannot widen it. On the hosted side, an organization-level model policy on your gateway or inference provider catches traffic from machines you do not manage. Neither reaches a developer using their own API key.
What are the four functions of the NIST AI Risk Management Framework?
Govern, Map, Measure, and Manage. The framework was released as AI RMF 1.0 on 26 January 2023 and is voluntary. NIST published a Generative AI Profile, NIST-AI-600-1, on 26 July 2024 to cover risks specific to generative systems.
Is ISO 42001 worth certifying against?
It is worth it when customers ask for it in procurement. ISO/IEC 42001 defines an AI management system with 38 controls across 9 objectives, requires a Statement of Applicability justifying inclusions and exclusions, and certifies through Stage 1 and Stage 2 audits valid for three years with annual surveillance. Budget $20,000 to $60,000 and four to nine months, shorter if you already hold ISO 27001.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.