Security overview
- Written for
- ＋ Written for
- Deprecated
- ＋ Deprecated
- Applies to
- ＋ Applies to
Security overview
Security in Atlas is layered: some of it is always on and needs nothing from you, and some of it is a control you tune per instance. This section covers the controls you own — attack protection, who may sign up, session lifetimes and revocation, and the audit trail.
Always on
Encryption at rest. Every sensitive value — provider secrets, refresh tokens, SCIM and captcha secrets — is encrypted with a per-instance data key derived from a root key using envelope encryption. See Configuration & secrets.
Secrets stay server-side. The browser only ever holds a publishable key; secret keys and provider credentials never leave your backend or the Atlas core.
Tenant isolation at the data layer. The repository refuses to read across instances or organizations, so a request can't return another tenant's data.
Signed, short-lived sessions with refresh-token reuse detection — see Sessions & JWTs.
Controls you own
Control | What it protects against | Page |
|---|---|---|
Attack protection | Brute force, bots, breached passwords | |
Allowlist & blocklist | Unwanted sign-ups, specific addresses/IPs | |
Session security | Stale or stolen sessions | |
Audit logs | Not knowing who did what | |
Account recovery | Users locked out of their accounts |
A note on change safety
Every security-relevant change in the dashboard — a policy edit, a key rotation, a secret reveal — is written to the audit log, and disabling a defense (the brute-force lockout, breached-password checks) is called out in the UI as weakening sign-in. Security controls are meant to be turned up, not quietly off.
Next
Turn on the front-line defenses → Attack protection.