Incident response for a leaked AI access key

The first decision in an AI-key incident is what kind of credential escaped. A workload-specific virtual key and a reusable model-provider credential have different blast radii and require different containment actions.

A virtual key should identify one governed workload or scope. A provider credential may authorize direct access to the vendor account and can affect every application that shares it. Treat an unknown key as the higher-impact type until its ownership is established.

Prepare before a key leaks

Containment is faster when every workload has its own credential, owner, environment, and intended model scope. Maintain enough metadata to answer:

• Which application or agent owns this key?
• Where is the secret stored and deployed?
• Which organization, team, or project does it represent?
• What models, budgets, and rate limits apply?
• When was it issued, last used, suspended, or revoked?
• Does the workload possess any separate provider credential?

Shared keys erase this context. They force responders to choose between leaving an exposed credential active and interrupting unrelated applications.

The containment sequence

1. Preserve the signal

Record when and where the exposure was discovered, the non-secret key identifier or hint, the affected repository, host, ticket, or log, and the person coordinating the response. Do not paste the full secret into another ticket or chat channel.

If the secret is in a public repository or artifact, remove public access where possible, but do not assume deletion removed it from history, caches, forks, or logs.

2. Suspend or revoke the credential

Suspend a virtual key when a short investigation window and reversible containment are operationally useful. Revoke it when exposure is confirmed or the key no longer has a legitimate purpose.

If a provider credential may have escaped, rotate or revoke it at the provider and update the governed provider connection. Revoking a virtual key does not invalidate a separately exposed provider credential.

3. Stop retry loops

An application may interpret the containment response as a transient authentication failure and retry indefinitely. Stop or reconfigure the affected workload, then verify that request volume has fallen. Rate limits reduce this risk but do not replace containment.

4. Investigate the activity window

Define a window beginning before the earliest known exposure. Review the affected identity’s request rate, models, providers, token and configured cost usage, source context available in your deployment, policy findings, errors, and administrative changes.

Compare the activity with the workload’s established behavior. A valid key used from a new environment may still appear syntactically normal; attribution and timing matter.

5. Recover with a new identity

Issue a new workload-specific key rather than reactivating the exposed value. Store it through the approved secret-delivery process, update only the affected workload, and verify successful governed calls and audit attribution before restoring full traffic.

Decide the scope of escalation

Escalate beyond the individual workload when:

• the credential type or owner cannot be established;
• a reusable provider key or catalog encryption secret may be involved;
• suspicious usage crossed organizational or project boundaries;
• audit data suggests administrative compromise;
• sensitive prompts or responses may have been accessed; or
• the same disclosure path may contain other secrets.

Follow the organization’s legal, privacy, customer-notification, and provider-reporting procedures where the investigation indicates exposure beyond unauthorized model usage.

Learn from the incident

The post-incident review should produce concrete control changes. Common outcomes include replacing shared keys with workload identities, shortening expiry, applying a key-level budget and rate limit, removing direct provider egress, adding secret scanning, restricting log output, or improving owner metadata.

Track both containment time and certainty. A fast revocation with no reliable activity history leaves an important question unanswered; perfect analysis while the key remains active leaves the attacker time.

Response checklist

From response plan to product procedure

Practice this sequence with a non-production key so responders know where the controls and evidence live before a real incident. The current leaked-key containment recipe provides the Agent Access Manager-specific procedure and explains which automated detection and containment functions require the applicable deployment tier.