Your security team is probably already building agents to automate security work, like reviewing PRs, triaging findings, or finding dependencies to upgrade. And on a small scale, they may already be showing promising results.
The trouble starts with the next question: can we run them at scale on every repo?
An agent that works for one engineer on one repo behaves very differently once it runs on every repo and PR in the company, every day, on a budget someone has to defend. Two of our recent studies help explain why. In one, we gave the same model the same security questions twice, once with Endor Labs security context it could look up and once working alone, and measured the tokens, time, and tool calls each run took. In the other, we benchmarked Endor Labs AI SAST against frontier models prompted to find vulnerabilities on their own, and counted the real vulnerabilities each one found and missed.
The short version: handed security context, the same agent did the same security tasks with 12x fewer tokens, in about a third of the time. And a purpose-built security scanner that covers the whole codebase found 2.6x more real vulnerabilities than frontier models working alone.
The security review agent pays to rediscover your codebase
In The Token Economics of AI AppSec Agents, we gave the same model (claude-sonnet-4) the same 34 security prompts across 13 scopes: 12 open source projects in six languages, plus one tenant-wide view. The prompts were the questions an AppSec team asks every day. What's reachable? What should we fix first? Which upgrades can go in one PR? Why is this vulnerable transitive dependency even here?
One agent could look up precomputed security evidence from Endor Labs: findings, reachability from call graphs, upgrade paths, and license risk. The other worked from the repo and the web, the way a homegrown agent usually does.
Working alone, the agent spent 12x the tokens to answer the same questions. The unaided agent averaged about 14 tool calls per question (vs. the agent with evidence needed about 3), almost all of them low-level: 1,985 web searches, 849 greps, 783 manifest reads, 689 directory listings, and 547 file reads across the run. It was rebuilding software composition analysis from scratch, grepping for version strings and walking package.json files. And since an agent re-sends its accumulated context at every reasoning step, every repo dump got paid for again on the next step.
We also looked at how this changed depending on the size of the codebase. Asked the same 34 questions, the unaided agent spent 2.7M tokens on Kotti, a small Python CMS (content management system), and 10.5M on OpenCMS, a large Java one. That's a 4x swing driven by how much code it had to crawl. With Endor Labs evidence, every project landed between 0.33M and 0.61M tokens (a 1.8x swing), because a lookup costs about the same on 10 files or 10,000. Predictable costs matter for planning. If you're forecasting next quarter's AI budget, spend that stays in a narrow band is a lot easier to plan around than spend that swings 4x depending on the repo.
The more expensive failure is when the agent is confidently wrong. We asked both agents for the highest-severity finding in Ghost (a popular open source publishing platform built on Node.js) that's actually reachable at the function level. With call-graph evidence, the agent came back with one medium-severity reachable finding and zero reachable critical or high findings. Without it, the agent spent 22x the tokens (723K vs. 32K, across 45 tool calls and 29 reasoning turns) and confidently reported an Express XSS (CVE-2024-43796) as function-level reachable and High/Critical. Its evidence was that Express is imported all over the codebase. It also cited version 4.22.2, when the project runs 4.18.2. Import presence isn't reachability, and someone on your team would have had to catch that before it became a ticket.
The caveats: this measured cost, not correctness (so treat the Ghost example as illustrative), on one model, and the precomputed evidence takes real work upstream. What it captures is the marginal cost per question, which is what matters once you're running a fleet of agents.
Frontier models miss what they never read
The second problem is coverage. Every file a model reads costs tokens, so when you point one at a whole repo, it only reads part of it. And it can't find a vulnerability in code it never saw.
We measured this in our AI SAST benchmark: 8 public projects with hand-verified ground truth, comparing Endor Labs AI SAST against four traditional SAST tools and two frontier models prompted to find vulnerabilities directly (Claude Opus 4.7 and Codex on GPT-5.5).
The frontier models were accurate about what they flagged: when Claude or Codex reported a vulnerability, it was usually real. But they missed most of what was there, because they only examined part of each codebase. That part shrank as the codebase grew: on a large enterprise Java project, Claude and Codex examined less than 10% of the security-relevant code.
A lot of what they missed was the hard stuff. One example is an insecure direct object reference (IDOR) in Shopizer, an open source ecommerce platform. Its product-image delete endpoint deletes whatever image ID the client sends, without checking that the image belongs to the caller's store. The missing ownership check is split across a controller and a service, so there's no dangerous function call to grep for and no suspicious string to pattern-match. You only find it by following how the request moves through the application.
Endor Labs AI SAST found 192 real vulnerabilities across the benchmark, 2.6x what Claude Opus 4.7 found and 3.5x what Codex found. 63 of them weren't caught by any other tool in the test (the next highest was 18), and it covered 64 of the 106 CWE types in the ground truth, against 36 for the next best.
Endor Labs gets that coverage because it understands how your application actually works. First, Endor Labs builds a code context graph of the whole codebase: which functions call which, how data flows, and where that crosses files and repositories. This is the deterministic foundation. Alongside it, Endor Labs builds a searchable index of every function by what it does (rename getDog() to getCanine() and the index still recognizes the same logic). Then AI agents reason on top of both. They query the graph instead of reading raw files, so inexpensive models can scan every function, a stronger model checks each candidate finding against the actual code, and the deepest reasoning goes to building evidence and a fix for the findings that hold up. The AI SAST whitepaper walks through the full pipeline.
What this means when you're building
In both studies, the models working alone had to figure out the basics on their own: what's in the codebase, what's reachable, how data moves through it. On one repo, the extra token cost might not matter much, but at scale it isn't sustainable.
That doesn't mean your team should stop building. The agent your engineer wired up can know things no vendor does: your triage rules, your fix conventions, which services would ruin your week if they went down. That's worth building and owning. The part that isn't worth rebuilding is the foundation underneath it, the call graphs and reachability data that should be computed once and looked up, not re-derived on every question. That foundation is what Endor Labs builds, so the agents your team writes can look it up instead of reconstructing it.
Our Applied AI Playbook for AppSec goes deeper on where to draw that line. Coverage is the case for buying purpose-built, verified detection. Tokens are the case for building your own skills on top of security context you can look up (Level 3). The playbook walks through all four levels, with a short test for deciding what to build and what to buy at each one.
And if you want to see what these numbers look like for your own repositories and PR volume, you can try out the Agentic Remediation Token ROI Calculator.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help:
