AI-assisted PR review for AppSec: what defensible evidence looks like when software moves at AI speed

Software development has entered an unusual period: producing code is getting dramatically easier, but understanding whether that code is safe has not become equally easy.

That changes the economics of application security.

Historically, code production itself was constrained by engineering capacity. Features had to be designed, implemented, reviewed, tested, and then moved through a delivery pipeline. Security teams were already operating downstream of that system, frequently reviewing only a fraction of the changes being produced.

AI coding assistants and autonomous coding agents are removing part of that production constraint.

GitHub reported that in 2025 developers created 20.4% more pull requests, merged roughly 23% more, and produced 25.1% more code pushes year over year — the rates the chart in the next section sets against review activity. The volume behind those rates:

Merged pull requests a month, on average

43.2M

Commits pushed during 2025

~1B

Pull requests from GitHub’s coding agent in its first five months

1M+

This is not proof that AI caused all of the increase. GitHub itself correctly describes many of these relationships as observational. But the direction is difficult to ignore: the supply of software changes is increasing rapidly at the same time AI-assisted development is becoming normal.

DORA’s 2025 research reached a similar conclusion from a different direction. Greater AI adoption was now associated with higher software-delivery throughput, while still carrying a negative relationship with delivery stability. Their conclusion is important for security leaders: AI behaves less like an independent productivity tool and more like an amplifier of the engineering system around it.

The AppSec implication is straightforward:

When the rate of change increases faster than the rate of verification, security risk accumulates in the gap.

The verification gap is already visible

Rapticore analyzed several public engineering datasets to look at the relationship between code-change activity and visible review activity.

GitHub’s 2025 data, with change activity set against review activity:

Those numbers do not measure security-review quality. A pull request can be reviewed without producing a comment, and automated review may replace some human discussion. But they can be used as a rough indicator of how visible review activity is scaling against change volume.

Using GitHub’s published aggregates, comments on issues and PRs per PR created fell by approximately 16.7% year over year, and commit comments relative to code pushes fell by approximately 41.6%.

We would not call either number a security metric. We would call them a warning about review-attention compression: software-change activity expanded considerably faster than visible discussion around those changes.

A separate 2026 analysis from LinearB, based on more than 8 million pull requests, found another version of the same problem. At the 75th percentile, AI-assisted PRs contained roughly 2.6 times as many changed lines as unassisted ones. They also waited longer to be picked up for review, yet once review started they were reviewed faster. LinearB explicitly treats these relationships as correlational, but the pattern is worth investigating inside any engineering organization using coding agents.

This produces a new security problem.

The bottleneck is moving.

It is no longer primarily:

Can engineering produce the change?

It is increasingly:

Can the organization verify the change with enough depth, context, and evidence before it becomes production software?

AI-assisted PR review is not another SAST scanner

AI-assisted PR review is sometimes described as an improved static-analysis tool. That undersells both its potential and its limitations.

Traditional SAST is strongest when a problem can be represented through deterministic rules, semantic analysis, data-flow analysis, taint tracking, or known insecure patterns. SCA can identify vulnerable packages and dependency risk. Secret scanners can detect exposed credentials. IaC scanners can compare configuration against policy.

Those controls remain essential precisely because they are deterministic.

An AI reviewer is useful for a different class of questions:

• Did this change weaken an authorization boundary?
• Does a new API path bypass a control that exists elsewhere?
• Is an apparently safe input later used in a dangerous context?
• Does the change create an abuse path that is only visible across several files?
• Is a new cloud permission materially broader than the feature requires?
• Did the code alter a security assumption without changing the architecture documentation?
• Does an AI feature introduce prompt injection, unsafe tool invocation, excessive agency, or sensitive-data exposure?
• Is the code technically correct but inconsistent with the application’s intended trust model?

These are contextual questions.

They require reasoning about intent, architecture, control flow, trust boundaries, dependencies, and abuse cases.

That makes AI-assisted review valuable.

It also makes it probabilistic.

The right architecture therefore does not replace deterministic AppSec controls with a model. It combines them.

The emerging control stack

A defensible modern PR security pipeline should contain at least four complementary layers:

Deterministic analysis

Identifies known classes of problems consistently: SAST, SCA, secrets, IaC, container, policy, and dependency analysis.

Contextual AI review

Reasons about the change as a change: what moved, what assumptions changed, which controls are affected, and what an attacker could do with the new behavior.

Validation

Attempts to prove or disprove important findings using deterministic analysis, tests, repository context, security tooling, or controlled reproduction.

Human security engineering

