Security

API key management, tenant isolation, encryption, and data protection in CLAIV Memory.

API key lifecycle

API keys are the primary authentication mechanism for the CLAIV Memory API.

Creation

Keys are generated in the console under your project's API Keys page. The plaintext key is shown exactly once at creation time. Copy it immediately — it cannot be retrieved later.

Storage

Keys are stored as SHA-256 hashes with per-key salts. The plaintext is never stored. Each key is scoped to a single tenant_id, which is how CLAIV infers the tenant from your API key.

Revocation

Keys can be revoked from the console at any time. Revoked keys immediately stop working. Revocation is permanent — you cannot un-revoke a key.

Never commit API keys to source control. Use environment variables or a secrets manager. Rotate keys regularly and revoke any that may have been compromised.

Tenant isolation

Every project creates a unique tenant. All data operations are strictly scoped to the tenant associated with the API key:

  • Events are stored per-tenant and cannot be accessed across tenants
  • Recall only returns memories within the tenant boundary
  • Forget only deletes data within the tenant scope
  • Usage metrics are tracked independently per tenant
The tenant_id is inferred from the API key. You never include tenant_id in request payloads. This prevents accidental cross-tenant data access.

Data encryption

In transit

All API communication uses TLS 1.2+ encryption. HTTP requests are rejected.

At rest

PostgreSQL data is encrypted at rest using AES-256. Backups are encrypted using the same standard.

Backend API keys

Backend API keys stored in the console settings are encrypted with AES-256-CBC and a unique IV before being persisted. The encryption key is stored as an environment variable, separate from the database.

GDPR / CCPA compliance

CLAIV Memory provides built-in tools for data subject rights:

  • Right to erasure: Use /v1/forget to delete derived data. Returns a receipt_id for audit trails.
  • Data minimization: Token budgets ensure only relevant data is returned.
  • Purpose limitation: Tenant isolation ensures data is only used within the intended context.
  • Audit trail: Every forget operation returns deleted_counts for compliance documentation.

Best practices

Rotate keys periodically. Create a new key, update your application, then revoke the old one.

Use separate keys per environment. Keep development and production keys separate. Revoke development keys when they're no longer needed.

Monitor usage for anomalies. Sudden spikes in usage may indicate a compromised key. Check the Usage page regularly.

Use server-side calls only. Never expose your API key in client-side code. All CLAIV API calls should happen from your backend.

Next steps

Deploying CLAIV Memory infrastructureCommon issues and debugging tips