What is AI SAST? A guide to AI-powered static application security testing

TL;DR

• AI SAST is static application security testing that combines rule-based pattern matching, dataflow and program analysis, and multi-pass LLM reasoning to review code the way a security engineer does.
• It goes after flaws that rules can't express, such as IDORs, broken access control, and business logic bypasses. It also triages false positives before they reach a developer.
• It differs from pointing a frontier model at a repo. Deterministic program analysis decides what the model sees, which keeps results grounded and scans cheap enough to run on every pull request.
• Test vendors against ground truth you control. Then roll out in stages: PR diff scans first, scheduled full scans next, and an MCP connection for AI coding agents last.

What is AI SAST?

AI SAST is static application security testing that combines rule-based pattern matching, dataflow and program analysis, and multi-pass LLM reasoning to find vulnerabilities the way a security engineer reviews code, without running the application. The rules catch the well-understood patterns. Program analysis traces how data moves through the codebase. The LLM reasons about intent, such as whether an endpoint should check who owns the record it returns.

The category exists because two older approaches stopped scaling. Rule engines can describe what a dangerous function call looks like. They can't describe a missing authorization check, because there's nothing to match. Human code review can catch those flaws, but no AppSec team can read every pull request when coding assistants and agents produce a large share of new code.

The naming is still settling, so you'll see several overlapping terms:

• AI SAST: the most common search term, and the one this guide uses.
• AI-native SAST: tools where AI reasoning is part of detection itself.
• AI-augmented SAST: a traditional rule engine with AI added afterward for triage or autofix. Detection still comes from rules.
• Agentic application security testing: the analyst term for tools that use multiple AI agents to detect, triage, and fix issues.

Gartner recognized the category under that last name. Endor Labs is named a Sample Vendor for Agentic Application Security Testing in the Gartner® Hype Cycle™ for Application Security, 2026.

Throughout this guide, Endor Labs AI SAST serves as the reference implementation.

Why does AI SAST matter now?

AI SAST matters now because coding assistants and agents write code faster than rule-based scanners and human reviewers can evaluate it. Almost half of companies now have codebases that are at least 50% AI-generated, up from 20% at the start of 2025.

Volume would be manageable if the code were secure by default. It isn't. In the SusVibes benchmark from Carnegie Mellon researchers, the top-performing coding agent produced functionally correct solutions for 61% of tasks, but only 10.5% were secure. The code compiles, the tests pass, and the feature works. The authorization check is still missing. Endor Labs now tracks this gap across agents and models in the Agent Security League.

None of this means AI-written code is uniquely dangerous. It carries the same vulnerability patterns people have always written: injection, broken access control, and logic that trusts the wrong input. The difference is scale. An AppSec team that once reviewed a few dozen sensitive changes a week now faces hundreds of pull requests a day across hundreds of repositories. Manual review at that pace isn't possible, and a rule engine that floods the queue with false positives makes the problem worse. For more on this shift, see how AI coding assistants change what static analysis needs to catch.

AppSec teams need a reviewer that keeps up with the PR volume and catches the logic flaws. Platform and DevSecOps teams need that reviewer to deliver a fix with each finding instead of another comment thread.

How does traditional SAST work, and where does it fall short?

Traditional SAST parses source code into an abstract syntax tree, applies rules that describe known-bad patterns, and runs taint tracking to follow untrusted input from a source to a sink. A rule might say: if a value from an HTTP request reaches a SQL query string without passing through a sanitizer, flag it. For classic SQL injection or a hardcoded credential, that works well.

The limits are structural, and they show up in three places.

1. False positives. A rule flags anything shaped like the pattern, whether or not it's exploitable. In NIST's 2018 Static Analysis Tool Exposition (SATE V) report, C/C++ SAST tools produced 69% false positives. A rule that flags every use of SHA-1 can't tell a weak password hash from SHA-1 inside ASN.1 DER encoding, where it's a legitimate part of the format. After enough noise, developers stop reading findings, and the real ones get ignored with the rest. We cover this in more depth in why SAST failed and what comes next.

