Security & data handling

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 (tenant, app, agent) with read/write scopes, and revocation is immediate. See Authentication.
Dashboard access is OAuth (GitHub / Google) with short-lived JWT session cookies. Control-plane actions (managing tenants, apps, 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.

Two KEK backends ship: a local AES-256 key supplied via MARKDB_LOCAL_KEK_BASE64 (used by the managed and default deployments, sourced from a secret manager), and a Google Cloud KMS backend. Decrypted DEKs are cached only briefly in memory so a busy proxy doesn't call the KEK on every request. The KEK identifier is stored alongside each ciphertext so key rotation is detectable.

Tenant isolation

Memory is partitioned by (tenant, app, agent). An API key only ever reads its own tenant's data, and agents don't see each other's raw turns unless they explicitly share through broadcasts. The API's per-tenant 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.