Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How should you review agent-generated pull requests?
Updated
Review agent-generated pull requests with a risk-tier decision tree: change type sets required review depth, automated gates, and merge criteria. Use the reviewer checklist below. Distinguish org best practice from ShipReady Metrics recommendations.
Agent PR review playbook, last verified 10 September 2026 against OWASP secure coding and LLM guidance, NIST SP 800-218 Rev. 1 and SP 800-218A, DORA change-management findings, GitHub branch protection documentation (updated through 2026), GitLab protected branches documentation, and SLSA provenance levels. Not legal advice.
Why agent PRs need a different review bar
Audience: an engineering manager, staff engineer, or security champion responsible for merges from coding agents, copilots, and autonomous PR bots. Agents can produce plausible diffs with wrong assumptions, missing edge cases, injected secrets, or licence-incompatible snippets.
This page is operational guidance — org best practice and framework-aligned practice — not legal advice. ShipReady Metrics recommendations are labelled separately. Last verified 10 September 2026.
- Org best practice versus ShipReady Metrics recommendation: branch protection, human review, and CI gates are your engineering standards. SRM surfaces AI-authored-code counts and findings ingest — it does not merge PRs for you.
- The detect-security-issues-ai-coding-agents guide on this site is the security pipeline page. The detect-ai-generated-code guide on this site covers attribution signals. The AI coding governance checklist guide on this site is the control map.
- Framework versus law: NIST SSDF and OWASP are guidance unless your sector rule makes them mandatory. This page does not determine regulatory duties.
Risk-tier decision tree — change type to review depth
Start with change type, not author identity. The table is the centerpiece decision tree. Tier 1 is lightest scrutiny; Tier 4 is highest. Adjust tiers to your blast radius. Last verified 10 September 2026.
| Tier | Change type (examples) | Required human review depth | Required automated gates | Merge criteria | Primary source basis |
|---|---|---|---|---|---|
| Tier 1 — low | Docs, comments, typos, test-only fixtures with no production path | One reviewer; author explains diff in PR description | Lint; optional secret scan | Green CI; reviewer spot-check; no protected-data paths touched | DORA lightweight change practice; SSDF RV.1 sampling |
| Tier 2 — medium | Application logic in non-critical services; UI copy; refactors with unchanged tests | One domain reviewer plus code owner if CODEOWNERS applies | Unit tests; SAST; secret scan; dependency diff review | Tests pass; SAST no new critical/high; reviewer walks logic paths | OWASP secure review; SSDF PW.8; GitHub/GitLab branch protection baseline |
| Tier 3 — high | Auth, crypto, payments, PII handling, infra-as-code, public API surface | Two reviewers including security or platform delegate; no self-merge | SAST; DAST on staging; dependency scan; IaC scan; licence check | Security reviewer sign-off; threat assumptions documented; rollback plan | OWASP ASVS-aligned review; NIST SSDF PW.4–PW.7; DORA change-failure sensitivity |
| Tier 4 — critical | Production config, CI/CD pipelines, secrets management, supply-chain manifests, agent tool permissions | Two senior reviewers; security mandatory; change window if applicable | Full CI; signed provenance where available; manual config diff; break-glass audit | Written approval ticket; staged rollout; provenance artifact archived | SLSA build provenance guidance; SSDF PS.3; GitHub/GitLab protected environment rules |
Branch protection and platform controls
Platform docs describe enforceable merge gates — org best practice when enabled. Last verified 10 September 2026 against GitHub Docs branch protection (current through 2026) and GitLab Docs protected branches (current through 2026).
- GitHub: require pull request before merging; require approvals (count by tier); require status checks; restrict pushes to protected branches; require signed commits where policy demands.
- GitLab: protected branches with allowed merge roles; approval rules; external status checks; merge request only workflows for production branches.
- These settings implement SSDF RV.1 independent review — they are not automatic compliance with any regulation.
Reviewer checklist
Human reviewer steps for agent PRs. Apply all rows for Tier 3–4; sample for Tier 1–2. Org best practice unless labelled SRM.
- Confirm provenance: PR labels agent run ID, initiating human, and linked ticket.
- Read the full diff — agents hide issues in large files; use hide-whitespace cautiously.
- Verify tests assert behaviour, not implementation trivia; add missing cases for edge paths.
- Search for secrets, tokens, and hard-coded endpoints — do not trust agent claims of redaction.
- Check dependency additions for typosquatting, unmaintained packages, and licence conflicts.
- Validate auth and input handling on every new external boundary — OWASP injection and SSRF categories.
- Confirm config changes match environment matrix; no prod values in non-prod files.
- Ensure rollback: feature flag, revert plan, or migration down path.
- Reject if author cannot explain a merged hunk — unexplained AI output fails review.
- SRM recommendation: cross-check Security findings ingest for new SAST or secret hits on the branch before merge — product surface, not a substitute for human review.
Automated gates mapped to SSDF and OWASP
Minimum automated gates by tier are in the decision tree. The mapping below ties gate types to framework practice — guidance, not law. Last verified 10 September 2026.
| Gate | Catches (agent failure modes) | Framework reference | Kind of text |
|---|---|---|---|
| Secret scan | Credentials pasted by agent or copied from prompts | OWASP LLM sensitive disclosure; SSDF PW.6 | Industry best practice |
| SAST | Injection, path traversal, weak crypto in generated code | OWASP Top 10; SSDF PW.7 | Industry best practice |
| Dependency scan | Vulnerable or malicious packages suggested by agent | SSDF PS.3; OWASP supply chain | Industry best practice |
| DAST (staging) | Runtime issues SAST misses on new endpoints | SSDF PW.8; OWASP ASVS | Industry best practice |
| Provenance / attestation | Unknown build origin for agent-produced artifacts | SLSA v1.0 provenance levels | Framework guidance |
What you need to do now
Operational steps for engineering leaders. Not legal advice.
- Publish the risk-tier table in your engineering handbook; map repos to default tiers.
- Enable branch protection on main and production branches per GitHub or GitLab docs.
- Require agent PR labels and human owner in your AI coding policy.
- Wire Tier 3–4 gates into CI before expanding agent write access.
- Train reviewers on the checklist — especially secret and dependency review.
- Track change failure rate and review latency with DORA metrics — interpret as trends, not league tables.
Checklist
Organisation readiness for agent PR review. Not legal advice.
- Risk-tier table adopted and linked from AI coding policy.
- Protected branches block direct agent pushes.
- CODEOWNERS or equivalent routes Tier 3–4 paths to experts.
- CI runs secret, SAST, and dependency scans on agent branches.
- Reviewer checklist in merge request template.
- Provenance fields mandatory on agent PRs.
- Incident path if a bad agent merge reaches production.
- Quarterly review of tier assignments after incidents or near-misses.
Where this shows up in ShipReady Metrics
Shipped capabilities only. SRM does not replace human review or branch protection.
- Signed-in AI Code Readiness reporting shows an AI-authored-code floor from git markers or attributed commits — useful for volume monitoring, not proof of safe review.
- Signed-in Delivery Health includes DORA-style deployment frequency and change-failure signals when CI and deploy sources are connected — shows Not measured when data is missing.
- Signed-in Security findings ingest surfaces SAST, DAST, dependabot, and secret-scan results on branches you connect — cross-check before merge; not an app route in related links.
- Engineering risk score composites quality and delivery signals — vendor methodology on the engineering-risk-score-explained guide; not an industry standard or audit opinion.
Primary sources (last verified 10 September 2026)
Claims on this page trace to these sources. Platform doc URLs change; verify current settings in your vendor admin UI.
OWASP Top 10, OWASP LLM/GenAI project, and ASVS — secure coding and review practice. NIST SP 800-218 Rev. 1 and SP 800-218A — SSDF review and AI-augmented development practices. DORA research program and State of DevOps reports — change management and review latency context (framework guidance, benchmarks shift by year). GitHub Docs — protected branches and pull request reviews (accessed September 2026). GitLab Docs — protected branches and approval rules (accessed September 2026). SLSA v1.0 specification — build provenance levels. Not legal advice.
Frequently asked questions
Can we merge agent PRs with CI green and no human review?
Not for Tier 2 and above on this page. Org best practice requires human review proportional to blast radius. CI green does not prove semantic correctness, licence compliance, or absence of subtle security flaws.
Does ShipReady Metrics review or block agent pull requests?
No. The product ingests findings and reports AI-authored-code volume and DORA-style delivery signals. Merge decisions stay in your Git platform and engineering process.
How is this different from the security detection guide?
The detect-security-issues-ai-coding-agents guide maps failure modes to pipeline controls. This page is the human review playbook and risk-tier decision tree before merge.
Are GitHub branch protection rules a legal requirement?
No. They are enforceable platform configuration — org best practice aligned with SSDF independent review. Sector regulators may impose separate duties.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.