Skip to content

How AI Pentesting Works

AI Pentesting runs on Cascade, Escape's multi-agent pentest engine. Cascade pairs Escape's crawling with an autonomous swarm of agents that reason about your application, attack it, and prove what they find. This page walks through an assessment from setup to evidence.

Profile Setup & Scope

AI Pentesting profiles are created from the AI Pentesting page with the New Pentest creation form.

The first section is scope:

  • Standard: Recommended. Escape starts from the listed URLs and can add related discovered assets that belong to the same application footprint.
  • Strict: Contained. Escape only tests the URLs you list. Anything omitted stays out of scope.

You can also add scope restrictions from the form:

  • CRAWL restrictions prevent the agent from visiting a URL or path.
  • API Testing restrictions prevent active security testing against a URL or path. You can restrict by HTTP method (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD, or ANY) to allow testing only specific methods.

These controls map to pentest profile rules. For the deeper blocklist semantics used by the underlying DAST engine, see Scope Configuration.

Before launch, Review configuration starts a validation workflow. It checks that Escape can reach the target, classify the listed URLs, and authenticate each configured user. The assessment can only be launched after that validation passes.

Crawling

Cascade starts every assessment with a crawling phase that builds the map the swarm works from. AI Pentesting uses agentic crawling to explore applications:

  • State-aware exploration
  • Natural language instructions
  • Error recovery
  • Context understanding

Agents use LLM reasoning to navigate web applications and discover endpoints.

Scope & blocklists: what the agent controls, and what it doesn't

Cascade agents honor the assessment's crawling and API testing scope when deciding where to navigate and which endpoints to actively attack. An entry in the api_testing blocklist guarantees that the agent itself will not directly fire requests against a matching endpoint and that the security-check engine will not fuzz it.

It does not, today, act as a network-level proxy. If the page the agent is testing issues its own XHR/fetch calls to a blocklisted endpoint as part of its normal behavior, the browser will still execute those requests, exactly as it would for a real user. They will show up in the assessment logs as captured traffic, but no active security checks will run against them.

To guarantee an endpoint is never contacted during an assessment, including by the application itself, block it at your WAF/gateway for the duration of the assessment.

The Cascade Swarm

After crawling, Cascade takes over. It's not a fixed pipeline of single-purpose agents: it's an orchestrated swarm that adapts to what the crawler found. See Cascade: Multi-Agent Pentest for the full reference.

The swarm has four roles:

  • Orchestrator: plans the engagement, breaks it into tasks, and spawns workers on demand. It decides where to spend effort based on the crawl map, the configured users, and your context.
  • Exploitation: focused, short-lived agents the orchestrator creates for a specific job, for example reconnaissance on an API, exploitation of a suspected injection point, or validation of an access-control boundary. Each runs in a sandbox with a browser, an HTTP client, and classic pentesting tools.
  • Reporter: receives every candidate finding and re-runs it against the live target with its own evidence collection. A candidate that the reporter cannot reproduce is not filed. This independent step is what keeps the false-positive rate low.
  • Coverage: an advisory auditor that tracks which surfaces have been tested and pushes the orchestrator toward gaps so the assessment doesn't over-focus on one area.

Exploitation agents share what they learn through a message bus and a shared knowledge store, so a discovery from one worker (a leaked token, a database-backed parameter, a tenant boundary) informs the rest of the swarm.

Cascade multi-agent pentest engine architecture

What Cascade Tests For

Cascade spins up the right specialists for the surfaces it finds. The classes it covers include:

  • Cross-site scripting: context-aware payloads across HTML, attribute, JavaScript, and DOM contexts.
  • SQL injection: reconnaissance-first testing that prioritizes database-backed endpoints before escalating to confirmed exploitation.
  • Access control: BOLA, IDOR, tenant isolation, and privilege escalation, using the users you configure.
  • Business logic: workflow bypasses, state manipulation, replay, and idempotency flaws.
  • Front-end JavaScript: leaked secrets and undocumented APIs mined from served bundles.
  • SSRF and command injection: server-side request forgery and remote command execution where the surface allows it.

These classes were once handled by separate, single-purpose agents. Cascade now runs them as dynamic capabilities: see Legacy: The Previous Agent System for the mapping.

Cascade uses the users configured in the Authentication section to test authorization boundaries. Each user has a name and natural-language instructions that explain how to sign in and what that account should be able to access. See Authentication for configuration details.

