Picture this. It's a Tuesday, you're deep in a sprint, and you need to get an evaluation job running against your fine-tuned model. The grader needs to pull data from S3, so you paste an AWS key into the platform's "secrets" field.
Done in 10 seconds. Ship it.
Now picture that same key, weeks later, being sold through an underground proxy gateway to strangers who are burning through your credits.
That's the story behind the Fireworks AI double breach, and it should change how you think about every "secrets" box in every AI platform you use.
Two waves, 18 days, one very bad October
Fireworks AI is a Redwood City inference and fine-tuning platform with a lot of the market's trust. According to its own security bulletins, this is how things unfolded:
- Oct 6: Fireworks detects unauthorized use of internal credentials. Attackers had grabbed environment variables, API keys, and tokens stored as secrets, for example in evaluation jobs.
- Oct 9: The first public bulletin says there's no evidence of unauthorized access to customer models, datasets, training data, or inference traffic.
- Oct 23: A third-party cloud provider hosting Fireworks' R&D machines gets breached.
- Oct 24: The attacker pivots into Fireworks development machines and runs an unauthorized workload.
- Nov 9: After forensics with Palo Alto Networks Unit 42, Fireworks updates the story. Incomplete model weights, datasets, billing records, and resource metadata were accessed for a subset of accounts.
Read that timeline again. The reassuring "no evidence" statement on October 9 got overtaken by events two weeks later. That's not a gotcha. It's how incident response works. But it should make you wary of treating any first bulletin as the final word.
The plot twist: they had the badges
Before the first wave, the platform reportedly held SOC 2 Type II, ISO 27001, ISO 27701, ISO 42001, and a HIPAA report of compliance.
Certifications tell you a control existed during an audit window. They don't tell you that nobody can get into your R&D cloud on a random Thursday. The attack came in through the part of the house the audit probably wasn't looking at. Many SOC 2 scopes focus on production, and R&D GPU clusters often sit outside the boundary. Attackers don't read your scope document.
What actually leaked (and what didn't)
The split is the most useful part for developers.
Exposed for a subset of accounts:
- Incomplete model weights and datasets
- Stored secrets, env vars, and API keys, including third-party credentials
- Billing details (addresses, invoice history, balances, credit usage; no card numbers)
- Resource metadata (IDs, names, descriptions, timestamps)
Reportedly untouched:
- Real-time inference, the Training SDK, and Nexus, which are Zero Data Retention by default
Notice the pattern. Stateless stuff survived. Stateful stuff got hit.
If the platform never stores your data, nobody can steal it. The exposure landed on features where you hand the platform something to keep: datasets, eval secrets, batch inputs.
Why attackers wanted this: LLMJacking
This looks like LLMJacking, a financially motivated model that Google's Mandiant and Palo Alto's Unit 42 have both written about. The playbook is more like commodity trading than ransomware:
- Harvest API keys, tokens, and GPU quotas from AI platforms and pipelines.
- Plug them into underground OpenAI-compatible proxy gateways that resell cheap LLM access.
- Drain prepaid credits before the victim notices the usage spike.
Nobody locks your files or sends a ransom note. You just get a weird invoice, if you're lucky enough to look at it.
The part that should make you uncomfortable
Deleting a secret in the platform UI does not revoke the credential at its source.
If you stored an AWS, Snowflake, OpenAI, or Hugging Face token in an eval job, the platform can delete its copy all day long. The real token is still valid at the issuer until you rotate it there.
The button says "Delete." What it means is "Forget." Those are very different things.
The 4th-party problem
Here's the twist for people who never signed a Fireworks contract. Inference platforms like this often sit behind other SaaS tools as subprocessors. Your legal AI, coding assistant, or knowledge tool might route requests through them without you ever seeing the logo.
And the Wave 2 entry point wasn't Fireworks at all. It was a cloud provider behind Fireworks. For a buyer of a downstream SaaS product, that's the vendor's vendor's vendor. If you can't name your fourth parties, you can't assess them.
The dev checklist (do this today)
1. Audit your accounts. Review API keys, users, evaluators, training jobs, and datasets in every AI platform you use. Replace anything Fireworks told you was revoked.
2. Rotate at the source. Any third-party credential you ever put in an eval job or env var gets rotated at AWS, GitHub, Hugging Face, or wherever it was issued.
3. Check the logs. Look through your cloud audit logs (CloudTrail, GCP Audit Logs) from Oct 6 to Nov 9, 2026 for reads, downloads, or token use you can't explain.
4. Ask your vendors one question. "Did your Fireworks tenant receive an October/November 2026 incident notice, and do you store datasets, weights, or secrets in their eval or batch workflows?"
5. Write the rule down. Use stateless, zero-retention endpoints where you can. Don't put production datasets or long-lived secrets into third-party eval harnesses.
A quick way to hunt for leftovers in your own repos and configs:
# find hardcoded secrets that may have been pasted into eval configs git grep -nE "(AKIA[0-9A-Z]{16}|hf_[A-Za-z0-9]{30,}|sk-[A-Za-z0-9]{20,})" The takeaway
Every AI platform with a "secrets" tab is a small vault you didn't build, run by people you've never audited. The Fireworks incident isn't a story about one company having a bad month. It's about a habit: we've been treating convenience features like they're security boundaries.
Ask of every AI tool: What do I hand it, who else can reach it, and can I revoke it without their help?
If you can't answer all three, don't paste the key.
This post is based on Fireworks AI's official bulletins and the Vendor Trust Index analysis. Details may evolve as the investigation continues, so check the primary sources.
