Core concepts

Top-level objects

These four objects make up the operating model. Most of the app is just a richer view onto them.

• Organization — the account boundary. Holds members and roles, billing, integrations (GitHub, Microsoft Entra, Google Workspace), business context, and compliance framework selection. All work happens inside one organization.
• Scope — the authorization boundary for one target environment. A scope owns its own targets, rules of engagement, credentials, mapped repositories, runner assignment, assets, findings, runs, automations, and reports. You will typically have one scope per product surface or environment (production web app, staging API, corporate internal network, and so on).
• Target — an authorized address the agent may assess. Targets can be public domains, public hosts, public CIDRs, or internal CIDR ranges. Public targets require ownership verification before active testing; internal CIDRs are reached through a private runner.
• Run — one goal-driven assessment inside one scope. The agent reads your goal plus all of the scope context, drafts a plan, executes it, and produces assets, findings, evidence, activity, and a report.

Where work executes

Every run executes from a specific network position. Choosing that position is half of how you scope an assessment.

• Cloud execution — the default for public, internet-facing targets. NullSquare manages the execution environment in the cloud. No infrastructure work on your end.
• Private runner — a small worker you deploy inside a network you control. It lets the agent reach internal subnets, VPN-only systems, staging environments, intranet hosts, and machine targets. Private runners attach to a scope and are required for any internal CIDR target.

Testing modes

The mode of an assessment is determined by what context you give the agent before the run. The same scope can be tested in any mode — or multiple at once.

• Black-box — no credentials, no source code. The agent sees what an external attacker sees. Right for first discovery and external exposure work.
• Gray-box — you provide credentials, tokens, headers, or session cookies so the agent can exercise authenticated workflows. Right for customer portals, admin surfaces, and API authorization testing.
• White-box — you map source repositories to the scope (through the GitHub integration), and the agent can read those repositories for context during assessment. Right for finding root causes and producing more actionable remediation guidance.

What runs produce

A run is not just a one-time scan. Each run contributes to a durable record that grows over time.

• Asset — a piece of attack surface that the platform has discovered or that your team has chosen to track. Assets include domains, IPs, services, ports, HTTP endpoints, technologies, and observations. Assets carry a state: candidate (discovered but not yet curated), validated (confirmed live and reachable), or managed (intentionally tracked and prioritized by your team).
• Finding — a security issue tied to an asset and supported by evidence. Findings carry severity, validation state, lifecycle status, remediation guidance, optional code location, and retest history.
• Evidence — preserved artifacts (requests, responses, screenshots, payloads, traces) that prove a finding and support compliance reporting.
• Report — a stakeholder-ready summary of a run or readiness assessment, suitable for sharing with engineering, leadership, or auditors.

Continuous and assistive features

• Automation — a scheduled or event-driven run configuration that keeps coverage continuous. You can automate discovery, targeted testing, retests, or readiness work.
• Assistant chat — a read-only analyst over your existing scope data. Use it to query assets, findings, and rules of engagement. It does not start active testing — for that, launch a run.
• Compliance readiness — supporting evidence mapped to selected frameworks (for example SOC 2 technical controls). This is not certification or auditor opinion; it is the artifact set you bring to one.

Governance and limits

• Rules of engagement (RoE) — a written document on each scope that defines mission, testing window, rate, impact tolerance, exclusions, forbidden techniques, and escalation contacts. The agent reads it on every run.
• Safe Mode — a per-scope setting that pauses manual runs after planning so an operator can approve, reject, or revise the plan before execution.
• Credits — the unit of consumption for running the agent. Credits are deducted as runs execute; plan limits, automation caps, and concurrent-run limits apply on top of the credit balance.
• Subscription / plan — the entitlement layer. Plans control concurrent run limits, active scope limits, automation availability, private runner access, and refill flow. Manage from Settings → Billing.
• Audit log — a tamper-evident record of sensitive organization and scope actions: scope edits, credential changes, runner deployments, automation changes, integration changes, evidence reviews.
• Roles — Owner, Admin, Lead, and Member. Owners and Admins manage organization settings, billing, and integrations. Leads manage scopes, runners, automations, and evidence. Members triage assigned work.

Common lifecycle states

You will see these states across the app. They are written here so you can look them up without leaving the page you are on.

• Run status — queued, running, paused, completed, failed, cancelled.
• Pause reason — approval (Safe Mode), manual, credits, runner unavailable, system.
• Asset state — candidate, validated, managed.
• Finding validation — unvalidated, under review, validated, false positive, inconclusive.
• Finding lifecycle — open, in remediation, retest requested, resolved, accepted risk.
• Runner status — online, busy, offline, quarantined.
• Automation status — active, paused, archived.