Security overview

​

Cryptography

See Cryptography for the algorithm-by-algorithm breakdown.

​

Access controls

​

Audit chain (GA today)

Every authorization decision and every Console mutation lands in an immutable, append-only audit chain. The chain has two properties customers rely on today:

1. Hash-chained. Each entry references the hash of the previous, so insertion, deletion, or modification of a historical entry is detectable.
2. HMAC-signed permit tokens. Each authorization decision binds an HMAC-SHA256-signed permit token into the chain entry, providing cryptographic integrity on the authorization itself.

Cryptographic-primitive boundary (unambiguous). At GA, the audit chain’s integrity rests on (a) SHA-256 hash-chaining of entries and (b) HMAC-SHA256 signatures on the permit tokens bound into entries. Ed25519 signing is associated only with the Wave 3 portable evidence bundle surface described in the next section. The chain itself is not Ed25519-signed today. Where other AtlaSent documentation references an “Ed25519-signed audit chain,” that wording is being reconciled to distinguish chain integrity (hash + HMAC, GA) from bundle integrity (Ed25519, Wave 3 roadmap). Customer verification today is API-mediated inspection of the audit chain. See Audit chain design for the wire format.

​

Portable signed evidence bundles (Wave 3 roadmap)

Beyond the immutable chain, AtlaSent is building detached, Ed25519-signed evidence bundles for portable third-party offline verification — the artifact a customer’s auditor verifies without any AtlaSent infrastructure in the loop. Bundles are a distinct trust surface from the chain: the chain proves event continuity in-place; bundles provide externally- verifiable proof of a defined audit window. Status: specification written as a Draft (available on request from security@atlasent.io; see also Evidence bundles); implementation gated on spec ratification (target 2026-08-15) and follows on the wave-anchor timeline. The spec defines a three-tier Ed25519 key hierarchy (root / issuing / per-bundle), 12-month issuing-key rotation cadence, compromise-recovery procedure, and a seven-step offline verification path. Reference verifier implementations in Python and TypeScript ship alongside spec ratification. Bundles are not yet generally available. The boundary between the chain and bundles is preserved on this portal even after Wave 3 GA. See Proof verification for the verification flow design.

​

Fail-closed guarantees

The authorization decision is the only product output that matters for safety. Every failure path collapses to a deny decision rather than a silent allow:

• API unreachable → deny.
• Request timeout (10 s) → deny.
• Malformed response → deny.
• Remote returns allow without a permit_token → deny.
• Unknown decision string → deny.
• Permit verification returns an unrecognized verify_error_code → invalid (treated as not valid).

No path in the SDKs, the MCP server, or the GitHub Actions gate returns a permissive result on error. See the atlasent-mcp-server fail-closed behavior for the canonical list.

​

Vulnerability and patch management

​

Operational security

​

Reporting a vulnerability

Email security@atlasent.io. We respond within one business day. See Security disclosure for scope and the disclosure timeline.

​

See also

• Compliance status
• Sub-processors
• Reliability and SLO
• Audits and assurance