Skip to main content

The Ceiling for DIY Security Reviews

· 5 min read

Every security team is now running the same debate: build your own AI security review, or buy one. You drop a coding agent into CI, it finds real issues, rerun the same PR and you get different findings, different severities, no memory of last triage, no audit trail for AppSec. Get a better model and you get sharper findings but it won't close the gap. The real question isn't whether an LLM can find issues. It's whether you back yourself to build a great harness. That takes eval infrastructure, state, and the kind of engineering Cloudflare, Rogo, and Anthropic are writing blog posts about. Most teams don't have it. That is the ceiling.

The AI Review Ceiling

/security-review is the ceiling for build-it-yourself AI security review. Anything beyond it costs 2-3x more and makes results worse, unless you fund a real eval infrastructure team.

The path looks like this. First, a richer prompt. Then a skill that runs the prompt with scaffolding. Then sub-agents. Severity first, then reachability, then exploitability, then business context, then whatever your CISO asked for this week. Each step costs more tokens and more engineering time than the last, and the bill compounds. By the third sub-agent, every PR is firing multiple frontier-model calls. Finance starts asking questions.

Evals are the first thing that breaks. The first time you write a sub-agent to do severity scoring, you hand-check ten findings and feel good about it. The second time, after a model update, calibration drifts and you find out from a developer. By stage three, every sub-agent needs its own eval suite, plus regression tests you run daily as the harness behavior changes underneath you.

State is the next problem. PR comments are not an audit trail. They get resolved, dismissed, ignored, or buried under a force-push. Six months later when somebody asks whether that IDOR finding from May was triaged, nobody knows. The system has no memory of what it found, what was acknowledged, what was fixed, and what was suppressed. Every scan starts from zero. Findings repeat. Developers learn to dismiss them faster.

Comparison of DIY security review approaches: simple prompt, security review prompt, skill-based workflow, and agents-based workflow. All four can find issues, but triage severity and reachability require evals, and none provide an audit trail or context and memory. Token cost and engineering effort escalate from left to right.

Subdividing the problem becomes the right way forward. A good harness breaks the problem into thousands of small questions and answers them one at a time. Tens of thousands of (preferably) cheap, narrow LLM calls per scan, each one walking around a specific finding to confirm it, calibrate severity, check reachability, and decide whether the audit trail should record it. One hero prompt with a frontier model against a PR is the wrong approach.

This is the part of the work that takes years. Cloudflare's Project Glasswing pointed Mythos and other security-focused models at their live code, and the conclusion they shared publicly was that significant work around the models is needed before any of it can scale.

Rogo built Sisyphus, an autonomous agent that runs continuous offensive testing against their own infrastructure. They raised $160M Series D this year. The section in their post called "what we got wrong" is the most honest part.

And this month, Anthropic shipped Claude Security in public beta to Enterprises. It is the product version of /security-review, with validation, patch suggestions, audit export, scheduled scans, and dismissals that carry forward across runs.

All three are serious efforts by well-resourced teams. None of them is something a six-person engineering team can stand up between sprints.

So when we say years of engineering work, we mean the kind of years where a CISO writes a blog post, a Series D company names the project Sisyphus, and Anthropic ships a separate product alongside the slash command.

The question is which side of the ceiling you need to be on. For most teams, the answer is above it. Below the ceiling, what you have is a hackathon artifact. It finds real issues. It catches things developers miss. The findings make for a good Slack screenshot. AppSec cannot defend any of it in a SOC 2 audit.

If consistent severity calibration matters. If reachability needs to gate merges. If AppSec needs an audit trail. If memory needs to improve the scan over time. Then you are looking at the artifact above the ceiling. Build it or buy it. Either way, most of the cost is evals and state.

Make the call before you spend another quarter on it.


Written by Patrick Collins.