An AI coding agent can close a security gap in hours, but speed does not transfer understanding to the founders who approve the patch. Before merging, a small team needs to prove what changed, why the fix works, and what could still fail.
On 26 September 1983, Stanislav Petrov was the duty officer at Serpukhov-15, a Soviet early-warning command centre near Moscow, when the system reported that the United States had launched a missile.
Then it reported more.
The software had produced an answer. Petrov still had to decide whether the answer deserved action.
The alert looked complete
Petrov had limited time and incomplete information. The satellite warning system classified the alert at its highest confidence level, according to accounts later documented by the BBC and other publications.
He did not accept the classification at face value. A real first strike involving only a handful of missiles made little sense to him, and ground radar had not confirmed the launch. Petrov reported a false alarm.
He was right. The system had mistaken sunlight reflected from high-altitude clouds for missile launches.
The stakes for a two-person software company are nowhere near those inside Serpukhov-15. The decision shape, however, is familiar: a machine produces a confident conclusion faster than either person can reconstruct the reasoning behind it.
This time, the output is a pull request.
The agent has found an authorization gap, changed several files, added a test, and returned a clean result before lunch. The vulnerable request now fails. The founders can see the green checks. Neither can yet explain why the new condition belongs in that layer of the application, which legitimate requests it might block, or whether another route reaches the same data without passing through it.
The patch may be correct. That does not make the review complete.
Green tests answer a narrow question
A passing test proves that the tested input produced the expected output under the tested conditions. It does not prove that the test represents the full security boundary.
This distinction matters on limited runway. Bringing in a security specialist for every change may be impossible. Delaying every fix until both founders understand every dependency may also leave a known gap open. The practical decision sits between those extremes.
I would begin by asking one founder to describe the vulnerability without referring to the patch. Which user could do what they should not be able to do? What request made it possible? Where should authorization have stopped it?
Then I would ask the second founder to explain the patch in plain language. If both explanations describe the same boundary, the team has a basis for review. If one person talks about authentication while the other talks about record ownership, the green test is hiding a disagreement.
That disagreement is useful. It shows where review effort belongs.
The next step is adversarial testing around the boundary, not another broad request for the agent to “check security.” Try the original exploit. Try the same action with a different account, role, object owner, route, and direct API request. Remove any convenient interface assumptions. Record which cases fail and which remain uncertain.
A previous decision may offer useful context here: Should I Approve an AI Agent’s Code Change While the Specialist Sleeps? examines the same pressure from the approval side. The recurring problem is ownership. Someone must be able to defend the merge after the agent’s session is gone.
Review the boundary, then the code
Small teams often start code review at the diff because the diff is visible. Security review should start one level above it.
Write down the protected resource, the actors allowed to reach it, and the rule that separates them from everyone else. Map each entry point that can touch that resource. Only then compare the agent’s change with the boundary you intended to enforce.
This changes the question from “Does this code look reasonable?” to “Does every path enforce the same rule?”
It also gives the team a stopping condition. The founders do not need to understand every library implementation before lunch. They do need to understand the trust decision their product is making.
If the patch adds a dependency, changes token handling, alters database permissions, or touches encryption, the stopping condition moves. Those changes can create consequences beyond the local diff. A specialist review may become the cheapest option, especially when the product holds customer data or when rollback would not undo exposure.
Runway makes this uncomfortable. The agent can generate another patch immediately. Human understanding remains the scarce resource.
Make the merge reversible
Petrov did not ignore the warning system. He compared its output with the attack pattern he expected and the independent evidence available to him. That separation between signal and decision is the useful part of the story.
A founder approving an AI-generated security fix needs the same separation.
Merge through a short-lived branch. Keep the change narrow. Add a regression test that names the forbidden behavior. Prepare a rollback path before deployment. Watch authorization failures and unusual access patterns after release. If the team cannot observe the boundary, it cannot know whether the fix held.
Most importantly, leave a written explanation beside the code: what the gap allowed, which rule now blocks it, the cases tested, and the uncertainty still open. Five clear sentences are more valuable than an agent transcript nobody will reread.
The fix being ready before lunch is good news. The afternoon belongs to the decision the agent cannot own.
Comments
No comments yet.