Fireworks AI Evaluation Jobs Breach (October 2026): Rotate Your Keys

Fireworks AI says that on 6 October 2026 someone used stolen internal Fireworks credentials to read environment variables from evaluation jobs in a limited number of customer accounts, and that API keys and tokens stored as secrets were likely captured. If you got a notice, revoke every named credential at the provider that issued it, then check that provider's logs.

This post covers what Fireworks has published, what it has not, how evaluation job secrets reach a running job, and a provider by provider revocation runbook for Fireworks, OpenAI, Anthropic, Google, AWS, Hugging Face and GitHub, built from each provider's own documentation. Facts come from Fireworks' public security bulletin or from labelled reporting. We have not seen any private customer notice.

The short answer

The single most important line in the bulletin is Fireworks' own warning that removing a stored secret from Fireworks does not invalidate it. The keys that were copied out of evaluation jobs belong to other companies: your model providers, your cloud account, your code host. They keep working until you revoke them there.

What happened

Fireworks AI runs an inference and model customization platform. Among its features are evaluators and evaluation jobs: code that scores model output, often by calling another model or another service. To make those calls, an evaluator needs credentials. Fireworks' evaluator documentation tells users to store credentials in the Fireworks secret management surface and reference them by environment variable name, and never to embed secret values in evaluator code, datasets or run reports. That is standard advice, and the incident shows its limit. A secret kept out of code still has to be present in the job's environment when the job runs, and anyone who can read that environment can read the secret.

Fireworks published its bulletin, titled as its October 2026 security incident, on 9 October. It says Fireworks identified unauthorized use of internal Fireworks credentials, and that a third party used them to access environment variables used in evaluation jobs in a limited number of customer accounts. Fireworks believes API keys and tokens stored as secrets in certain affected accounts were captured.

The bulletin also lists what Fireworks says it has not seen evidence of, within its security perimeter or control: access to customer models, datasets or training data; access to inference traffic, including prompts and outputs; and access to personal information. Fireworks adds that it does not store prompts or outputs by default and describes its platform as zero data retention (ZDR) by default. It says the review of calls made with the exposed credentials is ongoing.

Timeline

All times are as published by Fireworks in Pacific Daylight Time. We added the UTC conversion (PDT is UTC minus seven hours). Rows marked as reporting come from the named outlet, not from Fireworks.

Two things stand out. First, notifications started on 7 October, a day after discovery and more than two days before the public bulletin. If your security inbox was not watched that week, check it now. Second, the gap between discovery (6 October) and the employee key rotation (9 October) and service account token rotation (10 October) suggests the credential review widened as the investigation went on. Fireworks has not said that directly, so treat it as a reading of the timeline, not a finding.

What Fireworks says it did

From the bulletin:

1. Revoked the identified internal credentials.
2. Revoked affected Fireworks API keys.
3. Revoked API keys the actor created.
4. Added access restrictions.
5. Rotated Fireworks employee API keys (9 October).
6. Revoked additional Fireworks user API keys and rotated service account tokens identified in a completed credential review (10 October).
7. Directly notified identified affected customers.
8. Engaged an outside cybersecurity firm, which it does not name.
9. Began reviewing how secrets are made available to evaluation jobs, with remediation measures to be shared once implemented and verified.

Item 3 matters for your own checks. If the actor could create Fireworks API keys, then the actor had some ability to act within accounts, not only read job environments. Fireworks asks customers to look for unrecognised API keys, users, evaluators, training jobs and datasets. The runbook below turns that into commands.

What Fireworks has not said

As of 22 October, the bulletin does not give:

• How the internal Fireworks credentials were obtained.
• How many customer accounts were affected. Coverage says "limited" because Fireworks does.
• Whether any captured third party key has been used outside Fireworks. The bulletin says the review of calls made with exposed credentials is ongoing.
• Indicators of compromise such as IP addresses, user agents or key name patterns.
• The names of the outside firm or the specific changes to evaluation job secret handling.

The "seems agentic" remark

