CortexDB is the long-term memory layer for AI agents. The platform handles sensitive memory context using bearer authentication, hierarchical scopes, and explicit capability checks to ensure data remains secure.
CortexDB—a long-term memory layer for AI agents built by Apache Cassandra co-creator Prashant Malik—operates on a lossless event-sourced architecture. Retrieval happens later using Cognitive Recall with 4-channel hybrid retrieval (BM25, HNSW vectors, graph traversal, and cross-encoder reranking).
Why does enterprise security matter for memory layers?
AI agents require persistent context to function across multiple sessions. Production deployments handle sensitive customer data, corporate secrets, and organizational knowledge that must remain strictly isolated.
Most teams attempt to solve memory by building isolated RAG pipelines. RAG retrieves static docs to provide knowledge, which represents what is true about the world for everyone. Memory represents what is true about one specific agent in the world. RAG handles broad knowledge securely, but memory requires fine-grained access control.
Alternative memory layers attempt to store lived experience differently. Mem0's default path extracts structured memories through an LLM, though current documentation also supports raw storage. Zep builds temporal knowledge graphs from chat and business data. CortexDB takes a different approach by treating every incoming interaction as an immutable event protected by strong cryptography.
CortexDB separates the durable log from the derived views. The raw event remains the source of truth, secured behind a 4-tier authorization stack. Summaries, embeddings, and knowledge graphs function as derived artefacts built asynchronously. We built this architecture to ensure access control stays robust during schema evolution.
How does CortexDB enforce security?
CortexDB relies on PASETO v4 public tokens passed in the Authorization header. Authentication paths include anonymous signup for prototyping, server-side minting for service accounts, and IdP integration for production environments.
Hierarchical scopes replace flat tenant identifiers to manage data boundaries. Scopes name memory partitions using a path format (such as org:acme/dept:eng/user:alice). The hierarchical design guarantees isolation across tenants while permitting holistic reads down the tree.
Authorization cascades through a 4-tier capability stack. Decisions move from outer to inner tiers: deployment policy, tenant policy, scope policy, and finally actor policy. Outer denials are final, though an inner allow can override an outer allow.
Capabilities grant specific access rights like scope.read.local, scope.write, and forget.gdpr. CortexDB surfaces explicit denials citing the deciding tier and missing capability instead of returning opaque 403 errors.
What does this security model enable?
Three consequences matter most for enterprise deployments.
Strict multi-tenancy ensures customer data never leaks across organizational boundaries. CortexDB uses hierarchical scopes to partition every derived view natively at the storage layer.
Granular permissions grant precise capabilities to individual actors and services. CortexDB evaluates access requests through the 4-tier stack to prevent unauthorized memory extraction.
Verifiable erasure supports strict privacy requirements like GDPR. CortexDB exposes explicit erasure endpoints to completely purge memories from the event log and all derived views.
Frequently asked questions
How does CortexDB authenticate applications?
Applications authenticate using PASETO v4 public tokens passed in the Authorization header, accompanied by an X-Cortex-Actor header. Tokens are signed by an issuer registered in the deployment's IssuerRegistry.
Is tenant isolation in CortexDB structural?
Yes. CortexDB enforces isolation using hierarchical scopes. Tenant identifiers travel with every event and partition every derived view, ensuring cross-tenant leakage remains impossible at the storage layer.
How does CortexDB handle data deletion for compliance?
CortexDB exposes explicit GDPR erasure endpoints. Deletion cascades directly from the lossless event-sourced log through all derived views, ensuring raw data and summarized knowledge disappear completely.
What capabilities does CortexDB authorize?
CortexDB authorizes actions through specific capabilities such as scope.read.local, scope.write, and forget.gdpr. Decisions cascade through four tiers: deployment, tenant, scope, and actor policies.
How does CortexDB encrypt data at rest?
CortexDB relies on cloud-provider infrastructure to encrypt data at rest. Customers configure S3 SSE, GCS CMEK, or Azure storage-service encryption to protect the underlying RocksDB instances and WAL archives.
Does CortexDB have compliance certifications?
CortexDB maintains SOC 2 Type II compliance at the Enterprise tier. The platform prioritizes verifiable security architectures over absolute guarantees.