Security & data handling
How MarkDB protects credentials and isolates accounts.
Transport
In the managed and reference deployments, Caddy terminates TLS and auto-issues
Let's Encrypt certificates for every host (api, mcp, proxy, and the
dashboard). All traffic to MarkDB is over HTTPS.
Authentication
- API keys are
mk_live_tokens; only a SHA-256 hash is stored, and the plaintext is shown once. Each key is scoped to one (account, workspace, agent) triple ((tenant, app, agent)in API terms) withread/writescopes, and revocation is immediate. See Authentication. - Dashboard access is OAuth (GitHub / Google) with short-lived JWT session cookies. Control-plane actions (managing accounts, workspaces, agents, keys) require a signed-in session, not an API key.
Credential encryption
The model-provider keys you add under Settings -> LLM keys are envelope-encrypted at rest:
- A fresh random 256-bit data-encryption key (DEK) encrypts the credential with AES-256-GCM.
- The DEK itself is wrapped by a key-encryption key (KEK) that lives outside the application.
The KEK is a local AES-256 key supplied via MARKDB_LOCAL_KEK_BASE64, sourced
from a secret manager in the managed and default deployments. Decrypted DEKs are
cached in memory for about 60 seconds so a busy proxy does not call the KEK on
every request. The KEK identifier is stored alongside each ciphertext so key
rotation is detectable. A Google Cloud KMS backend also exists in the codebase
but is not wired into the current build.
Account isolation
Memory is partitioned by (account, workspace, agent). An API key only ever reads its own account's data, and agents do not see each other's raw turns unless they explicitly share through broadcasts. The rate limiter is keyed the same way.
What's stored
To provide memory, MarkDB stores what flows through the proxy: the prompts, model responses, and tool calls of each captured exchange, plus the derived summaries and their embeddings. You bring your own model-provider keys; MarkDB uses them only to dispatch your requests and enrichment.
For data-handling and privacy terms, see the Privacy Policy.