Scopes, targets, and rules of engagement

What a scope is

Think of a scope as one labelled environment that the agent is allowed to touch. "Production web app", "Staging API", "Corporate internal network", and "Customer portal" are all good scope names. Each one is independent — its own targets, its own rules of engagement, its own credentials, its own assets and findings over time.

Most organizations end up with somewhere between three and a dozen scopes. There is no penalty for creating one per environment; in fact, it is the recommended pattern because it keeps assessments focused and reports clean.

When to create a new scope

A new scope is the right answer whenever any of these change between two environments. If they are the same, one scope is fine.

• A different product or environment is being assessed.
• The rules of engagement differ (rate limits, testing windows, exclusions).
• A different private runner is needed because the network position is different.
• You want findings, assets, automations, and reports to stay separate.

The setup flow

A scope is useful once it has at least one verified target and a rules-of-engagement document. The order below works for almost every team.

1. 1Create the scope and name it after the environment, not the project.
2. 2Add the public or internal targets that define what is in bounds.
3. 3Complete verification for public targets, or attach a private runner for internal CIDRs.
4. 4Write the rules of engagement.
5. 5Decide whether to leave Safe Mode on while you trust the configuration.
6. 6Optional: add credentials for gray-box testing or map a repository for white-box testing.

Public targets

Public targets are the apex domains, subdomains, and hosts your organization owns on the public internet. These run from NullSquare cloud execution; there is no infrastructure for you to deploy.

Typical examples include example.com, api.example.com, app.example.com, and admin.example.com. Wildcard subdomains and public CIDRs are also supported but may require admin review.

1. 1Open the scope.
2. 2Click Add target and enter the domain or host.
3. 3Complete DNS or HTTP verification — the app generates a unique record or file and waits for it to appear.
4. 4Once verified, the target is ready to assess from cloud execution.

Internal CIDR targets

If you want the agent to assess internal machines — corporate networks, intranet apps, VPN-only systems, internal APIs, staging environments — add the subnet or host CIDR to the scope. The platform routes that work through a private runner you deploy in a network that can reach the range.

• 10.0.0.0/24
• 10.20.30.15/32
• 172.16.5.0/24
• 192.168.10.0/24

How verification works

For public domains and hosts, the platform asks you to prove control before active testing — either a DNS TXT record at a generated name, or an HTTP file at a generated path. Verification typically completes within minutes once the record or file is in place.

For private CIDRs, the platform cannot verify ownership the same way. Your team is the authorization source. Be deliberate: only add ranges your organization owns or for which you have explicit written permission from the owner.

Write the rules of engagement

The rules-of-engagement document is the single most important piece of context you write per scope. The agent reads it before every run and uses it to decide what to do, what to avoid, and how aggressive to be. Two paragraphs of clear writing here saves you from hours of remediation later.

• Mission objective — one or two sentences on what a successful assessment looks like.
• Testing window — when active probing is allowed (e.g., business hours only, weekends only, always-on).
• Rate limit — requests per second the agent may sustain.
• Impact tolerance — how much active testing is acceptable. Production-critical paths usually warrant lower tolerance.
• Exclusions — specific subdomains, paths, query parameters, third parties, or services that are off limits.
• Forbidden techniques — for example "no credential stuffing", "no destructive payloads", "no DoS-style flooding".
• Prior knowledge and operator notes — anything the agent should know up front (legacy systems, expected oddities, sandbox accounts).
• Escalation — who to notify and how, if the agent finds something high-severity.

Sample rules to copy

• Use only the synthetic test accounts listed in scope credentials.
• No destructive testing in production. Stop at proof of concept once impact is established.
• Avoid payment capture endpoints under /checkout/charge.
• Run active probes outside business hours (00:00–06:00 UTC).
• Hold rate at or below 5 requests per second per host.
• Notify security@example.com for any finding rated High or Critical.

Safe Mode and plan approval

When Safe Mode is on, manual runs pause after the agent drafts its plan. You can review the plan, approve it as-is, send back feedback, or discard the run. When it is off, manual runs continue straight from plan to execution.

New scopes and production environments are the right place for Safe Mode. As you build confidence in a scope and its rules of engagement, you can turn it off for routine work — automated and scheduled runs already execute without manual approval by design.

Once a scope is set up

You are ready to assess. If targets are public, head to the Quickstart and run discovery. If targets are internal, head to the Runners guide first so the private runner is online before you launch.