How your key is stored

Your AI provider API key is stored using Supabase Vault, encrypted at rest, scoped to your atlas alone, and never logged in plaintext. The key is used to make API calls to your chosen provider; it is not used for anything else. This page describes the storage in detail. The formal policy is in BYOK / API Key Handling Policy.

​

The short version

• Your key is encrypted at rest using Supabase Vault, a key-management service backed by libsodium.
• The key is decrypted only when needed to make an API call to your AI provider.
• The decryption happens in memory; the plaintext key is never written to disk and never logged.
• The key is scoped to your atlas; it cannot be used by any other atlas in Brand Atlas.
• You can revoke the key at any time from your provider’s dashboard; Brand Atlas detects the revocation within minutes.
• You can replace the key in Brand Atlas at any time; the old key is deleted in the same operation.

​

How Supabase Vault works

Supabase Vault is the storage layer for sensitive material in Brand Atlas. It uses libsodium for authenticated symmetric encryption. Each key stored in the Vault is encrypted with a key-encryption-key that is not available to the application layer. When Henry needs to make an API call:

1. Brand Atlas’s API server requests the decrypted key from the Vault.
2. The Vault returns the plaintext key to the requesting process in memory.
3. The process uses the key to call the provider.
4. The plaintext key is discarded at the end of the request.

The plaintext key never leaves the memory of the process handling the request. It is not written to disk. It is not included in any log line. It is not transmitted to any service other than the AI provider it authenticates to.

​

What is logged

Brand Atlas logs metadata about Henry usage:

• The atlas the request came from.
• The provider it was sent to.
• The size of the request (tokens in and tokens out).
• The success or failure of the call.
• The latency.

What is not logged:

• The plaintext API key.
• The user prompt or the model response in plaintext (Brand Atlas does retain a conversation history for the team member’s reference; that history is encrypted at rest and accessible only to the team member and the brand owner).
• The brand-record content sent to the provider.

The metadata is retained per the brand record’s history retention; the conversation history is retained per the team member’s settings (default 30 days; configurable on Guardian).

​

Provider-side storage

Once the key reaches your AI provider, it is stored by them under their own policies. Both OpenAI and Gemini store API keys with industry-standard encryption at rest and access controls. Brand Atlas’s storage hygiene is one half of the picture; the provider’s is the other. You can audit the provider side by reviewing your provider’s API key list and usage. Both providers show recent usage by key.

​

What happens on revocation

You can revoke the key at any time from your provider’s dashboard. When you do:

1. The next API call from Brand Atlas using that key will fail.
2. Brand Atlas detects the failure and notifies the brand owner.
3. Henry stops responding to new questions until the key is restored or replaced.
4. The brand owner can paste a new key or remove the old one entirely.

The provider’s revocation is immediate. The Brand Atlas detection runs on the next call; in practice, the gap between revocation and detection is at most a few minutes.

​

What happens on rotation

Rotation is the practice of replacing a working key with a new one for security hygiene. The flow:

1. Create a new key in the provider’s dashboard.
2. Paste the new key into Brand Atlas. Brand Atlas tests it.
3. On success, the old key is deleted from Brand Atlas’s Vault in the same operation.
4. (Optional but recommended.) Revoke the old key in the provider’s dashboard.

A 90-day rotation cadence is a reasonable default. See Rotating and revoking for the full procedure.

​

Multi-atlas customers

Customers running multiple atlases (an agency, a holding company) typically use:

• One key per atlas. Each atlas has its own key, scoped to that atlas in the provider’s dashboard. Cleanest separation of usage and billing.
• One key shared across atlases. Simpler to manage; usage is aggregated. Less clean from an auditing perspective.

Brand Atlas supports either model. The recommendation is one key per atlas for atlases of any meaningful size.

​

What Brand Atlas can never see

Three things that are out of Brand Atlas’s reach by design:

• The provider’s account credentials. Your OpenAI or Gemini login is yours alone.
• Other API keys in your provider account. Brand Atlas only sees the key you supply.
• Other usage on your provider account. Brand Atlas sees only Henry’s usage of the key you provided.

​

When the key cannot be recovered

If a key has been pasted into Brand Atlas, deleted from your provider’s dashboard, and the provider’s record of it is also gone (an account closure, for example), the key cannot be recovered. Brand Atlas does not maintain its own copy beyond the Vault entry, and the Vault entry stops being useful when the key is no longer valid on the provider side. Create a new key and paste it in.

​

Related pages