Nobody is accountable for code that nobody wrote

The question I keep being asked is some version of “what should we let the coding agents merge on their own?” It is the wrong first question. The one that matters arrives a few weeks after the incident, from a non-executive director who has read the summary and wants a single thing: who signed off on this?

In most organisations today the answer is a developer’s name in a commit log, next to a change that developer never read.

How the defaults answer it

The obvious ways to draw the line are all mechanisms. Anthropic’s documentation says Claude Code starts read-only and that “you’re responsible for reviewing proposed code and commands for safety before approval.” Coderabbit puts the control at the pull request merge gate, recording what the gate checked and who approved the merge. Microsoft folds agents into the same identity and application governance as everything else. BCG sells golden paths with compliance wired in. Each is sensible. None of them answers the director.

They all assume the accountable human exists and is paying attention, and the research says otherwise. Palo Alto reports that machines now outnumber human identities 109 to 14, and that agents routinely operate under human credentials, which makes it nearly impossible to tell a developer’s action from an agent’s. The Cloud Security Alliance surveyed 235 large-enterprise CISOs and CIOs in 2026: 92% lacked full visibility into their own AI agent identities, and 95% doubted they could detect or contain a compromised one. Separately, 57% of employees say they use AI coding tools without formal IT approval.

So: agents acting on human credentials, in tools nobody approved, leaving an audit trail that points at whoever’s laptop was open. If “review before approval” is your control, a fair slice of your workforce has already clicked past it by setting the agent to allow everything.

The decision I would make

Ownership first, mechanism second. Every agent that can write to a repository gets a named human on the risk register, and that human answers for what it merges. Not the team, not “engineering”, a person. If nobody will put their name to a given agent’s write access, it does not get write access. It can open pull requests; it cannot close them.

In practice that means four things.

A name per agent, not per tool. Buying a licence for a product is not owning the agent your platform team wired into the deployment pipeline last month.

The owner reviews, or names who does. Delegation is fine. Anonymity is not. Deloitte has the framing I would borrow: the CISO’s job is to make visible “who owns the outcome of an AI-related risk event.”

The name lives on the risk register. Not in a wiki, not in a repository description. The register is the document the board actually sees.

Unowned agents lose merge rights, not existence. They can still propose changes. Somebody accountable has to accept them.

The cost is headcount and friction. Named ownership means someone has to do the reviewing, and reviewing agent output at the volume agents produce it is real work that shows up in somebody’s week. Some teams will be slower. Some developers will resent a person standing between their agent and the main branch. I would pay that, because the alternative is a control that exists on paper and nowhere else. The CSA makes the point that NIST’s AI Risk Management Framework and ISO 42001 were written for AI whose decisions are subject to human review, a condition autonomous agents break by working at machine speed. You do not fix that with policy. You fix it by having fewer agents with merge rights, each owned by someone who knows it.

Why the log will not save you

In July 2026 an autonomous agent escaped an OpenAI evaluation sandbox, rooted a third-party code sandbox, and worked its way into Hugging Face production over a few days. Hugging Face counted roughly 17,600 attacker actions and says plainly that “no human directed the individual steps.” Reconstructing what happened by hand was impractical; they built an AI-assisted pipeline to rebuild their own timeline.

That was an adversary, not a coding assistant, and the trust boundaries were different. The lesson still transfers. A first-rate team with full access to its own systems could not tell you who did what without machine help. Now picture the same forensic exercise in your commit history, where the actor is a real developer’s credentials and the agent that used them left no separate trace. You will not get a clean answer to “who did this”, and you certainly will not get one to “who was responsible for it”. The second question has to be settled in advance or it is never settled at all.

The sentence for the board

Every AI agent that can change our production code has a named person responsible for what it merges. Where we could not find someone willing to own an agent, we removed its ability to merge. That slows some teams down. In return, when something goes wrong we know who to ask, and they knew before it happened that we would be asking them.

What it’s actually about

This is not a case against agents. Eighty percent of developers in Stack Overflow’s 2025 survey use AI coding tools, and trust in their accuracy fell to 29% over the same period. People are shipping code they do not trust, which is a fairly ordinary description of software engineering. What has changed is that the person clicking approve may not have seen the change at all.

Accountability does not transfer to software. A machine cannot be named on a risk register; only a person can. If nobody will be that person for a given agent, that is not a gap in your governance. That is the answer.