2. Missed logic and access control flaws. Rules describe the presence of something bad. An IDOR or a broken access control flaw is the absence of something good: a missing ownership check, a missing tier check, an auth path that fails open. Pattern matching wasn't built to model how code is supposed to behave, so these flaws produce no match and no finding. That silent gap is the subject of false negatives in SAST.

3. Lost cross-file flows. Modern applications split a request across a route handler, a service layer, a repository, and framework middleware. Taint tracking that stops at a file or function boundary, or that can't see through framework wiring, loses the thread. The vulnerable path exists, but the tool never connects its ends.

AI-augmented SAST improves the first problem and leaves the other two in place. Adding AI triage on top of a rule engine can filter out some false positives. It can't add a finding the rules never produced, because detection still runs on rules.

How does AI SAST work?

AI SAST works by running three layers of analysis inside one engine, then handing the results to specialized agents that detect, triage, and fix issues. Each layer covers a weakness in the others.

Three layers in one engine

Rule-based pattern matching handles the known-bad patterns quickly and deterministically. 

Layer 1: Dataflow and program analysis builds a model of how the application behaves. In Endor Labs AI SAST, that model is a patented code context graph with call graphs, dataflow, and line-level detail. It answers questions like "which functions can reach this database query" and "does this request parameter ever pass through an authorization check." The answers are deterministic: the same code produces the same graph every time.

Layer 2: Multi-pass LLM reasoning reads the code paths the graph identifies and asks the questions rules can't encode. Should this endpoint check ownership? Is this cryptographic call a weakness or a protocol requirement? 

Layer 3: The model makes several passes, refining its reasoning each time, instead of giving a single-shot answer.

Detection, triage, and remediation agents

Endor Labs AI SAST orchestrates multiple specialized agents on top of those layers.

Detection agents trace user-controlled data from source to sink, following flows through 3 to 5 architectural layers and across multiple files and functions.

Triage agents classify every finding as true positive, false positive, or unknown. Each classification comes with a written explanation, so a security engineer can audit the reasoning instead of trusting a verdict.

Remediation agents propose a context-aware fix for each confirmed vulnerability, written against the code that exists in your repo.

Deployment-aware prioritization

A vulnerability's priority depends on where and how the code runs. AI SAST reads Dockerfiles, Kubernetes manifests, and CI configuration to learn that context. An endpoint behind an internet-facing ingress carries more risk than the same flaw in an internal batch job. A service that runs as root changes the impact of a command injection. Reading deployment configuration moves prioritization away from generic severity labels and toward exposure. It also connects first-party code findings to full-stack reachability analysis across dependencies and container images.

A worked example: tracing a cross-file IDOR

Here's an invoice endpoint split across three files, the way most production code is.

// routes/invoices.ts
router.get("/invoices/:id", requireAuth, async (req, res) => {
  const invoice = await invoiceService.getInvoice(req.params.id);
  res.json(invoice);
});

// services/invoiceService.ts
export async function getInvoice(id: string) {
  return invoiceRepo.findById(id);
}

// repositories/invoiceRepo.ts
export async function findById(id: string) {
  return db.query("SELECT * FROM invoices WHERE id = $1", [id]);
}

Any logged-in user can request any invoice by changing the ID in the URL. That's an IDOR.

A rule engine finds nothing. The query is parameterized, so injection rules stay quiet. The route uses requireAuth, so a "missing authentication" rule is satisfied. No line of this code matches a known-bad pattern, because the flaw is a check that isn't there.

An LLM given only routes/invoices.ts doesn't have enough to decide. It sees authentication middleware and a call to a service function. Whether getInvoice enforces ownership lives in another file. The model either guesses or reports nothing, and a second run might guess differently.

AI SAST follows the whole path. A detection agent uses the code context graph to trace req.params.id from the route handler through getInvoice to the query in findById. Along the way, it notes that no step compares the invoice to req.user. It also sees that sibling repository functions in the same codebase filter by owner_id, which tells the model what the expected pattern looks like.

