Enterprise Security

Security for CortexDB should be planned the same way you plan security for other stateful application infrastructure: around identity, network boundaries, storage controls, auditing, and operational responsibility. This page covers those deployment considerations at a high level; for the field-by-field configuration see Security & Compliance.

Authentication and access

Applications typically authenticate to CortexDB using bearer credentials:

curl https://api-v1.cortexdb.ai/v1/recall \
  -H "Authorization: Bearer your-api-key"

On self-hosted deployments, setting CORTEX_API_KEY requires bearer authentication and the configured value itself is the working credential (compared in constant time; PASETO v4 and JWT bearer tokens also work). There is no shipped default key. To run unauthenticated for local dev, set CORTEX_INSECURE_NO_AUTH=1 (every request served as user:local; binds loopback) — never expose that mode to a network. A keyless, network-exposed server auto-generates a key and requires it rather than serving open. The default dev_local preset does not enforce it — an X-Cortex-Actor header with no bearer is still served — so on a network-exposed server also set CORTEX_DEPLOYMENT_PRESET=on_prem_enterprise (or a cloud_* preset); see Authorization.

For production, define: how application credentials are issued and rotated; which services and operators may access CortexDB; and how tenant / workspace / environment boundaries are enforced.

Encryption and transport protection

Follow your organization's standards for encrypting sensitive data, protecting secrets and service credentials, terminating TLS (or applying network-layer encryption), and restricting access to trusted networks and workloads.

Tenant governance

For multi-tenant or multi-workspace environments, plan for clear tenant scoping in applications and integrations, environment separation (dev / staging / prod), least-privilege access for services that read or write memory, and review paths for retention, deletion, and data-handling requirements. See Multi-Tenancy for the tenant-isolation model (tenant = token audience, the cloud_shared_saas preset, per-tenant scopes) and Scopes for the addressing model within a tenant.

Auditability

Production deployments should make memory operations observable and reviewable — capturing who accessed the service, what action was performed, which tenant or workspace was affected, and whether the operation succeeded or failed. See Audit Trail.

Compliance planning

In a regulated environment, deploy CortexDB as part of your broader compliance program. Typical topics: data residency, retention and deletion policies, incident response and audit evidence, and vendor / provider controls when external AI services are used.

Shared responsibility

Security posture depends on deployment model. On the application side, focus on identity, access, and usage policy. On the infrastructure side, plan for networking, secrets, storage, monitoring, and operational procedures.

Deployment presets and live validation

Deployment posture is shaped by the CORTEX_DEPLOYMENT_PRESET setting — dev_local (default), on_prem_enterprise, cloud_shared_saas, cloud_private. See Deployment Presets. The source repository also ships a live Docker validation matrix operators can run locally:

python tests/live/run_docker_live_suite.py

Next steps

• Deployment Presets — the deployment postures
• Audit Trail — governance and audit workflows
• Backups & DR — the verified cold-backup and restore procedure