Writing code isn't the hard part anymore. Knowing it's safe to ship is.
Strix PR Security Reviews is built for that second part. It's a native GitHub and GitLab integration that runs a full autonomous pentest against every pull request, directly inside your CI pipeline. The check spins up a live sandbox of your application, attacks the code paths your diff touches, and reports any exploitable vulnerabilities it finds before the branch merges.
The review bottleneck has moved
Coding agents like Codex, Claude Code, and Cursor have changed the shape of the average diff. More code is being written, faster, by fewer people. The rate-limiting step in most engineering orgs is no longer how long does it take to write the patch. It's how confident are we that the patch is safe to merge. Maintainability and scalability are already surfaced in code review. Security, historically, has not, at least not at the resolution that matters.
AppSec today is split between two modes: static analysis running on every commit, and dynamic pentesting running on some cadence measured in months. There's nothing in between. PR Security Reviews closes that gap.
What actually runs on a PR
When a pull request opens, Strix clones the repository at the PR commit and ingests the full source tree, because agents need the surrounding context, not just the diff, to reason about data flow and reachability. It then spins up the application in an isolated sandbox using the real binary, real dependencies, and real HTTP surface. A multi-agent run launches against the live instance, with the diff annotated so agents know where the new attack surface lives and prioritize testing around it. Findings are reported back as a PR status check, with full reproduction steps, the exact requests used, and the observed responses.
Because the target is a running application, every finding Strix reports is backed by an actual exploit against an actual instance. This is the core distinction from SAST: a static rule can tell you a sink looks tainted; Strix can tell you it got data out.
How it differs from SAST
SAST reads source and matches patterns. It's fast, cheap, and useful as a first pass, but it has structural limitations that don't go away with better rulesets. It can't observe runtime behavior. Whether an eval is reachable with attacker-controlled input depends on routing, middleware, and authorization that static analysis generally cannot resolve. It can't verify exploitability either: a "possible SQL injection" finding is a hypothesis, not a proof. And it can't meaningfully test logic bugs like broken access control, IDOR, and auth bypass, the class of issues that dominate modern bounty reports, because those bugs live in behavior, not syntax.
Runtime scales with diff risk
A pentest that blocks merges has to be fast, or it gets disabled. Most of our engineering effort on this feature went into keeping the runtime proportional to the actual attack surface a PR introduces, rather than flat-rating every diff.
A UI-only change that doesn't touch any request handler, route definition, auth code, or data access path typically completes in under a minute. Strix verifies that nothing in the diff expanded the attack surface and returns a clean check. A diff that adds a new endpoint, changes an authorization check, or modifies data access paths gets the full treatment: around 20 minutes of deep multi-agent testing against the live sandbox. The budget scales with what the diff actually does, not with its line count. A 2000-line React refactor that changes zero handlers will not cost 20 minutes. A 40-line change to a permission check might.
CI integration and merge gating
Strix reports as a first-class status check on GitHub and GitLab. Teams configure a severity threshold, typically high, above which the check fails and the branch becomes unmergeable under the repo's existing branch protection rules. Findings appear inline on the PR conversation itself, with reproduction steps, request/response traces, and impact analysis. There is no new dashboard to open and no ticket queue to triage; the finding lives where the code review already lives.
Because every finding is backed by a working exploit against the sandbox, Strix never blocks a merge on a guess. If Strix blocks a merge, there is a reproducible request that proves why.
Fix suggestions
Every finding ships with two remediation paths. The first is a suggested change: a concrete patch you can commit directly from the GitHub PR UI in a single click, identical in UX to accepting a review comment. The second is a copyable AI fix prompt: a self-contained brief that includes the relevant file context and the technical details of the finding, written to give Claude Code, Codex, or whichever coding agent you're using enough information to land the fix on the first attempt. Both paths keep remediation inside the tools the developer is already in.
Why now
Attackers now have autonomous agents of their own, and they're pointing them at production. The window between vulnerability shipped and vulnerability exploited is collapsing. Waiting for a quarterly engagement to find a bug that was introduced eleven weeks ago isn't a defensible posture anymore, not when an agent on the other side can find and exploit the same bug over a weekend.
The answer isn't more SAST rules. SAST already lives on every commit, it just can't prove exploitability or catch logic bugs. The answer is shifting pentesting left, all the way to the pull request, so vulnerabilities get caught and blocked while the code is still a diff, never reaching production. That's what Strix PR Security Reviews are.
Strix PR Security Reviews are available now on GitHub and GitLab.