How AI SAST Works: Detection, Triage, and Remediation Agents

TL;DR

• Endor Labs AI SAST runs detection, triage, and remediation agents on top of deterministic program analysis and rules. It builds a code context graph first, so agents query narrow paths instead of reading the whole repository, which keeps cost down and results repeatable.
• The detection agent traces user-controlled data from source to sink across files, catching flaws like a missing ownership check (IDOR) that a pattern rule can't express.
• The triage agent labels every finding, from AI or from rules, as true positive, false positive, or unknown, with written reasoning your team can audit and policies that encode your organization's decisions.
• The remediation agent proposes fixes that reuse your codebase's existing helpers and posts them as pull request comments, where a developer reviews and merges them.

AI SAST runs your code through a pipeline of specialized AI agents that sit on top of deterministic program analysis and rules. One agent detects candidate vulnerabilities. A second triages them into real and not real. A third proposes fixes. The agents add reasoning about how the code behaves, which is the part a pattern can't express. For the full definition of the category, see our guide to what AI SAST is and why it exists.

Disparate tools create more noise and can miss the bug classes that cause the most damage: broken access control, insecure design, and business logic flaws. A regex-style rule can spot a dangerous function call. It can't tell whether the user calling an endpoint is allowed to see the record it returns. For more on that gap, see what static analysis catches and misses in AI-generated code.

The rest of this post uses Endor Labs AI SAST as a worked model. It orchestrates multiple specialized agents and combines rule-based pattern matching, dataflow tracing, and multi-pass LLM reasoning, so it reads code the way a security engineer would. We'll follow one bug through every stage, covering what each agent reads, what it decides, and what it hands to the next agent or to a person.

What happens before any agent runs?

Before an agent looks at anything, Endor Labs builds a structured model of your code. The agents query that model. They don't read the whole repository.

That model is a code context graph: a map of functions, the calls between them, and the paths data takes through the application, down to individual lines. Building it is deterministic program analysis, meaning the same code produces the same graph every time, with no model guessing involved. Endor Labs exposes this through its Code API, a semantic model with callgraphs and dataflow.

This design choice matters for anyone who has priced out LLM-based scanning. Dumping an entire codebase into a prompt is slow and expensive at enterprise scale. It's also hard to repeat, because the model sees different slices of context on different runs. When an agent asks the graph a narrow question, the LLM only reasons over the code that matters to the finding. Code API support today covers C, C#, Go, Java, JavaScript, and Kotlin. AI SAST runs on a wider set of languages, and the ones with Code API support get faster, cheaper scans.

If you want the full multi-modal design, the whitepaper on combining agents, program analysis, and rules goes deeper than this post will.

Step 1: The detection agent traces data from source to sink

The detection agent finds candidate vulnerabilities by tracing user-controlled data from where it enters the application (the source) to where it gets used in a sensitive operation (the sink), across files and functions.

Here's the running example. It's an illustrative Spring service with an insecure direct object reference (IDOR), split across two files the way real code usually is.

// ReportController.java
@GetMapping("/reports/{reportId}")
public ReportDto getReport(@PathVariable Long reportId,
                           @AuthenticationPrincipal User user) {
    return reportService.findReport(reportId);
}


// ReportService.java
public ReportDto findReport(Long reportId) {
    Report report = reportRepository.findById(reportId)
        .orElseThrow(NotFoundException::new);
    return ReportDto.from(report);
}

The user is authenticated. Nothing checks that they own the report. Change the number in the URL and you can read another customer's reports.

The detection agent asks the code context graph where reportId goes. The graph shows a path from the path variable in the controller, through findReport in the service, into a repository lookup that returns a tenant-scoped record. The agent then reasons about what's missing along that path. It sees that the authenticated user is available in the controller but never compared against the report owner. It can also see that sibling endpoints in the same controller do perform that comparison. That inconsistency is a strong signal.

