Security posture

Security at AETHER Pulse

Last updated 17 May 2026. Honest about what's shipped, what's in flight, and what's on the certification roadmap.

Data handling

  • What AETHER reads. OAuth grant metadata (which apps have which scopes), workspace user directory, Apps Script project manifests, Chrome extension inventory, Conditional Access policy state, PIM assignments, Purview labels (presence only, not file contents), Audit log enabled flag, Risky user flags.
  • What AETHER NEVER reads. Mailbox content. File content. Calendar event bodies. Contact phone numbers / addresses / notes. Source code of Apps Script projects. Specific Purview-labelled files. Browser activity. Passwords or 2FA enrollment state.
  • Data retention.Scan data retained 90 days from most recent scan. Customer-deletable on demand via the in-app "Delete tenant" action.

Encryption

  • At rest (platform-level). AES-256 via Supabase Postgres disk encryption. Applies to every row in every table.
  • At rest (application-level credential encryption). Connector credentials in tenant_connector_credentials are currently plaintext in-row, protected by Row-Level Security per tenant. Application-level envelope encryption (KMS-wrapped data-encryption keys) is the immediate next sprint when our first paying enterprise with sensitive credentials signs. Tracked in docs/PHASE_5_TRIGGERS.md §B.1.
  • In transit. TLS 1.2+ enforced (Vercel + Supabase).
  • Evidence signing. HMAC-SHA256 with per-tenant signing key, rotatable. Signature is over canonical JSON, so audience PDFs (board / underwriter / audit) all carry the same signature.

Access controls

  • Row-Level Security. Every tenant-scoped table in the database enforces an RLS policy keyed on tenant_id. Customer data is isolated at the database level.
  • Operator access. Operator access to production data is audit-logged.
  • OAuth scope discipline. AETHER requests only the minimum-privilege scopes its product depends on. No restricted Gmail or Drive content scopes are requested. See the methodology page for the per-scope justifications.

Certifications + verifications

  • Google OAuth verification. In flight. Tier 2 self-attestation (no third-party security assessment fees on the current scope set).
  • Microsoft Publisher Verification. In flight via Microsoft Partner Network free tier.
  • SOC 2 Type I.Demand-driven — initiated upon first enterprise customer's committed ARR. Not yet started.
  • ISO 27001 / HIPAA / FedRAMP. Deferred until specific customer demand.
  • Cyber insurance.Tech E&O + Cyber Liability cover is scheduled to be bound at first paying enterprise customer commitment, alongside SOC 2 Type I and an external penetration test. Not held at preview stage; disclosed to prospects as such.

Subprocessors

AETHER processes customer data using the following subprocessors. Each is bound by a written Data Processing Agreement. The authoritative list lives in the privacy policy and is mirrored here for convenience — material changes are notified to affected customers before they take effect.

  • Supabase — Postgres database + Row-Level Security (EU-West-1, Ireland)
  • Vercel — application hosting (EU region preference on edge functions)
  • Inngest — background job orchestration for long-running enterprise scans
  • Stripe — subscription billing (PCI-DSS Level 1); receives admin email + billing details only
  • Google — OAuth identity provider for Workspace customers (identity authentication only)
  • Microsoft — OAuth identity provider for Entra ID customers (identity authentication only)

NextAuth.js (Auth.js) is the open-source authentication library that powers our sign-in flow; it runs in-process and is not a third-party data processor.

Incident response + reporting

  • Security contact. security@aetherpulse.app
  • Disclosure policy. Responsible disclosure acknowledged within 48 hours. Public security advisory posted within 7 days of confirmed remediation for any impact-eligible issue.
  • Status page. Coming with production launch — uptime + incident history publicly visible.

Bedrock connector — bounded IAM scope

The AWS Bedrock connector runs against a deliberately narrow read-only IAM scope. The allowed actions are enforced in code, not just documented — adding a permission requires a pull request against lib/connectors/bedrock/scope-policy.js.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sts:GetCallerIdentity",
        "bedrock-agent:List*",
        "bedrock-agent:Get*",
        "bedrock:ListFoundationModels",
        "iam:ListRoles",
        "iam:GetRole",
        "iam:ListRolePolicies",
        "iam:GetRolePolicy",
        "iam:ListAttachedRolePolicies",
        "iam:ListPolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion"
      ],
      "Resource": "*"
    }
  ]
}

AETHER explicitly refuses to call s3:*, ec2:*, rds:*, cloudtrail:LookupEvents, or bedrock-runtime:* — those calls error at the SDK layer before they reach AWS.

Regulatory framing

  • GDPR. AETHER processes B2B workspace metadata. Lawful basis: legitimate interest. Records of Processing maintained per Article 30. Data subject rights (access / erasure / portability) supported on request.
  • EU AI Act self-classification.AETHER is a "limited risk" AI system per Article 50 transparency obligations — it assists humans in compliance decisions but does not make automated decisions about natural persons in Annex III categories.
  • Customer Article 26 obligations.AETHER evidences observed governance state per agent (human oversight, provider-instructions adherence, monitoring, privacy controls). Customer's counsel determines compliance.
Questions or due-diligence request? Email security@aetherpulse.app. We respond to enterprise procurement DDQs within 5 business days.