Zero-knowledge by architecture

Share cloud truth.
Never your secrets.

CloudAutomaton is the secure layer for sharing cloud information and the advanced encryption center that governs application access. Every object is sealed on your device, wrapped by keys you control, and granted through short-lived, scoped access.

No plaintext at rest. No key escrow by default. 14-day pilot, no card required.

Designed against
SOC 2 Type II ISO 27001 GDPR HIPAA BAA FIPS 140-3 modules NIST 800-57
0Plaintext bytes written to our storage
11 msp95 key-wrap latency, EU → EU
99.99%Vault availability, trailing 12 months
31Regional key domains (data stays local)
The platform

One control plane for cloud knowledge and the keys that unlock it.

Teams leak cloud information through screenshots, shared drives and over-privileged service accounts. CloudAutomaton replaces that sprawl with sealed objects, scoped grants, and a proof trail every auditor can verify.

Zero-knowledge sharing

Objects are encrypted in the browser or SDK before upload. Our servers route ciphertext and wrapped keys — never plaintext, never a usable secret.

AES-256-GCM · XChaCha20

Advanced Encryption Center

A single console for key lifecycle: generate, rotate, split, revoke. Envelope encryption per object, KEKs resident in FIPS-validated HSM or your own KMS.

KEK / DEK · HSM-backed

Keys you actually own

BYOK and HYOK with split-knowledge ceremony: Shamir shares across your custodians, so no single party — including us — can reconstitute a key.

BYOK · HYOK · Shamir 3-of-5

Application sharing

Grant an app — not a human — access to exactly one sealed object. OIDC/SAML identity, per-app scopes, 15-minute tokens, instant revocation.

OIDC · SAML · scoped tokens

Tamper-evident proof ledger

Every seal, wrap, grant and reveal is hash-chained and signed. Export a verifiable audit pack without exposing a single byte of content.

Hash-chained · exportable

Post-quantum ready

Hybrid key agreement combines X25519 with ML-KEM-768 today, so objects sealed now stay confidential through the harvest-now-decrypt-later window.

X25519 + ML-KEM-768
The Encryption Center

Crypto operations, made an operational discipline.

Most breaches are key problems, not cipher problems. The Encryption Center gives you one place to define how data is wrapped, who can unwrap it, and what happens when trust changes.

  • 01
    Envelope encryption on every object

    A unique DEK per object, wrapped by a versioned KEK. Rotating a KEK never re-encrypts the corpus.

  • 02
    Key ceremony with split custody

    Generate the root in-browser, split it into Shamir shares, and distribute to custodians. Reconstitution requires quorum.

  • 03
    Policy as code

    Declare who unwraps what, for how long, from which network. Policies are versioned, diffable and enforced at the wrap call.

  • 04
    Cryptographic erasure on demand

    Destroy the wrapped DEK and the object becomes unrecoverable everywhere — including backups you no longer control.

KEY GRAPH · kek-7 / eu-central

a1f…
b74…
c02…
d9e…
e31…
f88…
07c…
1d5…
AlgorithmXChaCha20-Poly1305
KEK custodyCustomer HSM
Rotation90 days · auto
Shamir shares3-of-5 custodians
Grants active12 · 0 expired

key health · 98.4% · last rotation 12d ago

How it works

Seal. Grant. Reveal.

Three verbs, one API surface. The same object model works from a browser, a CLI, or a backend service — encryption always happens on the client side.

STEP 01

Seal on the client

Your SDK generates a fresh DEK, encrypts the payload locally, and wraps the DEK against the tenant KEK. Only ciphertext reaches us.

STEP 02

Grant to an application

Issue a scoped grant to an app identity rather than a person. Scope, TTL, network and purpose all evaluated at unwrap time.

STEP 03

Reveal with proof

The app unwraps in memory, decrypts locally, and the ledger records the event — signed, hash-chained, and independently verifiable.

// Encryption happens on your device. The key never leaves.
import { Vault } from "@cloudautomaton/vault";

const vault = new Vault({ region: "eu-central" });

const sealed = await vault.seal(file, {
  algorithm: "xchacha20-poly1305",   // or aes-256-gcm
  wrap:      "hsm://eu-central/kek-7",
  redact:    ["account_id", "secret_arn"],
  pqc:       true,                        // hybrid X25519 + ML-KEM-768
});

await vault.grant(sealed.id, {
  to:     "app://finops-reader",        // an app, not a person
  scopes: ["read"],
  ttl:    "15m",
  net:    "10.0.0.0/8",
});

// returns a signed, hash-chained ledger entry
const proof = await vault.verify(sealed.id);
console.log(proof.block, proof.chain);   // 48201 "ok"
# Server-side workloads use the same object model.
from cloudautomaton import Vault

vault = Vault(region="eu-central", kms="customer-hsm")

sealed = vault.seal(
    path="cloud_inventory.json",
    algorithm="aes-256-gcm",
    pqc=True,
)