Remains responsible for business context, exceptions, novel architecture risk, risk acceptance, and cases where ambiguity remains materially important.

The objective is not more findings.

It is higher-confidence decisions before merge.

What defensible evidence should look like

Security leadership should not evaluate an AI PR reviewer by the quality of its prose.

A convincing explanation is not the same thing as evidence.

For every review, the system should be able to reconstruct the following.

1. Exactly what was reviewed

A security review should be bound to an immutable software state.

At minimum, preserve:

• repository and pull-request identifier;
• base commit SHA;
• head commit SHA;
• diff or content digest;
• files included in review;
• files omitted from review and the reason;
• relevant manifests, lockfiles, IaC, policies, or architecture context used by the reviewer.

If the PR changes after review, the evidence should no longer represent the current PR.

This seems obvious, but it is foundational. A security approval without a specific code identity is not a durable security artifact.

This mirrors the broader provenance principle used by SLSA: useful assurance depends on being able to identify what was produced, how it was produced, and the inputs involved.

2. How the review was produced

Store the execution context for the review itself:

• reviewer or agent identity;
• reviewer version;
• model provider and model identifier where available;
• policy or rubric version;
• system instruction or prompt-policy hash;
• tools made available to the reviewer;
• deterministic scanners consulted;
• repository context retrieved;
• timestamps;
• run identifier;
• timeout or failure state.

This is the AI-review equivalent of provenance.

It does not make an AI decision reproducible in the strict mathematical sense—model behavior can remain nondeterministic—but it makes the decision auditable and approximately replayable.

3. Evidence must be anchored to code

A finding should never be only:

“This could lead to SQL injection.”

It should show the reviewer why.

A defensible finding should identify, where applicable:

• exact file and line range;
• changed code responsible for the condition;
• input source;
• transformation or control-flow path;
• sensitive sink or security boundary;
• exploit preconditions;
• affected asset or privilege;
• relevant CWE, OWASP category, or internal control;
• confidence;
• supporting scanner or test output.

For an authorization issue, show the missing authorization decision.

For SSRF, identify the attacker-controlled input and network request sink.

For a dependency finding, identify the package, resolved version, vulnerable range, and reachable usage if known.

For an AI-agent issue, identify the untrusted input, the instruction boundary, the tool or capability exposed, and the action an attacker could induce.

The reviewer should produce a security argument, not merely a security opinion.

A practical evidence ladder

One way to govern AI-generated findings is to classify them according to the strength of their evidence.

E0Assertion

The model identifies a possible security concern but provides no concrete trace beyond general reasoning.

Useful for investigation. Not sufficient for a blocking decision.

E1Code-anchored

The finding references the exact changed code and explains the weakness and required conditions.

Suitable for developer attention, but important findings should still be validated.

E2Contextually traced

The reviewer connects source to sink, privilege to action, input to trust boundary, or dependency to reachable behavior across the relevant repository context.

This is substantially stronger evidence.

E3Independently validated

A deterministic tool, targeted test, build artifact, policy check, controlled reproduction, or second independent mechanism corroborates the finding.

For high-impact merge blocking, this should be the preferred standard whenever practical.

E4Remediation verified

The issue was fixed on a later commit and the relevant analysis or test was rerun against that exact revision.

This is the state AppSec ultimately cares about.

Identified is not fixed. Fixed is not verified.

That distinction should be explicit in the evidence model.

Scoring should never hide a critical finding

Rapticore SentinelFlow uses a specialized review council of nine focused agents that examine bounded dimensions of a change:

• architectural drift;
• control-flow risk;
• security abuse;
• reliability;
• performance;
• compliance;
• cloud-native concerns;
• supply-chain risk;
• AI/ML security.

The value of specialization is that each reviewer can ask a narrower question with a more explicit rubric.

But multi-agent systems create a governance problem of their own: aggregation.

A critical security finding should not disappear because eight other agents gave the PR a high score.

For security decisions, aggregation should therefore be monotonic with validated risk.

One independently validated critical issue should be capable of blocking the merge regardless of the average score produced by the rest of the council.

The aggregate should summarize evidence.

It should never dilute it.

SentinelFlow preserves the individual reviewer output together with the normalized result for each PR so a security team can inspect both the recommendation and the evidence behind it.

Raw model output is useful — but it is not the audit record

Keeping the raw AI response is important for debugging, model evaluation, and post-incident analysis.

It is not enough by itself.

A mature evidence record should separate:

Observation

What the reviewer noticed.

Evidence

The repository artifacts, flow, configuration, tool result, or test supporting the observation.

Inference

