Attack surface and assets

Where assets come from

New assets enter the platform in three ways. The agent discovers them during a run (the most common path). Your team adds them manually when an environment is already known. Or an integration brings them in — for example a repository mapped to a scope can surface code-defined endpoints.

All assets are scope-bound. The same domain in two different scopes is two different asset records — that is intentional, because rules of engagement and context differ per scope.

Lifecycle states

Every asset carries a state that tells you how much trust to put in it and whether your team has chosen to track it long-term.

• Candidate — discovered by the agent but not yet curated. Most newly-discovered assets start here.
• Validated — the platform has confirmed the asset is live and reachable in the way the run claimed.
• Managed — your team has intentionally chosen to track this asset. Managed assets are what reports, prioritization, and continuous coverage center on.

What an asset can hold

Open an asset to see everything the platform knows about it. The more context that accumulates, the smarter the next run becomes.

• Services and ports (open ports, banner data, service fingerprints).
• HTTP endpoints and authentication surfaces.
• Technologies and version fingerprints.
• Subdomains and observations from passive sources.
• Related findings and the run history that touched the asset.
• Business context fields filled by your team (the profile).

Signals that mark an asset as important

When the platform recommends what to test next, it weights a few signals heavily. Use them as a checklist when deciding what to promote to managed.

• Authentication, admin, billing, checkout, API, file, VPN, or identity paths.
• Customer-facing or internet-facing exposure.
• Handles sensitive or regulated data.
• Existing open findings.
• High service or endpoint count (indicates a large attack surface on one host).
• Business-critical workflows (login, payment, data export, account recovery).

Profile fields

Profile fields turn the platform's guesses into your team's declared truth. Filling them in is the single biggest lever on how relevant future assessments will be.

• Business criticality — how critical to the business this asset is, on a defined scale.
• Operational criticality — how critical to running the system this asset is (different from business value).
• Customer-facing and internet-facing flags — quick filters for the agent.
• Authentication boundary — does this asset sit behind login, an API key, mTLS, or no auth?
• Data sensitivity — what kind of data this asset handles (PII, PHI, payment, source code, public).
• Owner team — who should be notified or assigned when findings appear.
• Criticality reason — a free-text note that explains why this asset matters, useful months later when context fades.

Common actions

1. 1Open an asset to review services, endpoints, technologies, and findings.
2. 2Promote to managed if your team intends to track it.
3. 3Fill the profile fields — at minimum business criticality, data sensitivity, and owner team.
4. 4Add credentials to the scope if authenticated coverage is needed for the asset.
5. 5Launch a targeted run referencing this asset in the goal.
6. 6Demote or ignore assets that are out of scope, third-party, or otherwise not your problem.

Demote, ignore, and out-of-scope assets

Discovery sometimes turns up surfaces that are not yours — third-party CDNs, SaaS providers, vendor APIs. Demoting or ignoring them keeps your assets list clean and ensures the agent does not waste effort on them next time. Demoted assets remain searchable; ignored ones are excluded from future runs in that scope.

From assets to the next run

Once your managed assets carry good profile data, future assessments become precise. Goals like "test the customer portal admin workflows" or "validate authorization on the billing API" produce focused, high-value findings because the agent already knows what those words refer to in your environment.