Introducing Semgrep Mandoline: Program Analysis Inside the Agent’s Reasoning Loop

Semgrep loves building tools, and for almost 10 years, we’ve been building the best security ones for humans. The next generation of security tools will not be built for humans, but for cyber models and accessed via customized harnesses. This means a toolkit of powerful primitives and static analysis algorithms that let agents rapidly explore gigabytes of code in seconds, in multiple languages, within frameworks and across libraries. 

Today, we’re announcing a research preview of our first security tool designed specifically for agents: Semgrep Mandoline.

Semgrep Mandoline is a decomposed set of tools (unix philosophy!) that agents can use to learn specific facts about the codebase that accelerate security engineering tasks:

• Speed: 50x faster than Semgrep Pro engine in agentic-relevant kinds of analyses

• Interfile-taint language coverage: supports 50 languages and implements state-of-the-art dataflow analysis

• Maturity: passes the majority of the Semgrep Pro and other industry-standard open-source test suites, and gets a perfect score on the OWASP benchmarks.¹ 

• Composability: library-first architecture with native bindings in six popular languages + WASM

We believe it’s the right technology base to build new program analysis tools for agents, and we hope others will join us and share their feedback as we continue to learn how to make the best program analysis tools for agents. We’re calling this the 4th generation of code analysis tools and it stands on the shoulders of the giants before: first generation brought program analysis from academia to enterprises, second generation introduced security into the software engineering pipeline, and third generation made customizability at the organizational level ubiquitous.

Background

In February 2026, I had early access to Mythos and used it to hunt vulns and benchmark existing tools. It was very impressive, but I noticed a recurring pattern from Claude: write incomprehensible regex → read random files with hits → try to make sense of the code structure → dynamic investigation that sometimes produces the vuln → sometimes spends thousands of dollars in tokens with little result → etc., and finally write a working exploit proving the vulnerability.

The fixation on generating a working exploit is how the latest frontier cyber models are able to turn a series of low-severity vulnerabilities into a working exploit. But after running the same prompts over and over again and every time finding a different set of vulnerabilities, it was clear that two things were happening: 

1. I was spending an enormous amount of tokens (thankfully I had tons of free credits), and

2. Every time I ran the model, it was like another pull at the slot machine. 

In the beginning, zero-days fell out every time, but as those got patched, it became rarer. I felt frustrated that I never knew when I was done and some quick mental math showed I would easily bankrupt the company if I tried to run the model even once a day. There had to be a better way to use these models’ advanced reasoning capabilities, and I believe there is: building powerful tools for the models to reach for. 

Our customers were starting to run Mythos as part of Project Glasswing, and as we listened to them, a few common themes emerged:

1. Static analysis was still very useful and was finding critical bugs the models missed.

2. The harness mattered a lot and several of our customers have built and open sourced their harness and often integrated tools such as Semgrep Community Edition, joern, sourcegraph, and/or tree-sitter.

3. An agent needs something that is verifiable to gain “purchase” and not go off the rails. For code this is easy: the compiler, typechecker, linter, tests, and Semgrep Guardian will report warnings and errors, and the model can reason over these errors and then produce better results. 

4. Most of the pure LLM findings have a very low developer fix-rate (0.5% of initial Glasswing findings were actually fixed)

By the summer, a new hybrid architecture of model + harness + context data + deterministic tooling emerged, both at Semgrep and among our customers.

Introducing Semgrep Mandoline

Mandoline (noun): a code analysis tool for slicing code into the parts that matter for agents.

Slicing code sounds easy: start at one line and work your way down. Or you can slice up, starting with a variable and asking, “What parts of the code influence it?” But a line as short as user.save() could run any of a dozen methods depending on your architecture. Frameworks quietly call functions for you, so much so that core functionality like route handlers may appear to have no callers at all. A value can be renamed, stored on an object, saved to a database, read back in a different request, and printed through a template written in another language entirely.

Getting slicing right means parsing every language, resolving every call, and following data across files, frameworks, and requests, all in milliseconds as the agent reasons. With that in mind, when we were developing this next generation of static analysis, we had these requirements:

1. Support all the languages Semgrep does

2. Surface facts about code, not vulnerability findings

3. Be correct and offer code as evidence for further reasoning

4. Fast!

5. Composable

Beyond program slicing, we actually do API endpoint detection, and we’ve found that the combination of figuring out where attackers are able to enter the application and then following the dataflow into the program has been one of our most effective techniques to date.

Language coverage

We’ve worked hard to expand on Semgrep’s already industry-leading language coverage. Mandoline supports 50 languages with full interfile and deep analysis support spanning everything from Fortran and COBOL to Scala, Rust, Swift, Kotlin, Typescript, Java, C++, and ancillary languages such as Terraform, Docker, Ansible, and even multiple popular dialects of SQL. But modern software is rarely written in just raw languages, and Mandoline reflects that with support for frameworks, templating engines, and routing models within ecosystems. All of this was built on the strong foundation of tree-sitter and using Semgrep’s extensive test suite as a correctness oracle.

Code facts, not findings