LAVA Security's write up reports that Fireworks CEO Lin Qiao, asked on X whether the attacker was a human or AI agents, replied "From the behavior, it seems agentic." We did not fetch the X post itself, and the remark does not appear in Fireworks' bulletin. LAVA itself notes that AI agent involvement is unconfirmed. Treat it as a reported first impression from the CEO, not a finding of the investigation. It does not change anything you need to do: a key read by a person and a key read by an automated agent are revoked the same way.

Is this part of a wider campaign?

October 2026 has had several incidents in which a platform that holds customers' keys to other services was breached, including Railway, Zeabur and OpenCode's console. Dealroom quotes investor Sarah Guo saying "that's three companies in the past week", without naming the other two, and draws a parallel between the OpenCode and Fireworks cases because both platforms held customers' keys. That is a parallel in target type. Nothing Fireworks has published, and nothing in the reporting we read, links the Fireworks intrusion to any other incident by actor, method or infrastructure. Railway's own disclosure describes its incident as one of a series of attacks on platform companies aimed at AI inference providers, but it names no one, and Fireworks has said nothing similar. We treat these as separate incidents with a shared lesson.

Who is affected

The third party case is easy to miss. If you gave a contractor or an evaluation vendor an API key for your own model provider account, and that vendor ran evaluations on Fireworks, your key could sit in their evaluation job environment without your name on any notice.

How it works

This section explains the mechanism in plain terms. There is no exploit here, and Fireworks has not published one.

An evaluation job is a managed workload. When it starts, the platform builds its runtime environment, and part of that environment is a set of variables. Some are ordinary settings. Others are secrets you stored, such as OPENAI_API_KEY or AWS_SECRET_ACCESS_KEY, which the platform decrypts and places in the environment so your evaluator code can read them with os.environ. Fireworks' evaluator documentation describes exactly this pattern: secrets are referenced by environment variable name.

Encryption at rest protects the stored value in the platform's database. It does not protect the value once the job is running, because the job needs the plaintext. Anything with the right access to the running job, or to the system that assembles the job's environment, can see the plaintext.

According to Fireworks, the actor did not break customer encryption or guess customer keys. It used internal Fireworks credentials. Internal credentials on any platform tend to reach across tenants by design, because staff and service accounts operate the platform for everyone. That is why one stolen internal credential can expose many customers' environment variables at once, and why Fireworks rotated employee keys and service account tokens.

The second half of the risk is what the stolen secrets unlock. A Fireworks API key buys inference on Fireworks. A captured OpenAI or Anthropic key buys inference billed to you. A captured AWS key buys whatever its IAM policy allows. A captured GitHub token with write scope can push code. Our explainer on LLMjacking and protecting AI API keys covers why model provider keys are such a common target.

Technical details

Fireworks' bulletin is short on technical indicators. This section lists everything defender useful that the primary source and Fireworks' own documentation provide, and says plainly what is absent.

What the primary source publishes

Our own read of the bulletin did not show the secret name and fingerprint offer in the page text the fetch returned, while Superpower Daily's summary of the bulletin includes it. If you need the list of secret names that were exposed in your account, ask Fireworks through your notice thread or security@fireworks.ai either way.

There are no CVE IDs, scores, package versions, file hashes, certificate serials or network indicators to list for this incident. This was a credential misuse on a hosted platform, not a vulnerability in software you install. If you see a blog or feed listing IOCs for "the Fireworks breach", check where they came from; they are not in Fireworks' bulletin.

How credentials map to fingerprints

Fireworks offers credential fingerprints rather than raw values, which is the right way to match a leaked key to your inventory without moving the secret again. Several providers expose a partial identifier you can compare against:

Ask Fireworks what its fingerprint format is, then match each fingerprint to an owner before you start rotating.

Fireworks controls you can use today

These commands come from Fireworks' firectl documentation. They help with the bulletin's fourth recommendation: look for unrecognised keys, users, evaluators and jobs.

# List API keys for every user in the account (admin only)
firectl api-key list --all-users -o json

