Fireworks AI Security Incident: Exposed Secrets and API Key Actions

Fireworks AI disclosed a security incident on October 9 and expanded its response in an October 10 update. An intruder used internal credentials to access evaluation-job environment variables in a limited number of customer accounts. Fireworks believes those included stored API keys and tokens. It says it first detected the activity on October 6.

The official bulletin, updated at 11:16 a.m. PDT on October 10, adds further user-key revocations and service-account token rotations. Identified affected customers were notified directly. Its current assessment finds no evidence of unauthorized access to models, datasets, training data, personal information or inference traffic within Fireworks' security perimeter. Review of exposed-credential activity continues.

Affected customers should replace revoked Fireworks keys, rotate identified third-party credentials at their issuers, and review associated activity. Fireworks says customers without an affected-account notice currently need no incident-specific action. These remain the company's findings during an ongoing investigation.

Evaluation infrastructure carries real access

An evaluator is executable software. Fireworks' evaluator documentation describes uploading Python source, dependencies and test functions that run inference and score outputs. The resulting evaluator can be used in evaluation jobs or reinforcement fine-tuning. That helps explain why evaluation belongs in the security review of an AI application, alongside the model endpoint and the application itself.

The practical question for a team is what that software can reach. A test may be temporary, but the credentials supplied to it can have a longer life and a wider scope. Reviewing an evaluation should therefore include the identity it runs under, the services it calls and the permissions each credential provides. This is an architectural implication, not a claim about the attacker's undisclosed entry point.

Read the retention promise precisely

Fireworks' data-handling documentation defines its default zero-data-retention behavior for open-model prompts and generations: no persistent logging without opt-in, with request data held in volatile memory. It also documents exceptions and settings. The Responses API stores conversations for 30 days when its default store option is enabled; customers can disable that storage.

For a buyer, this is a reason to ask separate questions about each part of the system. How are prompts handled? Where are credentials held? What identity can read them? Which service decides whether a copied key still works? A retention policy is useful evidence about a particular data flow. The security review still needs to follow the credentials through the rest of the application.

Rotation needs an owner and a verification step

OWASP's secrets-management guidance recommends revoking exposed credentials, deploying replacements, removing obsolete copies and retaining the information needed to investigate their use. It also recommends minimum necessary permissions, short-lived credentials where feasible, and documented ownership and dependencies. Deleting a stored copy or restarting its consumer does not invalidate a credential at the issuing service.

A useful response record would track each identified key, its issuer, the affected application, the person responsible and the time revocation was confirmed. Record whether the replacement works, too. That makes the handoff between security and application teams concrete without putting the secret itself into an incident ticket.

For Enterprise accounts, Fireworks provides audit and access logs through its CLI and API. Its documentation describes storage reads, writes and deletes, with filters including API-key identifiers. There are two details worth checking during an investigation: CLI date ranges use midnight UTC, and an empty results page can still contain a continuation token. Reviewers need to exhaust pagination before treating a search as complete.

The broader lesson is operational. Before adding another credential to an AI workflow, know who can revoke it, what will stop working and how the team will establish that recovery is complete. Those answers make an incident easier to contain and a normal deployment easier to maintain.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn complex product decisions into clear articles and founder-led stories people can understand.

Book a 30-minute call