The Real North Star Was Never "Shift Left"

Almost every conversation I have with enterprise security teams starts in the same place: their security testing programs can't keep up with their AI-enabled developers. And when I ask what they actually want, nobody says, "I want to shift farther left." They say: I want someone who already knows my environment, who catches problems before I have to file a ticket, who doesn't need to be told what matters.

That's not a tool request. That's a description of an expert.

The whole "shift left" mandate was a workaround for something the industry couldn't actually solve: you can't put a dedicated offensive security expert on every engineering team. So instead, you put a tool at every stage of the SDLC and hoped the aggregate coverage would approximate what that expert would do.  In this post, I’ll make the case that how we’ve shifted offensive security left was more of a treatment than a cure. There’s a better way to think about AppSec entirely.

‍

‍The AppSec Stack: A Graveyard of Good Intentions

A SAST tool for source code. SCA for dependencies. A container scanner. An API security tool. A DAST tool for the running app. A pentest once a year to find what all of them missed. A vulnerability management platform to aggregate the noise.

None of it was planned. Every time a new attack surface appeared, a new tool appeared to scan it. Enterprises ended up with fifteen products that don't talk to each other, a team to manage them, and the same painful, annual pentest.

Even when those tools detect something real, a security expert still has to triage the output, validate the finding, and figure out where to deploy remediation resources. At scale. Now at the speed of vibe coders. The stack doesn't eliminate the expert dependency. It just creates more work for the experts you don't have enough of.

In 2026, 84% of developers use AI tools that now write 41% of all code. It's estimated that the pre-existing (and already unsustainable) security-to-developer ratio was 1:50 to 1:200. A 2026 Microsoft field study found developers using agentic coding tools now merge 24% more pull requests. So, the effective ratio for security reviewers has blown out to something closer to 1:62 to 1:248. Without anyone hiring a single new developer.

Some of the most consistent feedback I hear is that security leaders don't want to adopt another tool because it means surfacing more findings they don't have the resources to fix. Are we treating a resource symptom when the real diagnosis is structural?

‍

The Question Nobody Was Asking

Think about what you'd actually request of a dedicated offensive security expert embedded on your team. Not "run a scan." You'd say: review this PR. Look at what we shipped last sprint. Tell me if this API endpoint is exploitable. Help me understand which of these scanner findings actually matters. And do all of it with memory of what you already know about our environment, without me having to brief you every time.

You wouldn't even have to ask. Ideally, they'd already be looking.

That's not a phase-gate model. It's a relationship. The closer you look at everything the AppSec stack was trying to build, the more you realize it was always trying to replicate that relationship. It just couldn't. No single thing could do what that expert does, the way they do it, continuously, across your entire application.

Until an agent could.

‍

The Mistake Most Vendors Are Making Right Now

New foundation model releases aren't incremental improvements. They change what's possible in offensive security: the depth of reasoning, the sophistication of chaining, the speed of coverage. With every major release, the attack surface your adversaries can probe gets wider, and the techniques they can apply get sharper.

The vendors who lose in the next three years will be the ones who wrapped new models onto old infrastructure. Applied the latest capabilities to source code review here and runtime testing there. Kept the phase-gate model and just swapped in AI at each gate. That's still fifteen tools, just with better brains. The structural problem doesn't go away…

And neither does the visibility problem. Security leaders I talk to aren't just asking where the bugs are. They're asking what was actually tested. When they present findings to the board or a regulator, they need to answer two questions, not one: what did we find, and what do we know we looked at? A phase-gate model built on discrete tools can't answer the second question cleanly. Every tool has its own scope, its own logic for what it covers, its own definition of "done." The aggregate is a patchwork, not a picture.

The organizations that win are the ones who stop asking "which phase needs AI?" and start asking “what do I need to know, and when do I need to know it?" The answer to that question has to include the full scope of what was tested, not just a list of what was found.

‍

Rethink AppSec

Sybil isn't modeled after a single pentester. The architecture is modeled after how the most effective offensive security operations actually work: nation-state-level teams running complex campaigns against hardened targets. The way those teams operate is hierarchical. Specialists and generalists. People executing and people watching over. That structure is what lets them move fast and think deeply at the same time.

Sybil is built that way. A hierarchy of agents, each reasoning at a different resolution: some mapping attack surface, some executing hypothesis-driven tests, some watching over the campaign and deciding what matters next. What reaches you is confirmed and reproducible.

You can point Sybil at something specific: a new auth flow, a particular section of source code, a VDP finding that needs validation before anyone prioritizes it, or to complete a compliance pentest requirement. You can also run Sybil continuously to monitor your attack surface, self-direct testing, prioritize findings, and surface AI-ready remediation guidance integrated with your coding tools.

The security expert your team always needed wasn't a headcount problem. It was a technology problem.

Rethink AppSec. RunSybil.