A triage agent then checks for anything that would make the finding a false positive, such as row-level security in the database or an ownership check in middleware. Finding none, it classifies the issue as a true positive and writes down why. The deployment configuration shows the route behind a public ingress, so the finding moves up the queue.

The developer sees something like this in the pull request:

With that evidence, a developer can verify the finding in a minute instead of spending an afternoon reproducing it.

Where to go for the architecture

For a full walkthrough of how the code context graph, the agent orchestration, and the deterministic engineering fit together, read about the architecture behind Endor Labs AI SAST. It covers how the engine models application behavior and how reachability analysis feeds prioritization.

How is AI SAST different from pointing a frontier model at your repo?

AI SAST uses program analysis to choose which code paths the model reads, so the model reasons over the complete path every time.

A frontier model pointed at a repo sees only the slice of code that fits in its context, without deterministic grounding, so results vary between runs and cost scales with repo size. 

The IDOR example shows the gap. Ask a model to review the route file and it misses the flaw, because the evidence sits in two other files. Ask it to review the whole repo and you pay for every token, often more than once, while the model decides on its own what deserves attention. Run the same prompt twice and you can get two different sets of findings.

What the benchmark shows

Endor Labs tested this difference directly. The Endor Labs AI SAST benchmark covered 8 real-world projects across Java, Python, JavaScript, TypeScript, C#, and Go, with ground truth established by the Endor Labs security research team. Endor Labs AI SAST found 192 real vulnerabilities. That's 2.6x what Claude Opus 4.7 found, 3.5x what Codex GPT-5.5 found, and 2.4x what Semgrep OSS found.

Separate Endor Labs testing on four embedded C projects showed the same pattern. AI SAST caught 96 of 102 known vulnerabilities, 48 times as many as the next-best buildless, pattern-based SAST tool.

The difference comes from what the model is shown. Program analysis puts the right code paths in front of the model, so detection doesn't depend on the model finding them on its own.

Cost, speed, and consistency

Practitioners raise three objections to AI in the scanning path. Model calls cost far more than a rule scan. LLM output varies between runs. And AI analysis is too slow for pipelines that need results in minutes. All three are fair criticisms of LLM-only scanning. A common response is to run a rule engine and an AI tool side by side, then reconcile two sets of results.

AI SAST built on deterministic program analysis answers the objections inside one engine instead.

