Safety, scope and authorisation

Aether AI runs offensive work against a live production surface, so the guarantees around what it will touch, and what it will never do, matter as much as the findings themselves. The short version is this: Aether AI only ever acts on a customer's own assets, always within a scope that has been defined and authorised, and the continuous validation path is non-destructive by design. A security leader can sign off knowing the boundary is real, a risk owner knows exactly which assets are in play, and an engineer can trust that a check against production will not change or damage anything.

Only your own assets, only in scope

Every offensive action Aether AI takes is bounded to the customer's own attack surface. Assets enter that surface through discovery from seeds a customer provides (domains, subdomains, IPs, CIDRs, keywords) and through cloud connectors that enrich it, and nothing outside that surface is a target. Scope is not a suggestion layered on afterwards; it is the frame that offensive work runs inside.

Within that surface, the monitoring status of each asset decides how far Aether AI goes. The deeper the work, the more deliberate the choice to enable it has to be. Passive Monitor work watches an asset; the Conventional Attack Surface validation only runs on assets a customer has promoted to Monitor Plus, and downgrading an asset stops that deeper work immediately. The heavier Autonomous AI Pentest runs only against explicitly authorised scope. Nothing escalates on its own.

The validation path is non-destructive by design

Conventional Attack Surface is the continuous validation layer, and it is built to be safe to run against production. It uses generally-available tooling (nuclei), the same class a commodity adversary would reach for, but it checks for the presence of an exploitable condition rather than acting on it. It validates, it does not exploit.

Concretely, on the validation path there is no brute force, no state change, and no data exfiltration. Aether AI reads what is exposed, confirms whether a condition is really there, and moves on. It does not push an asset into a different state, it does not pull data out, and it does not try to force its way past a control. That boundary is what makes continuous validation against a live surface honest and safe at the same time.

Actually chaining weaknesses, working through authentication, and reaching for novel or business-logic flaws is the job of the frontier engine, the Autonomous AI Pentest, which is heavier, slower, and gated behind explicit authorisation for exactly that reason. The line between the two is deliberate: the commodity baseline stays non-destructive, and the more capable work is held to a stricter authorisation bar.

How authorisation is established

Today, authorisation is human-established. Bringing an organisation onto Aether AI includes a white-glove verification step where the scope a customer wants covered is confirmed with a person, not self-served through a form. That manual step is what stands between a claim of ownership over an asset and Aether AI beginning offensive work against it, and it is intentionally in place while the platform's customer base is verified by hand.

Where this shows up

The safety model is not a separate screen; it is the set of rules the rest of the platform runs inside. It is why an asset's monitoring status governs how deep validation goes, why Conventional Attack Surface findings can be produced continuously against production without risk, and why the frontier pentest is scoped and authorised on its own terms. When a finding lands in the Risk Inbox, the boundary that produced it (own assets, defined scope, non-destructive check) is already established.

Related