Write the Guidance
Give the agents the context of an application: attack surface, priorities, strategy and prohibited techniques, evidence requirements and stop conditions, OpenAPI or Postman documents and test accounts.
The Guidance is the reusable context of a target. Every pentest starts from its active version; a good Guidance gives better-targeted tests and more useful findings.
Prerequisites#
- The target's domain is verified: the Guidance stays locked until then.
- Your role allows editing the target (administrator or member).
The fields#
| Section | Fields | What they expect |
|---|---|---|
| Attack surface | Surface context, Out-of-scope elements | The parts of the application and APIs that matter (authentication, role-based areas, uploads, integrations, webhooks), and what must be left alone. |
| Priorities | Priority objectives, Business context | What you want tested first and what has the most impact for you (customer data, payment, administration). |
| Attack strategy | Vulnerability classes, Test instructions, Prohibited techniques | The families to look for (access control, injection, business logic…), useful instructions, and what the agents must not do (denial of service, data deletion, sending real messages or payments, accessing third-party services outside the scope). |
| Validation | Evidence requirements, Stop conditions | What counts as a demonstrated weakness in your context, and the situations where the test must stop. |
Starter templates (SaaS, e-commerce, API, public website) prefill these fields; adapt them. No field may stay empty or contain only spaces.
API documents#
Attach your OpenAPI, Swagger or Postman descriptions and choose which ones to include in the next Guidance version. They are private, canonicalised on import and versioned with the Guidance. They help the agents cover the APIs; they can never widen the verified URLs: a path that points outside the authorised scope is ignored.
Deleting a document does not change Guidance versions already published.
Test accounts#
If the application requires authentication, provide, when preparing the pentest, dedicated test accounts with the roles you want exercised. They are encrypted at rest, materialised just before the run, redacted from the evidence and purged afterwards.
Scheduled (recurring) pentests receive no test accounts.
Exclusions and guardrails#
The Guidance's "out-of-scope elements", the target's explicit exclusions and the excluded paths in a pentest's guardrails are instructions given to the agents; they are not a network policy. For a strictly bounded scope, the external pentest stays limited to the authorised URLs and the internal scan to the mandate. See also During the test.
Publishing#
Publish the Guidance to make it active. Published versions are kept; a pentest already launched keeps the version it started with. A scheduled pentest pauses if the Guidance goes missing.
Tips#
- Describe the roles and what each one must or must not be able to do: that is the raw material of access control findings.
- Name the high-impact flows (payment, data export, administration).
- State the environment: an isolated staging environment avoids side effects on your real data.