Security
API key lifecycle, tenant isolation, input validation, 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 from your project's API Keys page in the console. 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 persisted. Each key is scoped to a single tenant, which is how CLAIV infers the tenant from your API key.
Revocation
Keys can be revoked from the console at any time. Revoked keys stop working immediately. 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:
- All queries are scoped by tenant_id — derived from the API key, never sent in payloads
- Events, facts, and derived data are tenant-isolated in the database
- Recall only returns memory within the tenant boundary
- Forget only deletes data within the tenant scope
- Tenant data is fully isolated — no cross-tenant access is possible at the query layer
- Usage metrics are tracked independently per tenant
The tenant is inferred from the API key. You never include a
tenant_id in request payloads — this design prevents accidental cross-tenant data access.Input validation
Schema validation
All request bodies are validated against strict schemas. Unknown fields are rejected, preventing injection of unexpected data or attempts to override system fields.
Parameterized queries
All database operations use parameterized queries. No raw string concatenation is used in SQL — SQL injection is structurally prevented.
Content limits
Event content is capped at 32,000 characters per ingest. Oversized payloads are rejected with a
400 invalid_request error.Data encryption
In transit
All API communication uses TLS 1.2+. Plain HTTP requests are rejected with a redirect to HTTPS.
At rest
PostgreSQL data is encrypted at rest using AES-256. Backups use the same standard. Vector embeddings stored via pgvector are encrypted with the rest of the database.
API keys at rest
API keys stored in the console settings are encrypted with AES-256-CBC using 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 (Article 17)
Use
/v6/forget to delete all memory for a user. Returns a receipt_id and deleted_counts breakdown for audit documentation. Supports scoped deletion by thread or time range.Data minimization
Fact extraction gates low-utility data before storage — only meaningful structured facts are retained. The Gate step filters out propositions below a utility threshold.
Purpose limitation
Tenant isolation ensures data is only accessible within the intended context. API keys are scoped per tenant — a key cannot access another tenant's data.
Audit trail
Every forget operation returns a
receipt_id with exact deleted counts — verifiable compliance proof for GDPR Article 17 and CCPA deletion requests.Best practices
Rotate keys periodically
Create a new key, update your application, then revoke the old one. This limits exposure windows if a key is leaked.
Use separate keys per environment
Keep development and production keys separate. Revoke development keys when they are no longer needed.
Monitor usage for anomalies
Sudden spikes in usage may indicate a compromised key. Check the Usage & Limits page regularly and set up alerts.
Server-side calls only
Never expose your API key in client-side code. All CLAIV API calls should originate from your backend — the API key must never appear in browser JavaScript or mobile app bundles.