AI coding agent governance: the guardrails that keep AI-generated code safe

AI coding agent governance is the set of controls that make it safe to let an agent draft production code: a review gate that requires a real human sign-off before anything merges, a security policy that scopes exactly what the agent can touch, and specific defence against the two risks unique to agents, prompt injection and data leakage. None of it is about slowing the tool down. It is about making the speed safe to use.

This page is the governance model itself, the specific technical controls. The programme that installs those controls across a whole engineering team, over roughly a quarter, training included, is AI-native engineering. Read this page for the controls. Read that one for how a team adopts them.

Why AI-generated code needs a governance model, not just a tool

CodeRabbit's State of AI vs Human Code Generation Report found AI-authored pull requests had about 1.7x more issues than human-only ones (470 open-source pull requests, December 2025). An agent is fast and confident, and neither trait correlates with correct. It produces code that compiles, passes a casual read, and is wrong in a way a rushed reviewer misses, because it reads exactly like code a competent engineer would write.

The instinct to fix this by buying a better tool is the wrong instinct. Across the region, leaders name organisational barriers ahead of technical ones as the reason AI initiatives stall (Deloitte–HKU AI Adoption Index, 2026), and code safety is the same story: the gap is rarely model quality. It is whether anyone designed the review step, the access controls, and the definition of done before the agent started shipping. Governance is a people-and-process system, not a setting you switch on.

The failure mode is also specific, and worth naming plainly. An agent defaults to "make it work," not "make it correct, minimal, and safe," because that is what its training and its instructions reward unless you explicitly reward the other three. It will over-permission a database call because the broader grant made the error go away. It will handle the happy path convincingly and quietly mishandle an edge case a senior engineer would have flagged on sight. None of that shows up in a quick glance at a diff that reads like clean, idiomatic code, which is exactly why the review step has to be structural, not a habit you hope survives a deadline.

The review gate: what has to happen before an agent's code merges

The rule is simple to state and easy to skip under deadline pressure: an agent's output is a draft, never a commit.

• No agent-authored change merges without a second human reviewer who reads the diff, not just the description of what changed.
• Tests are part of the definition of done, written or reviewed by a human, not generated and trusted blind.
• The agent's own explanation of its change is a starting point for review, never a substitute for it.
• Anything touching authentication, payments, or customer data gets a named senior reviewer, no exceptions.

The security policy: what an agent is allowed to touch

Review catches what an agent got wrong. A security policy limits what it could get wrong in the first place.

• Agents work with scoped, short-lived credentials, never with a human's full production access.
• Dependencies an agent proposes get the same vetting a human's would: known maintainers, no fresh, unvetted package pulled in to solve a problem quickly.
• Secrets and credentials never sit in a prompt, a rules file, or anywhere an agent's context window can read them.
• Every environment, dev, staging, production, carries its own access scope; clearance for one is not clearance for all three by default.

Supply-chain risk: the dependencies an agent pulls in

An agent asked to solve a problem quickly will often reach for a package rather than write the logic itself, the same shortcut a junior engineer takes under deadline pressure, just faster and with more confidence in the choice. That is a real supply-chain exposure: a typo-squatted package name that looks right, an unmaintained library with a known and unpatched vulnerability, or a licence that is not actually compatible with what you are shipping. None of that is hypothetical; it is the same risk dependency management has always carried, arriving faster and with less human judgment in the loop by default.

The fix is not banning agents from adding dependencies. It is the same review discipline applied one level earlier: a new dependency an agent proposes gets the same human check a new dependency a person proposes would get, before it lands in a lockfile, not after.

A definition of done for agent-generated code

"It works" is not a definition of done for an agent's output any more than it would be for a junior engineer's first pull request. A change is done when it passes the same bar a senior engineer's own commit would: a named human is accountable for it, tests exist and were reviewed rather than merely generated, no secret or credential appears anywhere in the diff, and anything touching a critical path has a rollback plan before it ships, not one improvised after it breaks. Writing this down once, and holding every agent-assisted change to it, is most of what governance actually is in practice.

Prompt injection and data leakage: the risks specific to agents

Prompt injection is what happens when an agent reads untrusted content, an issue ticket, a scraped webpage, a dependency's README, a code comment, and treats instructions hidden inside it as commands from you. A coding agent with repository and internet access is exposed to it exactly the way a chatbot is. Data leakage is the mirror risk: an agent with broad read access summarising or pasting content elsewhere, a pull request, a log, an external service, and carrying secrets or customer data along with it without anyone intending that.

The defence against both is the same discipline: treat everything an agent reads as data, never as an instruction; sandbox its tool use so it cannot execute a shell command or call an external service outside a fixed allowlist; and diff its output before anything runs, not after. None of this requires exotic tooling. It requires deciding, in advance, what an agent is trusted to do unsupervised, and keeping that list short.

Measuring whether the guardrails are actually working

None of this is worth installing if nobody checks whether it works. I measure it against a baseline: defect rate before and after the guardrails go in, how much the review gate catches before merge versus what still reaches production, and whether review turnaround stays fast enough that engineers do not quietly route around it. If you do not know your team's current numbers, an engineering audit is where that baseline gets set, before any AI-specific guardrail is installed on top of it.

Who needs this, and when

This tends to matter most for three situations, and the fix is the same governance model in each:

• A team already shipping AI-assisted code with no review discipline beyond the habits it had before agents arrived, where usage grew faster than anyone updated the rules.
• A team about to adopt agents that wants the guardrails built in from day one, not retrofitted after an incident forces the question and the fix has to happen under pressure.
• A near-miss or an actual incident involving agent-generated code, a leaked credential, a bad migration, a dependency that should never have been pulled in, that made the question impossible to defer any further.

In every case, the work is the same: write the review gate and the security policy down, not as a memo nobody reads but as the actual condition for a merge, put a named person accountable for enforcing it, and measure whether it is holding. It is not a one-time setup task any more than code review itself is. It is a standing part of how the team works, for as long as agents are writing code, which by now is indefinitely.