Agents load modular skills scoped per task (vulnerability classes, tooling, frameworks, protocols, and more) rather than running a fixed playbook. See Cascade: Multi-Agent Pentest for the full catalogue.

Assessment Workflow

  1. Discovery: the crawler explores the application and builds the map.
  2. Planning: the orchestrator reasons about structure and behavior, then assigns work.
  3. Testing: workers execute injection attacks, access-control probes, and business-logic tests in parallel.
  4. Validation: the reporter independently reproduces each candidate and collects evidence.
  5. Reporting: confirmed issues are filed with an attack chain, impact, and a Proof of Exploit.

Agent reasoning is visible in assessment logs, showing why agents took specific actions and how they adapted their strategies.

AI Models

A common question from customers is "which LLM does AI Pentesting use?", often with the assumption that everything is powered by a single model like ChatGPT. It isn't. Cascade is a multi-model system: different stages of an assessment, and different agents, are powered by different models chosen for the job at hand.

A Portfolio of Models, not a Single Model

Escape routes work across a portfolio of frontier commercial models and open-weight models hosted on Escape's own infrastructure. No single provider or model powers the product end-to-end. We treat models as interchangeable components and select the best one for each sub-task based on continuous internal benchmarks.

Why Different Models for Different Tasks?

Security testing is not one problem. It's a pipeline of very different cognitive tasks, each with different requirements:

  • Crawling & navigation: Visual and DOM reasoning, tool use, and cost efficiency. Agents click, type, and navigate thousands of pages per assessment. Speed and cost dominate. See Agentic Crawling.
  • Exploit design & payload generation: Creativity, divergent thinking, and broad world knowledge. Finding a new attack path or crafting a novel payload benefits from models that explore the solution space aggressively.
  • Exploit validation & confirmation: Strict, deterministic reasoning, low hallucination, and adherence to evidence. Confirming an exploit worked must be precise. A false positive here becomes a false positive in your Issue queue.
  • Business logic & multi-step planning: Long-context reasoning, planning, and state tracking. Multi-step attacks (BOLA chains, workflow bypasses) require reasoning over long transcripts of requests, responses, and prior agent actions.
  • Evidence summarization & remediation write-ups: Instruction-following, concision, and technical writing. The reproduction steps, cURL commands, and remediation guidance surfaced in a finding are generated from raw evidence.

A model that is excellent at one of these stages is often not the best choice for another. Using a single model everywhere would mean trading off creativity against rigor on every single task.

Model Selection per Role

Cascade composes the stages above across its agent roles with different weightings:

  • The orchestrator leans on long-context planning models to track identities, roles, and multi-step attack plans across a long engagement.
  • Exploitation workers pair creative payload-generation models with reconnaissance-oriented reasoning to prioritize the highest-value surfaces.
  • The reporter uses a strict validation model that only confirms a finding when the evidence is unambiguous.
  • Summarization of reproduction steps and remediation guidance uses instruction-following models tuned for concise technical writing.

The exact routing, including which model is used at which step, with which prompts, tools, and guardrails, is part of Escape's private IP and is what makes the product work. Customers benefit from this routing without having to build it themselves.

Always Evaluating the Newest Models

Frontier models move fast. Escape runs every new major release (GPT, Claude, Gemini, Llama, and others) against an internal security-evaluation harness composed of real-world vulnerability reproduction tasks, benchmark applications, and regression suites. A new model is promoted only when it beats the incumbent on our metrics, not on a public leaderboard. This means:

  • The model mix today is not the model mix six months ago.
  • Improvements in upstream model capabilities translate into better findings, reproductions, and remediations without changes on the customer's side.
  • If a new model regresses on security reasoning, we don't ship it, even if it's cheaper or faster.

Data Handling

Regardless of which model is used, customer data handling is governed by Escape's Privacy & Security policy:

  • No training on customer data. Customer traffic, payloads, findings, and evidence are never used to train third-party models.
  • Zero-retention agreements are in place with commercial model providers where available, so prompts and responses are not retained by the provider.
  • Open-weight models used in sensitive contexts run on Escape-controlled infrastructure, so data never leaves Escape's trust boundary.
  • Organization administrators can disable all AI Pentesting activity at any time via the AI Pentesting Kill Switch.

What about reproducibility?

Because the model mix evolves over time, an AI Pentesting assessment is intentionally not bit-for-bit reproducible. That's a feature, not a bug. It's what lets agents find things that a frozen, signature-based scanner cannot. Determinism where it matters, such as finding identity, reproduction steps, and evidence, is provided by Escape's own engine, not by the underlying LLM.