# Delete a Fireworks API key you do not recognise
firectl api-key delete <key-id>

# List stored secrets (names, not values) so you know what lived there
firectl secret list -o json

# Replace a secret's value after you have rotated it at the issuing provider
firectl secret update --id OPENAI_API_KEY --from-file new-openai-key.txt

# Enterprise accounts: pull audit logs for the exposure window
firectl audit-logs list --start 2026-10-01 --end 2026-10-11 -o json --no-paginate

Fireworks' audit log documentation says audit logs are available on Enterprise accounts and record read, write and delete operations on storage, including data access. The --filter flag accepts AIP 160 expressions over message, resource, email, api_key_id, event_type and target_api_key_id, with = for exact and : for substring matches. --end is exclusive, so pass the day after the last day you care about. The REST equivalent is GET /v1/accounts/{ACCOUNT_ID}/auditLogs, with pageSize up to 200; keep paging until a response has no nextPageToken, because an empty auditLogs array with a token means the scan is still running.

A useful first filter is any activity tied to an API key ID you do not recognise:

firectl audit-logs list --start 2026-10-01 --end 2026-10-11 \
  --filter 'api_key_id="<unrecognised-key-id>"' -o json --no-paginate

What to do now: a revocation runbook

Fireworks' bulletin gives four recommended actions for affected customers. In order: create new Fireworks API keys to replace revoked ones (applications using the old keys will fail authentication until updated); rotate or revoke every third party credential named in the notice with its issuing provider, then update applications and Fireworks secrets; review access logs and data reachable through each exposed credential, rotating even if nothing looks wrong; and check for unrecognised API keys, users, evaluators, training jobs and datasets, reporting anything unfamiliar to Fireworks.

The steps below expand that into a working order.

Step 1. Build the list without moving the secrets again

Start from the notice and from firectl secret list. For each secret name, write down the issuing provider, the account or project it belongs to, the owner, what the key can do, and every other place the same value lives (CI variables, a .env on a laptop, another hosting platform). Do not paste values into a ticket or a chat. Names and fingerprints are enough.

firectl secret list -o json | jq -r '.secrets[].name'

The JSON field names depend on firectl's output; adjust the jq path if your output differs.

Step 2. Rank by blast radius

Step 3. Rotate at the issuing provider

For each provider, the pattern is the same: create the replacement, update consumers, revoke the old credential, confirm it fails, then review its usage for the window from late September onward. The provider sections below give the exact steps from each provider's documentation.

Step 4. Update Fireworks secrets and applications

Once the new value exists, update the Fireworks secret with firectl secret update and redeploy any application that reads the old key. Applications that used a Fireworks API key Fireworks revoked will already be failing authentication, according to the bulletin.

Step 5. Hunt for persistence

Look for anything the actor could have created: Fireworks API keys, users, evaluators, training jobs and datasets you do not recognise, per the bulletin. At each third party provider, do the same: new API keys, new IAM users or access keys, new GitHub deploy keys or OAuth apps, new Hugging Face tokens.

firectl api-key list --all-users -o json
firectl user list -o json

Step 6. Record it

Write down which credentials you rotated, when, and what the usage review showed. If a model provider key shows usage you cannot explain, open a ticket with that provider and tell Fireworks.

Provider by provider revocation steps

Each subsection follows that provider's own documentation as we read it on 22 October 2026.

Fireworks

Fireworks documents firectl api-key list (with --all-users for admins) and firectl api-key delete <key-id>. Create the replacement key first, update applications, then delete the old one. For secrets, firectl secret update --id <NAME> --value <new> or --from-file <path> replaces a value; prefer --from-file so the value does not land in shell history. For AWS credentials stored as a Fireworks secret, the documented form is firectl secret update --id AWS_CREDS --aws-access-key-id ... --aws-secret-access-key ..., which formats the pair as JSON. Remember the bulletin's warning: updating or deleting the Fireworks secret does nothing to the credential at its issuer.

OpenAI

