Quickstart: your first assessment

Why your first run should be discovery

It is tempting to immediately ask the agent to "find all the vulnerabilities" — but on a brand-new scope, the agent has no idea which assets matter, which workflows are sensitive, or where authentication boundaries live. The result is broad and shallow.

A discovery run is the opposite. It maps what is reachable, which technologies are in use, which endpoints look interesting, and which surfaces should get authenticated or code-aware testing later. Once that map exists, your team can add context and the next run becomes precise.

Before you begin

• Decide on a target environment you are authorized to test (you, your company, or a customer who has signed off in writing).
• For a public target, have access to the DNS records or web root so you can complete verification.
• For an internal target, plan to deploy a private runner on a host inside that network — see the Runners guide.
• Skim the Scopes guide so the rules of engagement section is not new vocabulary.

Step 1 — Create a scope

Open Scopes in the app and create a new scope. Name it after the environment, not the project — "Marketing site (prod)" or "Customer API (staging)" reads clearly months later when you are looking back at findings.

1. 1Open Scopes.
2. 2Click New scope.
3. 3Name the scope after the environment it represents.
4. 4Add a short description that captures why it exists.
5. 5Save the scope.

Step 2 — Authorize a target

A scope without a target cannot do anything. Add one public domain, host, or — for internal work — a CIDR range. Public targets need DNS or HTTP verification before active testing; the app walks you through it.

1. 1Open the scope.
2. 2Add the target (for example app.example.com, api.example.com, or 10.0.0.0/24).
3. 3For a public domain, complete DNS or HTTP verification.
4. 4For an internal CIDR, deploy and attach a private runner before continuing.

Step 3 — Set rules of engagement

Rules of engagement tell the agent how to behave: rate limits, testing windows, what is off limits, what techniques to avoid, who to escalate to if something serious appears. A few minutes here saves you from awkward surprises later.

• Mission objective (one or two sentences on what success looks like).
• Testing window (when the agent is allowed to actively probe).
• Rate limit and impact tolerance.
• Excluded paths, subdomains, third parties, or techniques.
• Escalation contact for high-severity findings.

Step 4 — Launch the discovery run

Open the Runs page (or the New run button inside the scope), pick the scope, and write a discovery goal. Discovery goals describe the outcome, not the technique — leave the "how" to the agent.

1. 1Click New run.
2. 2Confirm the scope is selected.
3. 3Pick the execution location: NullSquare cloud for public targets, or the attached private runner for internal ones.
4. 4Paste a discovery goal (see below).
5. 5Choose an intelligence category if prompted.
6. 6Start the run.
7. 7If Safe Mode is on, review and approve the plan when it pauses for approval.

A discovery goal you can copy

Discover the reachable attack surface for this scope. Identify live services, map key endpoints and authentication surfaces, fingerprint technologies, and recommend the highest-value priority targets for follow-up testing. Stay strictly within the configured rules of engagement.

Step 5 — Watch the run

Open the run detail page once execution starts. You will see live activity, a running list of discovered assets, and any findings as they get validated. You do not have to babysit it — the workbench is for when you want visibility, not because the agent needs supervision.

When the run finishes, the overview tab summarizes what happened, the plan tab shows what was executed, and the assets, findings, activity, and reports tabs hold the raw output.

Step 6 — Turn discovery into context

This is the step most new customers underuse. Discovery shows the platform what is reachable; the next run is much better when you tell the platform which of those things matter.

• Promote the assets you intend to track long-term to "managed".
• Fill in business criticality, data sensitivity, owner team, and authentication boundary on the assets you care about.
• If discovery found authenticated workflows worth testing, add credentials or tokens to the scope.
• If the relevant source code lives in GitHub, map the repository to the scope to enable white-box context.
• Update rules of engagement if discovery found anything that should be excluded next time.

Step 7 — Run a targeted follow-up

Now write a goal that points at one or two prioritized assets or workflows. The agent has the map, your team has added the context — the second run is where deep, specific testing happens.

Review authenticated workflows on the customer portal for IDOR, privilege escalation, and tenant isolation issues. Focus on the admin and billing endpoints flagged during the discovery run. Use the test account provided in scope credentials.

You are now on the operating loop

That is the rhythm: discover, contextualize, target, triage, retest, automate. Once you have done it on one scope, scale it by repeating the same flow on the next environment, then turn on automations to keep coverage continuous.