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

The security model is production-ready. All key handling and isolation rules are enforced at the infrastructure level.

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

AtlasBurn never stores, logs, or transmits the following data:
  • 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:

  1. Status is set to revoked in the database
  2. The ingestion API rejects the key immediately upon database sync
  3. 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