Privacy policy

What AETHER Pulse does

AETHER Pulse is an AI agent risk scanner designed to help organisations understand which third-party applications and AI-connected tools have been granted access across supported environments such as Google Workspace and Microsoft 365. We use permission and connection metadata to identify AI-connected tools, map their access scopes, and generate estimated exposure and prioritisation outputs.

What we read

AETHER Pulse is designed around read-only access to connection and permission metadata. Where a supported integration is connected, we read information such as connected applications and the permission scopes granted to them. We do not read the content of emails, files, documents, or calendar entries as part of the standard scan experience. We do not write, modify, or delete anything in your connected environment.

Identity-provider user data accessed by AETHER Pulse

AETHER Pulse currently supports two identity-provider integrations: Google Workspace and Microsoft 365 / Entra ID. Each integration requests a specific, strictly necessary set of scopes to deliver the core user-facing feature — a workspace-wide inventory of AI-connected applications and their permission scopes. The two sections below disclose, provider by provider and scope by scope, exactly what data AETHER reads, how it is used, and what it is not used for.

Customers who connect only Google Workspace are subject to the Google scope disclosure only. Customers who connect only Microsoft 365 are subject to the Microsoft Graph scope disclosure only. Customers who connect both are subject to both.

Google user data accessed by AETHER Pulse — full scope-by-scope disclosure

The following section discloses, scope by scope, exactly which Google user data AETHER Pulse requests access to, what we read with each scope, what we do not read with that scope, and how the data is used. AETHER Pulse only requests scopes that are strictly required to deliver its core user-facing feature — a workspace-wide inventory of AI-connected applications and their permission scopes.

Sign-in scopes (OpenID Connect)

• openid— authenticates the signed-in administrator. We receive a Google-issued ID token containing the administrator's Google account subject identifier. Used only for authentication. The identity is carried in a session cookie issued by AETHER. We do not read any other Google account information with this scope.
• email— receives the signed-in administrator's Google Workspace email address. Stored only against the administrator's AETHER account record so we know which Workspace the session belongs to. Not used for marketing, never shared with third parties, never sold.
• profile— receives the signed-in administrator's display name and profile picture URL. Used solely to render the administrator's name in the AETHER UI. Not stored beyond the active session and the administrator account record.

Workspace administrative scopes (sensitive)

• https://www.googleapis.com/auth/admin.directory.user.readonly
  What this grants: read-only access to the Workspace directory of users belonging to the administrator's organisation. AETHER reads each user's name, primary email address, organisational unit, and a small set of directory metadata (e.g., suspended state, last-login timestamp where surfaced by the API).
  Used to: enumerate the set of employees in the Workspace so AETHER can attribute each AI agent grant to its granting employee in the inventory.
  Not used to: read user mailboxes, Drive files, calendar entries, contacts, chat content, browser history, or device telemetry. AETHER reads directory metadata only — never user content.
• https://www.googleapis.com/auth/admin.directory.user.security
  What this grants: read-only access to each user's third-party OAuth grant list via the Admin SDK Directory tokens.listendpoint. For each grant AETHER reads the OAuth client identifier, the granting user's email, the granted scope strings, and the grant timestamp.
  Used to: build the shadow-AI inventory — the core user-facing feature. This is the primary data surface AETHER exists to inventory.
  Not used to: revoke, modify, or otherwise change OAuth grants. AETHER does not call tokens.delete in the standard scan flow. Mailbox, Drive, calendar, and contact contents are never read with this scope.
• https://www.googleapis.com/auth/cloud-identity.policies.readonly
  What this grants: read-only access to the Workspace's Cloud Identity policy registry, including the domain-wide delegation policy entries that authorise service accounts to act on behalf of users.
  Used to: surface service-account-based AI agents that bypass per-user OAuth — a class of shadow-AI sophisticated enterprises typically miss.
  Not used to: modify any policy, create any policy, or read user content of any kind.
• https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly
  What this grants: read-only access to admin role assignments in the Workspace — who holds super-admin, delegated admin, or specific privileged-role grants.
  Used to: surface privileged identities relevant to AI Act Article 26 deployer governance evidencing (admin role grants confer broad data access equivalent to many AI agents).
  Not used to: modify roles, grant roles, or read any user content.
• https://www.googleapis.com/auth/script.projects.readonly
  What this grants: read-only access to Apps Script project metadata and the OAuth scope manifest declared in each Apps Script project.
  Used to: identify Apps Script projects deployed inside the Workspace and inventory the OAuth scopes they request — a major shadow-AI surface for customer-built scripts using LLM APIs.
  Not used to: read the source code of Apps Script projects, execute scripts, or modify any script. We read the scope manifest declaration only.
