If an AI API key is exposed, revoke it promptly through the provider's documented process; Claude's guidance calls for immediate revocation. Do not wait for a complete usage investigation or a replacement rollout. Then track two outcomes: containing unauthorized spending and ending unauthorized access to inference capability. One revocation action can address both; a billing adjustment proves neither.
Anthropic's September 2026 threat-intelligence report describes stolen customer API keys being used to support further intrusion attempts. That makes the response bigger than an invoice dispute. Your account may be supplying compute to someone else's operation.
The practical response is an incident card that keeps four evidence trails distinct: revocation, legitimate workload recovery, usage investigation, and provider escalation. The card below is Berryhill Dev defensive operator synthesis, not an Anthropic procedure.
A stolen key supplies more than a bill
An inference credential is access to a service. Unauthorized use can incur charges, as Claude's API key guidance explains. The threat report illustrates another exposure: the service can supply capability for further malicious activity.
Those are different incident outcomes, not necessarily different technical fixes. Revoking the exposed credential is a containment action relevant to both. Reviewing charges answers a narrower question: what financial exposure can you account for?
Keep that distinction when interpreting a quiet usage chart. It may help bound observed activity. It does not, by itself, establish that the exposed credential was revoked or explain what happened outside the records you can inspect.
This extends the problem in AI misuse doesn't stop at the session boundary: the useful unit of investigation may be larger than one visible interaction. Here, the immediate operational question is whether an unauthorized party still has inference access through your account.
What Anthropic reported, and what it did not
In the September report, Anthropic says stolen keys were abused as the actor continued intrusion attempts against a vendor and unrelated targets. The report describes customer credentials being stolen; the cited case was not a compromise of Anthropic's systems.
These are Anthropic's reported observations, not independently verified findings by Berryhill Dev. The report describes its selection as notable cases, not a representative sample of AI use or misuse. It supports the possibility that stolen inference access can feed further operations. It does not tell us how often that happens, and it does not establish that every exposed key has been used that way.
For responders, that is enough to change the question from “Have we disputed the charges?” to “What evidence supports containment, and what remains unknown?” It is not a reason to attribute unseen attacks to every unexplained request.
Separate access containment from legitimate workload recovery
Claude's compromised-key guidance recommends immediately revoking the key using Delete API Key, creating a replacement key, and storing it securely. Follow the current documented controls for your provider. Do not delay urgent containment while completing the incident record.
Treat recovery as a separate check. Record which authorized applications received replacement credentials and whether those workloads can complete their intended requests. A working application demonstrates continuity for that application; it does not prove the old credential has been revoked. Likewise, a revocation confirmation does not prove all legitimate workloads have recovered.
This is not a promise that deleting an API key instantly cancels already accepted work or invalidates other kinds of credentials. The cited guidance does not establish those guarantees. If they matter to the incident, record the uncertainty and ask the provider rather than treating API keys and session tokens as interchangeable.
Investigate usage alongside recovery. Claude's key-safety guidance recommends reviewing usage and logs and warns against including secret keys in support tickets. Capture the available time window and any missing coverage. Do not convert “we have no record for that period” into “nothing happened.”
Build an inference-key incident card
Use this card inside your existing incident process, not as a second process that delays action. It is Berryhill Dev defensive operator synthesis. Store restricted evidence in the appropriate incident system and put sanitized references in the card; never copy the secret value into it.
- Owner and scope: Name the incident owner and affected account or workload. Identify the credential using a non-secret identifier, never the key itself.
- Exposure window: Record the earliest known exposure, discovery time, and containment time. Separate observed timestamps from estimates. Mark an unknown start as unknown.
- Revocation evidence: Record the action taken, timestamp, affected credential identifier, and reference to the provider confirmation. List unresolved questions about work already accepted, if relevant.
- Workload continuity: List the authorized workloads checked after replacement, the check time, result, and owner of any remaining outage. Keep this separate from old-key containment.
- Usage investigation: Record which usage records and logs were reviewed, their time range, suspicious activity identified, and gaps. Distinguish observed charges from any estimate. Do not infer attacker intent from volume alone.
- Provider escalation: Record the support reference, questions raised, and disposition when available. If escalation is not pursued, record why. Do not include credentials, raw prompts, or unnecessary personal data in the card or support request.
- Closure and follow-up: State what the evidence supports, what remains uncertain, who owns each unresolved risk, and when it will be reviewed again.
Claude's compromised-key guidance advises contacting support for continued suspicious activity or other concerns. A provider response can help resolve uncertainty, but this card does not make a response universally necessary for closure. Record a pending request as pending; do not imply that support has confirmed containment or promised a refund.
Keep the procedure current, too. As discussed in Your AI security checklist has a version problem, a familiar checklist is not a substitute for checking the controls that apply now. Record which provider instructions informed the response.
Close on evidence, not a lower bill
A defensible closure statement is narrow: the exposed credential's revocation is documented, legitimate workload checks are recorded, available usage has been reviewed with its coverage limits, and unresolved questions have owners. Include the provider's disposition when available, or the pending escalation and follow-up date when it is not.
That does not prove every downstream consequence has ended. It tells the next responder what was contained, what was restored, and where uncertainty remains. A credit on the account, a quiet dashboard, or a recovered application cannot substitute for that record.
Add the card to the incident template before the next exposure. Ask the owner to point to the revocation evidence and the investigation gaps without opening a billing dispute. If they can, your response is addressing the credential's capability as well as its cost.
Sources
- Anthropic: September 2026 threat-intelligence report — attributed case observations and limits of the reported sample.
- Claude: API key best practices — usage review and safe handling of keys.
- Claude: What should I do if I suspect my API key has been compromised? — immediate revocation, replacement, and support guidance.