Security model

Security in AthenaDB is designed in, not added on. Three properties matter most.

Encryption at rest and in use

Data is encrypted in the storage engine. Because AthenaDB owns its storage format and crypto — with no bundled third-party datastore — the cryptographic surface is ours to audit and control.

The real-data clearance gate

AthenaDB enforces a real-data clearance gate in the engine itself. Ingestion of real (sensitive) data is blocked until a signed clearance attestation — recording who performed the cryptography and storage-format review, and which review it was — is present and verifies against the trust anchor your deployment configures. This is not a policy note; it is enforced in code, and it fails closed. Without a valid attestation, real-data ingestion simply does not run.

During Early Access, evaluate AthenaDB on synthetic or non-sensitive data. Clearing the gate is a step your organization performs and controls, not one you wait on us for: you decide who reviews the engine, you record their attestation, and the engine verifies it before any real data is accepted.

Instance trust

Cross-instance operations — sync, federated queries — ride the Instance Trust Fabric. Trust is explicit and verifiable between instances rather than implied by shared credentials.

Reporting a concern

If you believe you've found a security issue, contact [email protected] before disclosing publicly.