Security · Vault & customer-data control

Your knowledge. Your control.

Cortex uses encrypted Supabase Vault storage for all secrets, with row-level customer-data isolation. Your credentials never leave Vault, your knowledge never crosses to another customer, and every secret access is logged.

Get started free →Read architecture

[ 01 · Vault architecture ]

Five layers between your secrets 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.

[ 02 · Customer-data isolation ]

Your data never touches another customer.

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

Your secrets

Vault-only. Always.

What keeps your secrets safe

Encrypted at rest with pgsodium (XChaCha20-Poly1305)
Referenced by ID — value never stored in app code
Scoped per org — 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.

[ 03 · 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 integration credentials — 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.

[ 04 · vs. common patterns ]

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

Same row, four approaches. See where the tradeoffs land.

Security property	Cortex	Shared API key	.env on server	Multi-tenant container
Key encrypted at rest	Vault (pgsodium)			Varies
Key isolated from app code				Varies
Per-org data isolation			Depends
Secret access audit trail				Varies
Blast radius contained	Single org	Entire platform	Single account	Other 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