Before a scanner touches anything, it needs an answer to a much simpler question first: whose authorization is this running under? In Eresus Guard, that answer is a Project — and almost everything else in the product is scoped underneath one.
One card, one authorization. Scans, findings, HTTP records, and scope all live under whichever Project they were run against.
Why a Project, and not just a target URL
A raw target URL answers "what." It doesn't answer "who approved this," "under what constraints," or "which team owns the result." A Project holds all three. Its description is the natural place to record the authorization reference — the ticket, the signed scope document, the email thread — so six months later, nobody has to reconstruct from memory whether a given scan was ever actually sanctioned.
It also draws a hard boundary. Findings, scan history, HTTP records, and OAST interactions are all attached to the Project they came from. Switch projects in Workbench and you're not filtering a shared pool of results — you're looking at a genuinely separate set of evidence, scoped to a separate authorization.
What belongs in scope — and what doesn't
Add only the assets a Project's authorization actually covers. This sounds obvious until discovery is running: a scan will routinely surface related hosts, linked subdomains, or unlisted routes that look like they belong. They don't, automatically. A link discovered mid-assessment is an observation, not an authorization — it has to be added deliberately, the same way the original target was, before it becomes something the scanner is allowed to touch.
This is the same discipline that applies on the ingest side: importing an OpenAPI spec or Postman collection can pull in server URLs beyond what you meant to test. The Project boundary and the ingest review step are two checkpoints on the same rule — the scanner's authority never silently grows past what was explicitly approved.
Staging first, then repeat
For a first assessment, staging is the right target — not because production is off-limits forever, but because it gives the team room to validate authentication, request pacing, and traffic behavior somewhere a mistake costs nothing. Once that first run inside a Project looks right — reachable target, working identity, clean evidence — the same Project becomes the home for every rerun after it: re-run from Scan History with identical settings, or launch a new profile against the same authorized boundary.
Getting started
Create a Project from Projects, name it after the real authorization rather than just the application, and add only what that authorization covers. From there, walk through running your first assessment or read the full reference in Access and onboarding.