Trust, Governance & Security · 09.07
Auth & Secrets
AES-256-GCM credential encryption, hashed API keys, and an auto-generated RS256 JWT keypair with workspace–user ownership re-checked on every request.
Nothing sensitive is stored, or returned, in the clear
Stored credentials are encrypted with AES-256-GCM and are never returned decrypted through any API — a credential can be used by the platform on your behalf, but never read back out. API keys are hashed at rest, the same discipline a password would get; even a full database dump doesn't hand over a usable key. Auth issues JWTs signed with an auto-generated RS256 keypair, so token verification never depends on a symmetric secret that has to be separately protected on every verifying process.
A valid token for the wrong workspace is still rejected
Every authenticated request re-checks that the token's user actually owns (or belongs to) the workspace it's targeting — a structurally valid, correctly-signed JWT for workspace A is still rejected outright on a request scoped to workspace B. This closes a specific, easy-to-miss class of bug: a multi-tenant-shaped system where the auth check only verifies the signature and forgets to re-verify the tenant boundary on every single call, not just at login.
| Login rate limit | Limit | Why |
|---|---|---|
| Per (IP, username) pair | 5 attempts / minute | Stops brute-forcing one specific account. |
| Per IP, any username | 20 attempts / minute | Stops an attacker dodging the per-account limit by spraying many usernames from one IP. |
Continue
The Experiment primitive: define, assign, record, and read results — A/B-style assignment and outcome tracking, feeding the same trust + learning loop the Brain uses.
Scanning untrusted ingested content for injection carriers, neutralizing invisible characters, and raising approval friction rather than pretending pattern-matching is complete.