Introducing Cascade 2 Iguazu: multi-agent AI pentesting you can audit
Introducing Cascade Iguazu: version 2 of our pentesting engine Cascade. Now with a scheduler-driven multi-agent architecture ensuring consistent, repeatable runs, much wider coverage, and a fully readable trail of what happened.
AI pentesting has a trust problem. Two runs on the same app come back with two different reports. A finding lands in your queue with a severity, a payload, and no explanation of how the agent got there. And when an auditor or a developer asks "why should I believe this?", you're the one reverse-engineering the agent's thinking.
That doesn't scale. Your team is already covering more engineering orgs every quarter without the headcount to match. The last thing you need is a pentester you have to babysit.
Today we're releasing Cascade Iguazu. We rebuilt Escape's AI Pentesting around a new multi-agent architecture so it explores more of your app, discovers more critical vulnerabilities, and shows its work on every decision it makes.
Here's what's new:
- A scheduler-driven multi-agent architecture: consistent, repeatable runs instead of agents improvising their way through your app
- Continuous coverage tracking: a continuously updated coverage map that helps the scheduler identify what hasn't been tested yet.
- Reasoning logs: a full, readable trail of why Cascade did what it did
Results on our internal benchmark, V1 vs V2:
1. A new multi-agent architecture: the scheduler calls the shots
Most autonomous pentesters are built one of two ways. Either a fixed pool of specialists (e.g. one for XSS, one for SQLi) treats every surface as equally important, or a single agent recursively spawns subagents that chase the first promising lead and burn their budget before half your app is touched. The run looks like a pentest, but the coverage isn’t there.
It isn’t consistent either. Run most AI pentesters twice on the same app and you get two different reports. A finding shows up on Monday and disappears on Tuesday, with no code change in between. Was it fixed? Was it a false positive? Or did the agent just not look there this time? When results move on their own, you can’t use them to confirm a fix, catch a regression, or show an auditor that a surface was covered. The cause is simple: agents decide for themselves where to go and when to stop, so every run takes a different path through your app.
Iguazu puts a scheduler in charge. Using a continuously updated coverage map, it decides which discovered surfaces need more testing, which agent works on each one, and when a surface has been sufficiently tested. Agents no longer decide on their own when to stop. They report back, and the scheduler decides what happens next. Same app, same plan: when a finding appears or disappears between two runs, it’s far more likely to be because your app changed than because an agent wandered somewhere else.
Under the hood. We model an engagement as an explore/exploit search problem. The scheduler protects breadth while authorizing depth. It spawns specialized agents only where a surface warrants it, with explicit limits on how deep delegation can go. Surfaces now carry block and unblock conditions, so a surface closed too early gets reopened when new context arrives instead of being silently abandoned. LLMs will never be perfectly deterministic, but the plan they execute now is.
What you get:
- Results you can compare. Run-to-run differences point to changes in your app, so a finding that disappears can actually confirm a fix.
- No more premature closure. Surfaces only close with a recorded reason, and they reopen when there's more to test.
- Effort where it matters. Depth goes to the surfaces that warrant it, not to whatever the agent saw first.
2. Coverage tracking: knowing what you haven't tested yet
The most common reason AI pentests underperform is simple: they don't look everywhere. An agent busy exploiting one promising endpoint can easily overlook dozens of other routes. You can't find a BOLA vulnerability on an endpoint nobody visited.
Iguazu addresses this with a continuously updated coverage map that gives the scheduler visibility into the attack surface throughout the engagement.
Rather than treating reconnaissance as a one-time phase, Iguazu continuously tracks what's been discovered, what's already been tested, and what still needs attention. The scheduler uses that information to guide subsequent testing decisions. As agents explore the application and uncover new surfaces, those discoveries inform subsequent testing decisions.
Under the hood. The coverage map serves as a shared view of the engagement. It combines discovered attack surfaces with their testing status and execution outcomes. The scheduler uses that information to assign work, revisit blocked surfaces when new context becomes available, and avoid prematurely closing unexplored areas.
What you get:
- 5.3× more coverage on API surfaces, and 3.4× more coverage on application pages and states . With Iguazu, more of your app is actually explored, not just touched.
- ~10× more worked attack scenarios. More mapped attack surface means far more attack paths actually attempted.
- Every file in white-box. A deterministic file listing means nothing in your codebase gets skipped.
3. Reasoning logs: see why, not just what
A finding without an explanation is a finding someone has to re-investigate. Developers push back, auditors ask for evidence, and your team ends up redoing the agent's work just to defend it.
Reasoning logs make every Cascade decision readable. For each finding, you see how the agent discovered the attack surface, what it tried, what it observed, and how the reviewer reached its verdict. For each surface, you see why it was closed: fully tested, blocked, or waiting on information Cascade didn’t have.
Under the hood. Because the scheduler owns the plan, every hand-off between agents is a recorded event, not a hidden step inside one long prompt. Every agent records its verdict alongside the specific business context it relied on, so a dismissed finding comes with the reason it was dismissed and nothing is filtered out silently.
What you get:
- Findings developers trust. The reproduction path is right there, so the fix starts sooner.
- An audit trail by default. Show stakeholders exactly what was tested and why each result stands.
- Control over the filter. If Cascade dismissed something you care about, you can see why and reopen it.
A pentester you don't have to babysit
The three pillars reinforce each other. The scheduler keeps runs consistent. The coverage map helps the scheduler ensure all surfaces are explored. Reasoning logs let you check every step. The result is AI pentesting that behaves like a continuous program inside your engineering process, not a black box where you rerun and hope.
Cascade Iguazu has been live for all Escape AI Pentesting customers since October 26.
Want to see it against an environment that looks like yours, white-box or black-box? Book a demo.
PS: Why “Iguazu”?
Our engine is called Cascade, so our awesome marketing team thought this second version had to be named after the most serious cascade on the planet. Iguazu Falls, on the border between Argentina and Brazil, isn’t one waterfall. It’s about 275 of them, spread over 2.7 km, all fed by the same river. The name comes from the Guarani for “big water”, and when Eleanor Roosevelt first saw it, she reportedly said: “Poor Niagara!”
That’s roughly what Iguazu does to your app: one plan, many agents, and every surface gets its share of the water. The biggest drop is called the Devil’s Throat. We like to think that’s where the business-logic bugs end up.