Notifications
Clear all
Topic starter
01/07/2026 2:04 am
TL;DR: Years of ProdSec review history have been turned into 343 rules across 16 vulnerability categories by a SAGE pipeline using a multi-model Finder, Critic, and Judge, while cutting review time and hardening against prompt injection, according to 1Password. The core lesson is that AI-assisted security review only works when discovery, verification, and adjudication are separated.
NHIMG editorial — based on content published by 1Password: SAGE and the future of AI-assisted security review
By the numbers:
- SAGE v1 now has access to 343 rules that cover 16 vulnerability categories.
Questions worth separating out
Q: How should security teams design AI review pipelines for code changes?
A: Security teams should separate finding, critique, and final approval into distinct stages with different inputs and decision thresholds.
Q: Why do single-model security review workflows create governance risk?
A: Single-model workflows create governance risk because the same model is asked to discover issues, interpret evidence, and decide whether the issue is real.
Q: What do teams get wrong about using AI for security code review?
A: Teams often assume that a powerful model is enough, when the real control problem is workflow design.
Practitioner guidance
- Separate detection from adjudication Use different stages or services for issue discovery, technical challenge, and final verdict so one model never has unilateral approval authority over security findings.
- Constrain context by review stage Pass only the artefacts each stage needs, such as compact rules for finding and full code hunks only for critique, to reduce prompt-injection exposure and overreach.
- Benchmark against human-reviewed history Train and validate review rules on your own historical security comments and diffs so the system reflects local coding patterns, sensitive directories, and known failure modes.
What's in the full article
1Password's full blog post covers the operational detail this post intentionally leaves for the source:
- The rule extraction workflow that converted nearly 9,000 historical ProdSec reviews into a structured rule set.
- The Finder, Critic, and Judge prompts and how each stage is constrained differently.
- The model-testing approach used to compare five model profiles across the same pull requests.
- The production deployment pattern for running SAGE inside the largest repositories.
👉 Read 1Password's full post on SAGE's AI security review pipeline →
AI code review for security: are your reviews keeping up?
Explore further
01/07/2026 2:25 am
Security review pipelines fail when one model is forced to act as both detector and judge. That is the core governance lesson in this design. Security review needs broad signal capture first and narrow adjudication second, because evidence quality changes across the review flow. The implication is that AI review has to be treated as a control chain, not a single control.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How can organisations reduce prompt-injection risk in AI-assisted review?
A: Organisations should limit what each stage can see and do, and avoid giving one model unrestricted access to raw code, rules, and final judgment at the same time. Scoped inputs reduce the chance that malicious text inside a pull request can steer the whole process. Human review should remain available for edge cases and final escalation.
👉 Read our full editorial: AI code review for security scales by splitting recall from proof