Because Mandoline runs in the hybrid architecture, it gets to cheat. We don’t have to surface ultra-high-quality findings that won’t annoy developers. Instead, Mandoline’s job is to pull reliable answers to questions the model is asking about the callgraph, the dataflow tree, the taint paths, the exposed surface area, dependency reachability, etc. If we’re not able to decide, we can be conservative and rely on the LLM to go make a final decision. When we do this, we give the model the evidence for our answers and what limitations our analysis might have had. For example, we tell the model if we have full type resolution when building the graph edge. Rice’s Theorem still says we can’t be perfectly sound and complete at the same time for most properties; our bias in Mandoline is towards recall.²

Correctness

Models will quickly realize if the tool they are using is wrong and stop using it. Just as a human wouldn’t use a broken tool, neither would LLMs. We have built full test suites for a range of our languages and frameworks, including Python, Go, and JavaScript, and we’re constantly making improvements and fixing bugs. But as we know from our benchmarking, the best tests are external: Mandoline passes 36,000+ C++ and Java tests from the NIST Juliet test suite, spanning 22 vulnerability categories. Mandoline scores 100% on the OWASP Benchmark for Java and 98.28% for Python, which we used as a way to harden the taint analysis engine. Mandoline passes ~90% on the PySA and Mariana Trench test suites from Meta and the similarly on CodeQL taint test suite. Not bad for a research engine! 

We’ve relied on property-based testing and formal verification (Verus and Kani) to verify certain aspects of the analysis kernels where we can go from textbook definition → formal spec → production code. Here are some smaller examples:

• The lattice join of two values sits above both inputs, so merging taint facts never drops either input.

• Converting a byte offset to a line and column and back returns the original position.

• A distributed IR dataflow session accepts the messages in its phase order and can always close.

Performance

Semgrep has a reputation for being fast, but while 5 mins/scan might be fast in CI, it's not fast for an agent. One of the motivating factors was that we talked with our friends at the frontier labs and learned that anything we could do to improve the runtime would be useful for running inside an RL training loop; perhaps that’s less true these days with async GRPO, but still, who wants to wait for an agent to call a tool that takes minutes? Let’s be the ripgrep for code analysis!³

We’ve focused heavily on performance from day one and have a three-layer cache design to avoid as much rework as possible. As a quick anecdote, we ran the default semgrep rules over a few dozen repos and we’re reliably seeing performance gains of 15-50x and repeat runs are almost instant – perfect for agents.

Composable and remixable

In addition to ripgrep, we took inspiration from @mitchellh’s exceptional ghostty and libghostty and decided to build it as a library from the beginning. Using UniFFI, Mandoline has first-class bindings for six languages. Data types are defined in protobuf, and you have your choice of CLI, MCP, gRPC interfaces with a variety of output formats. 

Cloudflare published an insightful post on using code with MCP and letting the model do what it’s great at: writing code. We’ve been experimenting with different ways of letting the model write code against the internal APIs when given typescript definitions.

Mandoline is multi-platform and multi-architecture and runs on Mac, Linux, Windows, and WASM, which unlocks use in agent containers, edge compute, and the browser / IDE.

Observability

One cool superpower we get from having a tool in the agent flow is it’s easy to record which parts of the code graph we’ve explored. One research question we’ve been pondering is, “how do you know when a codebase has been totally explored by LLMs?” We think the answer probably involves recording which paths are still unexplored from prior runs and telling Mythos, Daybreak, GLM, etc. to go hunt those paths.

Finding Vulnerabilities with Mandoline

While developing Mandoline, we’ve discovered many critical vulns in our customers’ code. Although our primary focus is private customer code, we have a backlog of CVEs to publish: in a sweep of 30 trending GitHub open source projects, we found 103 findings and generated a working exploit using Mandoline + Mythos, and some are already released like Redash vulnerabilities CVE-2026-77371 and CVE-2026-42093. Stay tuned!

How Do I Get Access To Mandoline?

Good news: Semgrep customers already have access to Mandoline inside Semgrep Agentic Workflows and within Semgrep’s Context Layer. Those workflows combine program analysis with frontier models to investigate vulnerabilities. Read how Agentic Workflows with Context works.

If you are developing a security harness, evaluating agents against your code, or struggling with the cost of repeated investigations, we would like to work with you. Our research preview is an opportunity to test this architecture against those problems. Bring us the framework the tools struggle to understand, the monorepo that exhausts the budget, or the investigation where the agent finds three good bugs and leaves you wondering what it missed. If you are currently using Semgrep Community Edition in your agents, we are especially interested in connecting.

Our vision is that Semgrep Mandoline underpins the platform that security engineers can use to take LLMs from vulnerability slot machines to verification engines for systemic security properties. We’re pretty excited about it and we'd love to collaborate with you! drew@semgrep.com 

^{1 This was a fun result (and it's very dollar-efficient to get that score compared to models), but we want to insist that based on what we see with customers, OWASP benchmark results have very little correlation to performance on private real-world codebases.}

^{2 Who knows, maybe one of the AI labs will have announced the halting problem is solved in Lean by the time you’re reading this ;)}

 ^{3 We’re grateful to be using a lot of the libraries BurntSushi made 🙏}