TL;DR: Coding agents came up on eleven security calls between February and September 2026, and only two of those calls were booked to discuss coding agents. The other nine were teams who found them already running. The missing control isn't a better scanner. It's a written answer to who approves code that no person wrote.
A security leader at a hospital system built a working app in two hours on a Saturday. Then he looked at what the thing could reach. His whole machine. His API keys.
His reaction, when he told me about it in August 2026, wasn't panic. It was closer to delight with a caveat attached. This is awesome, he said, how do we do it responsibly.
That's the honest version of where most security teams are with coding agents. The tool works. It works well enough that the person who's supposed to be suspicious of it built something with it over a weekend.
What is a coding agent, and why is it a governance problem?
A coding agent writes and runs code on someone's behalf. It reads a repository, edits files, installs packages, and executes what it wrote. The governance problem is that it inherits the permissions of whoever launched it, which is usually a developer with broad access, and nobody scoped that access for a program that acts on its own.
A developer with admin rights on their laptop is a normal, accepted risk. A program running with that developer's rights, making its own decisions about what to install and what to run, is a different thing wearing the same credential.
The hospital app is a clean example. Nothing was exploited and no attacker was involved. The agent simply had everything its human had, because that's how it was launched, and nobody had drawn a smaller box for it.
Why do coding agents keep showing up on calls nobody booked about coding agents?
Because they arrive through the developer, not through procurement. Of the eleven calls where coding agents came up between February 2026 and September 2026, nine were booked about something else entirely: cloud posture, identity, data governance, and cost control. Coding agents surfaced as a complication partway through.
That ratio is the whole story. When a topic keeps interrupting other topics, it isn't a niche concern. It's a thing that's already everywhere and hasn't been named yet.
It also explains the pattern where a coding assistant turns into an on-ramp for everything else. The assistant ships with tool integrations enabled. The developer connects it to a couple of internal systems to save time. Now there's a path from a laptop into production that no architecture review ever saw.
Why doesn't normal code review catch this?
Code review was built around a person who can explain their own work. A reviewer asks why a change was made, and the author answers. That loop breaks when the author is a model that produced 400 lines in a minute and the human submitting it read maybe a third of them.
A security lead at a health insurer put it better than I can. He said he feels like a thin layer between Claude and production.
Review volume is part of it. The bigger part is that the reviewer's assumption changed without anyone updating the process. Reviews assume the submitter understands the code. When that stops being true, approval is a signature on something nobody read closely.
An architect at an investment bank named the other half of it in July 2026. There are a lot of people traditionally not developers doing developer work now. Those people are shipping code that works. They just can't tell you what it does when it fails.
What does an approval control for coding agents actually look like?
It's an answer to one question, written down: who signs off on code a person didn't write? A team at a consumer brand asked exactly this in March 2026. Their product was built with vibe coding, meaning code generated conversationally rather than typed. It worked. They wanted levels of approval, and they wanted to know who was approving.
Run the agent in a smaller box than the developer. A separate account with its own scoped permissions. Not the developer's laptop credentials, and not their production access.
Require a human to state what the code does. Not a checkbox. A sentence in the pull request describing the change and what breaks if it's wrong. If the submitter can't write it, the review isn't ready.
Gate the actions, not the text. Reviewing generated code line by line doesn't scale. Restricting what the agent may install and execute does.
Log what the agent ran, separately from what it wrote. The code lands in version control. The commands it executed usually land nowhere, and that's the record you'll want during an incident.
Set a size limit that forces a conversation. Above some line count, a second reviewer is required. Arbitrary, and it works, because it puts a person back in the loop at the point where reading stopped happening.
Does any of this slow the developers down?
Some of it does, and that's the trade you're making. Scoping the agent's account costs an afternoon once. Requiring a plain-English description of the change costs a couple of minutes per pull request. Neither one stops anybody from using the tool.
What I'd avoid is the reflex to ban the agents outright. The hospital story is the argument against banning. The person who built that app runs security. He wasn't going around the policy. He was finding out what the tool could do, which is exactly what you want your security people doing before the rest of the company gets there.
Constraints turn out to be useful here for a reason that has nothing to do with safety. An agent with a narrow, well-described set of permissions produces better work than one with everything, because the boundary tells it what problem it's solving.
What can you do this week?
Ask who's using one. Not in a survey. In a conversation, with no consequence attached to the answer. You'll get a bigger number than your tooling shows.
Check what credentials the agent inherits. Launch one yourself and list what it can reach. Most people are surprised, including the people who installed it.
Look at your last twenty merged pull requests. Find the ones nobody could explain today. That's your review problem measured, not guessed.
Write the one-sentence rule. Decide who approves agent-written code and put it somewhere people will find it. Any clear rule beats an unwritten good one.
Separate the agent's account from the human's. This is the single highest-value change, and it's mostly configuration rather than new spend.
Key takeaways:
Coding agents came up on eleven security calls between February 2026 and September 2026, and only two of those calls were booked about them.
The agent inherits whoever launched it, so a developer's broad access becomes a program's broad access with no review in between.
Code review assumes the submitter can explain the code, and that assumption stops holding when a model wrote most of it.
People who never wrote code before are shipping working code now, which changes who needs to be in the approval path.
Gate the actions the agent may take rather than trying to read every generated line, and give the agent its own scoped account.
Frequently asked questions
What is vibe coding?
Building software by describing what you want to an AI model and accepting what it produces, rather than writing the code yourself. It works surprisingly well for small tools. The security problem isn't code quality. It's that nobody in the approval chain can explain the result.
Should we block coding agents until we have controls?
Blocking them tends to move the usage somewhere you can't see. Scoping the agent's account and writing down who approves its output gets you most of the protection in a week, without a policy fight you'd probably lose anyway.
Can a code scanner catch what an agent gets wrong?
Scanners catch known-bad patterns and they're worth running. They won't tell you the agent installed a package nobody vetted, reached a system it had no business reaching, deleted a record on the way through, or wrote code that's correct and does the wrong thing. Those are permission questions rather than code questions.
Who should approve AI-written code?
A person who can describe what the change does and what breaks if it's wrong. That's the working test. It's usually the submitter, and if they can't pass it, the pull request needs a second reviewer before it merges.
How does this connect to AI agent governance more broadly?
A coding agent is an agent with unusually good access, so it's an early look at the problem you'll have everywhere. Identity, scoped permissions, an approval gate on consequential actions, and a log the agent can't edit. Same five questions, arriving through the development team first.
What's the most common mistake?
Letting the agent run as the developer. It's the default in almost every setup, it takes an afternoon to fix, and it's the difference between a bad output and a bad output with production credentials attached.
The security leader who built that app on a Saturday is ahead of most of the people reading this, because he found out what his tools could reach before something forced him to. Most organizations will learn the same lesson from an incident report instead.