Blog/Enterprise
Enterprise2026-05-213 min read

Audit Trail

How CortexDB logs every API operation for compliance, security monitoring, and debugging. The system captures structured fields, supports SIEM export, and ensures verifiable deletion.

CortexDB is the long-term memory layer for AI agents. The platform logs every API operation as a structured audit entry to support compliance, security monitoring, and debugging.

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 auditability matter for AI agents?

AI agents require persistent context to function across multiple sessions. Traditional environments often obscure which application accessed specific memory fragments. Lack of visibility breaks compliance when handling sensitive customer information or regulated data.

Most teams attempt to solve memory by building loosely coupled 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. Tracking memory access requires dedicated audit trails to prove who read what, and when.

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 with built-in audit capabilities.

CortexDB separates the durable log from the derived views. The raw event remains the source of truth, and every operation against that truth produces a cryptographic record. Summaries, embeddings, and knowledge graphs function as derived artefacts built asynchronously. We built this architecture to ensure access logs remain verifiable across schema evolution.

How does CortexDB manage audit logs?

CortexDB relies on structured fields to track API activity. Every request generates an AuditRow containing the actor, token_jti, tenant_id, scope, endpoint, capability, decision, decided_by_tier, request, response_status, event_id, client_ip, request_id, elapsed_ms, and a gdpr flag.

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, and full scope paths travel within every audit record.

Administrators execute queries against the audit trail using the GET /v1/admin/audit endpoint. The API supports filters for tenant, operation, time range, status, and API key. Responses paginate for large result sets to maintain performance.

What does the audit trail enable?

Three consequences matter most for security teams.

Tamper detection relies on SHA-256 chaining across the log to prevent unauthorized modifications. CortexDB verifies the integrity of the audit chain using the POST /v1/audit/verify endpoint.

Compliance verification supports GDPR Article 30 requirements by recording exactly who accessed which data. CortexDB audits the forget operation to prove data deletion cascades correctly across derived views.

SIEM integration streams audit data continuously to external security systems. CortexDB exports logs via Server-Sent Events (SSE) or ships them in batches using the experimental POST /v1/admin/siem/drain endpoint.

Frequently asked questions

What does CortexDB log in the audit trail?

Every API operation generates a structured AuditRow entry. The payload includes the actor, token_jti, tenant_id, full hierarchical scope, endpoint, capability, decision, decided_by_tier, request details, response_status, event_id, client_ip, request_id, elapsed_ms, and gdpr flags.

Is audit logging enabled by default?

Yes. Audit logging activates automatically on every deployment profile. Retention defaults to 365 days through the CORTEX_AUDIT_RETENTION_DAYS configuration variable, though regulated environments can extend this period.

How do I query the audit log?

Use the admin endpoint GET /v1/admin/audit with filter parameters for tenant, operation, time range, status, and API key. Responses paginate.

How do I export audit logs for SIEM?

CortexDB supports SIEM integration via continuous SSE streaming or through batch shipping. The experimental POST /v1/admin/siem/drain endpoint allows systems to drain logs periodically.

Does the audit trail capture query text?

By default, query text from recall and search is excluded from audit entries for privacy. Request bodies are stored as SHA-256 hashes alongside safe metadata to ensure raw secrets never leak into logs.

Can audit logs be tampered with?

The audit store is append-only and runs alongside the event log. CortexDB uses SHA-256 chaining for tamper detection, and administrators can verify integrity using the POST /v1/audit/verify endpoint.

Related concepts