> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlasent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Security overview

> How AtlaSent protects customer data — encryption, access controls, audit-chain integrity, and fail-closed guarantees.

<Note>
  This page is the customer-facing summary of AtlaSent's security posture.
  Detailed engineering security documentation is available on request
  from `security@atlasent.io`;
  the contractual technical and organizational measures live in the DPA
  Annex II (see Legal).
</Note>

## Cryptography

| Control | Implementation |
| - | - |
| Transport encryption | TLS 1.3 for all customer-facing endpoints. TLS \< 1.2 disabled. |
| At-rest encryption | AES-256-GCM (Supabase-managed encryption at the storage layer). |
| API key storage | SHA-256 hash only. Plaintext is returned once at creation; never persisted. |
| Audit-chain integrity (GA) | Append-only, hash-chained entries; HMAC-SHA256-signed permit tokens bound into each entry. Insertion, deletion, or modification of historical entries is detectable. |
| Portable signed evidence bundles (Wave 3 roadmap) | Detached Ed25519-signed packages assembled from the audit chain for offline third-party verification. Three-tier key hierarchy (root / issuing / per-bundle); issuing-key rotation every 12 months on a published schedule. **Not yet GA.** See Evidence bundles for details. |
| Key management | Production signing keys held in a managed secrets vault, separate from primary data. |

See Cryptography for the algorithm-by-algorithm
breakdown.

## Access controls

| Control | Implementation |
| - | - |
| Customer authentication | Console: SSO (when configured) or email + password + TOTP MFA. API: scoped API keys with `<resource>:<action>` permissions. |
| Tenant isolation | Database row-level security enforced on every read, keyed by `organization_id`. No cross-tenant access path. |
| Least privilege | API keys carry minimum scopes required for their use case. `admin:execute` is reserved for internal mint paths and never exposed to customer key minting. |
| Per-key IP restriction | Customers may restrict an API key to specific CIDR blocks at creation time. |
| Per-key rate limit | Per-key token-bucket rate limit, configurable per key. |
| Session management | 1-hour JWT expiry, 30-minute inactivity timeout. |
| Personnel access to production | Named list of personnel with documented business need; all access logged and reviewed. No shared credentials. |

## 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](/concepts/audit-chain) 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](/concepts/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](https://github.com/Atlasent/atlasent-mcp-server#fail-closed-behavior)
for the canonical list.

## Vulnerability and patch management

| Control | Implementation |
| - | - |
| Dependency scanning | Continuous on every PR. |
| Infrastructure scanning | Weekly. |
| Penetration testing | **Planned — no third-party test completed yet.** First external engagement is being scoped (see VQP Delta 2026-06-12.01); annual cadence applies from the first completed test. Summary will be available under NDA upon completion. |
| Remediation SLA | Critical: 7 days. High: 30 days. Medium: 90 days. *Numbers reflect current operating practice; the formalised SLA will publish here once committed.* |
| Supply chain | Production deploys via reviewed GitHub Actions workflow with policy gate. No manual production access. Release artifacts signed. |
| Secret scanning | Pre-commit and CI; alerts to dedicated channel; rotation runbook on alert. |

## Operational security

| Control | Implementation |
| - | - |
| Incident response | Documented IR plan, on-call rotation, blameless post-incident review within 5 business days. |
| Personnel | Confidentiality agreements at hire; background checks before production access; mandatory annual security training. |
| Endpoint posture | Managed devices via MDM; disk encryption; screen-lock; remote-wipe capability. BYOD prohibited for production access. |
| Physical security | AtlaSent operates no data centers. All compute and storage runs on sub-processors with audited physical security (see [Sub-processors](/trust/subprocessors)). |
| Backups | Provider-managed daily backups; **retention windows are targets pending the provider's written attestation** (VQP Delta 2026-06-12.01). The prior 7-year cold-storage claim is withdrawn until evidenced. Quarterly restore-drill cadence begins with the first executed drill (scheduled). Verified today: the audit chain is append-only and not purged; permit-use purge has an enforced 90-day floor. |
| Logging | Centralized log aggregation; system access logs retained ≥ 12 months. |

## 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](/trust/compliance-status)
* [Sub-processors](/trust/subprocessors)
* Reliability and SLO
* Audits and assurance


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.