Cost stays contained because the engine never dumps the codebase into a model. Endor Labs AI SAST runs on its Code API, a semantic model of the code with call graphs and dataflow. The LLM sees the specific paths that matter. Languages with Code API support (C, C#, Go, Java, JavaScript, and Kotlin) get faster, cheaper scans.

Speed comes from scoping. A pull request scan analyzes the diff and the paths it touches, not the whole repository, so results arrive while the PR is still open.

Consistency comes from the deterministic layer. The code context graph is the same on every run, so the candidate paths the model evaluates don't drift. The reasoning step still uses an LLM, and teams should test for run-to-run variation as part of any evaluation. Written triage explanations and policies that block only on high-confidence findings keep that variation from reaching developers as noise.

How do traditional SAST, LLM-only scanning, and AI SAST compare?

Traditional SAST detects with rules, LLM-only scanning detects with a model reading whatever code it's given, and AI SAST combines rules, program analysis, and model reasoning in one engine. The table summarizes the differences covered above.

Traditional SAST still fits as a fast, low-cost check for well-defined patterns, which is why AI SAST keeps a rule layer. LLM-only scanning works for one-off exploration of a small codebase, while AI SAST fits teams that need logic-flaw coverage on every pull request without the noise.

What vulnerabilities does AI SAST catch?

AI SAST catches the classes rule engines handle well, plus the ones that need an understanding of how code is supposed to behave. The second group is where the difference shows:

• IDOR and broken access control: an endpoint returns or modifies a record without checking that the requester owns it, like the invoice example above.
• Authentication bypass: an auth path that fails open on an exception, a check that runs after the sensitive action, or a route that skips middleware its siblings use.
• Business logic flaws: a missing tier check that lets a free account call a paid feature, or a missing ownership check on a state change like a refund or a role update.
• Cross-file injection: user input enters in a controller and reaches a query, shell command, or template in a different file, through layers that lose taint in rule-based tools.
• Configuration as attack surface: missing input validation at trust boundaries, and deployment settings that turn a minor flaw into an exposed one.

These map to the OWASP Top 10 categories AppSec teams already report against. Broken access control, which covers IDOR, has held the top spot since 2021. Insecure design, authentication failures, and security misconfiguration all require an understanding of authorization flows and application intent. Endor Labs AI SAST covers the full OWASP 2025 Top 10, including those categories, alongside the injection findings rule engines have always produced.

The same benchmark measured breadth. Of the 192 real vulnerabilities Endor Labs AI SAST found, 63 were found by no other tool tested. It covered 64 of 106 CWE types in the ground truth, against 36 for the next tool.

AI-written code tends to concentrate in exactly these classes, because a coding agent optimizes for working behavior and doesn't know your authorization model. For a closer look, see what static analysis catches and misses in AI-generated code.

How do you evaluate AI SAST tools?

Evaluate AI SAST tools by running them against projects where your own reviewers already know the real vulnerabilities, then measuring what each tool finds, what it gets wrong, and what it costs. Vendor claims about false-positive rates are easy to make and hard to compare. Ground truth you control removes the guesswork.

Build a ground-truth test

The Endor Labs benchmark design is a usable template: 8 real-world projects, 6 languages, and ground truth set by a security research team before any tool ran. You can run a smaller version.

1. Pick 3 to 5 repositories that represent your stack, including at least one with a multi-layer service architecture.
2. Establish ground truth. Use vulnerabilities your team has already confirmed and fixed, rewind to the commit before the fix, or seed known flaws such as a missing ownership check or a cross-file injection.
3. Run every tool against the same commits with default settings, then again with any tuning the vendor recommends.
4. Have your reviewers label every finding as a true positive, false positive, or duplicate. Don't let the tool's own triage verdict count as the label.
5. Record the results in one table so you can compare tools on the same terms.

What to measure

• Detection coverage: true positives found against your ground truth, broken out by CWE type. A tool that only finds injection will look fine until you count the access control flaws it missed.
• False-positive rate: findings your reviewers rejected, as a share of everything raised.
• Evidence per finding: whether each finding shows the data flow, call path, and reachability proof, or only a line number and a rule name.
• Consistency: run the same scan twice and compare the results.
• PR and CI/CD integration: latency on a pull request diff, how findings appear in the PR, and whether policies can block only on high-confidence results.
• Cost per scan: at PR scale, not on a single demo repo.
• Language support: coverage for every language in your estate, and which languages get deeper analysis.

‍

For reference, Endor Labs AI SAST eliminated 95% of false positives in comparative testing at launch, and it supports 40+ languages. The whitepaper explains how agents, program analysis, and rules eliminated 95% of false positives, which gives you a baseline to compare against your own results. When you're building a shortlist, our roundup of SAST tools and our comparison of application security tools for the AI era are good starting points.

How do you roll out AI SAST?

Roll out AI SAST in order of cadence: start with diff scans on pull requests, add scheduled full-repository scans, then connect AI coding agents so findings reach them while they write code. Each stage builds trust before the next one widens coverage.

Stage 1: pull request diff scans

Install the engine through your SCM app and scan the diff on every pull request. Developers see findings in the place they already review code, scoped to the lines they changed. That keeps the signal relevant and the latency low.

Endor Labs AI Security Review does this by running the AI SAST engine on every pull request, confirming which vulnerabilities are exploitable, and shipping a context-aware fix with each one. See how AI security review on every pull request works in practice.

Treat findings as fixes delivered in the PR. A developer who gets a confirmed IDOR with the call path and a proposed patch can merge the fix in minutes. Developers typically spend 4+ hours researching a single SAST finding when it arrives without context. With OPA-based policies, you can block pull requests only on high-confidence findings, suppress known false positives, and route findings by team, so the scanner speeds review up instead of stalling it.

Stage 2: scheduled full scans

Once PR scans are running smoothly, add scheduled full-repository scans. These catch flaws in code that predates the rollout and paths that span changes no single PR touched. Run them nightly or weekly, and send results into the same policy engine and ticketing flow your team already uses, with no separate workflow for AI-driven findings.

Stage 3: coding agents

Much new code now starts in an AI coding agent. The next step is to put security analysis inside that loop. AURI by Endor Labs connects coding agents to the engine through Hooks, Skills, MCP, CLI, and API. With an MCP server in place, an agent can check its own output against the code context graph and fix an access control gap before it ever opens a pull request. AURI also gives security teams governance over the actions coding agents take, alongside the code they produce. For the developer side of this loop, see how to secure AI-generated code from prompt to merge.

Explore the AI SAST guide

 Start with fundamentals if you’re making the case to move off a legacy scanner, or skip to evaluation if you already have vendors on a shortlist.

Fundamentals

• Why SAST failed (and what's next): how legacy SAST lost developer trust.
• False negatives in SAST: the real vulnerabilities rule-based tools never report.

How it works

• Reachability analysis: how tracing call paths across code, dependencies, and containers separates exploitable findings from theoretical ones.
• AI SAST: Code Security for the Agentic SDLC: the architecture deep dive.

AI-generated code

• SAST for AI-generated code: the bug classes coding agents introduce.
• How to secure AI-generated code: a developer workflow from prompt to merge.

Evaluation

• AI SAST benchmark: methodology and per-project results.
• SAST tools and application security tools for the AI era: for building a shortlist.

FAQs

Does AI SAST replace traditional SAST?

AI SAST replaces a standalone rule-based scanner for most teams, because a well-built AI SAST engine includes a rule layer. Rules stay useful for fast, deterministic detection of known patterns. The difference is that rules become one input to the engine instead of the whole detection method.

Are AI SAST results consistent from scan to scan?

AI SAST results are more consistent than LLM-only scanning because deterministic program analysis fixes the set of code paths the model evaluates. The model's reasoning step can still vary slightly. Written triage explanations and high-confidence policy thresholds keep that variation out of developers' queues. Test consistency directly during evaluation by running the same scan twice.

What's the difference between AI SAST and DAST or AI pentesting?

AI SAST reads source code without running the application, while DAST and AI pentesting test a running application from the outside. DAST sends crafted requests to find exploitable behavior. AI pentesting uses agents to chain those probes into attack paths. Static analysis finds flaws earlier and points to the exact line, while dynamic testing confirms behavior in a live environment. Most mature programs use both. For the full picture, see how SAST fits alongside DAST, IAST, and SCA.

Are there open-source AI SAST tools?

Open-source rule-based scanners exist and are widely used, and teams can script their own pipelines that send code to a model. What's harder to find in open source is the full combination: a semantic code model, cross-file dataflow, multi-agent triage, and deployment-aware prioritization in one engine. If you build your own, use the ground-truth evaluation method above to measure it against commercial tools.

How much does it cost to run AI SAST on every pull request?

The cost of running AI SAST on every pull request depends mostly on how much code the model reads per scan. Tools that send whole repositories to a model get expensive as repos grow. Engines that use a semantic code model and diff-scoped PR scans send the model only the relevant paths, which keeps per-PR cost contained. Measure cost per scan at your real PR volume during evaluation, not on a demo repo.

Which languages does AI SAST support?

Language support varies by vendor, so check every language in your estate. Endor Labs AI SAST supports 40+ languages. C, C#, Go, Java, JavaScript, and Kotlin get Code API support, which makes scans faster and cheaper in those languages.

‍

Gartner, Hype Cycle for Application Security, 2026, Dionisio Zumerle, 21 July 2026.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and HYPE CYCLE is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.