The output is a candidate finding with the full trace attached: the source, the sink, the call path between them, and a description of the missing check. Endor Labs labels findings from the detection agent with an AI finding tag, so you can tell them apart from findings produced by rules. The detection agent documentation covers configuration and how those tagged findings appear.

Compare that with a pattern rule for the same bug. A rule can match findById called with a request parameter. That rule fires on every lookup in the codebase, including the ones that are properly guarded, and it has no way to express "the caller should own this record." You either drown in matches or write a rule so narrow it misses the variant in the next service. Authorization is a property of the path, and a pattern only sees a line.

Step 2: The triage agent decides what's real

The triage agent gives every finding one of three verdicts: true positive, false positive, or unknown. Each verdict comes with written reasoning that your team can read and audit. The triage agent documentation covers how verdicts appear.

Triage runs on findings from both sources, the detection agent's AI findings and the rule-based findings. This is where most of the noise from legacy SAST disappears. Endor Labs reports up to 92% false positive reduction for AI SAST.

For the report example, the triage agent weighs evidence from the code model. It checks the data flow trace, whether any interceptor, filter, or annotation along the call path enforces ownership, and how the rest of the codebase handles the same resource. It finds no ownership check on this path. Other report endpoints call an ownership helper. The verdict is true positive, and the reasoning says so in plain language, citing the call path.

Context also clears findings that a rule would flag forever. A familiar case is a rule that sees SHA-1 and flags it. The triage agent can recognize SHA-1 used inside ASN.1 DER encoding as a legitimate use rather than a vulnerability, because it reads what the code is doing with the hash.

What does an "unknown" verdict mean?

An "unknown" verdict means the agent didn't have enough evidence to commit either way, and it says so instead of guessing.

Suppose the report service sat behind an API gateway that enforced ownership in configuration living outside the repository. The code model can't see that config. A binary classifier would have to pick a side, and an LLM forced to pick a side is exactly where hallucination risk lives. An "unknown" verdict routes the finding to a person who knows how the gateway is set up. Treat unknowns as a review queue. Look at the reasoning, decide, and feed that decision back so the next similar finding resolves on its own.

How does organizational context shape triage?

Organizational context shapes triage by telling the agent which patterns, priorities, and policies matter in your codebase. 

 For the details, read how Endor Labs AI SAST learns what matters to your organization, or explore it in the product tour.

Policies are where your team encodes decisions once instead of re-making them per finding. Endor Labs uses OPA-based policies, so you can suppress a known false positive pattern, route findings to the owning team, or decide which confidence levels should hold a pull request. Custom prompts and feedback on verdicts let the system adapt to how your codebase is built.

Step 3: The remediation agent proposes a fix that fits your code

The remediation agent proposes a specific fix alongside every confirmed vulnerability, written to match the conventions already in your codebase.

That last part is the difference between a useful fix and a generic one. For the report bug, a generic patch might inline a raw comparison of user IDs. The remediation agent sees that the codebase already has an ownership helper used by the sibling endpoints, and it proposes using that:

// ReportController.java (proposed fix)
@GetMapping("/reports/{reportId}")
public ReportDto getReport(@PathVariable Long reportId,
                           @AuthenticationPrincipal User user) {
    accessPolicy.requireOwner(user, Report.class, reportId);
    return reportService.findReport(reportId);
}

The fix reuses the team's existing pattern, so it reads like code a teammate would write, and it inherits whatever logging and error handling requireOwner already does. Developers typically spend 4 or more hours researching a single SAST finding. A confirmed finding with a call path, a reason, and a ready fix cuts that to minutes.

The fix shows up where developers already work, as a comment on the pull request, connected to your CI/CD pipeline and the Endor Labs policy engine. There's no separate workflow for AI-generated findings.

A developer still owns the change. They read the suggestion, check it against what they know about the feature, and merge it if it's right.

How do the three agents hand off to each other?