We could not fetch OpenAI's own help or API reference pages on 22 October (they returned access errors to our fetcher), so we are not reproducing click paths or endpoint details from memory. The principle from Fireworks' bulletin applies: create a replacement key in the right OpenAI project, update your applications and the Fireworks secret, delete the old key in OpenAI, and review usage for that key and project for the exposure window. Check OpenAI's help article on deleting API keys for the current steps, and look for project keys or service accounts you did not create.

Anthropic

Anthropic's Admin API reference documents POST /v1/organizations/api_keys/{api_key_id} with a status field that accepts active, inactive or archived. The reference lists the statuses but does not spell out their effects, so after changing a key, test that a call made with it now fails. The request needs the anthropic-version header and an admin credential:

curl https://api.anthropic.com/v1/organizations/api_keys/$API_KEY_ID \
  -H 'Content-Type: application/json' \
  -H 'anthropic-version: 2023-06-01' \
  -H "X-Api-Key: $ANTHROPIC_ADMIN_KEY" \
  -d '{"status": "inactive"}'

The returned object includes partial_key_hint, created_at, created_by and scope (workspace or organization). Use partial_key_hint to match the key against Fireworks' fingerprint, and created_by to spot keys created by an actor you do not recognise. Create the replacement in the same workspace before you deactivate the old one.

Google (Gemini API and Google Cloud API keys)

Google Cloud's API key documentation gives these commands:

# List keys, including recently deleted ones
gcloud services api-keys list
gcloud services api-keys list --show-deleted

# Map a leaked key string to its project
gcloud services api-keys lookup KEY_STRING

# Inspect one key by ID (the ID is not the display name or the key string)
gcloud services api-keys describe KEY_ID

# Tighten API restrictions on the replacement key (the list replaces existing services)
gcloud services api-keys update KEY_ID --api-target=service=SERVICE_1

Google's rotation guidance is to create a new key with the same restrictions, update applications, then delete the old key. Google notes that a deleted key can be restored with gcloud services api-keys undelete KEY_ID only within 30 days of deletion, so deletion is reversible for a short window; keep that in mind when you confirm the old key is dead. Google's best practices page recommends sending keys in the x-goog-api-key header rather than a URL query string, using Cloud Monitoring and Cloud Logging to spot unauthorized use, and, for Gemini API keys moving to production, making sure the service account bound to the key has no IAM roles granted. If a Google Cloud service account key (JSON) was stored as a secret, treat it as a cloud credential and rank it with AWS keys.

AWS

AWS's IAM documentation describes a rotation that avoids downtime:

# 1. Create the replacement (a user can hold at most two access keys)
aws iam create-access-key --user-name <user>

# 2. Update applications and the Fireworks secret to use the new key

# 3. Check when the old key was last used, and by which service and region
aws iam get-access-key-last-used --access-key-id <OLD_KEY_ID>

# 4. Deactivate the old key
aws iam update-access-key --user-name <user> --access-key-id <OLD_KEY_ID> --status Inactive

# 5. After confirming nothing breaks, delete it
aws iam delete-access-key --user-name <user> --access-key-id <OLD_KEY_ID>

AWS's guide is written for planned rotation and suggests waiting several days between steps. For a key named in a breach notice, compress that: deactivate as soon as the replacement is live. AWS recommends CloudTrail to monitor access key usage; search CloudTrail for the old access key ID across all regions for the exposure window, and look for CreateUser, CreateAccessKey, AttachUserPolicy and similar calls made with it. AWS's own best practice is temporary credentials through IAM roles rather than long term access keys, which is the longer term fix discussed below.

Hugging Face

Hugging Face's token documentation says to delete or refresh a leaked token from the Access Tokens tab in settings. It also documents an endpoint that invalidates a token from its raw value, with no rights over the owning account needed:

# LEAKED_HF_TOKEN holds the raw token value; avoid typing it on the command line
curl -X POST "https://huggingface.co/api/credentials/revoke" \
  -H "Content-Type: application/json" \
  -d "{\"credentials\": [\"${LEAKED_HF_TOKEN}\"]}"

