Aether AI
Platform

Integrations

How Aether AI connects to your cloud accounts to enrich the attack surface today, and where those connectors are headed as action channels.

Integrations connect Aether AI to the systems that hold your real attack surface. Today they are enrichment connectors: they pull cloud assets into your surface, capture where each one came from, and keep everything current as your estate changes. On the roadmap, the same connectors become action channels, so validated exposure can flow straight into response.

The distinction matters, and this page keeps it honest. What Aether AI does now is described as fact. What it is designed to do later is flagged as roadmap and kept in its own section.

Provenance travels with every asset

Every asset Aether AI pulls in through a connector carries full provenance (the provider plus the account or scope id it came from). That means a finding is always traceable back to the exact cloud account it lives in, which is what makes an exposure actionable rather than just visible.

Today: cloud connectors that enrich the surface

Aether AI ships cloud connectors for AWS, Azure, Cloudflare, and more. Their job right now is enrichment. They discover the assets that live in your cloud accounts, add them to your attack surface, and keep that picture accurate over time.

These are enrichment connectors, not a public API. There is no developer REST interface to call. A connector is something you authorise once so Aether AI can read your cloud estate and reflect it into the platform.

You connect an integration from Settings, then Organisation, then Integrations, where the available services are grouped by what they do. The cloud providers that enrich your surface, Amazon Web Services, Microsoft Azure and Cloudflare, are available today. The action channels described later on this page (ticketing, identity, and security tooling) are listed there as coming soon, so the page itself draws the today-versus-future line.

The Integrations settings page. Amazon Web Services, Microsoft Azure and Cloudflare are available under Cloud and DNS, while ticketing, identity and security integrations are marked coming soon.

Org-wide cloud connection is coming soon

Today a cloud account is connected one at a time. A better approach for connecting an entire cloud organisation at once, through a single org-wide setup rather than account by account, is built and set for release soon. It turns onboarding a large multi-account estate into a single step rather than many.

What a connector does

Each connector is built to do three things.

Discover cloud assets. Rather than relying only on seed-based discovery (domains, subdomains, IPs, CIDRs, keywords), a connector reads directly from the source of truth. It finds the domains, IPs, and cloud resources that actually exist in the connected account, including assets that outside-in discovery would struggle to see.

Capture full provenance. At ingest, every discovered asset records the provider and the account or scope id it belongs to. Provenance is not a label bolted on afterwards; it is captured as the asset enters the platform. This is what lets you segment a surface by account, attribute a finding to the right owner, and scope access per business unit.

Keep the surface current. Cloud estates move constantly. A connector keeps discovered assets in step with reality, so the surface Aether AI monitors and validates reflects what is deployed now, not a snapshot from when you first connected.

How discovered assets flow through the platform

A cloud asset that a connector brings in behaves like any other asset. It lands with a monitoring status, and you decide how much attention it gets:

  • Monitor applies passive enrichment: Port Analysis (an open-ports inventory) and Technology Detection (a technology and version fingerprint), both of which alert on change.
  • Monitor Plus adds active exploitability validation on top through the Conventional Attack Surface, checking what a commodity adversary could exploit without ever exploiting it.

Because provenance travels with the asset, the resulting findings inherit it too. A Conventional Attack Surface finding on a cloud resource carries the account it came from, and it surfaces in the same Risk Inbox as everything else, source-agnostic across ASM and pentest.

Same treatment, different source

Connectors change where assets come from, not how they are treated once inside. A subdomain found by a cloud connector and one found by seed discovery run through the same monitoring tiers, the same validation, and the same risk scoring. The connector's contribution is coverage and provenance.

On the roadmap: connectors as action channels

Today's connectors read from your environment. The direction Aether AI is designed to take is to let them act on it as well. The following is roadmap. It describes intended direction, not shipped capability.

Once a connector can act, the intelligence and validation Aether AI already produces can move straight into response, either natively inside the platform or through the tooling an organisation already runs. The lead channels are SOAR and SIEM, with identity providers and ITSM close behind, because between them they cover the two things a response needs: somewhere to orchestrate and investigate, and somewhere to actually contain.

How much the agent does: configurable per rule

Automated action is not designed to be all or nothing. It is designed to be configurable per rule, so the level of autonomy matches the confidence in the finding and the blast radius of the action. A high-confidence, low-regret action, such as revoking a leaked session, can be set to fire automatically. A higher-stakes or more ambiguous one, such as anything touching a named executive or a broad reset across an estate, can be set to prepare the action and wait for a human to approve it. The agent always shows its work first: the exact accounts it would touch, the incident it would raise, the ticket it would open.

Scenario: infostealer compromises 100 corporate identities

When Aether AI correlates infostealer and stealer-log intelligence against a customer's monitored domains and confirms that roughly 100 corporate identities are compromised, that exposure surfaces today as a Threat Radar verdict and a set of atomic identity findings in the Risk Inbox, each tied to the affected person and the credential involved.

The Threat Radar showing an infostealer verdict card with 75 exposed credentials, a dark-web verdict card for an exposed executive identity, and a Conventional Attack Surface card, each marked exposed.

The ideal flow does not stop at surfacing it. Because each finding is validated and attributed, it fans out to the systems that can act on it:

  • Identity provider (Okta, Entra): force a password reset and revoke active sessions for each affected identity. This is the real containment, which is why an identity provider is a first-class channel rather than an afterthought.
  • SOAR and SIEM: raise a single correlated incident so the security team works the exposure inside its existing runbooks, with the full list of identities attached rather than a hundred separate alerts.
  • ITSM (ServiceNow, Jira): open tracking tickets for the owning teams so remediation is followed through to closure.

Under the per-rule model, the reset and session revocation can be set to contain automatically the moment the exposure is confirmed, while the incident and the tickets are created for people to work.

Scenario: an executive's identity surfaces on the dark web

A customer adds a keyword seed for a named executive, for example the CEO. When that name is found on a dark-web forum alongside other personal information, Aether AI surfaces it today as a Threat Radar verdict and an identity finding.

This is intelligence you cannot patch. A leaked name and home address cannot be un-leaked, so the ideal flow is not remediation, it is investigation and response. Aether AI raises a SOAR or SIEM incident so the security team can assess the exposure, decide whether protective monitoring or a takedown request is warranted, and involve executive protection if needed. Under the per-rule model, anything touching a named executive is exactly the kind of rule an organisation would set to require human review before it routes anywhere, rather than firing on its own.

Roadmap, not a promise of timing

Action-channel connectors, native defensive workflows, per-rule automation, and SOAR, SIEM, identity provider and ITSM integration are planned direction. They are described here, alongside the app surfaces where the underlying exposure is already visible today, so the today-versus-future line stays clear. Nothing in this section is a currently available feature.

On this page