Workflows: Your Fleet Against the Swarm

Exploit complexity used to be a security control. Plenty of serious bugs survived for years because turning them into a working attack took more skill and time than anyone was willing to spend.

PHP2Shell shows how much of that protection is gone. Disclosed on October 21, it is two flaws in the PHP engine that had been sitting in the code for more than a decade. With help from frontier models, they were turned into working exploits and adapted to specific targets in hours. The details leaked early. Cloudflare saw attack traffic aimed at its customers before the official disclosure, and watched attackers change their payloads to get around the protections it had deployed nine hours earlier.

The attack was running before most defenders knew there was anything to defend against.

Attackers already work in parallel

In April we wrote that cheaper offense means more offense. PHP2Shell is what that looks like up close, but the bigger change is in how attacks get carried out.

In July, the OpenAI and Hugging Face incident gave us an early look. The agents involved did not behave like a single attacker. They split up the work, shared what they learned and kept going until one of them found a way in. We wrote at the time that defense has to learn to think in chains, because attackers already do.

A swarm like that does not need to be clever on every attempt. It needs volume, persistence and one path that works. And the number of paths worth trying keeps growing: published CVEs rose 68% from April to July.

Defense needs a fleet

Defense still mostly runs one person at a time. A critical CVE lands. Someone checks whether you run the affected software, someone else works out which repos are exposed, someone tries to confirm it is actually exploitable, and eventually someone writes and ships a fix. Each step waits on the one before it, and all of it waits on people being online.

Hiring helps, but it does not change the shape of the work. Ten more engineers are ten more people working tickets in sequence. Against something that tries every path in parallel, sequence loses.

What defense needs is a fleet: many autonomous agents working at once, each on a scoped piece of the job, starting whenever the work shows up rather than whenever someone is free. Check every repo at the same time. Try the exploit against everything that looks exposed. Write the fix. Check that it holds. People still make the calls that need judgment. The fleet takes the breadth.

Running a fleet is the hard part

None of this is a new idea. The hard part has always been running it.

Running agents at scale is its own engineering problem. They have to start on the right events without anyone pressing a button, fan out across every repo, pass results from one step to the next, stop when they hit a budget, and do it all again tomorrow without someone babysitting them. Almost no security team has the time to build that, and they should not have to.

That is the part we built.

Workflows brings the fleet to your team

Workflows brings that fleet to your team. You describe the job once, in plain English, and Opsec builds the agents and steps behind it, reusing the ones you already have before it creates new ones. From then on it runs by itself whenever the trigger fires: a new pull request, a schedule, a critical CVE.

Here is an order you can give it today:

Workflow prompt

"Create a workflow - when a critical CVE is published for software in our stack, check every repo for exposure, then prove what's exploitable."

A scanner would tell you the CVE exists. This workflow finds out whether you are exposed, tries to exploit what it finds so you only see what is real. Steps run in parallel across your repos, branch on what an earlier step found and hand their results forward. You can add a condition so it only fires on what matters, such as critical findings.

Handing work to agents that run on their own makes security people uneasy, and it should. You see exactly what a workflow will do before you save it, and every run has a spending cap it will not go past.

Built for teams that ship faster than they can review

The teams that need this most are the ones that never had a real security program: companies whose code ships faster than a small security team can review it. In April we argued that AI would bring real security within reach of thousands of companies that could not afford it before. A fleet that runs on its own is a big part of how that happens.

Attackers already have their fleets. Now defenders can have theirs.