Baz Advanced Security Reviewer uses cyber-capable models, Agent Harness, and Context Broker to find exploitable security issues in code changes with real codebase context.
Most application security tools were built to detect known patterns, not investigate real exploitability. They can flag dangerous APIs, vulnerable packages, suspicious data flows, and risky configuration, but they usually stop at the moment the hard work begins. Someone still has to understand the change, trace the code path, check the surrounding system, decide whether the issue is reachable, and determine whether it is worth blocking the PR. That gap is where security teams lose time and developers lose trust in scanner output.
Baz Advanced Security Reviewer is built for that gap. It reviews code changes for exploitable security issues by combining cyber-capable models with the context Baz already understands about the codebase. Instead of treating a PR as an isolated diff, it looks at the change in the context of surrounding code, related repositories, package usage, module boundaries, prior review context, and runtime signals when available. The result is not just “this pattern looks risky,” but a finding that explains why the behavior matters in this system.
This is possible because the model capability curve has changed. Earlier models were useful for summarizing code and catching obvious mistakes, but they struggled with deeper security reasoning. Newer cyber-capable models are better at following multi-step logic, connecting behavior across files and services, and separating theoretically suspicious code from behavior that can plausibly be exploited. That makes them a better fit for security review, where the important question is rarely “does this match a rule?” and more often “can this actually be abused?”
Models alone are not enough. A strong model without the right context becomes a more expensive scanner. Advanced Security Reviewer runs inside Baz’s Agent Harness, which gives it a dedicated security review flow, and uses the Context Broker to fetch additional information required to validate a finding. When the reviewer sees something suspicious, it can pull in the surrounding implementation, related repositories, module and domain summaries, package context, PR metadata, comments, and other signals before deciding whether to post a finding.
That architecture is what makes the reviewer different from traditional static analysis. It does not need to make a final call from a single file or a single rule match. It can investigate. It can ask for more code. It can compare the change against how the rest of the system works. It can reason about whether the risky behavior is introduced by the PR, whether it touches a sensitive path, and whether the evidence is strong enough to justify interrupting the review.
We are starting in the PR because that is where security issues are cheapest to fix and easiest to understand. The developer still has the change in their head. The reviewer can see the finding next to the code. AppSec gets higher-signal findings without becoming the bottleneck for every merge. The goal is not to create another queue of theoretical issues. The goal is to stop real security risk at the point it enters the codebase.
Over time, this same approach extends beyond individual PRs. Repo-level scans can identify broader posture issues, risk hotspots, and attack vectors across services. Validated findings can connect into Baz Fixer so teams can move from detection to remediation. Scanners will continue to be useful for broad coverage and known patterns, but the center of gravity is shifting. The next generation of AppSec will be defined by tools that can prove which findings matter. Baz Advanced Security Reviewer is our first step in that direction.