• https://www.googleapis.com/auth/chrome.management.reports.readonly
  What this grants: read-only access to the Chrome Management Reports API, which lists Chrome extensions installed across managed devices in the organisation, including extension ID, name, version, and per-user install counts.
  Used to: surface Chrome-extension-based AI agents (browser-side AI assistants) that OAuth scanning alone would miss.
  Not used to: read browsing history, downloads, form data, saved passwords, or any other per-user browser activity. We list extension presence only.

Workspace restricted scope — deferred

• https://www.googleapis.com/auth/drive.metadata.readonly DEFERRED — NOT CURRENTLY REQUESTED
  Current status (May 2026): AETHER Pulse does not currently request this scope. It is the only Google restrictedscope that would otherwise be in AETHER's OAuth request, and any restricted scope triggers an annual recurring CASA Tier 2 security assessment. We have deferred this scope (and the dependent feature — Apps Script project enumeration via Drive metadata) until first paying enterprise commitment funds the CASA assessment. This decision was confirmed in writing by the Google verification team in May 2026.
  If and when re-enabled, what it would grant: read-only access to Drive file metadata — file IDs, file names, owners, MIME types, parent folder IDs, and creation / modification timestamps. We would never read the content of any Drive file.
  Apps Script enumeration today: script.projects.readonly (sensitive, not restricted) remains in the scope set. Customer administrators who want Apps Script governance visibility can supply specific project IDs to AETHER as an opt-in workflow; AETHER then reads the manifest for those specific projects only.

How Google user data is stored and retained

The OAuth scope grant lists, Apps Script manifests, Chrome extension inventory, Cloud Identity policy entries, and admin role assignments returned by the Google APIs above are stored in AETHER's Supabase-hosted Postgres database (EU-West-1 region, Ireland) under per-tenant Row-Level Security policies. Storage is metadata only; no user-content payloads (mailbox bodies, file contents, calendar event details) are ever stored because they are never read.

Retention follows the schedule described under Data retention and deletionbelow: scan results are retained for 90 days from the most recent scan; tenant deletion is cascade-applied on demand. Revoking AETHER's OAuth grant from myaccount.google.com/permissions immediately and unilaterally terminates AETHER's access.

AI / ML training disclosure

AETHER Pulse does notuse any Google user data obtained through Workspace APIs to develop, improve, or train generalised AI or ML models — neither AETHER's own models nor any third-party model. The deterministic toxic-combination matcher that powers the core feature contains no LLM in the scan path; it is a Boolean predicate engine. Future ML extensions (such as a vendor-similarity classifier) would be trained exclusively on synthetic or public-domain vendor-catalogue data, never on customer Workspace data.

Microsoft Graph user data accessed by AETHER Pulse — full scope-by-scope disclosure

The following section discloses, scope by scope, exactly which Microsoft 365 / Entra ID user data AETHER Pulse requests access to, what we read with each scope, what we do not read with that scope, and how the data is used. AETHER Pulse uses the Microsoft Graph application-permission (app-only) model: an administrator grants tenant-wide admin consent once, and AETHER reads tenant-wide metadata without acting as any single user.

Consent flow

An administrator with the Privileged Role Administrator or Global Administrator role grants admin consent at https://login.microsoftonline.com/{tenantId}/adminconsent. No per-user delegation is requested. The administrator's consent action is the only identity flow involving Microsoft user data; subsequent scans use app-only access tokens against the Microsoft Graph.

Core scopes (required for the inventory feature)

• Application.Read.All
  What this grants: read-only access to the tenant's service-principal registry — every third-party application the tenant has consented to, together with the application permissions each has been granted. This is the Microsoft equivalent of Google's OAuth grant inventory.
  Used to: build the tenant-wide shadow-AI inventory. This is the primary data surface AETHER exists to inventory on the Microsoft side.
  Not used to: register applications, modify application permissions, revoke service principals, or read application content. Read-only.
• Directory.Read.All
  What this grants: read-only access to the tenant directory — users, groups, organisational units, and basic directory metadata.
  Used to: attribute each AI agent grant to the user(s) it covers and surface directory context (organisational unit, group membership) in the inventory.
  Not used to: modify directory objects, create users, manage groups, or read user content (mailbox, files, calendar, chat). Directory metadata only.