Why those artifacts indicate a security problem.

Decision

Warn, block, accept, request human review, or take no action.

Disposition

Fixed, false positive, accepted risk, deferred, or superseded.

Verification

What demonstrated that the disposition is valid.

This structure matters because language models are exceptionally good at producing plausible explanations.

Security programs need records that survive after the explanation is forgotten.

NIST’s Secure Software Development Framework explicitly treats code review and automated code analysis as complementary practices and emphasizes documenting and triaging discovered issues within the development workflow. The AI reviewer should strengthen that control, not create a parallel stream of ephemeral comments.

The failure state matters as much as the pass state

One important correction to many early AI-review designs is the treatment of availability failures.

A model timeout is not a successful review.

A connector failure is not a clean PR.

A context-window limit is not evidence that no vulnerability exists.

Every run should therefore have an explicit state such as:

• Complete
• Complete with limitations
• Partial
• Unavailable
• Invalidated by subsequent commit

Organizations can decide whether a particular branch or risk class should fail open or fail closed.

A low-risk documentation change may reasonably proceed if the AI reviewer is unavailable.

A privileged authentication change in a regulated production service may reasonably require successful review before merge.

The principle is not “AI must never block.”

The principle is:

An infrastructure failure must never be silently converted into a security PASS.

The model itself should not be the root of trust

Security teams should also assume that model quality will change.

Providers update models. Models regress on particular tasks. Context retrieval fails. Repositories contain adversarial text. Prompt injection can be embedded in comments, documentation, tests, fixtures, or source code.

The reviewer therefore needs its own security boundary.

That means:

• repository content should be treated as untrusted input;
• code comments must not be allowed to redefine reviewer policy;
• tool use should be explicitly allowlisted;
• secrets available to the reviewer should be minimized;
• external network access should be constrained;
• model actions should be logged;
• evidence collection should be separable from model reasoning;
• critical decisions should rely on policy and validation rather than model confidence alone.

The AI reviewer is part of the security control plane.

It must itself be engineered as one.

Speed makes evidence more important, not less

There is another reason this matters: AI-generated code can be highly functional without being reliably secure.

Veracode’s 2025 benchmark across more than 100 language models found that generated samples passed its security tests only about 55% of the time, while its 2026 update reported syntax correctness above 95% but little corresponding improvement in security performance. This is a benchmark of constrained generation tasks, not a production vulnerability rate, but the gap illustrates an important point: the ability to generate working code is improving faster than the ability to assume that code is secure.

GitLab’s June 2026 survey of 1,528 developers and technology buyers found a similar organizational gap: most said developers were committing code faster after adopting AI tools, and as many said AI adoption had moved faster than their organization’s governance policies.

This is why simply adding another AI-generated comment to a PR is not enough.

The security control has to scale with the new production system.

AI review should reduce human uncertainty, not create more of it

GitHub reported in March 2026 that Copilot code review had already performed more than 60 million reviews and represented more than one in five code reviews on GitHub. That tells us automated review is no longer hypothetical infrastructure. It is becoming part of the normal engineering workflow.

The next question is therefore not whether AI will participate in code review.

It will.

The important question is what role it plays.

The strongest pattern is not an autonomous model declaring code secure.

It is an evidence-producing system that continuously narrows uncertainty:

Change detected → contextual review → evidence collected → important hypotheses validated → remediation proposed → fix applied → fix re-verified → merge decision recorded.

That is a materially different control from “AI commented on the PR.”

What security leaders should measure

The success metrics should reflect outcomes rather than model activity.

The goal is not to prove that the AI is busy.

The goal is to prove that the organization is making better security decisions at software-development speed.

The AppSec control is changing

Traditional AppSec assumed that code was the expensive thing to produce and security analysis had to fit around the engineering process.

AI changes that assumption.

When software can be generated, modified, refactored, tested, and proposed continuously by humans and agents, the organization needs a verification layer capable of operating at the same cadence.

That layer will contain deterministic tools.

It will contain AI.

It will contain targeted validation.

And it will still contain humans.

But the durable product of the system should be something security engineering has always needed:

evidence.

Evidence of what changed.

Evidence of what was reviewed.

Evidence of why something was considered risky.

Evidence of how the finding was validated.

Evidence of what fixed it.

And evidence that the exact code being merged was the code that passed.

In the AI-assisted SDLC, velocity will continue to increase.

The organizations that handle that transition well will not be the ones that generate the most code or the most security findings.

They will be the ones that can increase velocity without losing the ability to prove why they trust what they ship.

Outcomes, not outputs.