Fireworks Can Revoke Its Own Keys, Not Yours

As of October 10, 2026.

When a platform that stores your API keys is breached, it can revoke the keys it issued. It cannot revoke the OpenAI, cloud or database keys you pasted into it. Those stay live until you rotate them at the provider that issued them.

What happened

Fireworks AI published a security bulletin late on October 9 and updated it on October 10. On October 6 at 9am PDT, it identified "unauthorized use of internal Fireworks credentials." With them, a third party "accessed environment variables used in evaluation jobs in a limited number of customer accounts."

The bulletin says Fireworks believes "environment variables, including API keys and tokens stored as secrets, were captured in certain affected accounts." It has not detected access to customer models, datasets, training data, inference traffic or personal information, and its review of other access is ongoing.

Fireworks began containment the same day. Its timeline lists notifications to affected customers starting October 7, a rotation of employee API keys on October 9, and, on October 10, revocation of more user API keys and service-account tokens found in a completed credential review. It says it is reviewing "how secrets are made available to evaluation jobs."

The half of the cleanup Fireworks cannot do

The bulletin's customer guidance splits in two. Revoked Fireworks API keys "no longer work," and customers need to create new ones. Fireworks did that part itself.

Third-party credentials are different, and the bulletin says so directly: "Removing a stored secret alone does not invalidate the underlying credential. Third-party credentials require action with their issuing providers."

Deleting the secret from the Fireworks dashboard removes one copy. The copy that was captured still works, and whatever it is used for is billed and logged at the provider, not at Fireworks. Only the account that owns the key can revoke it.

Every copy is part of the blast radius

An evaluation job needs the keys for whatever it evaluates: a model provider, a vector store, a judge model, a dataset bucket. So an eval platform can end up holding copies of the same keys that run the product.

Each platform that holds a copy can leak it, and none of them can revoke it. Only you know every place you put it. That list is the blast radius of a single key.

This pattern is not new. The Context.ai breach at Vercel started at a third-party AI tool one employee used, and AI projects already leak keys more than most, because so many services each want one. Eval and agent platforms add another place to paste them.

What to do now

If Fireworks notified you:

1. Replace the revoked Fireworks keys. Create new keys and update the applications that used the old ones; they will fail authentication until you do.
2. Rotate every third-party credential named in the notice at its issuer. Do this even if logs look clean, as the bulletin advises. Then update the applications and the Fireworks secrets that use them.
3. Review provider-side activity. Check access logs and billing at each provider for reads, downloads, changes or usage you do not recognize.
4. Check your Fireworks account for anything you did not create. The bulletin lists API keys, users, evaluators, training jobs and datasets, and asks customers to send the names or IDs of anything unrecognized. It also offers secret names and credential fingerprints through a secure channel.

If Fireworks did not notify you, the bulletin says no incident-specific action is required. The general exercise still applies:

5. Pick one production provider key and list every place it is stored. Include eval platforms, LLM gateways, agent consoles, CI secrets, notebooks and .env files. If the list takes more than a few minutes, the next platform breach will take longer.
6. Give each platform its own key. A key per platform, scoped to what that platform needs, means a breach of one platform is one rotation instead of a hunt. Where the provider offers spend limits, they cap what a captured key can cost.

Our leaked-key emergency checklist covers rotation order and log review per provider.

Where Rafter fits

Some of those copies sit in repositories. rafter secrets . scans a working tree locally, with no account, for plaintext keys, and rafter agent install-hook adds a commit hook that scans staged changes for secrets before each commit. Neither can see secrets held by a third-party platform; that inventory is yours.