Security · BYOK & customer-data control

Your keys, your knowledge. Your control.

Cortex uses a Bring Your Own Key model with encrypted Vault storage and row-level customer-data isolation. Your LLM keys never leave Vault, your knowledge never crosses to another customer, and every secret access is logged.

Get started free →Read architecture
[ 01 · BYOK ]

Cortex doesn't hold your LLM API keys.

You bring them. We encrypt them. You rotate them on your schedule.
01 · How it works
  1. 01During onboarding, you provide your LLM API key (Anthropic, OpenAI, or another supported provider).
  2. 02The key is immediately encrypted and stored in Supabase Vault — backed by Postgres's pgsodium encryption.
  3. 03The key is referenced by ID — never stored in plain text in any database.
  4. 04At runtime, the key is read directly from Vault inside the orchestration pipeline — never written to disk, never exposed to the agent runtime itself.
02 · What this means
  • Your key is never visible in the Cortex dashboard.
  • Your key is never stored in application code.
  • Your key is never accessible to anyone except the specific agent deployment it's assigned to.
  • If you revoke or rotate your key, you control that process entirely.
[ 02 · Vault architecture ]

Five layers between your key and the agent runtime.

Cortex uses Supabase Vault for all secrets management.
Layer 01

Encryption at rest

Keys are encrypted using pgsodium — the Postgres extension for libsodium-based encryption. Hardware-accelerated, authenticated encryption (XChaCha20-Poly1305).

Layer 02

Reference-based access

The application database stores a reference ID pointing to the vault entry — never the secret value itself. Application code never sees the decrypted key except during the orchestration pipeline at the moment of use.

Layer 03

Scoped naming

Vault secret naming is scoped per-organization and per-deployment. Organization A's key for Agent 1 cannot be confused with Organization B's key for Agent 2.

Layer 04

Audit logging

Every secret access is logged: who accessed it, when, which deployment, and what operation.

Layer 05

Metadata separation

A dedicated secrets table tracks metadata (organization, deployment, secret name) without exposing values. You can see that a secret exists, but never its contents.

[ 03 · Customer-data isolation ]

Your data never touches another customer.

Row-level isolation in Postgres means every query is scoped to your organization. Your keys, your knowledge, your conversations — completely separate.
Your keys

Vault-only. Always.

What keeps your key safe
  • Encrypted at rest with pgsodium (XChaCha20-Poly1305)
  • Referenced by ID — value never stored in app code
  • Scoped per deployment — no cross-org access possible
  • Read at runtime inside the pipeline only — never written to disk
  • Every access audit-logged
Your data

Row-level isolated.

What keeps your data private
  • Postgres row-level security on every table
  • Every query scoped to your org_id — no cross-org reads
  • Memory facts, conversations, and knowledge all org-isolated
  • No shared process space or session context
  • Your workflow outputs stay in your org scope
Your knowledge

Private per org.

What keeps your knowledge yours
  • Your knowledge hub is private to your org — no other team can read it.
  • Knowledge scoped per agent role — role-specific facts stay with their agent.
  • On cancellation, your knowledge is exportable and fully yours.
[ 04 · What another customer can never see ]

Your data stays yours. No exceptions.

If a session were compromised · could find
  • The agent's conversation context within a single session
  • The tools and integrations the agent has been authorized to call in your org
Another customer can NEVER see
  • Your LLM API key — stored in Vault, scoped to your org, never written to the runtime
  • Your conversations and message history — row-level isolated per organization
  • Your memory and knowledge — scoped to your org in Postgres; other orgs can't query it
  • Your knowledge hub — private per org; no other agent can read it
  • Your workflow outputs and scheduled-job results — scoped to your org's tools and credentials

Blast radius containment: a worst-case event affects one session for one customer. No lateral movement to other customers or the platform itself.

[ 05 · vs. common patterns ]

Cortex vs. the patterns the rest of the market ships.

Same row, four approaches. See where the tradeoffs land.
Security propertyCortexShared API key.env on serverMulti-tenant container
Key encrypted at restVault (pgsodium)Varies
Key isolated from app codeVaries
Per-org data isolationDepends
Secret access audit trailVaries
User controls key lifecycleBYOKUser-managed
Blast radius containedSingle orgEntire platformSingle accountOther tenants at risk

Your keys. Your knowledge. Your control.

Deploy an AI agent with enterprise-grade security in 10 minutes.

Get started free →Back to product