Security
Summary
AtlasBurn is designed with a zero-trust security model. This page documents key generation, verification, storage, isolation, and what data is — and isn't — captured.
System maturity: Stable
Key Generation
API keys are generated server-side using cryptographically secure entropy strings. Keys follow the format abn_xxxxxxxxxxxxxxxxxxxx.
Key Verification
Keys are verified via deterministic HMAC-SHA-256 hash comparison with O(1) lookup. Raw API keys are never stored — only their hashes.
Key Rotation
- Generate a new key in the dashboard at any time
- Old keys are revoked in batch
- Revoked keys are rejected immediately upon database sync
What AtlasBurn Never Stores
Privacy guarantee
- Raw API keys — only HMAC hashes are persisted
- PII — no personally identifiable information is extracted
- LLM request body — prompts are never captured
- LLM response body — completions are never captured
What Is Safe to Log
- Key prefixes (e.g.,
abn_abcd...) - Event counts
- Forensic IDs
Isolation Model
Strict owner-based multi-tenancy is enforced at the Firestore Security Rule level. Each organization's data is logically isolated. Cross-tenant access is architecturally impossible.
Usage records are stored under /organizations/{orgId}/usageRecords/ with per-organization security rules.
Revocation
When a key is revoked:
- Status is set to
revokedin the database - The ingestion API rejects the key immediately upon database sync
- No grace period — revocation is instant
What This Means in Practice
AtlasBurn captures metadata about your AI calls — model, tokens, cost, latency — but never sees your prompts, completions, or provider API keys. The security model is designed so that even a full database breach would not expose sensitive application data.
Next Steps
- Telemetry Architecture — what data flows through the pipeline
- Troubleshooting — auth failures and key issues