Skip to main content
Rotating Henry’s API key periodically is good hygiene; revoking the key quickly is the right response to a security event. The mechanics are described here.

​
Rotation

Rotation is the practice of replacing a working key with a new one on a regular cadence. The new key is valid; the old key is invalidated. The practice limits the damage a leaked or stolen key could do.
  • Every 90 days for most teams. Adequate balance between security and overhead.
  • Every 30 days for high-sensitivity atlases. Faster turnover; more setup work.
  • At specific events. A team member who had access leaves; the key is rotated regardless of cadence.
A 90-day cadence is a reasonable default. Brand Atlas surfaces a reminder in Settings → AI → Henry when 90 days have elapsed since the last rotation.

​
Rotation steps

1

Create the new key

In your AI provider’s dashboard, create a new API key. Name it descriptively (e.g. Brand Atlas Henry — Rotated 2026-08-27). Apply the same scope and limits as the current key.
2

Paste the new key into Brand Atlas

Settings → AI → Henry → Rotate key. Paste the new key. Click Test and save.Brand Atlas tests the new key, swaps it in, and removes the old key from the Vault. The old key is gone from Brand Atlas’s storage.
3

Revoke the old key in the provider's dashboard

The old key is no longer used by Brand Atlas, but it may still be valid on the provider side. Revoke it in the provider’s dashboard to close the loop.
The rotation is complete. The old key is invalidated on both sides; the new key is in active use.
The whole exercise takes about three minutes including the provider-side steps.

​
Why rotate

Three reasons:
  1. Limit the blast radius of a leak. A key that was leaked six months ago is dangerous; a key that was leaked six weeks ago is less so if it has been rotated since.
  2. Catch misuse. A key that has accumulated months of usage history can hide unexpected activity; a recently-rotated key has a clean baseline.
  3. Routine hygiene. The practice of rotation is itself a marker of operational discipline.

​
Revocation

Revocation is the immediate invalidation of a key, usually in response to a specific event:
  • A team member with access to the key has left the organisation.
  • The key may have been exposed (a leaked screenshot, a public repository, a phishing event).
  • An audit has surfaced unexpected usage.
  • The atlas is being closed or the AI feature is being turned off.

​
Revocation steps

The fastest revocation is in the provider’s dashboard. This stops the key working immediately; Brand Atlas detects within minutes.
1

Revoke at the provider

In OpenAI or Gemini, find the key and revoke. Both providers offer one-click revocation.The key stops working immediately. Any in-flight Henry session may complete; new sessions fail.
2

Remove from Brand Atlas

Settings → AI → Henry → Remove key. Confirm. The Vault entry is deleted.This step is optional in a strict sense (the key is already revoked) but it tidies the state and removes any lingering reference.
3

Decide on replacement

Three paths from here:
  • Set up a new key. See Setting up Henry.
  • Switch providers. See Switching providers.
  • Leave Henry off. Some atlases prefer Henry off until the situation that prompted the revocation is fully understood.

​
What happens to the team

When Henry’s key is revoked or removed:
  • The Henry chat icon disappears from the portal.
  • In-flight conversations are closed; conversation history is preserved.
  • Team members can still use the atlas without Henry; only the AI assistant is affected.
When a new key is added, Henry returns and conversation history is restored. There is no lasting damage to the atlas from a temporary revocation.

​
The provider-side audit

After a security event, audit the provider-side usage of the revoked key:
  • Recent requests. Was the usage consistent with normal Henry activity?
  • Unusual sources. Did the requests come from unexpected IPs or geographies?
  • Unusual volumes. A spike in usage may indicate misuse.
Both OpenAI and Gemini expose this information in their dashboards. If anything is unexpected, escalate to the provider’s security team and (if appropriate) to your own security or legal function.

​
Documenting the rotation

A simple log is helpful, especially in larger organisations:
  • The date of each rotation.
  • The reason (routine vs. event-driven).
  • Whether the old key was revoked at the provider.
  • Who performed the rotation.
The log can live in your organisation’s security wiki, or in a Horizon scoped to security-relevant operational documentation. The point is for the next person who does the rotation to be able to reconstruct the practice.

How your key is stored

The storage model.

Switching providers

Provider changes.

BYOK Policy

The formal policy.