AI-written pull requests contain 1.7x more issues than human-authored ones — averaging 10.83 issues per PR against 6.45 for human-only code — yet most engineering teams route every pull request through the same review queue regardless of who, or what, authored it. That is a triage failure. According to ProjectDiscovery's 2026 AI Coding Impact Report, 66% of security practitioners already spend more than half their working hours manually validating findings rather than resolving the underlying vulnerabilities. As AI-generated code volume compounds, treating every pull request as equal risk becomes a structural bottleneck. The fix is not more reviewers. It is a scoring layer that surfaces the highest-risk pull requests before human review begins. This article walks through a five-factor PR risk scoring framework that teams can implement today.
Why Uniform Review Fails at Scale
The standard pull request queue treats a one-line config fix from a senior engineer with the same priority as a 900-line autonomous agent commit that touches authentication logic. Both enter the review queue. Both wait their turn. Both receive roughly the same allocation of reviewer attention. This works when AI code volume is low and when the defect rate is comparable to human output. Neither condition holds today.
The same CodeRabbit analysis that quantified the 1.7x issue gap also found that incidents per pull request increased 23.5% year-over-year — even as the number of PRs per author rose 20% over the same period, driven by AI-assisted coding productivity gains. More PRs, more issues per PR, and flat or shrinking security review capacity is a compounding problem. At the 90th percentile, AI PRs reached 26 issues per change. Reviewing those at the same pace as a clean human PR is not a prioritisation decision — it is a miscalibration.
Veracode's 2025 GenAI Code Security Report found that AI-generated code contains 2.74x more security vulnerabilities than human-written code across more than 100 tested LLMs — with specific failure rates of 86% against cross-site scripting and 88% against log injection in isolation tests. The pattern is not model-specific. It is structural: LLMs optimise for code that compiles and passes surface-level tests, not code that withstands adversarial input. Security practitioners in the ProjectDiscovery survey ranked exposing secrets as the number one challenge amplified by AI-assisted coding — cited by 78% of respondents — ahead of injection vulnerabilities, insecure dependencies, and logic errors.
A 2026 formal verification study, Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code (arXiv), found measurable exploitability in AI-generated code even in cases where static analysis showed a clean result — meaning the failure mode is precisely the one that conventional review misses. Risk scoring addresses this by routing likely-vulnerable PRs to the reviewers and tools that can catch what static analysis cannot.
The 5-Factor PR Risk Scoring Framework
Each factor contributes a point value to a composite score. Scores above defined thresholds trigger escalation gates rather than standard queue placement. The factors are designed to be computable by a CI pipeline step using data already available at PR creation time — no external services required for basic implementation.
Factor 1: Author Signal (0-25 points)
The origin of a code change is the single strongest predictor of its risk profile. Assign points based on authorship signal: a human-only PR scores 0; a human PR with AI-assisted suggestions scores 5; an AI-generated PR reviewed by a human before opening scores 10; a PR opened directly by an autonomous agent — triggered by CI, a scheduler, or an orchestration system without a human reviewing the diff — scores 25.
The CodeRabbit data shows AI-co-authored PRs carry 1.4x more critical issues and 1.7x more major issues on average compared to human-only PRs. The distinction between AI-assisted and fully autonomous matters because human review of an AI-generated diff before it is opened as a PR is a meaningful control — it is not equivalent to a CI agent pushing code directly to a shared branch with no intermediate human checkpoint.
Factor 2: Diff Exposure Profile (0-30 points)
What the diff touches determines its blast radius. Score based on what category of code is changed: a diff containing credential patterns, API keys, or token strings scores 15 points (a non-negotiable escalation trigger regardless of other factors); changes to cryptographic routines, authentication flows, or session management score 10; third-party dependency additions or version bumps score 5. A diff that touches none of these categories scores 0 on this dimension.
OWASP's LLM Top 10 v1.1 (January 2026) formalises this risk class as LLM09: AI-Generated Code Vulnerabilities — covering embedded backdoors, hallucinated cryptographic implementations, and insecure dependency resolution as the primary failure patterns in AI-generated code. Scanning diffs for these patterns at PR creation time is the lowest-cost intervention point in the development lifecycle.
Factor 3: Diff Size and Test Coverage Delta (0-20 points)
Large diffs are harder to review and statistically more likely to contain undetected errors. Score this dimension by combining diff size with test coverage change: a diff larger than 500 lines with a negative or zero test coverage delta scores 20; the same size diff with positive test coverage delta scores 5; a focused diff under 200 lines scores 0 regardless of coverage, because scope-limited changes have bounded failure modes.
The Broken by Default study found that exploitable vulnerabilities in AI-generated code were disproportionately concentrated in code paths that lacked accompanying tests — confirming that test coverage delta is a legitimate risk signal, not merely a quality metric. AI models produce code that passes the test cases they are given while silently failing against adversarial inputs that were not covered by the original test suite.
Factor 4: Path Criticality (0-15 points)
Not all code paths carry equivalent production risk. Score based on what the diff touches within the repository: changes to authentication, payment processing, or core data persistence layers score 15; changes to external API integrations or webhook handlers score 10; changes to internal business logic or data transformation layers score 5; front-end or styling changes with no backend reach score 0.
Path criticality is computable from a repository manifest — a YAML file checked into the repository root that maps directory paths to criticality tiers, consumed by the CI scoring step. The security team maintains it once and the pipeline reads it on every PR. No external tooling required to start.
Factor 5: Historical Risk Signal (0-10 points)
Prior behaviour is a predictor of future risk. A contributor — human or agent — whose previous PRs produced critical regressions, security incidents, or failed post-merge scans scores 10 points. A new contributor or agent with no prior merge history scores 5 (unknown baseline). An established contributor with a clean track record on the code paths being modified scores 0.
For autonomous agents, this signal is especially useful: agents operating in production for weeks accumulate a detectable failure pattern far faster than human contributors. If an agent's PRs have consistently introduced dependency issues or produced secrets-in-diff warnings, that history should escalate every subsequent PR from that agent until the root cause is addressed in the agent's configuration.
Scoring Thresholds and Review Gates
The five factors combine into a composite score from 0 to 100. Apply the following gates:
0-15: Standard review queue. No escalation required.
16-35: Elevated. Assign to a senior reviewer. 48-hour SLA. Automated SAST scan required before merge.
36-60: High. Mandatory security team review. Full dependency audit. Block merge until explicitly cleared.
61-100: Critical. Block merge. Require security lead sign-off plus a documented risk acceptance record attached to the PR.
One hard override: any diff that triggers a secrets pattern in Factor 2 automatically escalates to Critical regardless of composite score. Secrets in diffs are never a standard-queue item.
Implementing in a CI Pipeline: Five Steps
Enforce authorship labelling at PR template level. Every PR opened by an agent or AI-assisted workflow must carry a machine-readable label. Make it a required field in your PR template — the scoring step reads it as the first input.
Run diff analysis against the exposure pattern library. Use a secrets scanner (gitleaks, truffleHog, or equivalent) for Factor 2. Use path matching against the criticality manifest for Factor 4. Both are available as standard CI actions with no additional infrastructure.
Compute and post the composite score as a PR check. Surface the score as a native check result — not as a comment, but as a first-class status on the PR. Include the factor breakdown so reviewers understand exactly what drove the score and can make informed escalation decisions.
Apply branch protection rules based on threshold. Configure required checks so PRs scoring above 35 cannot merge without the relevant reviewer group approving. This is native GitHub or GitLab functionality — no custom infrastructure needed beyond the scoring step itself.
Maintain the contributor history log as a structured artifact. After each merge, record the final score, the post-merge incident outcome, and whether the review gate was overridden. This log powers Factor 5 and gives you the data to calibrate thresholds over time as your AI code mix evolves.
The Cost of Not Scoring
ProjectDiscovery's 2026 survey found that 60% of security teams are already struggling to keep pace with AI-generated code volume — with mid-sized organisations feeling the pressure most acutely, 69% of that cohort reporting growing difficulty. The compound effect is predictable: as AI coding volume grows, uniform review queues get longer, reviewer throughput stays flat, and the security attention allocated to each PR shrinks. Risk scoring reverses that dynamic. It does not reduce total review work — it concentrates review effort where it matters, which is the only scalable path to improving security outcomes without proportionally growing headcount.
The same survey found that 57% of security practitioners would need a full audit trail of AI actions to trust AI-based security tooling. Risk scoring, implemented with a contributor history log, is the foundation of that audit trail — every routing decision is reviewable after the fact, which satisfies the evidentiary standard that compliance-oriented teams require.
How re-entry.ai Applies This at the PR Boundary
re-entry.ai implements PR risk scoring as a native control at the Git boundary — applied at the moment an AI agent or AI-assisted developer opens a pull request, before any human review begins. The platform captures authorship signal automatically from agent metadata, runs diff exposure analysis against a managed pattern library, scores path criticality against the repository criticality manifest, and computes a composite risk score that gates the PR into the appropriate review track.
The full scoring audit trail — factor-level breakdown, routing decision, reviewer assignment, and post-merge outcome — is attached to every pull request and retained for compliance and retrospective analysis. Teams operating under SOC 2, ISO 27001, or EU AI Act obligations gain an evidence record without instrumentation overhead or pipeline changes.
If your team is shipping AI-generated code through a flat review queue today, risk scoring is the highest-leverage change available to your security posture. Visit re-entry.ai to see the framework in operation and request a demo.
Summary: Scoring Is Triage, Not Gatekeeping
The goal of PR risk scoring is not to block AI-generated code — it is to allocate review effort in proportion to actual risk. A fully autonomous agent committing 600 lines of authentication logic without tests deserves more scrutiny than a human developer fixing a typo in a configuration comment. The five-factor framework operationalises that principle into a computable, consistently applied gate that security teams can tune over time.
The data is unambiguous: AI coding velocity is outpacing security review capacity. Uniform queues amplify that gap. Scored triage closes it — not by doing more work, but by doing the right work first.