Per Hugging Face, a matching token is invalidated immediately everywhere, the owner is emailed, and the endpoint always returns 202 Accepted whether or not the token existed. Hugging Face recommends one token per app or use and fine grained tokens for production. For CI, its Trusted Publishers feature exchanges the CI provider's OIDC token for a short lived Hub token, so no Hub token needs to be stored at all. After revoking, check your private models and datasets for unexpected commits or downloads.

GitHub

GitHub's documentation says a revoked or expired token cannot be restored, and revocation events may appear as oauth_authorization.destroy in your security log. For your own tokens, revoke them in your account's personal access token settings, or revoke an app's access under authorized GitHub Apps or OAuth apps, which revokes the associated tokens. GitHub also offers an unauthenticated revocation endpoint:

curl -L -X POST https://api.github.com/credentials/revoke \
  -H "Accept: application/vnd.github+json" \
  -d "{\"credentials\": [\"${LEAKED_GH_TOKEN}\"]}"

Per GitHub's REST reference, it accepts up to 1,000 credentials per request and up to 60 requests per hour, supports the ghp_, github_pat_, gho_, ghu_ and ghr_ prefixes, returns 202 on acceptance, and returns 403 if you send an authenticated request. Owners are notified. After revoking, review the security log and the audit log of any organization the token could reach for pushes, new deploy keys, new webhooks and workflow changes in the exposure window.

Summary table

What changed since first reports

The bulletin went up on 9 October at 10pm PDT. The 10 October update, at 11:16 PDT, added a completed credential review that led Fireworks to revoke more user API keys and rotate service account tokens, and set the status to "Active monitoring". As of our read on 22 October there is no newer update, no root cause and no count of affected accounts.

Secondary coverage since then has mostly restated the bulletin. LAVA Security added the CEO's reported "seems agentic" remark. Redbot Security rated it high severity under its own taxonomy. Dealroom placed it alongside the OpenCode console breach as a second platform holding customer keys. None of these adds new primary facts about how the intrusion happened.

Open questions

• Initial access. How were internal Fireworks credentials obtained: a phished employee, a leaked token, a compromised service? Unknown.
• Scope. How many accounts, and did the actor read all evaluation job environments in those accounts or only some?
• Downstream use. Has any captured third party key been used? Fireworks says that review is ongoing, and only the issuing providers can see most of that usage.
• Agentic behaviour. The CEO's reported remark has not been explained in the bulletin.
• The fix. Fireworks says it is reviewing how secrets are exposed to evaluation jobs. The design it lands on (per job scoped tokens, a broker, or a different isolation boundary) will matter for anyone choosing where to run evaluations.

Moving to short lived, scoped credentials

The deeper problem is that long lived provider keys were sitting in job environments. Here is what to change, ordered by effort.

1. One key per platform, per purpose. Never reuse the key your production app uses inside an evaluation job. A dedicated key can be revoked without an outage, and its usage is easy to attribute.
2. Scope every key down. Hugging Face fine grained tokens, GitHub fine grained PATs, Google API key restrictions and AWS IAM policies all let you cut a key to the minimum. An evaluator that calls one model needs inference on that model, nothing else.
3. Spend limits on model provider keys. Where a provider offers per project budgets or alerts, set them for keys that live on third party platforms.
4. Federation instead of stored keys. AWS recommends IAM roles and temporary credentials over access keys. Hugging Face Trusted Publishers swaps a CI OIDC token for a short lived Hub token. Where a platform supports workload identity federation into your cloud, use it, and ask platforms that do not when they will.
5. Expiry on everything else. GitHub app user tokens expire after eight hours by default, per GitHub. Prefer credentials that expire on their own over ones that wait for you to notice.
6. Treat each platform as a vendor with blast radius. Keep a register of which platforms hold which of your secrets, who owns each, and how to rotate it. When a notice arrives, the register is the runbook.

What would have helped

Practices any team can use

