A developer asks a coding agent to build a feature. The agent writes the code, chooses the libraries it needs, installs them, and runs the commands to check its own work. The developer reviews every line before merging. Careful, diligent, exactly what the process says.
It does not matter. The libraries were installed before the review started, and anything that runs at install time already ran, with that developer's credentials, on that developer's machine, connected to your network. Supply chain attacks on widely used open source libraries are a matter of public record, and the damage from one happens at install, not at review.
That is a story about coding agents. It is also not really about coding agents at all.
Every agent does this
Agents never sleep. That is the pitch, and it is also the problem.
The invoice-matching agent that runs at two in the morning. The intake agent that reads the inbox and files tickets. The one that reconciles the two systems that never talked to each other. The one that drafts and sends the follow-up. Each of them takes actions in your environment, with real credentials, against real systems, and by design there is no person watching when it happens.
Somebody approved the agent's design once. Nobody approves what it does on a given Tuesday night. The review, where there is one, happens after the fact, and review after the fact is not control. It is an audit trail at best, and in most organizations we walk into, it is not even that.
The question nobody has been asked
Ask this in your next leadership meeting: who in this organization is accountable for what our agents do?
Not for what they produce. Plenty of people review the output. Accountable for what they do: the systems they touched, the records they changed, the emails they sent, the things they installed and ran to get there.
In most organizations the answer is a silence, followed by the name of the person who set the agent up, who has since moved to a different team and has not looked at it in four months. The agent is still running. It has been running the whole time.
Three questions you should be able to answer today
Which agents run, and what do they touch? A list. Every automation that acts without a person in the loop, the systems it can read, the systems it can write to, the credentials it holds. Most organizations cannot produce this list, and the ones that can are usually surprised by how long it is.
If something broke tonight, could you say which systems were affected? Not eventually. Tomorrow morning, to the leadership team, with confidence. If the honest answer involves the words "we would have to check," you do not have visibility. You have hope.
Who owns each one? One name per agent. Not the vendor, not "the team." A person who can read what it does step by step, who decided where a human has to stay in the loop, and who would be the one to notice if it started doing something slightly different.
What owning an agent looks like
This is a job. It is a new one, it has landed on operations leaders and managers who never asked for it, and almost none of them have been shown how to do it.
Read what it actually does. Step by step, not the summary in the vendor's deck. Where it gets its inputs, what decisions it makes and on what rule, what it writes and where, what it does when the input is not what it expected.
Decide where a human stays in the loop. Some steps carry accountability or judgment and a person has to sign them. Some steps are pure transformation of information and a person adds nothing. Deciding which is which, explicitly, is the single most important design choice in the workflow, and it is usually made by default.
Notice when the design tied you to one vendor. Agents built quickly tend to be built inside one provider's product, with that provider's features doing the load-bearing work. Nobody planned the dependency. It is there anyway, and the person who owns the agent is the only one positioned to see it.
Watch for the failures that do not throw an error. The agent that keeps running and keeps producing output, and the output is quietly wrong. No alert fires, because nothing broke. This is the most common failure mode of an automation in its third month and the hardest to catch, because everything looks fine.
Own the handoff. When the agent escalates to a person, that person has to know it happened, know what the agent already did, and know what is expected of them. A handoff nobody owns is where work goes to disappear.
Adopting and adopting responsibly are not the same thing
Your organization is using agents. That is not the question, and it is not a problem. The problem is running them the way most organizations run them: designed once, approved once, owned by nobody, reviewed after the fact.
The fix is not to stop. It is to give every agent an owner who knows how to do the job.
Where to go next: Managing Agents, Agentic Workflows, and Automations is a two-day course for the operations leaders and managers who now own automated processes: reading what an agent does, deciding where a human stays, monitoring for the failures that do not throw an error, and owning the handoff.
The platform view: our product team wrote about the incident that prompted this, and the governance behind it, in When Your AI Writes the Code, Who Reviews What It Installs?