Security findings have always been written for a person to read. There’s a short title, a severity, and a suggested patch, and someone on the team decides what to do with it. That assumption is breaking. We looked at every developer reply to a Corgea finding on a pull request between October 2025 and September 2026, 4,007 of them across our customer base. Nearly half of the replies we now get come from a coding agent that reads the finding, looks through the repository, and answers on the developer’s behalf.
The agents don’t behave like the people they stand in for. Developers rarely say more than “fixed” or “false positive.” Agents rule on the finding, cite the code, and move on to the next one.
Get the full research brief
Three pages with every chart, the classifier method, and the redacted reply examples. It’s a PDF, and you don’t need to fill in a form.
Who is triaging application security now
Source: 4,007 developer replies to Corgea findings, 10 Oct 2025 to 18 Sep 2026. No organization or author identifiers.
Agent replies went from zero to half in eleven months
In October 2025 we didn’t see a single agent-written reply. In August 2026, 48.7% of replies were agent-written. The odds that a given reply came from an agent grew 1.33x per month over the year. The climb wasn’t smooth. March had a one-month burst to 21.8% that fell back to under 6% in April and May, and then adoption picked up for good in June.
Agent-written replies as a share of all replies, by month
Replies per month range from 24 (October 2025) to 1,015 (March 2026). Odds of an agent-written reply grew 1.33x per month.
Bold values are labeled in the brief. The other months are read from the brief's chart and rounded to one decimal. Default classifier threshold.
Across the full year, 19.5% of replies were agent-written (95% CI 16.7 to 22.3). The annual average hides how fast the share rose from June onward.
Agents argue, developers report status
We grouped every reply by what it does: dispute the finding, accept the risk, defer it, report a fix, ask a question, or tell the scanner what to do. The two groups split clearly.
What the reply does
Share of replies within each author class.
- Disputes the finding
- Accepts the risk, won't fix
- Defers or calls it out of scope
- Reports it fixed
- Asks a question
- Instructs the scanner
Intent is assigned by a deterministic rule set. Replies classed as 'other' (9% of agent and 23% of developer replies) are left out. Odds ratio for accepting risk: 5.6 (95% CI 4.0 to 7.8).
Disputes, risk acceptances and deferrals make up 60% of agent replies. Those are verdicts: the reply decides the finding’s fate instead of reporting on it. Agents report fixes at roughly the same rate as developers (29.8% vs 31.9%), so they aren’t avoiding fixes altogether. The gap is in what happens when they don’t fix. An agent is 5.6 times more likely than a developer to accept the risk and leave the code alone.
The two most human kinds of reply barely show up from agents. Developers ask a question about a finding in 4.3% of replies and give the scanner an instruction in 5.4%. For agents those numbers are 0.5% and 0.7%. An agent doesn’t ask what a finding means. It decides.
The argumentation gap
The difference is sharpest in disputes. A developer who disagrees with a finding usually types “false positive” and moves on. An agent builds a case.
Agents bring evidence. Developers bring a verdict.
Orange: AI agent replies. Grey: developer replies.
Here is what that looks like in practice. These are verbatim replies, redacted.
AI agent, disputing a finding: “False positive — this repo is on React 19.2.5 (see pnpm-workspace.yaml), where ref as a plain prop on function components is the officially supported pattern…”
It cites the lockfile, the framework version, and the pattern’s use elsewhere in the codebase.
Developer, disputing a finding: “false positive”
That exact text shows up in 47 replies. Half of all developer replies (50.2%) are exact duplicates of another reply. Only 16.4% of agent replies are.
Risk acceptance follows the same shape:
AI agent, accepting the risk: “Acknowledged. The TRY_CAST(ErrorID AS INT) approach is intentional — it handles source data where ErrorID can be non-numeric.”
Developer, accepting the risk: “Accepted risk”
The agent names the construct, states the design intent, and closes the thread. Nobody else is asked.
Where agents show up
Teams seem to point agents at high-volume, low-drama findings first. Agents wrote 26.5% of replies to code quality findings (always-incorrect control flow, dead code, empty catch blocks) and only 8.7% of replies to classic security findings like XSS, SQL injection, missing authorization, IDOR, open redirect, and CSRF.
When an agent does answer a security finding, it’s much more likely to push back.
Used three times as often on code quality, arguing twice as hard on security
- Share of replies written by an agent
- Share of agent replies that dispute the finding
Agents dispute IDOR, SQL injection and missing-authorization findings 60% to 71% of the time.
That’s the part a security team should notice. The findings agents argue with most are the ones where being wrong costs the most.
They arrive in bursts
Developers trickle in. Agents tend to arrive all at once, posting dozens of distinct, evidence-backed verdicts within the same minute.
Verdicts arrive in batches
They push back on the fix too
Agents don’t only argue with the finding. They also argue with the patch we suggest, and they check whether the code we cite exists.
Agents push back on the fix, not just the finding
AI agent, declining a patch: “Not applying this one — the loop terminates, and the suggested patch would break the script.”
When a finding names code that isn’t there, the reply calling it out is usually written by an agent: 15 of the 19 we saw.
The fingerprints agents leave behind
The classifier mostly relies on writing patterns, but some replies make it easy. Every reply that carries an explicit tool signature names Claude Code.
Fingerprints agents leave behind
Verdict formulas include openers like 'Refuted —', 'Not applying this one —' and 'Won't fix —'.
What this means for your AppSec program
A security program that assumes a person reads every alert now has a second reader, and that reader behaves differently. We’d change three things.
Write findings an agent can verify. The agent will open the file, line and data flow you cite. If the finding points at code that isn’t there, or a data flow that doesn’t hold, it’ll be refuted within the minute, and any real issue nearby gets dismissed along with it. Precise findings matter more now than they did when only people read them.
Watch automated risk acceptance. Agents accept risk at 5.6 times the developer rate and post their verdicts in batches. Whatever your policy says about who can accept a risk, it needs to cover an agent acting for a developer. Otherwise a single agent session can post 49 verdicts in eleven minutes with nobody signing off.
Treat agent disputes as evidence to check. Half of agent disputes cite hard evidence. That’s useful. Read the case, confirm the control it names, and feed confirmed ones back into your scanner rules so the same false positive doesn’t come back. A dispute that falls apart on inspection is just as useful, because it tells you where the agent can’t be trusted to rule alone.
Method
Authorship is scored by a marker-based classifier that we validated against 300 blind-labeled replies. For the AI class it has a precision of 0.93 and a recall of 0.91. Reply intent is assigned by a deterministic rule set. Quotes are verbatim and redacted, and the dataset has no organization or author identifiers. A full preprint is available on request.
Agents are now arguing in your pipelines (PDF)
Corgea research brief, September 2026. Share it with your AppSec and platform teams.