Draft pending counsel review. This document describes our key-handling practices and is being finalised by counsel.
1. Scope
This Policy applies to:
- OpenAI API keys supplied for Henry use.
- Google Gemini API keys supplied for Henry use.
- Any future BYOK provider supported by Brand Atlas.
It does not apply to Oswald, which uses a vendor-hosted AI provider through Brand Atlas’s own relationship.
2. Storage
BYOK keys are stored in Supabase Vault, which provides:
- Authenticated symmetric encryption using libsodium.
- Key-encryption-key separation so the encryption key is not available to the application layer.
- Scoped access so each key is reachable only from its atlas.
The key is never written to disk in plaintext outside the Vault’s encrypted storage.
3. Use
The key is decrypted into memory at the moment of a Henry API call to the provider. The plaintext key is held only for the duration of the call and discarded afterwards.
The key is used only for:
- Authenticating requests to the AI provider for Henry interactions.
- Periodic health checks that the key remains valid.
The key is not used for any other purpose. It is not shared with any third party other than the AI provider it authenticates to.
4. Logging
We log metadata about Henry usage:
- Atlas identifier.
- Provider in use.
- Request size and outcome (success or failure).
- Latency.
We do not log:
- The plaintext API key.
- The user prompt or model response (these are surfaced to the user in the portal but not retained in server logs in plaintext).
- The brand-record content sent to the provider.
5. Customer responsibility
The customer is responsible for:
- Providing a valid key with sufficient permissions and quota for Henry’s use.
- Paying for usage. The customer is billed directly by the AI provider at the provider’s rates.
- Setting appropriate caps. We recommend setting a monthly usage limit at the provider to prevent runaway costs.
- Rotating the key on a sensible cadence (90 days is the recommended default).
- Revoking the key in the event of suspected compromise.
- Selecting the appropriate model for the customer’s risk and cost tolerance.
6. Provider relationship
The customer’s contractual relationship for the AI usage is with the provider (OpenAI or Gemini), not with Brand Atlas. Brand Atlas mediates the integration but is not party to the provider contract.
This means:
- The provider’s terms apply to the customer’s use of the key.
- The provider’s privacy and data-handling commitments apply to the content sent through the key.
- Billing disputes about provider usage are between the customer and the provider.
7. Provider-side storage
Once the key is used to make an API call, the key itself reaches the provider. The provider stores keys under their own policies. Both OpenAI and Gemini store API keys with industry-standard encryption at rest and access controls.
The customer can audit the provider-side storage by reviewing their provider account.
8. Revocation
The customer can revoke the key at any time:
- At the provider. Through the provider’s dashboard. Effective immediately.
- From Brand Atlas. Through Settings → AI → Henry → Remove key. Removes the Vault entry. The key may still be valid on the provider side; the customer should also revoke at the provider for completeness.
After revocation, Henry stops working in the atlas. The Henry chat icon disappears. Conversation history is preserved; new conversations cannot start until a new key is added.
9. Rotation
We recommend rotating BYOK keys every 90 days. Brand Atlas surfaces a reminder when 90 days have passed since the last rotation. Rotation is described in Rotating and revoking.
10. Lost keys
If the customer loses access to the key (the original was deleted from the provider, no copy was retained), the key cannot be recovered from Brand Atlas. Brand Atlas does not maintain a recovery copy beyond the Vault entry, which becomes unusable when the key is revoked at the provider.
The fix is to create a new key in the provider’s dashboard and paste it into Brand Atlas.
11. Multi-atlas customers
A customer with multiple atlases configures one BYOK key per atlas (or shares one across atlases, at their choice). See Managing multiple atlases for the patterns.
12. Audit
The customer can audit BYOK-related activity:
- Key configuration changes in the brand record’s history.
- Henry usage in Settings → AI → Henry → Usage.
- Provider-side usage in the provider’s own dashboard.
13. Account closure and the key
On account closure, the BYOK key entry is deleted from Brand Atlas’s Vault as part of standard account cleanup. The key may still be valid on the provider side; the customer should also revoke at the provider.
14. Changes
We may update this Policy. Material changes are announced 30 days in advance.
What changed
- 27 May 2026: Initial draft published for counsel review.
