"AI SAST" showed up in nearly every application security vendor's pitch deck in 2025, but the label hides two very different products. One kind bolts a large language model onto a traditional rule-based scanner to summarize, rank, and patch the findings that scanner already produces. The other kind uses the LLM itself, reasoning over code, data flow, and business logic, as the primary detection engine. Aikido Security, the Ghent, Belgium-based platform that hit a $1 billion valuation on a $60 million Series B in 2025, is a useful case study because it is fairly transparent about which one it runs: Opengrep, its open-source fork of Semgrep launched in January 2025, does the actual scanning, and AI features called AutoTriage and AutoFix sit on top of it. That is not a knock on Aikido, it is an architecture decision with real tradeoffs either way. This post walks through what "AI-native" and "AI-augmented" actually mean, where each one breaks down, and how to tell which kind of tool you're evaluating before you buy it.
What's the actual difference between AI-native and AI-augmented SAST?
The difference is where the AI sits in the pipeline: augmented tools apply AI after a deterministic scanner has already produced a list of findings, while native tools use AI, usually an LLM, as the detection engine itself, reading source code the way a senior reviewer would instead of matching it against a library of rules. Classic SAST, the lineage running from Fortify (2003) through Checkmarx, Veracode, and Semgrep's YAML-based pattern rules, works by building an abstract syntax tree and control-flow graph, then tracking whether data from a defined "source" (a URL parameter, a form field) reaches a defined "sink" (a SQL query, a shell exec call) without passing through a sanitizer. It is fast and deterministic, but it can only find what its rule authors thought to encode.
AI-augmented tools take that same rule-engine output and add a layer on top: natural-language explanations of why a finding matters, deduplication of near-identical alerts, severity re-ranking based on exploitability, and LLM-generated patch suggestions. AI-native tools skip the rule file for the core detection step and instead feed the model source code, call graphs, and framework context directly, asking it to reason about whether untrusted input can reach a sensitive operation across function and file boundaries, or whether a business-logic check is simply missing. A concrete example: an endpoint that fetches /api/orders/{orderId} and returns the order without verifying the requesting user owns it is a broken-access-control bug, not a string pattern. A rule-based engine has nothing to match against; an LLM reasoning about the code's intent can flag the missing ownership check.
How does Aikido Security's SAST actually work under the hood?
Aikido's core detection engine is Opengrep, a permissively licensed fork of Semgrep that Aikido co-launched in January 2025 after Semgrep changed its own commercial licensing terms, and the company layers two AI features, AutoTriage and AutoFix, on top of whatever Opengrep's taint analysis and pattern rules surface. AutoTriage works by first trying to rule out exploitability on each raw finding, then ranking what's left by exploitability and severity; Aikido markets this as cutting alert noise by up to 95%. AutoFix takes a finding Opengrep already produced, and where a fix pattern exists, generates a diff using vetted LLMs (the company has cited Claude Sonnet via AWS Bedrock) running in short-lived, read-only sandboxes, then opens a one-click pull request; Aikido says it covers 100+ vulnerability types spanning SAST issues like XSS and path traversal as well as IaC misconfigurations in Terraform, CloudFormation, and Helm charts. Aikido's own funding trajectory tracks the category's momentum: €2 million pre-seed in January 2023, a €5 million seed round in November 2023, a $17 million Series A in May 2024 led by Singular, and the $60 million Series B in 2025 led by DST Global, reportedly the fastest a European cybersecurity company has reached unicorn status. This is a textbook AI-augmented architecture: the pattern engine finds the candidate, and an LLM decides whether it's worth showing you and drafts the patch.
Why does the underlying detection engine matter more than the AI layer bolted onto it?
It matters because a triage or autofix layer can only rank, explain, or patch findings the detection engine actually produced, it cannot surface a vulnerability that the pattern rules never matched in the first place. This shows up most clearly on vulnerability classes that require tracing data across multiple files and functions, such as command injection and SQL injection: on those categories, AI-native detection engines have measured true-positive rates at least 3x higher than pattern-based scanners, while on context-independent issues, like a hardcoded weak randomness call or a deprecated encryption algorithm, that don't need cross-file reasoning, accuracy is roughly comparable across both approaches. Broken access control has sat at or near the top of the OWASP Top 10 since the 2021 revision, and a meaningful share of the 2024 CWE Top 25 (entries like CWE-862, Missing Authorization, and CWE-863, Incorrect Authorization) describe missing logic rather than a matchable code pattern. A scanner whose core engine is rule-based will structurally under-detect that entire category no matter how good the AI ranking or patch-generation layer on top of it is, because there's nothing wrong in the syntax, only in what the code fails to check.
What do noise-reduction claims like Aikido's "up to 95%" actually measure?
They measure how many candidate findings the AI triage layer discards after the rule engine has already generated them, not how accurate or complete the underlying detection was to begin with, so a 95% figure describes noise removed from a haystack, not needles found inside it. Industry surveys have repeatedly put baseline SAST false-positive rates somewhere between 30% and 70% depending on how aggressively the ruleset is tuned; a scanner that over-generates by flagging, say, every string concatenation adjacent to a SQL keyword has a lot of room to post an impressive-looking reduction percentage while still missing the same access-control or workflow bugs it always missed. Two questions cut through the marketing number: reduction measured against what baseline (a tuned ruleset or an untuned default), and what is the corresponding false-negative rate on cross-file, business-logic vulnerabilities specifically, since that's the category the underlying rule engine was never built to catch. Vendors that lead with the noise-reduction percentage but not the coverage percentage are usually telling you their triage layer is strong without saying anything about their detection ceiling.
How do you tell which type of SAST tool you're actually evaluating?
Ask the vendor one direct question: "if I disabled your AI features entirely, what would the tool still find?" If the answer is "everything, just with more noise," you're looking at an AI-augmented tool; if the answer is "meaningfully less, because the AI is doing the analysis," you're looking at an AI-native one, and neither answer is automatically wrong, but you need to know which one you're buying before you plan your appsec coverage around it. A short checklist that surfaces the same answer faster: check whether the vendor publishes or open-sources its rules file (Opengrep's rules are public, which is itself a signal that Aikido's core detection is rule-driven); read a few changelog entries and see whether new detections are attributed to new rules or to prompt and model changes; ask for a sample finding that is a business-logic or access-control bug with no corresponding CWE pattern, since a native engine should have several and a pure rule engine will have almost none; and ask whether the LLM in the product sees a single file at a time (typically used for explaining or patching an already-found issue) or the broader call graph and repo context (typically used for detection itself). None of this makes AI-augmented tools bad, Opengrep plus AutoTriage plus AutoFix is a genuinely fast, low-noise setup for the vulnerability classes pattern matching already handles well, but it means the coverage ceiling is still set by the rule file underneath it.
How Safeguard Helps
Safeguard is built around the idea that AI-native code reasoning is only half the answer if it isn't grounded in real software-supply-chain context. Our platform correlates static findings with the actual dependency graph, SBOM data, and enriched CVE intelligence pulled from OSS package registries across 17+ ecosystems, so a finding is filtered by reachability, whether the vulnerable code path is actually invoked and whether the affected package version is actually deployed, before it ever reaches a triage step. That matters because the same 95%-style noise-reduction problem shows up on the SCA side too: most container and dependency scanners flag every CVE in a manifest regardless of whether the vulnerable function is ever called, and stacking an AI ranking layer on top of an unreachable-CVE flood just produces a faster way to deprioritize noise instead of removing it. Our offline CLI scanner combines Grype, Trivy, and gitleaks results with a 20+ enricher pipeline for exploitability and reachability signal, and that same vulnerability intelligence is exposed through our MCP server so AI coding agents, Claude Code included, can query real-time package risk and reachability data directly while writing or reviewing code, rather than relying solely on a model's static read of a file in isolation. The result is closer to a third option than a binary choice between "AI reads your code" and "AI ranks your alerts": ground the AI's reasoning in verified supply-chain and reachability data first, then let it do what LLMs are actually good at, explaining the multi-step, cross-file, business-logic bugs that pattern rules were never going to catch in the first place.