SAST-inside: expanding the hypothesis space of agentic security review

Large language models are useful security reviewers because they can reason across code that no single rule describes well. They can reconstruct a trust boundary from several files, infer how an authorization decision propagates through a service, compare a new code path with existing invariants, and explain why a defect is exploitable in the context of a specific Change.

That capability does not imply complete coverage.

A security agent still has to decide what to inspect, which files to retrieve, which vulnerability hypotheses to test, and when it has collected enough evidence. Its result depends on the model, the prompt, the available context, the search trajectory, and the order in which evidence is encountered. A model may correctly diagnose a vulnerability when shown the relevant path and still fail to search for that path in the first place.

SAST-inside adds a second source of hypotheses to Baz Advanced Security.

During a review, Baz runs specialized static checks over the changed code and passes the resulting signals into the same investigation performed by the Advanced Security agent. These signals do not become comments automatically. They become claims to test.

The agent then retrieves the relevant code, follows the surrounding data and control flow, searches for validation or sanitization, inspects callers and wrappers, and determines whether the reported condition is reachable and security-relevant in this repository.

The purpose is broader coverage, not deterministic output.

Security review has two separate problems

The first problem is discovery. The reviewer must decide which security conditions might hold.

The second problem is adjudication. The reviewer must determine whether a candidate condition constitutes a real vulnerability in the current program.

Static analyzers and language models fail differently on these two problems.

A static rule can repeatedly inspect every matching call site for a known source, sink, API misuse, or unsafe language construct. It does not forget to search for a vulnerability class because another code path consumed its attention. Its weakness is interpretation. A syntactic match often omits the application context required to decide whether the behavior is reachable, attacker-controlled, or already mitigated.

An agent can perform that interpretation. Its weakness is that it may not generate every relevant hypothesis. It may not retrieve the file containing the sanitization wrapper. It may fail to recognize an uncommon library call as a sink. It may search for direct string concatenation while missing a framework-specific query builder. It may inspect the changed function without enumerating all of its externally reachable callers.

SAST-inside combines these two error profiles.

The static check expands the set of candidate conditions. The agent evaluates each condition using repository context.

Example: query construction

Consider a Change that adds a search endpoint:

const query = `SELECT * FROM users WHERE email = '${req.query.email}'`;
return db.execute(query);

An agent may recognize the direct interpolation immediately. The interesting cases are less explicit:

const filter = buildFilter(req.query);
return userRepository.search(filter);

The vulnerability may depend on how buildFilter handles nested operators, whether userRepository.search parameterizes values, and whether a framework option permits raw expressions.

A static check can nominate the path because it recognizes a known source and sink or a framework-specific unsafe API. The agent can then inspect the implementation of buildFilter, trace the repository method, and determine whether the input reaches a query interpreter without an adequate boundary.

The signal improves discovery. The agent provides the verdict.

Example: path traversal

Suppose a Change adds file export behavior:

target = os.path.join(EXPORT_ROOT, request.args["name"])
return send_file(target)

A scanner may identify the request parameter flowing into a file API. That finding is still incomplete.

The agent needs to determine whether the application normalizes the path, whether send_file resolves symbolic links, whether the route is authenticated, whether the filename is constrained elsewhere, and whether an attacker can escape EXPORT_ROOT.

The same rule can produce different conclusions in two repositories. One implementation may reject path separators before this function is called. Another may decode the input after validation, reintroducing traversal sequences. Static analysis supplies the candidate. Context decides the result.

Example: server-side request forgery

A new webhook tester may accept a destination URL and issue a server-side request:

resp, err := http.Get(payload.URL)

A model may notice the direct request. It may also miss the vulnerability if the request is hidden behind an internal client abstraction:

result, err := integrations.Probe(ctx, payload.URL)

A static check can point the review toward the network operation. The agent can then inspect redirect handling, DNS resolution, protocol restrictions, private address filtering, proxy behavior, and alternate constructors for the client.

The vulnerability is rarely established by the call alone. The security property depends on the complete request path.

Example: authorization

Many authorization defects do not have a useful static signature.

A Change may load a resource by identifier, verify that the requester is authenticated, and then mutate the resource without checking tenant ownership. No dangerous API is required. Every individual call may be valid.

This remains primarily an agentic reasoning problem. The agent must infer the expected ownership invariant and compare it with the implemented control flow.

SAST-inside does not reduce Advanced Security to scanner output. Static checks add hypotheses where mature rules are useful. The agent continues to identify semantic defects such as broken authorization, inconsistent state transitions, tenant isolation failures, and validation logic that is locally correct but globally insufficient.

Independent detectors improve coverage

Using several detectors only helps when their failures are not fully correlated.

Running the same model twice with similar prompts may produce variation, but both runs still depend on similar learned representations and search behavior. Adding more tokens may improve exploration, but it does not guarantee that the model will enumerate every relevant vulnerability class.

A static analyzer contributes information produced by a different mechanism. Its rules, intermediate representations, and dataflow models encode security knowledge outside the model's generation process.

This matters when the model and the static check disagree.

When both identify the same path independently, the agent has stronger evidence that the condition deserves investigation.

When only the static check identifies a path, the agent receives a hypothesis it may not have generated.

When only the agent identifies a defect, Baz can still report vulnerabilities that are difficult to express as static rules.

The objective is not agreement between detectors. The objective is to reduce shared blind spots.

Validation is part of detection

A raw alert is not a completed security finding.

For each SAST-inside signal, Advanced Security can inspect the reported location, retrieve adjacent definitions, search for relevant callers, identify validations and transformations, and evaluate whether the path is externally reachable. It can also compare the signal with the Change itself to determine whether the risk is introduced, modified, or merely exposed by the current diff.

Signals that do not survive this process are suppressed.

A candidate injection finding may be rejected because the repository method always binds parameters. A path traversal warning may be rejected because the input is replaced with a generated identifier before reaching the file API. A cryptographic warning may be retained because the supposedly non-security use protects password reset tokens in another caller.

The distinction between a signal and a finding is central to the design.

SAST-inside contributes evidence. Advanced Security is responsible for the conclusion.

Review the Change while its context is available

Repository-wide security scans and Change review answer different questions.

A repository scan asks which vulnerabilities may exist in the current codebase.

A Change review asks which security properties are affected by a specific modification.

SAST-inside is currently designed for the second question. It runs within Advanced Security while the diff, surrounding code, relevant callers, and review context are available. This allows the agent to connect a candidate condition to the behavior being introduced and to explain the finding at the point where the developer can still revise the implementation.

The initial integration runs under the Advanced Security reviewer. SAST-derived findings retain source attribution so their origin remains visible, while their validation and presentation remain part of the same review.

The feature is being introduced through a controlled rollout. Candidate and suppressed findings are retained for evaluation so that coverage gains and rejection behavior can be measured before broader exposure.

The design principle

A security agent should not depend on its own recall to decide every test worth running.

It should be able to form hypotheses from the code, receive hypotheses from specialized analyzers, investigate both with the same repository context, and report only conclusions supported by evidence.

SAST-inside expands the hypothesis space available to Advanced Security.

The agent still has to prove the finding.

Configuration and rollout details are in the Secure AI Code documentation.