• User.Read.All
  What this grants: read-only access to user profile attributes (display name, userPrincipalName, mail address, job title, manager, account enabled flag).
  Used to: render granting-user attribution in the AETHER inventory and surface organisational context for compliance evidencing.
  Not used to: read user mailboxes, files, calendars, contacts, chat content, Teams messages, OneDrive content, or any other user-generated content. Profile attributes only.
• DelegatedPermissionGrant.Read.All
  What this grants: read-only access to the oauth2PermissionGrants table — the per-user delegated OAuth grants that authorise applications to act on a user's behalf.
  Used to: identify user-impersonating AI agents and stitch them to the application-permission view from Application.Read.All.
  Not used to: modify or revoke any delegated grant, and not used to read the content of the resources those grants protect.

Optional governance scopes (read-only; soft-fail if not granted)

The following scopes are optional. AETHER's core inventory feature works without them. They populate the Article 26 readiness scorecard with tenant-policy context; if a customer does not grant them, AETHER soft-fails and the scorecard remains empty rather than blocking the scan.

• AuditLog.Read.All
  What this grants: read-only access to the tenant's audit-log enabled flag and recent admin-action audit entries relevant to AI agent governance.
  Used to: evidence whether tenant-level audit logging is enabled for Article 26 record-keeping purposes.
  Not used to: read user sign-in events, individual user activity, or content access logs.
• Policy.Read.All
  What this grants: read-only access to Conditional Access policy definitions in the tenant.
  Used to: count Conditional Access policies for the Article 26 readiness scorecard.
  Not used to: modify Conditional Access policies, create policies, or evaluate policy decisions on user sessions.
• RoleManagement.Read.Directory
  What this grants: read-only access to PIM (Privileged Identity Management) role assignments and admin role definitions.
  Used to: count PIM assignments for the Article 26 readiness scorecard.
  Not used to: grant or revoke roles, modify PIM configurations, or read privileged-session details.
• InformationProtectionPolicy.Read.All
  What this grants: read-only access to Microsoft Purview sensitivity-label definitions configured at the tenant level.
  Used to: count Purview labels for the Article 26 readiness scorecard.
  Not used to: read which specific files or messages carry which labels, or read any labelled content.
• IdentityRiskyUser.Read.All
  What this grants: read-only access to the Entra ID Identity Protection risky-user signals at tenant level.
  Used to: count flagged risky users for the Article 26 readiness scorecard.
  Not used to: modify risk states, dismiss risk events, or read individual user activity beyond the risk flag itself.

How Microsoft user data is stored and retained

Service-principal lists, application-permission grants, delegated permission grants, directory user attributes, and tenant policy/governance metadata returned by the Microsoft Graph APIs above are stored in AETHER's Supabase-hosted Postgres database (EU-West-1 region, Ireland) under per-tenant Row-Level Security policies. Storage is metadata only; no user-content payloads (mailbox bodies, Teams messages, OneDrive contents, Purview-labelled file contents) are ever stored because they are never read.

Retention follows the same 90-day rolling window described under Data retention and deletionbelow. Customer administrators may revoke AETHER's admin consent at any time via the Microsoft Entra admin centre (Enterprise applications → AETHER Pulse → Properties → Delete). Revocation immediately and unilaterally terminates AETHER's tenant access.

AI / ML training disclosure (Microsoft)

AETHER Pulse does notuse any Microsoft user data obtained through Microsoft Graph APIs to develop, improve, or train generalised AI or ML models — neither AETHER's own models nor any third-party model. The same deterministic Boolean-predicate matcher operates on Microsoft data; no LLM is in the scan path; and any future ML extensions would be trained exclusively on synthetic or public-domain vendor-catalogue data, never on customer Microsoft 365 / Entra ID data.

What we store

Scan-session information may be processed temporarily to generate results and operate the service. By default, AETHER Pulse is designed to minimise retained data and avoid storing customer content.

Where you explicitly opt in, we may store limited aggregate or anonymised product analytics, such as the number of AI agents detected, general risk categories, industry type, and company size range. We do not intentionally store email content, document content, file names, or other customer workspace content as part of the standard scanning flow.

What we never do

• ✓We do not read the content of emails, documents, or files as part of the standard scan flow
• ✓We do not sell customer data to third parties
• ✓We do not modify or delete anything in connected accounts
• ✓We do not use customer workspace content to train AI models
• ✓We are designed to inspect permissions and connection metadata rather than business content

Who we share, transfer, or disclose Google user data with

