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 focuses on those deployment considerations at a public, high level.

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. If CORTEX_API_KEY is unset, the server runs in an explicitly logged local no-auth mode and, outside Docker, binds loopback only — never expose that mode to a network.

For production use, teams should define:

• how application credentials are issued and rotated
• which services and operators are allowed to access CortexDB
• how tenant, workspace, or environment boundaries are enforced in application use

Encryption and transport protection

Teams should follow their organization’s standards for:

• encrypting sensitive data according to policy
• protecting secrets and service credentials
• terminating TLS or applying network-layer encryption
• restricting access to trusted networks and workloads

Tenant governance

Many teams use CortexDB in multi-tenant or multi-workspace environments.

In those cases, security planning should include:

• clear tenant scoping in applications and integrations
• environment separation for development, staging, and production
• least-privilege access for services that read or write memory
• review paths for retention, deletion, and data handling requirements

Auditability

Production deployments should make memory operations observable and reviewable.

That usually means capturing:

• who or what system accessed the service
• what action was performed
• which tenant or workspace was affected
• whether the operation succeeded or failed

See Audit Trail for the broader governance view.

Compliance planning

If you are operating in a regulated environment, CortexDB should be deployed as part of your broader compliance program rather than as a standalone exception.

Typical topics to review include:

• data residency requirements
• retention and deletion policies
• incident response and audit evidence
• vendor and provider controls when external AI services are used

Shared responsibility

Security posture depends on deployment model.

• Focus on application identity, access, and usage policy.
• Plan for networking, secrets, storage, monitoring, and operational procedures.

Deployment presets and live validation

CortexDB deployment posture is also shaped by the CORTEX_DEPLOYMENT_PRESET setting:

• dev_local (default)
• on_prem_enterprise
• cloud_shared_saas
• cloud_private

The source repository also ships a live Docker validation matrix that operators can run locally:

python tests/live/run_docker_live_suite.py

Next Steps