• A secrets register per platform: secret name, issuer, scope, owner, rotation command and every other place the value lives.
• Rotation rehearsed quarterly, so a notice becomes a scheduled change rather than an all night scramble.
• Separate keys for evaluation and production, so revoking the exposed key has no customer impact.
• Provider side alerts on spend and unusual usage for every model provider key you store outside your own infrastructure.
• A watched security inbox. Fireworks started notifying customers on 7 October, two days before the public bulletin.
• Audit logs exported off platform where your plan includes them, so you can search them later on your own terms.

Where Safeguard fits

Safeguard would not have prevented this incident or told you about it. It has no view into Fireworks' systems, it does not hold your evaluation job environment, and nothing in it would have flagged misuse of Fireworks' internal credentials. Here is the narrower part it can play.

Knowing which services likely use which providers. Safeguard builds SBOMs from repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version. Searching for packages such as openai, @anthropic-ai/sdk, google-genai, boto3, huggingface_hub or fireworks-ai gives you a list of services that probably hold the matching keys, which is a cross check on the register in step 1. Our post on SBOM incident response explains the method.

Vendor records. Safeguard's compliance suite includes a Vendors area. Recording an inference platform there, with the secrets it holds and the owner for each, gives you the register this incident calls for in a place your auditors already look.

Policies and gates. Platform policies can gate builds on what your software contains, which keeps a rushed redeploy after rotation from shipping a known vulnerable dependency.

Approved changes through the CLI. The Safeguard CLI's assistant can edit code and run commands on your machine, asking first in the default flow (/permissions offers Ask, Accept edits, Plan, Auto and Strict). You can ask it to find every place a repository reads OPENAI_API_KEY or HF_TOKEN, split a shared key into separate evaluation and production variables, or switch a CI workflow from a stored cloud key to an OIDC role, then run your tests, approving each step. The desktop and phone apps can send that work to a computer running the CLI and approve each command. In CI, safeguard exec runs the checks.

Zero-Day Discovery and Gold

These address a different problem. This incident is about credentials stored on a hosted platform, not a vulnerable package in your software.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems. Findings are issued as SGZ advisories before they reach public CVE databases. It has nothing to say about how this intrusion happened, and Fireworks has not attributed it to a software vulnerability.
• Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid: hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages. An artifact loses its badge if it regresses.

The habit that carries across incidents is speed: knowing what you run and where your keys live, and being able to rebuild and redeploy from patched, signed components quickly. For the wider month, see October 2026 security incidents and what would have helped.

Common mistakes

1. Deleting the secret in Fireworks and stopping there. Fireworks says this does not invalidate the credential. The key still works at OpenAI, AWS or GitHub until you revoke it there.
2. Revoking before replacing. Create the new credential, update consumers, then revoke, or you trade a security incident for an outage. The exception is a key with clear signs of abuse: revoke immediately and accept the outage.
3. Rotating only the keys you remember. Use the notice and firectl secret list, not memory. Ask Fireworks for the secret names if the notice was vague.
4. Forgetting other copies. The same OpenAI key often lives in Fireworks, CI, a hosting platform and a laptop .env. Rotation means every copy gets the new value.
5. Skipping the usage review because nothing looked wrong. Fireworks recommends rotating even without suspicious activity, and reviewing what each credential could reach.
6. Ignoring keys the actor created. Fireworks revoked keys the actor created on its side. Check each third party provider for keys, users or tokens you did not create.
7. Assuming the 30 day Google undelete window does not matter. A deleted Google API key can be restored within 30 days. Make sure only trusted admins hold that permission while you clean up.
8. Pasting raw tokens into revocation commands. Hugging Face explicitly warns against raw tokens on the command line. Use environment variables or files, and clear shell history.

FAQ

Was my Fireworks account affected?

Fireworks says only accounts that received a direct notice are affected, and others have not been identified as affected so far. Check the inbox of every Fireworks account admin and your security contact address for notices from 7 October onward.

What exactly was exposed?

