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 six stages

The assessment page shows which of these stages the run is in.

1. Signing in. Before an agent starts, AISafe checks the target configuration and installs a deny-by-default network policy. The sandbox can reach only your targets, the hosts under your verified domains and the extra hosts you allowed. Every test user you saved then signs in once. If a sign-in fails for a reason only you can fix, such as a rejected password or a CAPTCHA, the assessment stops before it tests anything and its credits are refunded. See Test users and login instructions.

2. Mapping the application. Probe agents exercise each target in bounded batches, signed out and as each test user. They record observed HTTP exchanges, group them into operations, and record the application's entities, roles and data flows, and who may read or change what. 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.

   A response that matches the target's recorded fallback or not-found page does not establish an operation. Static browser resources remain recon evidence for reading scripts and analyzing DOM behavior. They do not receive operation checklists. Paths that differ only in generated identifiers are grouped into one operation, including generated filenames. A route mentioned by a page or script is explored before it becomes an observed operation. Unsupported methods, sign-in challenges and error responses remain discovery leads until a successful or redirect response establishes a handler.

   Browser visits also record HTML page routes, including client-side paths such as /#/search, separately from the server operation that served the page. The route keeps URL query field names and links to backend requests observed while the page was open. Query values are not copied into the route list.

3. Modelling threats. Agents record the threats the mapped application faces and plan which operations to test for which vulnerability classes. The plan becomes a checklist of specific security questions that testing must answer.

4. Testing. Each checklist item is tested by one agent, and AISafe checks every result against the captured traffic without a model. A completed test cites the traffic it is based on, so every result in the report points to requests that were actually sent to your target. Agents also look for attacks that chain several steps together.

5. Triage. A separate agent examines each proven candidate and either promotes or rejects it. AISafe keeps distinct runtime issues separate, and it copies the confirmed evidence into the finding that you see.

6. Report. The final stage compiles the confirmed findings, their evidence, the tests that were run, and remediation guidance.

You start the pentest, and AISafe runs the tests and prepares the results. If an AISafe execution problem interrupts one part of the work, AISafe retries that part. If it still cannot finish, the assessment stays running while the AISafe team fixes the problem, and the work then continues from where it stopped; no stage is skipped. Completed tests and findings are kept. The report discloses incomplete testing and any finding publications that could not be prepared. An automated check that cannot be judged because of an execution problem is recorded as inconclusive and the assessment continues. Inconclusive target responses also remain part of the results.

Exploration revisits new routes and security questions until no new work remains or the assessment uses its approved time or spend budget. Larger operation lists and sets of proven candidates are processed in batches; batch size does not cap how much work the assessment can consider.

When discovery checks which HTTP methods a path supports, it sends only GET, HEAD and OPTIONS. It learns POST, PUT, PATCH and DELETE from captured traffic and the server's method headers, without replaying those methods against existing records. Destructive tests must use disposable data created by the assessment.

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. Traffic and finding evidence keep the real request and response values, including cookies, authorization headers, custom tokens and test-user login bodies. Older captures may still show redaction markers for values that were not retained. Reports and exports preserve the finding's values so that you can reproduce it. Both surfaces refresh every few seconds while the run is live, so the count climbs as the agents work.

Captured requests remain available if the assessment pauses or fails. If an update temporarily fails, the page keeps the last available requests and count while it retries. A notice identifies delayed updates or any request that could not be displayed.

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. A request to your target that got no answer, for example because the connection was refused, is part of the list and its count, and it shows as having no response.

If the target stops answering after testing starts, affected checks can be inconclusive. Keep the target available for the duration of the assessment. An interruption on AISafe's side affects only that unit of work; the rest of the assessment continues.

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 find more than 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.