AI Coding Agent Governance: What to Control Before Agents Write Production Code

TL;DR: AI coding agent governance comes down to five controls. Each agent has its own identity. Its repository and tool access is scoped to the job. Policy runs on every request before code or data leaves the machine. Every pull request passes security checks that block unsafe changes, not AI-written ones. And a person merges. The human still decides; the controls make that decision informed and recorded.

Coding assistants and autonomous coding agents are no longer a side experiment. They write functions, fix failing tests, upgrade dependencies and open pull requests against repositories that ship to production. Enterprises evaluating governance for their coding assistant rollout, whichever tool their developers prefer, keep landing on the same questions: who allowed this agent, what could it reach, what checked its output, and who approved the merge?

This post sets out what to control and in what order. For the deeper detail on branch protection and permission ladders, see our earlier piece on governing AI coding agents that touch production code.

Key takeaways

• Treat every coding agent as a privileged automation identity, not as an extension of the developer who started it.
• Govern the request as well as the result: what goes into a prompt matters as much as what comes back.
• Check every pull request, block only on new serious findings in changed lines, and fail closed when a check cannot run.
• Review the agent itself, its models, tools, prompts and skills, before it is promoted, not only the code it writes.
• Keep merge and release authority with named people.

Why coding agents need their own governance

A coding assistant inside an editor and an autonomous agent working through a backlog are different actors, but they share one property: they produce code faster than a team can carefully read it. That changes where risk sits.

Three things go wrong in unmanaged rollouts. Sensitive values end up in prompts, because a developer pasted a config file or a log with a key in it. Agents get broad access, because the fastest way to make a trial work is to hand over a personal token. And review becomes the only control, at exactly the moment review capacity is the bottleneck.

Governance does not mean slowing all of this down. It means moving the important decisions earlier, so they are made once, by the right owner, and enforced automatically after that.

1. One identity per agent

If an agent authenticates as a developer, its changes look like that developer’s work, and you lose the ability to say which changes came from an agent and which person asked for them.

Give each agent its own identity, scoped to the repositories it needs, and record the requesting person on each run. Keep that identity off any branch-rule bypass list. On GitHub, rulesets carry a bypass list that can include apps, and an app added during a trial tends to stay there (about rulesets). Check it.

The wider pattern is covered in our post on AI agent identity and permissions.

2. Scoped access to repositories, models and tools

Scope is not just repositories. A coding agent also reaches models and tools: a shell, a test runner, a package registry, and increasingly tool servers that connect it to tickets, documentation and internal systems.

Decide each of those deliberately:

• Models. Only approved models should be reachable. A request to an unapproved model should be refused, not quietly allowed.
• Tools. Tool servers should come from a vetted registry, cleared by security and risk before agents can call them.
• Repositories. Write access ends at a branch and a pull request. Workflow files, CI configuration and infrastructure code sit behind a stricter review, because editing them changes what runs with your secrets.

In Moring’s AI coding agent governance on the AI-DLC page, one command per laptop routes the coding assistant through an AI gateway, and only approved models and AI tools are accepted. Developers keep their own subscriptions; the routing is what gives you a single place to apply policy.

3. Policy on every request

Most governance programs start at the pull request. The earlier risk is the prompt.

Policy on the request path decides what may leave the developer’s machine. In AI-DLC, each rule blocks, redacts or logs:

• Blocked, nothing sent: private keys, US social security numbers, payment card numbers, classification labels and customer IDs.
• Redacted, the rest goes through: cloud keys, GitHub, Slack and model API keys, and password values.

Rules start in monitor mode, so you can see what would be caught before you enforce. A new policy applies within a minute, and the last ten policy versions are kept, so you can show what the rule was on a given day. Security admins can read coding assistant sessions for 30 days, with sensitive values masked.

That last point matters for an investigation. If a customer ID appeared in a prompt, the record shows the request was refused and nothing was sent, which is a different conversation from “we think it was fine.”

4. Security checks on every pull request

The second checkpoint is the pull request. Here the goal is precise: block unsafe code, not AI-written code as such.

AI-DLC’s Security Check runs seven checks on every pull request to a protected repository: secrets, risky code, AI code smells, fake packages, dependency CVEs, infrastructure, and an AI review. Three design choices make it workable in practice:

• It blocks narrowly. Only a new high or critical finding on a line the change wrote blocks the merge. Everything else warns. Developers are not punished for pre-existing debt.
• It fails closed. If a check cannot run, the pull request is blocked. A green build always has evidence behind it.
• The AI review is checked against itself. One model proposes flaws; a separate verifier tries to disprove each one. Only a confirmed finding blocks. If the result is unsure, it goes to a person and never blocks on its own.

Some failure cases are worth testing deliberately. A code comment telling the AI review to ignore a flaw does not work; the flaw is still reported. A pull request that brings its own scanner settings to switch checks off is ignored. A package that does not exist, a common symptom of a model inventing a dependency name, is blocked. The GitHub app that runs the checks cannot change code, branches or settings.

5. Review the agent, not just its output

When the coding agent is itself something your team builds and deploys, there is a third checkpoint: the agent before it goes to production.

Moring’s Governance Plane builds a manifest of the agent at one commit: its frameworks, prompts, models, tools and skills. Thirty-one rules run against that manifest. Each finding names the rule, severity, file and line, with one redacted evidence line and a suggested fix, and the fixes arrive as one pull request that never changes the agent’s logic. The agent receives its own identity at this stage.

Deployment then builds by exact image fingerprint, tests on staging, runs six pass-or-fail checks and issues a certificate naming exactly what would go to production. Only named production approvers can promote it, and nobody approves their own deploy. The certificate is the answer to “what exactly is running?”

6. A person merges, and can stop the agent

Merge and release authority stays with people. The checks above exist to make that decision informed: a reviewer looking at a pull request that has already been scanned, with serious findings confirmed or ruled out, is doing a better job than one reading raw output.

The same principle holds after deployment. If an agent misbehaves, Stop agent blocks its key, so the gateway refuses every call, and the record shows who stopped it, when and why. Only the production approver or a super admin can resume it. Each agent’s key reaches only its granted models and carries a monthly budget; calls past the cap are refused. That is the AI Control Plane side of the same governance: the decision about what is permitted lives outside the agent.

What to measure

Once controls are in place, a few numbers tell you whether they are working. These come from the record, not from surveys:

Treat early numbers as a baseline rather than a result. Your own figures will depend on repositories, teams and how much traffic routes through the gateway.

A sequence that works

You do not need everything on day one. An order that keeps disruption low:

1. Route coding assistant traffic through a gateway and turn on request policy in monitor mode.
2. Move the highest-confidence rules, such as private keys and customer IDs, to enforce.
3. Protect your most sensitive repositories with pull request checks.
4. Give autonomous agents their own identities and remove them from any bypass list.
5. For agents you build and run, add manifest review and a deploy certificate before promotion.

Each step produces a record you can show a security reviewer. That is what lets a bank or insurer say yes to coding agents on production repositories, rather than banning them and finding them anyway.

The version to take into your next review is short: every coding agent has its own identity, it can reach only what it was granted, what it sends and what it writes are checked, a person merges, and someone can stop it. If you cannot say all of that today, start with step one.

Frequently asked questions

Sources

About the author

Arya SharanProduct Marketing & GTM, Moring AIChennai

Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.

LinkedIn profile →