Security
Security
Every control on this page is one you configure yourself, from the workspace security settings or the API, with nobody at Engram in the loop. This page is the map: what protects a workspace by default, what you can turn on, and where each one is documented.
What you can turn on
Single sign-on, the IP allowlist and the customer key belong to specific plans. The plan table is the one place that says which.
Signing in
There are three ways into a workspace, and an admin decides which of them a workspace uses.
- Email and password. Passwords are hashed with PBKDF2-HMAC-SHA256 at the OWASP 2024 cost, never stored or logged in the clear. A sign-in attempt against an address that has no account burns the same hashing time as a real one, so response timing does not reveal which addresses exist.
- Google. A Google account with a verified address signs in with no local password at all, and the account is structurally unable to acquire one later.
- Your own identity provider. Single sign-on over OpenID Connect, and you can require it, which stops passwords working for the whole workspace.
Open signup asks for email verification before any document can be loaded: an unverified user can sign in and look around, and gets a 403 email_unverified with a resend link the moment they try to add something. Production is invite-only today, so an account there starts from an invite and the invite itself proves the address.
| Credential | Lifetime |
|---|---|
| Password | 8 to 128 characters, hashed with PBKDF2-HMAC-SHA256 |
| Browser session | 24 hours, and it ends when the browser closes |
| Session with remember me | 30 days, counted from the last time it was used |
| Any session, whatever happens | 90 days |
| Email verification link | 48 hours, single use |
| Password reset and invite links | Single use, stored only as a hash, expire on their own schedule |
| API key | Never, or an expiry you set |
A password reset invalidates every session minted before it, in every browser, immediately.
Staying signed in
Check Remember me on this device and you stay signed in for 30 days. Signing in with Google or with your company account does the same thing without asking, because you have already told your identity provider to trust the device.
The 30 days run from the last time you used Engram, not from the day you signed in, so an account you use regularly stays signed in. After 90 days we ask for your password again whatever happens, and signing out or changing your password ends every session everywhere straight away.
Leave the box unchecked and the session ends when you close your browser.
How a request is authorized
Two credentials reach the API: a session token from the browser, and an ek_ API key from your own tools. Both resolve to a workspace, and every route is filtered on that workspace, so a workspace never sees another's data and a wrong id returns 404 rather than 403, because confirming that someone else's id exists is itself a leak.
A key is narrower than a person. Scopes cut what a key can change or spend, an admin scope is what lets a key reach workspace administration, and a key can never reach the platform console at all. See API keys and scopes.
Three checks run on every authenticated request, whichever credential it came with: the workspace is not suspended, the session was minted after the last password reset, and the request came from an allowed network when an IP allowlist is configured.
You can read your workspace's current settings with any admin credential:
curl -s https://api.engramdynamics.org/enterprise/sso \
-H "Authorization: Bearer <your key>"
curl -s https://api.engramdynamics.org/enterprise/ip-allowlist \
-H "Authorization: Bearer <your key>"
curl -s https://api.engramdynamics.org/enterprise/kms-key \
-H "Authorization: Bearer <your key>"Reading these is open to any workspace admin on any plan, so you can see what a control would involve before you buy the plan that turns it on. Writing is what the plan gates.
What happens to your documents
Documents are read once and compiled into model memory. The model weights are never modified and nothing is trained on your content, so your documents do not become part of a model anyone else can query.
- In transit. HTTPS to the API and to the app.
- At rest. Server-side encryption in the document store, on the platform key by default or on your own KMS key where your plan carries it.
- Integrity. Every compiled memory blob is stamped with a SHA-256 when it is stored and re-verified every time it is loaded, so a corrupted or tampered blob fails at the boundary and never reaches the model. The blob format cannot execute code when it loads.
- Isolation. A request only ever attends over its own workspace's memory, and there is no substitute. A question whose memory cannot be found or cannot be verified is answered without it, never from another document's. Space that was reserved for a memory and then not filled with it is cleared, rather than left holding whatever occupied it before.
- Containment. One bad request is one bad answer. A missing memory, a storage outage or a blob that fails its integrity check degrades that single question, counted and logged, while serving keeps running for everyone else.
- Deletion. A delete clears the warm serving copy before it removes the durable one, and writes a receipt naming every tier it touched. Data lifecycle and deletion has the full timeline.
Proving what happened
Key lifecycle, security-setting changes, deletions, source and webhook changes and legal acceptance all write an append-only row you can read back and download. See Audit log and Exports.
Next
Start with API keys and scopes if you are wiring up your own tools, or Single sign-on if you are rolling Engram out to a team.