Security Review Agents: 12x Fewer Tokens, 2.6x More Findings

Scaling AI agents for security automation faces two primary challenges: economic sustainability and comprehensive coverage. When an agent is provided external, precomputed security context—such as call graphs, reachability data, and findings from a specialized scanner like Endor Labs—it demonstrates significant efficiency gains. Specifically, tasks requiring daily security reviews use dramatically fewer tokens and less time compared to unaided agents that must reconstruct foundational knowledge by crawling repos and performing extensive web searches. Furthermore, purpose-built scanners showed superior vulnerability detection rates against frontier models operating alone.
However, relying solely on large language models (LLMs) without this structured context introduces risks. Unaided agents incur unpredictable cost spikes correlated with codebase size, and they frequently misidentify low-confidence issues as high-severity threats due to insufficient data linkage. Regarding coverage, LLMs limited by input token windows tend to examine only small subsets of large codebases, leading them to miss complex vulnerabilities that require tracing data flow across application components—a task best performed by systems with full codebase context graphs.
This suggests a strategic division of labor: core infrastructure knowledge (like dependency maps and reachability) should be computed once and indexed for lookup, allowing generative AI agents to focus their reasoning power on high-level decision-making, triage, and remediation advice based on that verified foundation.

Security teams are building agents to automate tasks like reviewing PRs, triaging findings, and finding dependencies to upgrade.
Studies compared models using Endor Labs security context versus those operating alone.
When provided context, the same agent used 12x fewer tokens for identical security tasks and took about one-third the time.
A purpose-built security scanner found 2.6x more real vulnerabilities than frontier models working alone in a benchmark of 8 public projects.
In a test using Claude-sonnet-4, an unaided agent spent up to 10.5M tokens on OpenCMS (a large Java CMS) versus between 0.33M and 0.61M with evidence.
The unaided agent performed approximately 1,985 web searches across one instance of the test for Kotti.
Without call-graph evidence in a Ghost vulnerability check, an agent spent 22x more tokens and reported a High/Critical Express XSS as reachable when it was not at the function level.
Frontier models examined less than 10% of the security-relevant code in a large enterprise Java project during the AI SAST benchmark.
Endor Labs AI SAST found 192 real vulnerabilities across the benchmark, compared to 2.6x and 3.5x for Claude Opus 4.7 and Codex respectively.

The central tension explored here is the trade-off between generative capability (the "thinking" of LLMs) and foundational completeness (the structured knowledge required to think accurately at scale). The narrative strongly implies that when operating in a highly specialized, data-intensive domain like AppSec, generalist LLM reasoning must be outsourced its prerequisites—namely, complete code understanding and verified system state. This frames the debate not as "AI vs. Manual Process," but rather "LLM on Top of Indexed Reality vs. LLM Alone."
The underlying assumption being leveraged is that tokens represent a measurable cost barrier to scale, which is undeniably true when an agent repeatedly re-derives what a graph database could provide instantly. The pattern leans heavily into VENDOR ADVERTORIAL: the precise quantitative results (12x fewer tokens, 2.6x more findings) are presented as objective proof of superiority for one product line's integrated methodology. This functions to persuade stakeholders that building bespoke tooling is inefficient when a comprehensive, indexed foundation exists to feed their existing custom logic.
The true cognitive sovereignty challenge here lies in differentiating between *syntactic possibility* (what the LLM can invent based on imported context) and *semantic reality* (what actually executes in the codebase). The Ghost example illustrates this perfectly: superficial syntactic presence (import statements) was mistaken for semantic reality (reachability). If organizations treat token cost reduction as the primary metric, they risk accepting functional efficiency while unknowingly outsourcing their deepest security assumptions to a proprietary black box.
What organizational strategies can bridge the gap between leveraging LLM creativity and demanding deterministic foundations? Where is the tipping point where an engineering team's irreplaceable institutional knowledge (e.g., specific internal triage rules) must reside within its own system versus being served via context lookup? How do we quantify the cost of "confident error" when that error stems from missing foundational data, rather than model hallucination on a query?
Autonomy check: No autonomy signals.