Encrypted Vaults

Copy MarkdownOpen

Vaults are encrypted document stores for content that should be protected at the application layer — private documents an AI agent needs to read, without exposing that content (or the encryption keys) to the agent's runtime. See the Vaults API reference for endpoints.

How it works (envelope encryption)

document bytes ──encrypt(DEK)──▶ [IV ‖ ciphertext] ──▶ object storage
                                   ▲
        per-vault DEK ──wrap(KEK)──┘ (wrapped DEK stored on the vault row)

• Per-vault DEK — each vault gets its own random AES-256 data encryption key.
• Wrapped by a KEK — the DEK is encrypted with the platform key encryption key and only the wrapped form is stored. Compromising one vault's DEK never exposes another vault.
• Ciphertext only — documents are encrypted before they reach object storage. Plaintext is never written to storage or the database.
• Bound to identity — each ciphertext is authenticated against its org / vault / document (AES-GCM AAD), so a swapped or relocated object fails to decrypt.

How agents read a vault — without keys

The decrypt step happens server-side on an authorized read. Agents never hold the DEK or KEK:

1. Your orchestrator (which holds the master key) mints a short-lived, read-only scoped token: { "vaults:<id>": ["read"] }, expires_in: 3600 (1 hour — the minimum TTL; revoke the token when the task detaches for tighter bounds).
2. Inject the token into the sandbox as an environment variable. Never bake it into an image or commit it, and never write it to .git/config.
3. The agent calls GET /v1/vaults/:id/documents/:docId; Coregit checks the scope and organization, decrypts server-side, and returns the plaintext.
4. Revoke the token (or let it expire) when the task ends.

If you want zero credentials in the sandbox, have the orchestrator proxy the read instead — the sandbox calls your orchestrator, which holds the token and forwards to Coregit.

Threat model

Vaults protect against object-storage theft, database exposure, backups, cross-tenant access, and casual insider access — the platform stores only ciphertext and gates every read by scope and org.

Vaults are not zero-knowledge: an authorized server decrypts content to serve it to the agent, so the operator is technically able to read content during processing. If you need the operator to be provably unable to read content (e.g. regulated data), that requires confidential computing (TEE), which is out of scope for this layer.

Limits

• One request-body limit applies to uploads (25 MB).
• Vault documents are not semantically indexed — vaults are a private store, not a search corpus. Use repositories / LLM Wiki for searchable knowledge.