AI Secrets Rotation Checklist: Keys That Reach Everything

AI provider keys buy compute on your account and frequently reach more systems than intended. This checklist covers managing them, drawn from FISTA Solutions' AI enablement operational work.

What secrets does an AI system hold?

Six categories, each with its own rotation needs.

Secret	Consequence if leaked
Model provider API key	Direct spend on your account
Agent service credentials	Actions in your systems
Vector or database credentials	Corpus access
Tool and integration credentials	Third-party system access
Webhook signing secrets	Spoofed events
Observability tool keys	Log access including prompts

Inventory

You cannot rotate what you have not listed.

• Every secret used by AI systems listed
• Owner named per secret
• Systems consuming each secret recorded
• Creation date and last rotation recorded
• Scope and permissions of each recorded
• Storage location confirmed as a secrets manager
• Unused secrets identified and revoked

Scoping

Surgical revocation requires separate keys.

• One key per application or service, not shared
• Separate keys for production, staging, and development
• Permissions limited to what each consumer needs
• Spend limits applied per key where the provider supports it
• Model access restricted per key where supported
• Rate limits set per key where supported
• Personal keys eliminated from production paths

Rotation process

Overlap, verify, then revoke.

• Rotation schedule defined per secret type
• New secret issued before the old is revoked
• Both valid during a verified overlap period
• Traffic confirmed moved to the new secret
• Old secret revoked and revocation verified
• Rotation automated where the provider supports it
• Rotation tested in staging before production

Leak prevention

The common paths are well known and all preventable.

• Repository scanning for committed secrets enabled
• Pre-commit hooks blocking secret patterns
• Logging configured to redact credential patterns
• Error messages checked for credential inclusion
• No provider keys in client-side code
• Prompts checked for embedded credentials
• Support and ticket systems checked for pasted keys

Detection

Usage anomalies surface a leak before the invoice does.

• Provider usage monitored per key
• Alerts on unexpected volume
• Alerts on unfamiliar source regions
• Alerts on models you do not normally call
• Spend rate alerts configured per key
• Public repository scanning for your key patterns
• Provider leak notifications subscribed to

Incident response

Speed matters because spend accrues immediately.

• Revocation procedure documented and reachable
• On-call can revoke without waiting for an owner
• Time from detection to revocation measured
• Replacement issued and deployed quickly
• Usage during the exposure window quantified
• Provider contacted where spend recovery may be possible
• Root cause addressed, not just the key replaced

What are the most common failures?

One key shared across every system. Keys in client applications. No usage alerting. Rotation as a direct swap causing an outage. And no repository scanning, which is where most leaks originate.

Who should own this?

Security defines the policy; the team running each system owns its secrets and their rotation. Secrets owned centrally and used locally do not get rotated on schedule.

How often should it run?

Rotation per the policy — commonly quarterly for high-value keys — plus immediately on any suspected exposure or team member departure. Inventory reviewed quarterly.

What evidence should it produce?

The secrets inventory with rotation dates, scanning configuration and findings, alerting configuration, and any incident records with time to revocation.

What about keys held by vendors?

Your vendors hold credentials to your systems, and those need the same treatment: scoped, inventoried, rotated, and revoked at contract end.

Vendor credentials are frequently the longest-lived and least reviewed in an estate. Include them in the access review and verify revocation at offboarding. See AI vendor offboarding checklist.

What should you do first?

Check whether one provider key serves several of your systems. If so, splitting it is the change that makes every future revocation possible.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: keys scoped per application so revocation is surgical, with usage anomaly alerts that surface a leak in hours rather than at invoicing, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI access review checklist.