Skip to main content

How it works

A pentest is a multi-agent workflow. Specialized agents carry out each stage over your live target. Each stage builds on the captured HTTP traffic from the stage before it.

The five stages​

  1. Validation and scope. AISafe checks the target configuration and installs a deny-by-default network policy before an agent starts. The sandbox can reach only the exact target origins and extra hosts you allowed.

  2. Reconnaissance. Probe agents exercise each target in bounded batches. They record observed HTTP exchanges, group them into operations, and list the specific security questions that testing must answer. Operations are per target: two hosts running the same application are tested separately and reported separately, so an issue present on both is reported against both. The probes respect your excluded paths and rate limits.

  3. Testing and coverage. One audit assignment tests each security question. Every assignment ends as covered or uncovered. A covered test cites captured traffic; an unreachable or incomplete test remains uncovered instead of being reported as clean.

  4. Triage. A separate agent examines each proven candidate and either promotes or rejects it. AISafe keeps distinct runtime issues separate and projects confirmed evidence into the customer finding.

  5. Report. The final stage checks that every planned test has a terminal result, then compiles confirmed findings, evidence, uncovered tests, and remediation guidance.

The whole workflow runs without human intervention. You start the pentest, the agents do the work, and you review the results when they are ready.

Watching a live run​

Every request an agent sends passes through a capture proxy, and you can read it while the run is still going.

The assessment page shows a running count of captured requests and the most recent one. Open Traffic from the tools list to see the full list: method, URL, status, timing, and the headers and body of both sides of each exchange. Both surfaces refresh every few seconds while the run is live, so the count climbs as the agents work.

The list shows the requests made against your target. If an agent — or the browser an agent drives — attempts a host outside the engagement's scope, the proxy refuses it; those refused attempts are kept out of the default list and out of its count, and you can list them with the Blocked filter if you want to audit what was turned away.

Traffic appears only for services that send HTTP. A code audit reads source and makes no requests, so it has no Traffic view.

Why agents beat scanners​

The agents reason about the application's behavior, adapt their approach based on responses, and pursue exploitation paths a traditional scanner would not attempt. They find vulnerabilities that require multiple steps or understanding of the application's specific logic.

Before you start​

Configure your target before running: target URLs, optional authentication, custom headers, rate limits, and excluded paths. See Prepare your target.