AgentDB / Access
The front door is built in.
Most stacks buy identity in one place, permissions in another, and audit in a third — then hope the seams hold. In AgentDB the door, the keys, and the ledger are part of the database itself.
Passkeys for people.
Your team signs in with passkeys — no passwords to leak. TOTP and single-use recovery codes back the front door, and step-up checks guard the sensitive moves.
Scoped keys for software.
Every service and agent gets its own key with its own role — read, write, admin — down to individual tables. A key that only reads can never be talked into writing.
Every decision is signed.
Allowed or denied, every request lands in the tamper-evident ledger with who, what, and when. Even “no” is on the record — that's what an audit wants to see.
Built for systems that need proof.
The only database where a prompt can’t ship until its evals pass — and where even “no” is signed into the ledger.
Every request answers four questions first: who’s asking, what they may touch, whether it’s sealed, and how much damage it could do. Even “no” goes in the ledger.
Who is calling.
- AgentDB Access — the built-in identity plane: humans sign in with passkeys and MFA, agents with scoped keys
- Provider credentials live in a sealed vault — agents use them, never read them
- Expire or revoke anyone, human or agent, in an instant
What they may touch.
- Permissions are checked on every single statement
- Search is permission-aware: forbidden rows never reach the ranking — enforced in the planner, not your app code
- Refusals are recorded, not just blocked
Sealed at rest.
- Seal everything on disk with AES-256 — the log, segments, indexes, individual columns
- Envelope-wrapped keys: your KMS — AWS KMS, Vault, or age
- Your control, rotated online — no downtime to re-key
Blast radius, capped.
- Runaway queries are stopped before they commit
- Per-tenant isolation: limits, logs, GC, checkpoints — one caller can't starve or read the rest
- Overload is refused cleanly, never cascading
For the evaluating engineer.
Passkey-first registration and login ceremonies; server-side sessions with SameSite=Strict, HttpOnly cookies and refresh TTLs; hardened CSRF sync tokens.
TOTP (RFC 6238) as a backup factor that only upgrades an existing session; enrollment secrets shown once and sealed at rest; single-use recovery codes, digest-only.
Grants are enforced inside query planning — a JOIN that touches a denied table is refused, and forbidden rows never even reach vector ranking. Not middleware; physics.
Third-party credentials live envelope-encrypted with per-credential data keys (age, Vault transit, or AWS KMS), and are only ever used server-side through an SSRF-safe relay — across a spread of real providers, secret zeroized the moment the response starts. The credential goes in; it never comes back out.
A teammate connects to a database resource without ever holding a credential — the broker authorizes every operation against their grants, derives read-only vs read-write from what they were granted, and writes each query to the access log. Grant expires, the live session narrows or ends.
Per-key token-bucket rate limits and per-statement budgets (scanned rows, execution time). Keys expire on a timestamp — revocation without a restart.
The tenant comes from the key, never the request. Every query is pre-filtered in the planner; every tenant has its own catalog, limits, logs, and GC.