Discovery and scope
How Aether AI expands your attack surface from seeds and establishes the scope it is authorised to act on.
Discovery is where Aether AI learns what you actually own, starting from a small set of seeds and expanding outward until it has mapped the surface a real adversary would see. Scope is the other half of the same story: it defines exactly what Aether AI is authorised to touch, so the surface stays accurate without ever reaching beyond your own estate.
Why this matters
An attacker does not work from an org chart. They work from whatever is exposed: a forgotten subdomain, a cloud bucket that outlived the project that created it, an IP range nobody remembers provisioning. If a defender's view of the surface is smaller than the attacker's, the gap is where breaches happen. Discovery closes that gap by building the surface the way an adversary would, then keeping it current as the estate changes.
Just as important, discovery is bounded. Everything Aether AI does downstream (passive monitoring, exploitability validation, the autonomous pentest) acts only on assets that are in scope and authorised. Getting discovery and scope right is what makes the rest of the platform both complete and safe.
Seeds
Discovery starts from seeds you provide. A seed is a known anchor into your estate, and Aether AI supports several kinds:
- Domains and subdomains, for example
example.comorapi.example.com. - IPs, single addresses that you know belong to you.
- CIDRs, network ranges expressed in CIDR notation.
- Keywords, distinctive strings (a brand name, an internal product name) that help attribute assets back to your organisation.
From these anchors, discovery expands outward. A domain seed leads to its subdomains; subdomains and IPs relate to the hosts and services behind them; CIDRs bound the address space worth exploring; keywords help attribute newly found assets to you rather than to someone who merely shares infrastructure. The result is a set of assets that grows past the handful you started with, covering domain, subdomain, IP, cloud resource, and person or identity asset types.
For risk owners
The seeds you provide are the record of what you intend Aether AI to look at. Reviewing them periodically is a quick way to confirm the surface reflects the real business, especially after acquisitions, rebrands, or new product launches.
Provenance captured at ingest
Every asset that enters the surface carries provenance, recorded at the moment it is ingested. Provenance is the answer to "where did this come from", and it is captured as the provider plus the account or scope id it was discovered under.
This matters for two reasons. First, it makes attribution defensible: when an asset shows up, you can see which source produced it and which account or scope it belongs to, rather than guessing. Second, it is what lets business-unit segmentation work later, because an asset discovered under a particular cloud account or scope can be routed to the team that owns it. Provenance is factual metadata, not an inference, and it travels with the asset for the rest of its life on the platform.
Scope and authorisation
Scope defines what Aether AI is authorised to act on. This is the safety boundary for the entire platform: only assets that you own or have authorised are ever touched. Discovery may surface assets that turn out not to be yours (shared infrastructure and keyword matches can pull in neighbours), and nothing in scope is assumed simply because it appeared. An asset has to be in scope and authorised before any deeper work runs against it.
That boundary carries through everything downstream. Passive enrichment, Conventional Attack Surface validation, and the autonomous pentest all inherit it, so heavier and more intrusive work only ever happens against assets you have explicitly authorised. The monitoring status an asset holds then determines how much of that authorised work actually runs, and downgrading an asset stops the deeper work immediately.
What you see and do
After seeding, you work with a growing inventory of assets, each tagged with its type and its provenance. From there you decide how each asset should be treated: leave it as Discovered, Confirm it as yours, move it to Monitor for passive watching, or to Monitor Plus for active exploitability validation, or mark it Ignored. Those decisions are where discovery hands off to monitoring and validation, and they are the point at which cost is metered per asset and per tier.
Related
Monitoring status
Discovered, Confirmed, Monitor, Monitor Plus, and Ignored, and what each tier runs.
Conventional Attack Surface
Continuous, non-destructive validation of what a commodity adversary could exploit.
Cloud connectors
AWS, Azure, Cloudflare, and more, discovering cloud assets and capturing provenance.