vault.grant(
    sealed.id,
    to="app://cost-anomaly-detector",
    scopes=["read"],
    ttl="15m",
)

# Cryptographic erasure: the object becomes unrecoverable everywhere.
vault.destroy(sealed.id, reason="retention_expired")
$ ca login --org acme --region eu-central
✓ authenticated · mfa ok · ledger attached

$ ca seal ./contract_v4.pdf --to app://finops-reader --ttl 15m
✓ sealed obj_8f21c   2.4 MB → 2.4 MB ciphertext
  dek     xchacha20-poly1305 · 32 bytes
  kek     hsm://eu-central/kek-7
  ledger  block #48,201 committed · chain ok

$ ca grant obj_8f21c --app finops-reader --scope read --net 10.0.0.0/8
✓ grant grt_31b issued · expires in 15m

$ ca audit --verify
✓ 48,207 blocks verified · 0 breaks · 0 plaintext recorded
Architecture

We are structurally unable to read your data.

Keys are wrapped in your custody domain. Ciphertext is routed, never re-written. The control plane sees metadata and policy — not content.

Your client browser · SDK · CLI seal() locally DEK never exported Control plane routing · policy · grants sees: metadata only never: plaintext 31 key domains p95 wrap 11 ms Your key custody HSM / customer KMS KEK · versioned 3-of-5 Shamir Proof ledger hash-chained exportable Recipient app unwraps in memory ttl 15m ciphertext wrap req sign grant
Client-side encryption
Customer-held key material
Metadata & policy only
Pricing

Priced per seat. Keys included.

Every plan ships the full crypto stack. You pay for scale, custody options and audit depth — never for cipher strength.

Developer
For a first proof of concept or a solo workload.
$0/ forever
  • 1 tenant · 3 app identities
  • Local-key mode (no HSM)
  • 10 GB sealed · 7-day ledger
  • Community support
Start free
Most adopted
Team
For platform teams sharing cloud context across functions.
$29/ user / month
  • Unlimited tenants & app identities
  • HSM-backed KEKs · 90-day rotation
  • OIDC / SAML · SCIM provisioning
  • 1 TB sealed · 1-year ledger
  • Post-quantum hybrid on by default
Start 14-day pilot
Enterprise
For regulated environments with their own key custody.
Customannual
  • BYOK / HYOK · key ceremony runbook
  • Dedicated key domain · data residency
  • Immutable ledger export · SIEM streaming
  • BAA · DPA · security review support
  • Named architect · 99.99% SLA
Talk to us
Questions

The ones a security reviewer asks first.

If CloudAutomaton can't read my data, how does search work?

Metadata — object names, tags, ownership, classification and policy — is stored in plaintext and is what you search. Content stays sealed. Optional blind indexes let you run equality lookups on chosen fields without exposing values, at the cost of a small amount of leakage you explicitly opt into.

What happens if we lose our keys?

Nothing is recoverable — that is the point, and we will not pretend otherwise. Teams that need a safety net configure a Shamir quorum with an escrow custodian of their own choosing. CloudAutomaton never holds a share by default, and can never assemble a quorum on its own.

Which algorithms are actually in use?

XChaCha20-Poly1305 or AES-256-GCM for object encryption, AES-256-GCM or AES-256-KW for key wrapping, HKDF-SHA-256 for derivation, and a hybrid KEM (X25519 + ML-KEM-768) when post-quantum mode is on. Modules are FIPS 140-3 validated where required; the full cipher suite is published in the docs.

What does "application sharing" mean in practice?

A grant is issued to an application identity rather than a person. The app proves its identity over OIDC or a workload-attested token, and receives a short-lived capability bound to a scope, a purpose and optionally a network range. Revoking the grant or rotating the KEK cuts access immediately, without touching the encrypted corpus.

Can we deploy in our own cloud account?

Yes. The control plane can run in your VPC with key material confined to your KMS or HSM. In that mode we operate software you control, and our visibility stops at telemetry you opt into.

How do you prove the ledger wasn't rewritten?

Each block commits to the hash of its predecessor and is signed with a tenant-scoped key. Export any range and verify the chain independently of our infrastructure — the verification tool is open source, and anchored roots are published hourly.

Contact us

Talk to someone who works on keys for a living.

Pilots, security reviews, key-custody design or a straight answer about how the ledger verifies — reach the team directly. A person replies, not a ticket bot.

Security disclosures go to the same inbox and are triaged within 24 hours. Please don't send production secrets, key material or customer data by email — use a sealed object instead and grant app://cloudautomaton-review.

Send a message

Fields marked with * are required.

Or email [email protected] · call (724) 701-0024
Now onboarding design partners

Seal your first object in under ten minutes.

Tell us where you run and what you need to share. We'll open a pilot tenant with a dedicated key domain and walk your security team through the architecture.

No card required · SOC 2 package available on request

Prefer to talk first? [email protected] · (724) 701-0024