Trust & Security
Sub-processors
We use a small number of vetted infrastructure and service providers to run AetherCloud. Each processes only the data necessary for its function.
| Provider | Purpose |
|---|---|
| Supabase | Managed Postgres database and authentication |
| Stripe | Payment processing and billing |
| DigitalOcean | VPS compute hosting and Spaces object storage (vault files) |
| Cloudflare | CDN, DDoS protection, bot mitigation (Turnstile), and hosting for aethersystems.net |
| Vercel | Hosting for app.aethersystems.net |
| OpenRouter | AI model routing — the sub-processor of record for inference requests, which route to the underlying model you select (Claude/Anthropic, GPT/OpenAI, Gemini/Google, DeepSeek) |
| Resend | Transactional and marketing email |
| PostHog | Product analytics |
For full detail on what each sub-processor sees and why, see our Privacy Policy.
Signing architecture
AetherCloud's own commitment/audit layer is Protocol C — open source and independently auditable today. Protocol L (patent-pending) and Protocol T are related commitment and attestation layers offered under Aether Protocol, a separate Aether AI product line, not shipped inside AetherCloud itself. Both require contacting us for access.
Protocol C
Zero-cost commitment infrastructure using OS kernel entropy (CSPRNG). Classical, no quantum hardware. Source: github.com/DBarr3/protocol-c.
Protocol L
Quantum-authenticated commitments using IBM Fez quantum hardware.
Protocol T
Execution-context attestation via hardware enclaves (Intel SGX / AMD SEV-SNP remote attestation).
Trust Service Criteria scope
Our SOC 2 readiness work targets Security, Availability, and Confidentiality for v1. Processing Integrity and Privacy are deferred — we haven't yet identified a single regulatory regime that governs our AI stack's data handling in a way that would make those criteria meaningfully scoped, and we'd rather scope accurately than claim broad coverage prematurely. We'll revisit as that changes.
Control mapping (planned)
The table below maps upcoming Team-tier features to the Trust Service Criteria they support. These controls are planned, not yet shipped — we're publishing the mapping now so prospects can see the shape of what's coming, not to claim it's live today.
| Feature | Trust Service Criterion |
|---|---|
| Team roles with row-level-security-gated roster management | CC6.1 — Logical access controls |
| Protocol-C-signed mutation log | CC7.2 — System monitoring |
| Immutable, cryptographically-signed edit history | CC8.1 — Change management |
| Append-only audit log (no update/delete grants) | Processing integrity — evidence can't be altered after the fact* |
* Previews a Trust Service Criterion beyond v1's stated scope (see "Trust Service Criteria scope" above); noted here for completeness, not claimed as in-scope yet.
Written policies
These policies are drafted and published, current as of the date above.
A note on company structure
AetherCloud is built and operated by a single founder-engineer. SOC 2 auditors accept solo-operator structures provided the owner's role as a control — approvals, incident response, access decisions — is explicitly documented with a sign-off trail, which it is internally. We're not hiding behind automation to look bigger than we are; we're documenting exactly how a small, accountable team runs this.
Questions
Security reviewers and prospective customers: reach out via [email protected] to request our SIG-Lite/CAIQ-style questionnaire or ask any follow-up questions.