The BYOK Security Model: How Cortex Keeps Your LLM Keys Safe

When you deploy an AI agent in production, you're entrusting it with some of your most sensitive credentials: API keys for OpenAI, Anthropic, or other LLM providers; database passwords; third-party service secrets. The way these keys are stored, accessed, and rotated can mean the difference between a secure deployment and a catastrophic data breach.

Most self-hosted agent platforms treat this casually. Keys get dumped into .env files, stored in plaintext, scattered across multiple servers, and accessed without any audit trail. If your server is compromised or a developer leaves the company, you have no idea who accessed what or when.

Cortex takes a fundamentally different approach. We've built a BYOK (Bring Your Own Key) security model that treats your secrets with the same rigor that banks use for encryption keys. Here's how it works, and why it matters.

The Problem with Plaintext Environment Files

Before we dive into the solution, let's understand what goes wrong with conventional approaches.

In a typical self-hosted setup:

• Developer adds secrets to a .env file
• The .env file sits on disk in plaintext
• Any process with filesystem access can read it
• If the server is compromised, an attacker has everything
• There's no log of who accessed the key or when
• Rotating a key means updating the file and restarting the service (downtime)
• There's no way to enforce different permissions for different keys

The risk surface is enormous. A misconfigured S3 bucket, a weak SSH password, a supply chain attack on your dependency chain: any of these could expose your entire .env file.

Cortex's BYOK Architecture

Cortex uses a multi-layered approach to secret management that eliminates plaintext storage and enables comprehensive audit logging.

Layer 1: Supabase Vault with pgsodium Encryption

At the core of our system is Supabase Vault, which uses pgsodium (a PostgreSQL wrapper around libsodium) to encrypt secrets at rest. Here's what this means:

• Your API keys are encrypted using authenticated encryption (XChaCha20-Poly1305)
• The plaintext key never exists on disk unencrypted
• Encryption happens in the database layer, not the application layer
• The encryption key itself is managed separately from the encrypted data
• Even Cortex engineers with direct database access cannot read your secrets in plaintext

When you provision an agent and add an API key, that key is immediately encrypted and stored in the Supabase Vault. The plaintext is never logged, never cached, never written to disk.

Layer 2: Secret References by ID

Your running agent doesn't need access to the plaintext key. Instead, it gets a reference ID.

Here's how it works:

1. You add an OpenAI key to Cortex
2. Cortex encrypts it and stores it in Supabase Vault
3. The system assigns it a unique ID (e.g., secret_abc123def456)
4. Only that ID is written to your agent's environment
5. When the agent needs the key, it queries the Vault by ID
6. The Vault decrypts on-the-fly, returns the plaintext only to the requesting process

The agent's environment file never contains the actual key. This means:

• If someone gains filesystem access, they see OPENAI_KEY_ID=secret_abc123def456 instead of the actual key
• The ID is useless without access to the Vault
• You can revoke access to individual agents without changing the underlying secret
• You can rotate keys without touching the agent's environment

Layer 3: Per-Organization and Per-Deployment Scoping

Secrets are scoped in layers to prevent accidental cross-contamination.

When you create a secret in Cortex, it's:

• Scoped to your organization (other orgs cannot see it)
• Scoped to your deployment (agents in other deployments cannot access it without explicit permission)
• Tagged with metadata indicating which agents can reference it

This architecture makes it safe to run multiple projects or environments in the same Cortex workspace. Your staging agents cannot accidentally pull production API keys.

Layer 4: Comprehensive Audit Logging

Every access to a secret is logged in the secret_access_log table. The log records:

• Which agent requested the secret
• Which secret ID was accessed
• The timestamp of the access
• Whether the access was successful or denied
• The IP address and user agent of the request

This audit trail serves multiple purposes:

• Compliance: If you need to prove you didn't access a key during a certain period, the log proves it
• Investigation: If you suspect a breach, you can trace exactly which agents accessed which keys and when
• Alerts: You can set up notifications when a key is accessed abnormally (e.g., from an unexpected deployment)

Even Cortex cannot hide access to your secrets. Every pull through the Vault is logged.

Layer 5: Secure Provisioning Pipeline

When an agent is provisioned (deployed), secrets must flow from the Vault to the agent's environment. This is where many systems leak data.

Cortex's provisioning pipeline works like this:

1. The provisioning orchestrator requests secrets by ID from the Vault
2. The Vault returns decrypted plaintext only within that request context
3. The plaintext is immediately written to a file on the agent's dedicated server
4. The file is owned by root with mode 0600 (read/write for root only, no access for anyone else)
5. The plaintext is never logged, never cached, never transmitted over an insecure channel
6. Only root (the systemd service running as root) can read the file
7. The application process spawned by systemd inherits access to the secret through the file descriptor

This ensures that even the agent developer (who might SSH into the server) cannot read the secret file directly. The secret exists only in memory, accessible only to the running process.

Automatic Secret Rotation

One of the biggest advantages of the Cortex BYOK model is that you can rotate secrets without downtime.

To rotate an OpenAI API key:

1. Generate a new key in the OpenAI dashboard
2. Update the secret in Cortex
3. Cortex marks the old secret as deprecated
4. New requests from your agent use the new key
5. Old requests complete using the old key (for a configurable grace period)
6. The old key is automatically removed from all environments

The agent keeps running. No restart. No downtime. This makes security practices like key rotation actually feasible in production environments.

Comparison: Cortex vs. Self-Hosted

Here's how Cortex stacks up against managing secrets manually on self-hosted infrastructure:

| Capability | Self-Hosted | Cortex | |---|---|---| | Plaintext secrets on disk | Yes (default) | Never | | Encryption at rest | No | Yes (pgsodium/XChaCha20) | | Audit logging | No | Yes (every access logged) | | Per-organization scoping | No | Yes | | Per-deployment scoping | No | Yes | | Secret rotation without downtime | No | Yes | | Automated provisioning | Manual (error-prone) | Fully automated |

Why This Matters

Security isn't a feature you add at the end. It's a fundamental architectural choice. By making BYOK central to our platform, we've eliminated entire classes of vulnerabilities:

• No plaintext secret leaks from accidental code commits
• No compromised servers exposing all your API keys
• No audit trail gaps when you need to investigate
• No manual secret rotation procedures that fail and create inconsistency

Your LLM API keys are some of your most valuable assets. They're the gateway to your models, and they're often used in high-volume production deployments. Cortex treats them accordingly: encrypted, audited, scoped, and automated.

Because when you're running AI agents in production, security shouldn't be a compromise. It should be the default.

Experience enterprise security out of the box. Sign up at launchcortex.ai and deploy agents with BYOK encryption, audit logging, and zero-knowledge security.