AETHER Pulse does not sell Google user data, ever. We share Google user data only with the limited set of subprocessors listed below, only for the purpose of operating the AETHER Pulse service, and only under written data-protection agreements. We do not transfer Google user data to advertisers, data brokers, or any third party for purposes unrelated to providing the service.

Specifically, we may share Google user data with:

• ·Supabase (PostgreSQL hosting) — stores tenant configuration, scan results, and the read-only metadata we retrieve from Google Workspace. Hosted in the EU-West-1 region (Ireland). Subject to a written Data Processing Agreement.
• ·Vercel (application hosting) — executes the AETHER Pulse application code that processes Google user data. Edge functions are configured with EU region preference. Subject to a written Data Processing Agreement.
• ·Inngest (background-job orchestration) — schedules and dispatches long-running enterprise scans. Event payloads may include short-lived OAuth access tokens scoped to the customer's own Workspace. Subject to a written Data Processing Agreement.
• ·Stripe (billing) — processes subscription payments. Stripe receives the customer-admin email address and billing details but does not receive any Google user data extracted from the customer's Workspace.
• ·Google (identity provider) — authenticates AETHER Pulse administrators via Google OAuth. Customer-admin identity is processed for authentication only.

We do not share Google user data with any other party. We may be required to disclose data in response to a valid legal request from a competent authority; where this occurs we will, consistent with applicable law, notify the affected customer and challenge requests that are over-broad.

The current subprocessor list is also published on our public security page at /security. Material changes to the subprocessor list are notified to affected customers before the change takes effect.

How we use Google user data (Google Limited Use compliance)

AETHER Pulse's use of Google user data complies with the Google API Services User Data Policy, including the Limited Use requirements. Specifically:

• ·We use Google user data only to provide and improve user-facing features of AETHER Pulse that are prominent in the user experience (shadow-AI inventory, classification, and signed governance evidence).
• ·We do not transfer Google user data to third parties for purposes unrelated to providing or improving these user-facing features, except in the limited subprocessor relationships described above.
• ·We do not use Google user data to serve advertising.
• ·We do not allow humans to read Google user data unless we have explicit customer consent for specific data, or as required for security purposes (such as investigating an abuse incident) or to comply with applicable law.
• ·Where the option exists, we use Google user data only on the user's own organisation, scoped to the Workspace whose admin granted the consent.

Data retention and deletion

Scan results are retained for 90 days from the most recent scan to support the time-machine view that reconstructs historical posture. Customers may delete their tenant on-demand from within the application; deletion is cascade-applied to all associated scan history, agent inventory, controls, and signed evidence exports. Backups held by our hosting provider (Supabase point-in-time recovery, 7-day window on the current tier) will roll off within the platform's recovery window.

Workspace administrators may request export of their tenant's data, or accelerated deletion outside the standard 90-day retention window, by contacting privacy@aetherpulse.app.

Your choices

You may choose whether to connect supported services and whether to opt in to any anonymised or aggregate analytics collection. You may also contact us to request deletion of information you have submitted directly to us. Revoking AETHER Pulse's OAuth grant from your Google Account at myaccount.google.com/permissions will immediately and unilaterally terminate our access; we treat such revocations as a customer-initiated disconnection.

ICO AI Governance & Accountability Framework alignment

AETHER Pulse's product surface is designed to provide technical evidence for the UK Information Commissioner's Office (ICO) AI Governance and Accountability framework. AETHER produces continuous, cryptographically-signed evidence relevant to five of the framework's eleven control measures:

• ·Control 1 — privacy management framework substrate (methodology v2 + signed evidence pack).
• ·Control 3 — risk-based audit programme (continuous scans, signed evidence per scan).
• ·Control 5 — information flows mapping (cross-platform agent-identity stitching).
• ·Control 9 — supply-chain repurposing detection (scope-change audit trail per agent).
• ·Control 10 — Article 22 solely-automated-decision-making safeguards (methodology v2 autonomy-tier + intervention-model classification).

Customer-attested LIA (control 7), consent mechanisms (control 8), and certain DPIA workflows (control 2) sit outside the AETHER product surface — these remain the responsibility of the customer's DPO and counsel. AETHER's evidence pack supports those workflows but does not perform them.

Data security

We use reasonable technical and organisational measures to protect information handled by the service, including secure transport and access controls. No system can be guaranteed completely secure, but we aim to minimise data collection and reduce data handling wherever possible.

Contact

If you have questions about this privacy policy or how data is handled, contact us at privacy@aetherpulse.app