The common-sense assumption about AI code review is that more is better. If one reviewer is good, several reviewers are safer, and a few rounds of feedback should produce code that is more likely to be correct than a single pass. When we tested that assumption on a small pipeline, we found that, sometimes, the opposite can happen.
After an initial round of AI-driven enhancements to our test code, we observed an instance where additional review rounds caused the implementer agent to remove authentication from an administrative endpoint, a security control it had correctly added a round earlier. By the time the review pipeline finished, anyone on the network could call it without authorization.
In this blog, we’ll explore what happened in our test and why, how the mechanism applies more generally, and what it implies for teams that are wiring agentic review into their software pipelines.
The AI security incident: why security controls disappeared
We set up our agentic development pipeline in a common structure: an implementer agent is provided with a feature specification and produces draft code. A panel of reviewer agents analyzes the code, each with a different focus. One agent is designed to look for security issues. Others look for access-control flaws, architecture and overall code quality. Finally, the product-fit agent analyzes whether the code is doing what the spec asked for, and only what the spec asked for. Once the reviewers have completed their jobs, the implementer revises the code in response to consolidated feedback. The cycle repeats for a configured number of rounds, designed to provide incrementally better code with each iteration.
We asked our implementer to build an administrative endpoint that deleted records from a database. The initial iteration produced code that worked as requested but lacked important security controls for a function that makes changes to production data. The endpoint had no authentication and no role check.
The review panel feedback immediately identified these shortcomings, and the implementer jumped back into action. The code came back transformed. The implementer added a substantial authorization stack, including “requireAdmin” middleware, a JWT verification gate, an “isAdmin” field on the user model, an explicit role check inside the handler, and a transactional wrapper on the delete operation. After a second round of analysis, five of the six reviewers were satisfied, and the implementer received a final round of feedback to clean up a few remaining issues.
The final round of edits undid all of it. The endpoint reverted to its insecure, unauthenticated state.
When we traced the cause, the product-focused reviewer had flagged the newly added authentication as a high-severity finding after the first round of changes. Its reasoning, paraphrased lightly, was that the specification did not require authentication, and the implementer had silently gated the endpoint behind a JWT and an isAdmin database flag. The product reviewer's prompt explicitly instructs it to flag behavior that goes beyond what the specification asks for, and our specification did not explicitly say "require admin authentication on this endpoint." Adding that requirement was, on the reviewer's literal reading, scope creep.
The product reviewer's finding entered the revision prompt at the same severity level as the security and access-control reviewers' findings. The implementer received a flat list of high-severity issues and had no instruction about how to weight them against each other. It resolved the most pointed objection by removing the disputed authentication code.
The governance mechanism: why security loses the tiebreaker in LLM pipelines
This kind of mistake is rare in human teams. When a product manager and a security engineer disagree about whether an endpoint should require authentication, the conversation does not end with the developer silently capitulating to whoever objected last or most loudly. There is escalation, debate and usually a tiebreaker from someone with the authority to make a call. The system has friction against capitulation.
Most agentic review pipelines do not have this friction by default. The reviewer outputs are concatenated into a revision prompt. The implementer reads them as parallel feedback, each with equal weight. Its job is to produce code that satisfies the constraints it is given. When two constraints conflict, the path that addresses the most objections is sometimes the one that removes the disputed behavior altogether.
There is an asymmetry built into this that makes security the natural loser. Security findings typically add scope, more code, more state, more dependencies, more validation. Feature and product findings naturally aim to reduce scope wherever possible: this does not need to be here, that flag is unnecessary, this is doing more than was asked. When an agent is presented with a flat severity ranking and is asked to resolve every concern, the cheapest resolution path almost always involves removing code, not adding more.
This is a system design failure, not a model failure. The implementer agent did exactly what its prompt asked of it. The reviewers did exactly what theirs asked. The model behaved obediently, but lacked proper internal governance.
Two design assumptions baked into many AI review pipelines are worth calling out. First, that all reviewer outputs are commensurable, that "high severity" from a product reviewer can be added to "high severity" from a security reviewer and the implementer can sort it out. Second, that the revision step is a search for an output that minimizes total complaints, with no memory preserved across rounds. Both assumptions are mostly fine when the reviewers agree. When the reviewers conflict on first principles, these assumptions become structurally dangerous.
Spec-level review catches what code review doesn’t
In a separate experiment, we tested a different placement for adversarial review, and it worked well.
We ran a panel of adversarial reviewers against the specification before any code was written. The panel had four reviewers, focused on trust models, access control, architecture and data handling. We fed it six specs. Four had deliberate design flaws. Two were "secure", submitted as experimental controls to see how the agents would react when there was nothing significant to find.
The panel correctly flagged all four insecure specs. More interestingly, it also surfaced findings in the two "secure" ones. When we looked at what the panel had actually found, it was not wrong. On a perfectly standard JWT authentication spec, the trust-model reviewer pointed out that the spec required signing with HS256 but did not require the verifier to pin the algorithm. That is the canonical setup for the JWT algorithm-confusion vulnerability class. Our "secure" spec was not as secure as its label suggested.
The lesson is that review placement in the pipeline and review target matter more than the number of review cycles. Adversarial review of the specification, run before implementation begins, catches design-level flaws that code-level review cannot fix without changing the spec. It is the cheapest place to catch security defects, and one of the few places where adding more rigorous review reliably improves outcomes.
Three rules for safer agentic pipelines
Three concrete recommendations follow from these findings.
First, designate security as non-overridable in the review graph. Whatever orchestration you use, no feature-focused or product-focused reviewer should be able to cause an implementer to remove a security control. This can be implemented as severity stratification, where security findings outweigh non-security findings of equal label. It can be implemented as preserved invariants in the revision prompt, or an explicit instruction not to remove security controls in response to non-security findings. It can be implemented as a separate auditor that scans diffs for security-control deletions. Do not run a multi-reviewer pipeline without one of them.
Second, require human escalation when reviewers do not converge after a defined bound. If the panel produces conflicting recommendations that the implementer cannot resolve in two or three rounds, that is a signal that the specification is ambiguous or the feature is contested. The right next step is a person, not another round of AI review.
Third, run a review against the specification, not only against the code. The cheapest security defect to fix is one that never gets written. Adversarial spec review takes less time than implementation, has no compile cycle and catches flaws that code-level review cannot meaningfully address. If your pipeline only has budget for one review pass, run it on the spec.
Review pipelines need rules, not just reviewers
There is a word missing from most AI code review pitches: governance. How you assemble reviewers, what authority you give them, what invariants you preserve across review rounds, and where you require human escalation are the design decisions that determine whether an AI review pipeline makes code safer or just makes it different.