Environment variables used in evaluation jobs in a limited number of accounts, which Fireworks believes included API keys and tokens stored as secrets. Fireworks says it has not seen evidence of access to models, datasets, training data, inference traffic or personal information.

Fireworks revoked my Fireworks API key. Do I need to do anything else?

Yes. Create a replacement Fireworks key and update your applications, which will fail authentication until you do. Then rotate every third party credential named in your notice at its issuing provider.

I deleted the secret from Fireworks. Is that enough?

No. Fireworks states that removing a stored secret does not invalidate the credential. Revoke it with the provider that issued it, using the steps above.

Were my prompts or model outputs exposed?

Fireworks says it found no evidence of access to inference traffic, including prompts and outputs, and that it does not store prompts or outputs by default. The investigation was still ongoing at the last update.

Did an AI agent carry out the attack?

Unconfirmed. LAVA Security reports that the CEO said on X that the behaviour "seems agentic". Fireworks' bulletin does not say this, and LAVA notes the point is unconfirmed. Your response is the same either way.

Is this the same attacker as Railway, Zeabur or OpenCode?

There is no public evidence of that. The incidents share a target type, platforms holding customer keys, and Railway described its own incident as part of a series aimed at AI inference providers. Fireworks has not linked its incident to any other, and we found no reporting that does.

Are there indicators of compromise I can search for?

Fireworks has not published any. The best indicators are your own: usage of the exposed keys at each provider, and API keys, users, evaluators, training jobs or datasets in your Fireworks account that you do not recognise.

Should I stop storing secrets on inference platforms?

Not necessarily, but store fewer and weaker ones. Use dedicated, tightly scoped keys with spend limits for evaluation, prefer short lived or federated credentials where supported, and keep a register so rotation is quick.

How do I know which key a fingerprint refers to?

Ask Fireworks for its fingerprint format, then compare against identifiers each provider shows without the full secret: Anthropic's partial_key_hint, the AWS access key ID, GitHub token prefixes, the Google API key ID and Hugging Face token names.

Fix it without waiting for upstream

Fireworks' incident is a credential problem, not a package flaw, so most of this section applies to what you rebuild and redeploy after you rotate. A rotation often forces a redeploy, and that redeploy should not reintroduce a known vulnerable dependency.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show the Fireworks incident. Each is a real Safeguard session, and the text says how the same flow applies to a rotation like this one.

The first demo is a CLI session that fixes a lodash CVE: the assistant reads the finding, asks before each command, edits package.json, runs the install and tests with your approval, and pushes nothing. After a Fireworks notice, you would open the same session in your evaluation repository and ask it to find every place the code reads OPENAI_API_KEY or HF_TOKEN, rename them to dedicated evaluation variables, and run the tests. It asks before each edit and command.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. For this incident, a platform engineer could point the same flow at the infrastructure repository and approve each change that replaces a stored AWS access key in CI with an OIDC role.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. If a notice lands overnight, the on call engineer can approve the redeploy and test commands from a phone after the keys are swapped, or deny one that looks wrong.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation. For a broader playbook, see our incident response playbook for a compromised dependency.

Quick check

Sources

• Fireworks AI: October 2026 security incident bulletin
• Fireworks AI docs: evaluators
• Fireworks AI docs: using secrets in an evaluator
• Fireworks AI docs: firectl secret list
• Fireworks AI docs: firectl secret update
• Fireworks AI docs: firectl api-key list
• Fireworks AI docs: firectl api-key delete
• Fireworks AI docs: audit and access logs
• Anthropic Admin API: update API key
• Google Cloud: manage API keys
• Google Cloud: best practices for managing API keys
• AWS IAM: manage access keys for IAM users
• AWS IAM: update access keys
• Hugging Face Hub: user access tokens
• GitHub Docs: token expiration and revocation
• GitHub REST API: revoke a list of credentials
• LAVA Security: Fireworks AI security incident
• Redbot Security: Fireworks AI credential compromise
• Superpower Daily: Fireworks discloses intrusion into evaluation jobs
• Dealroom: OpenCode breach and platforms holding customer credentials

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.