Each agent passes its output to the next agent or to a person, as the table shows.

People enter the loop at three points. They resolve unknown verdicts. They review and merge fixes. They set the policies that decide what gets suppressed, routed, or held.

Where does the pipeline run?

The same agents run in two places: full scans of a repository, and every pull request through AI Security Review.

AI Security Review is the AI SAST engine applied to each PR. The detection agent reads the change and traces how data moves through the files and functions it touches. The triage agent classifies what it finds, and remediation proposes fixes as PR comments. One PR scan also covers dependencies the change touched (SCA) and any secrets it introduced, so developers get one review instead of three separate bot comments. It runs on GitHub, GitLab, and Bitbucket.

Running at the PR is how security keeps pace with how code ships now, especially as AI coding agents write more of it. After rollout, fewer than 10% of PRs need human security review, so your security engineers spend their time on the changes that need them.

What should you look for when you evaluate an AI SAST pipeline?

A credible AI SAST pipeline shows its work on every finding and tells you when it isn't sure. Use these questions on any tool you evaluate, including ours:

• Per-finding evidence: Does each finding include the data flow and call path from source to sink, or only a label and a severity?
• Uncertain verdicts: Can the system return "unknown" and route it to a person, or does it force every finding into true or false?
• Auditable reasoning: Can your team read why a finding was marked a false positive and disagree with it?
• Policy input: How do your organization's policies and architectural patterns feed triage? Can you encode a decision once?
• Fix quality: Do proposed fixes reuse your existing helpers and conventions, and do they land in the PR where developers review them?
• Language coverage: Which languages get deep program analysis, and which get a lighter pass?
• Cost model: Does the tool query a structured model of the code, or prompt over whole repositories? That choice drives scan time and spend.
• Your own false positive rate: Run the tool on two or three of your repositories. Have a security engineer label a sample of findings by hand and compare the tool's verdicts against those labels. Count missed true positives too, since a quiet tool that misses bugs isn't a win.

Endor Labs AI SAST delivers up to 92% false positive reduction. Across 8 real-world projects in Java, Python, JavaScript, TypeScript, C#, and Go, with ground truth established by the Endor Labs security research team, AI SAST found 192 real vulnerabilities: 2.6x what Claude Opus 4.7 found and 3.5x what Codex (GPT-5.5) found. The full benchmark has the methodology. Your repos are the test that counts, so run the checklist above against them.

When you're ready to try it, see how Endor Labs AI SAST works on your code.

FAQs

Does AI SAST replace rule-based SAST rules?

No. AI SAST layers agents on top of rules and deterministic program analysis. Rules still catch well-understood patterns cheaply and consistently. The detection agent adds findings that rules can't express, like missing authorization checks. The triage agent then filters findings from both sources. This is also the difference from AI-generated fix suggestions added to a legacy scanner. In that setup the scanner's noisy output stays the same, and an LLM only writes a patch at the end. AI SAST changes how findings get detected and confirmed before any fix is written.

What's the difference between SAST and DAST?

SAST analyzes source code without running it, while DAST tests a running application from the outside by sending requests and watching responses. SAST can point to the exact line and call path behind a bug. DAST confirms behavior in a deployed environment. SCA is a third piece that covers vulnerabilities in open source dependencies, and AI Security Review runs SCA and secrets detection in the same PR scan as AI SAST.

Does AI SAST work on AI-generated code?

Yes, and it's a large part of why AI SAST exists. AI coding agents write a growing share of production code, and much of it isn't secure. In Carnegie Mellon's SusVibes benchmark, SWE-Agent with Claude 4 Sonnet produced functionally correct solutions for 61% of tasks, but only 10.5% were secure. That code carries the same vulnerability patterns as human-written code, including access control and design flaws, and it arrives faster than manual review can keep up. Running the detection, triage, and remediation agents on every pull request means AI-written changes get the same source-to-sink analysis as everything else.