AI & Agents

Agentic Coding Governance: The Agent Wrote It, Tested It and Merged It. Who Decided?

Agentic coding governance is a record of who allowed what, not a bigger review queue. Learn the four questions to ask and see your estate free in 15 minutes.

GR
Gil Rachlin
Diwo Team
November 9, 20267 min read
Agentic Coding Governance: The Agent Wrote It, Tested It and Merged It. Who Decided?

Agentic coding gives you a teammate that plans, writes, tests and opens the pull request on its own. Governing it isn't a bigger review queue. It's a record of who allowed what, kept above the tools you already run.

This post is part of our AI Code Governance series. Start with the pillar: AI Code Governance: A 2026 Field Guide.

An engineer hands an agent a ticket on a Tuesday morning: "Move the billing retries to the new queue." Then she goes to a meeting. By the time she's back, the agent has read the repository, edited, say, fourteen files, written the tests, run them and opened a pull request. The tests are green. The scanners are quiet.

Someone approves it in a couple of minutes. Or no one does. Months later a customer is charged twice, and the question arrives: who decided this change was safe to ship? The author field names an agent. The reviewer field is empty. Nobody can answer.

That is not a thought experiment. In a real 52-repo engineering org, the first Provenance connection surfaced 25 AI-authored pull requests merged with zero recorded human review.

What is agentic coding?

Agentic coding is software development where an AI agent takes a goal, not a prompt, and carries it through several steps on its own: read the repo, plan, edit, run the tests, open the pull request, and sometimes merge it.

Autocomplete suggests a line. An agent finishes a ticket.

The difference is where the human sits. A suggestion has a person at every keystroke. An agent has a person at the start, and maybe at the end.

Why agents change the governance problem

Three things move at once, and each one breaks an assumption your program was built on:

• Volume. An agent opens changes faster than any review process was designed to read them, and each one looks plausible. • Autonomy. The agent's own settings decide how much it can do unasked. An allow-list, a deny-list and an auto-approve switch sit in a settings file in the repository, and they define how much power the agent was given. • Custody. When a human writes a change, the author is accountable by default. When an agent writes it, the name on the commit is a tool, and accountability has to be recorded because it can't be assumed.

Quality is part of it too. Veracode reports that AI picks the insecure implementation 45% of the time in its testing. Speed without a record is how that ships.

Why your existing tools wave it through

Your scanners read what code says. Your tests prove what the agent chose to test. Your policy states a rule. None of them records which agent wrote the change, what permissions it ran with, or whether a human looked before it merged.

A scanner can be right that nothing is wrong with the code and still miss that nobody owned the merge. Nobody watches the building.

More detection on top of a missing record gives you more alerts and the same unanswered question.

The four questions for every agent-written change

Strip away the tooling and agentic coding governance comes down to the same loop we use for all AI-written code, the Accountability Loop:

• Attribute. Which agent wrote this change, in which repository, with which settings? • Classify. Does that repository touch production, customer data or money? • Decide. Against your controls, is this proven, a gap or a violation, and who owns it? • Prove. Can you hand a board, an auditor or an insurer the record?

Attribute → Classify → Decide → Prove. If your program can't do all four for agent-written changes, the missing step is where your exposure lives.

A control is a fact, not an opinion

The tempting shortcut is to ask a language model whether an agent's work looks fine. It will answer. That answer is an opinion, and it can't be sealed or reproduced in an audit.

Reading the switch is different. "Auto-approve is on in a repository that reaches production" is an observed fact: a value was read from the agent's settings. "A pull request merged with no recorded reviewer" is an observed fact too. What can't be observed is marked as a gap for a person to attest.

That is also how the record maps to the frameworks you answer to. Provenance grades evidence readiness against the EU AI Act and the NIST AI RMF. It is evidence readiness, not a legal determination. Your counsel makes the legal call.

What to do this quarter

Four steps, none of which needs a purchase order or a change to how your engineers work:

  1. List your agents. Write down every coding agent in use across the org, sanctioned or not: Copilot, Claude Code, Cursor, Devin, Codex. If the list comes from a survey, mark it as a claim.

  2. Read the switches. Open each agent's settings file in your repositories and note where auto-approve or bypass mode is on, and what the allow-list permits.

  3. Count the unreviewed merges. Pull last quarter's merged pull requests where the author is an agent and the reviewer field is empty. That number is your starting exposure.

  4. Write one rule and evidence it. "No agent merges to a sensitive repository without a recorded human approval." Make it a row in your control matrix that is checked continuously, not a line in a policy nobody re-reads.

Where Provenance fits

Diwo Provenance is the governance layer above the scanners you already run. It reads signals your estate already emits, including the agents' own settings files and the merge and review history, and derives which changes AI wrote, with what permissions, and whether a human reviewed them. It turns that into decisions (fix, waive, accept) with a named owner and a sealed record. It is not a scanner, and it reads code signals, never your source. A coach, not a blocker.

Seeing your own estate takes about 15 minutes, free and read-only: Connect your estate free at https://provenance.diwo.ai/provenance/signup

The agent can finish the ticket. Someone still has to own the merge.

Related reading

• AI Code Governance: A 2026 Field Guide: the pillar and the full operating model. • Your AI Agent Has Your Production Keys: Here's How to Find Out • Who's Accountable When AI Writes the Code? • What is AI code governance?

Frequently Asked Questions

What is the difference between agentic coding governance and AI coding assistant governance?

Assistant governance sets which tools people may use. Agentic coding governance records what agents actually did: which changes they wrote, with which permissions, and whether a human approved the merge.

Do I need to put another agent or plugin in my pipeline?

No. Provenance is read-only and works retroactively from history already in your repositories and your agents' settings. No engineer changes how they work.

Does this make us ready for the EU AI Act?

No tool can promise that. Provenance maps your evidence to the EU AI Act and the NIST AI RMF and shows where it is ready and where there are gaps. Your counsel makes the legal determination.

See it in action Your scanners detect. Provenance decides. Book a working demo →

TagsAI code governanceagentic coding governanceagentic codingAI coding agent governanceAI agentsAI agent security
See it in action
See a decision made on your data?