The bug is rarely in the diff: reviewing 5,000 PRs per day
A diff is a bad place to review a change. It shows you what moved, not what an attacker can reach. The two are often in different files.
Sentinel is our PR review bot. It reviews GitHub pull requests, GitLab merge requests, and Bitbucket Cloud pull requests to find real, exploitable security vulnerabilities before they merge. It runs about 5,000 times a day across customer pull requests, roughly one review every 17 seconds, on everything from TypeScript to Terraform. This post is about what it does in the gap between the line that changed and the thing that actually breaks.
Most automated review tools read the diff and reason from it alone. Sentinel opens the repository and follows the code.
What is agentic code review?
Agentic code review is automated review where an AI agent investigates a change the way a strong human reviewer would. It reads the diff, then opens the surrounding code, searches the project, and follows how untrusted data moves through the system before it decides what to flag. It acts, sees what comes back, and picks its next move.
That is the break from static analysis. A linter matches rules against source and reports whatever matches. Sentinel forms a hunch about a change and follows the execution path to confirm it or kill it.
It's pointed at the vulnerabilities that actually get you owned, not the ones that pad a report: authentication bypass, broken access control, IDOR, injection, server-side request forgery, and leaked secrets. Not code style. Not best-practice lint.
Where the bug actually lives
Think about the changes that actually cause incidents. Almost none of them look dangerous on their own line. The diff looks clean. The reachable bug is sitting in a file the pull request never opened.
| What the diff shows | What an attacker can actually reach | Where the evidence lives |
|---|---|---|
| A new endpoint with a tidy handler | Request data flows unescaped into a query downstream (injection) | The data-access layer the handler calls |
| A fresh auth check on one route | The same action is reachable through an older route that skips the check (auth bypass) | Elsewhere in the routing layer |
| An object fetched by ID for "the current user" | The lookup isn't scoped to the caller, so any user can read another's (IDOR) | The query, not the diff |
| A URL built from request input and fetched server-side | It can be aimed at internal services (SSRF) | The outbound call, a layer down |
The changed file is on the left. The reachable bug is on the right, in a file the pull request never opened.
Every row is invisible to a tool that only reads the diff, because the evidence lives somewhere else. That "somewhere else" is the whole job.
How Sentinel works a pull request
Connecting Sentinel takes a Git provider and the repositories you want watched. After that, every new pull request is analyzed the moment it opens. Sentinel reads the diff and the surrounding context, then follows the execution paths the change touches until it has enough to make a call.
Most paths out of a change go nowhere, and ruling them out is most of the work. The review is what's left when they're gone.
Here is one review out of that daily traffic, described by what it did rather than how. It opened the changed file, didn't trust it, and worked outward through the code that called into it, following the route untrusted input would take. It found nothing an attacker could reach, and closed the review. A clean result most tools would declare in a fraction of a second, this one earned by following the path.
Findings land as inline comments on the pull request, in the same flow the developer is already in. When someone marks a finding wrong, that feedback is captured as a reusable rule that sharpens later reviews and pulls the false-positive rate down over time.
Reading beyond the diff
The single most telling pattern in the data: Sentinel spends far more of its attention on the code around a change than on the changed lines themselves. It reads the neighbors, not just the patch. That habit is the entire thesis of the product expressed as behavior, and it's what lets one reviewer move fluently from application logic to CI config to infrastructure without changing gears.
Here's the same idea as a straight comparison with the tools most teams already run:
| Diff-only scanner | Sentinel | |
|---|---|---|
| Looks at | The changed lines | The change plus the code around it |
| Method | Pattern matching on keywords | Follows execution paths in context |
| What it flags | Anything that matches | Only what an attacker can actually reach |
| Ships with a finding | A warning | A concrete fix |
| Failure mode | Noise on clean code | Stays quiet on clean code |
How fast is a review?
Speed scales with the change. A small edit gets a quick pass. A large change gets a real investigation that reads across the codebase and follows data through it. Either way, findings land as comments within minutes of the pull request opening, well before anything merges.
The silence is deliberate. Most pull requests come back clean, and that's the intended outcome, not a failure to find something. Sentinel holds each finding to a hard bar of evidence and ships a suggested fix alongside it. If it can't show you the problem and hand you the patch, it doesn't speak. A reviewer that cries wolf gets muted, and a muted reviewer catches nothing.
FAQ
Is agentic code review different from SAST or a linter?
Yes. A linter and most SAST tools match patterns against source and surface anything that matches. They're fast, and they don't read intent, which is why they drift toward noise. Sentinel chases one change through the codebase, reasons about it in context, and reports only when an attacker could actually reach the issue. You trade a little latency per review for far more signal.
Do you need access to my source code?
Sentinel connects through your existing Git provider and reads the change in each pull request, along with the surrounding context it needs to judge that change. It looks at what it needs to review the diff, and nothing leaves your review flow.
Is it safe to run against production?
Yes. Sentinel reviews code in the pull request before it merges, so it never touches your running systems. It reads and comments on changes; it does not execute your application or send traffic to live environments.
How does it keep the noise down?
It reasons about each change in the context of the surrounding code, so it flags what's actually exploitable rather than keyword matches. It comments only where it matters, every finding ships with a fix, and developer feedback becomes rules that keep raising the signal.
How fast are results?
Sentinel reviews each pull request the moment it opens, so findings show up as comments within minutes, not days, in the same flow you're already working in.
For the same discipline applied to a running application instead of a pull request, see what 2,300 autonomous pentests turned up. To put Sentinel on your own repositories, start with Sentinel or book a call.
