Fireworks AI Breach: How Attackers Stole Model Weights in 2026

For three years, enterprise security teams vetting AI vendors have asked the same questions. Are customer prompts used to train foundation models? Is PII scrubbed from inference logs? Does the vendor hold a clean SOC 2 Type II attestation? All of them assume the asset at risk is the text moving through the API. The Fireworks AI intrusion in late October 2026 put a question in that assumption.

Attackers came in through a third-party cloud provider and reached Fireworks’ internal research and development environment. They did not stop at billing metadata or static API tokens. They moved through several internal identity hops, assumed a privileged cloud service account, and began pulling the model weights and training datasets that a subset of customers had stored there. For customers such as the legal-tech company Harvey, and for enterprise inference providers generally, the breach set an uncomfortable precedent. The weights are the mathematical matrices that hold millions of dollars of compute, domain adaptation and fine-tuning, and financially motivated criminal groups now go after them directly.

Why model weights are now a prime target

Strip away the marketing language around “cloud AI” and an inference provider is a fairly plain thing. Fireworks AI sits between raw GPU hardware providers and enterprise application developers. Customers use it for more than querying stock open-weight models like Llama or Mixtral. They host custom fine-tuned checkpoints, run large batch inference jobs over proprietary corpora, and schedule continuous evaluation runs.

A fine-tuned checkpoint or a LoRA (Low-Rank Adaptation) adapter uploaded to a provider sits on disk as serialized tensor files, usually safetensors or PyTorch .bin shards, next to configuration JSONs and tokenizer models.

Until this autumn, weight theft was treated as an espionage problem for frontier labs protecting hundred-billion-parameter models from state-sponsored actors. The Fireworks breach showed that smaller, specialized customer weights in object storage buckets are just as exposed to opportunists who already have the tooling to empty cloud storage at line speed.

Fireworks AI breach timeline: October 9 to November 9, 2026

The disclosure timeline shows how cloud forensics peels back a multi-stage intrusion one layer at a time.

• October 9: Fireworks publishes its first security bulletin. The scope looks limited to secrets stored for automated evaluation jobs. Those jobs often need external keys, such as an E2B_API_KEY for sandboxed code execution, or keys for judge models and vector databases, so the platform can benchmark a model against ground-truth test suites.
• October 23: an unnamed third-party cloud provider hosting Fireworks’ research and development machines is compromised.
• October 24: the threat actor uses that foothold to land on a Fireworks development machine, runs an unauthorized workload and starts moving laterally. Fireworks detects the activity the same day.
• October 25: the attacker reaches object storage. Fireworks completes containment.
• October 26: additional credentials are exposed.
• November 9: Fireworks publishes its full update, backed by forensic investigators from Palo Alto Networks Unit 42.

How the attackers pivoted from R&D compute to cloud service accounts

Getting from an external R&D virtual machine to production-adjacent storage in under a day makes sense once you look at how hybrid AI clouds are built. Inference and training providers rarely run everything inside one AWS or Google Cloud organization. High-density GPU capacity (NVIDIA H100, H200 or Blackwell B200 clusters) is scarce and expensive on the hyperscalers, so AI providers spread their infrastructure across GPU neoclouds, bare-metal hosts and traditional clouds. Research workloads, where engineers benchmark kernel optimizations, test speculative decoding or prototype container runtimes, often land on secondary providers offering spot or reserved GPU instances.

The weak spot in many of these multi-cloud setups is where the identity planes meet. Fireworks says the actor used its foothold at the third-party provider on October 24 to reach a Fireworks development machine. Development machines come loaded with conveniences: forwarded SSH agents, cached CLI configs (~/.aws/credentials, ~/.config/gcloud), Kubernetes kubeconfig contexts, environment variables set up for integration tests. Even without production admin keys, such a machine almost always holds an identity that a jump host, a CI/CD runner or a staging IAM role trusts.

IAM role chaining and transitive privilege escalation

Fireworks said the attacker “escalated permissions via multiple hops to assume one of the cloud service accounts.” In cloud security this is IAM role chaining, also called transitive privilege escalation.

Traditional lateral movement exploits an unpatched SMB or RDP service to hop between Windows servers. Cloud lateral movement happens almost entirely as HTTPS calls to control plane APIs. The attacker lands on Instance A, queries the local Instance Metadata Service (IMDS) or scrapes memory and disk for an identity token, and finds that Identity A holds sts:AssumeRole (AWS) or iam.serviceAccounts.getAccessToken (GCP) over Service Account B. Service Account B, maybe built for a deployment pipeline or an artifact sync daemon, can in turn impersonate or invoke a workload running as Service Account C.

As far as the cloud provider’s IAM policy engine is concerned, every hop is an authorized API call. Service accounts, IAM roles and workload principals never trigger interactive MFA prompts, so an attacker who has mapped the IAM graph can cross three or four privilege boundaries in seconds with automated enumeration tools. Once the attacker held the target service account at Fireworks, they inherited its resource policies, which granted read access to an internal application and a subset of backend storage systems.

What the attackers accessed

The data reachable through that service account falls into three groups.

The first is resource and account metadata: internal Fireworks resource identifiers, model display names and descriptions, creation timestamps, billing and shipping addresses, historical invoices, account balances and credit consumption. Raw payment card numbers were not included, since external payment processors handle them.

The second is stored secrets and evaluation credentials: API tokens and environment secrets customers stored for evaluation pipelines and external integrations, including a confirmed exposure window for an E2B_API_KEY on October 26.

The third is proprietary model weights and datasets. For a specific subset of customer accounts, the attackers reached dataset repositories and model weight storage, and exfiltrated between 6.9% and 7.69% of the targeted models on October 25 before Fireworks’ incident response team cut the connection.

Why the attackers got only 6.9% to 7.69% of the model weights

That percentage is one of the most revealing details in the incident, and it invites a question: why would an attacker walk away with roughly seven percent of a model?

A modern large language model is not one monolithic file. Take a 70-billion-parameter model fine-tuned in bfloat16 precision. The raw parameters alone take about 140 GB of disk (70 billion parameters at 2 bytes each). To keep loading, caching and tensor-parallel inference manageable across multi-GPU nodes, serialization frameworks split the model into shards, for example model-00001-of-00015.safetensors through model-00015-of-00015.safetensors. An index file, model.safetensors.index.json, maps each layer (such as model.layers.0.self_attn.q_proj.weight) to the shard that holds it.

Customers using Parameter-Efficient Fine-Tuning (PEFT) through LoRA have a different layout. The base foundation model stays frozen in a shared read-only cache, and the customer’s proprietary work lives in small adapter matrices (A and B matrices injected into the transformer attention and MLP blocks). These adapter checkpoints run from a few hundred megabytes to a few gigabytes. They sit in dedicated customer prefixes in object storage such as Amazon S3, Google Cloud Storage or Cloudflare R2, next to the JSONL datasets used to train or evaluate them.

An attacker holding a service account with s3:GetObject or storage.objects.get permission runs straight into bandwidth limits, egress throttling and anomaly detection. A 6.9% to 7.69% haul matches closely what you get from downloading one shard of a 13-to-15-shard checkpoint, or from an rclone or aws s3 sync job cut off mid-stream when the SOC revokes the service account’s session token. Fireworks says it detected the unauthorized activity on October 24, the day the attacker entered the development environment, and finished containment by October 25. The attacker was racing an active incident response team and Unit 42, and bulk transfers of multi-gigabyte tensor files across the network boundary tripped volume and behavioral alerts before the full directories could be mirrored.

A partial theft still hurts. If the stolen 7% includes model.safetensors.index.json, config.json and tokenizer.json (which often exposes custom domain vocabulary added during continual pre-training), plus the embedding layers or early transformer blocks, a competitor or researcher can work out the victim’s architecture, hyperparameters, context-window scaling changes and vocabulary adaptations.

The datasets are the bigger worry. Raw fine-tuning and evaluation datasets are compact, highly compressible JSONL or Parquet files that download far faster than tensor shards. If the attacker got them, the supervised fine-tuning (SFT) prompt-completion pairs may be gone. Clean, domain-specific training data such as annotated legal contracts, proprietary medical coding records or internal source code is much harder to recreate than the compute run. Someone holding a stolen SFT dataset can rent a cluster of H100s for a few thousand dollars and train new weights from scratch.

LLMJacking: why stolen AI credentials pay better than cryptojacking

The attribution surprised many readers. Fireworks’ November 9 update pointed to a financially motivated cybercriminal group specializing in “LLMJacking,” not a corporate espionage unit or an APT state actor. A few days earlier, on November 2, 2026, the Google Threat Intelligence Group (GTIG) and Mandiant had published an analysis of how fast LLMJacking has industrialized across the cloud ecosystem.

When criminals used to land cloud credentials, whether from public GitHub repositories, SSRF bugs or exposed Docker images, the default payoff was cryptojacking. They spun up the biggest instances the quota allowed and mined Monero. It is an inefficient business. Cloud providers built aggressive heuristics to spot mining pools, and an attacker could burn $50,000 of the victim’s cloud bill to net $2,000 in laundered cryptocurrency.

Over the past eighteen months, criminal groups worked out that stolen access to enterprise AI infrastructure pays far better. In an LLMJacking operation, attackers collect API keys for inference providers (OpenAI, Anthropic, Fireworks, Together AI, or cloud-hosted Amazon Bedrock and Google Vertex AI instances) or compromise cloud service accounts that can provision model endpoints. Instead of mining coins, they feed the credentials into illicit routing gateways, known in threat intelligence circles as “LLM Mixers” or reverse-proxy markets.

These gateways expose one OpenAI-compatible endpoint (/v1/chat/completions) to paying customers on darknet forums, grey-market coding communities and unmoderated roleplay platforms. Behind it, a load-balanced pool of thousands of stolen keys and hijacked cloud accounts fulfills the requests. The operators pay nothing for GPU compute and sell discounted, uncensored or high-rate-limit token quotas for cryptocurrency. The victim’s side of the ledger is ugly. Mandiant documented individual LLMJacking incidents with over $100,000 in fraudulent compute charges in a single 24-hour window, and cumulative losses at some compromised organizations reached $1 million before billing alerts or quota limits stopped the bleeding.

The Fireworks attackers fit this ecosystem. By going after an inference provider directly, and hunting for stored evaluation credentials, account metadata and model artifacts, they were robbing the bank instead of picking the pockets of its customers. Any external key stored in a Fireworks evaluation environment, including the exposed E2B_API_KEY or third-party model keys, could go straight into an LLMJacking mixer.

AI-driven attacks and AI-driven defense

Fireworks’ forensic timeline included a line worth quoting: “Based on the evidence we see, we believe the attacking group is sophisticated in using AI to drive the attack at high speed.”

That matches what incident responders have seen through 2026. Offensive actors are wiring large language models, often powered by the same LLMJacking gateways they sell, into their post-exploitation frameworks. A human operator on an unfamiliar Linux development box in a third-party cloud spends hours reading bash histories, parsing bespoke Python deployment scripts, studying Terraform state files and mapping IAM role-assumption paths. An AI-augmented agent can ingest the whole directory tree, environment variables and cloud CLI caches in seconds, work out which sts:AssumeRole or service account impersonation calls reach the storage buckets, and write the exfiltration script on the fly.

The pace of this intrusion shows the problem. A third-party R&D machine fell on October 23, multi-hop service account escalation followed on October 24, and storage exfiltration came on October 25. Human-speed SOC triage struggles against machine-speed lateral movement.

Fireworks answered in kind. During containment and remediation, its leadership said, the team ran AI-driven detection and defense agents across its telemetry, using OpenAI Daybreak, CrowdStrike Falcon Sensor and Wiz Sensor alongside open-weight models to correlate log patterns across systems and write custom anomaly detectors in real time. While tracing the attacker’s infrastructure and TTPs, investigators also found exposed internal credentials and signs of compromise inside the public Docker images of several other companies. Fireworks quietly notified those organizations before the same group could pivot into their environments.

How Zero Data Retention (ZDR) protected live inference

The attackers got evaluation secrets, billing metadata and partial weights for a subset of accounts. It could have been much worse if they had reached the live production inference plane. They did not, and the reason is a useful blueprint for segmenting AI infrastructure.

Fireworks stated throughout its disclosures that its real-time Inference engine, its Training SDK and its Nexus platform were unaffected and covered by Zero Data Retention (ZDR) by default. After the breach it disabled self-serve dataset uploads and downloads for Batch Inference and dataset-upload-based training while it worked with Unit 42 to harden storage boundaries, yet the real-time Inference API and Training SDK kept running. That can sound like PR spin. To a systems architect it reflects how data moves through volatile memory versus persistent object storage.

A naive AI platform logs every incoming request (POST /v1/completions) to a central observability pipeline such as Elasticsearch, Datadog or an S3 data lake, for debugging, abuse monitoring or later distillation. If an attacker compromises a privileged service account with read access to that layer, millions of customer prompts and completions are up for grabs, from proprietary source code to M&A legal drafts.

A real ZDR architecture takes persistent storage out of the inference lifecycle. A customer application sends an encrypted TLS payload to a ZDR endpoint. The API gateway terminates TLS and routes the request over an internal service mesh to the worker node that holds the GPU memory space. The prompt is tokenized in system RAM, moved across PCIe or the NVLink fabric into GPU High Bandwidth Memory (HBM), run through the transformer layers, and streamed back as output tokens. The prompt and the completion are never written to an NVMe drive, a relational database or an object bucket. When the request context closes, the KV-cache blocks in GPU VRAM are zeroed or overwritten by the next batch of pointers, such as PagedAttention blocks in vLLM-style engines.

The Training SDK keeps its ZDR guarantee in a similar way. It streams training batches from the customer’s client environment straight into the training cluster’s volatile memory, without staging the dataset at rest in Fireworks’ persistent buckets. Fireworks Lab-based training also ran inside an isolated network enclave protected by dedicated Palo Alto Networks firewalls and strict storage segmentation.

Compare that with the features Fireworks had to shut down: Batch Inference and self-serve dataset-upload-based training. Asynchronous batch inference cannot run purely in volatile memory. A customer uploads a .jsonl file with 500,000 prompts, walks away, and expects the outputs twelve hours later when spot GPU capacity frees up. That workflow writes the input dataset to persistent object storage, queues a background job under a resource identifier, pulls the files through an internal worker service account and writes the results back to storage. Hosting custom fine-tuned weights has the same requirement, because the tensor shards must sit at rest in a bucket until a customer invokes the custom model ID and they load into GPU VRAM.

The compromised service account had permissions over a subset of persistent storage and an internal management application. Anything at rest in those reachable buckets was exposed: uploaded batch datasets, stored evaluation secrets, and model weights that were unencrypted or readable by the service account. Everything flowing through the stateless, volatile ZDR inference plane stayed out of reach, because there was no database or bucket to query.

How to secure AI infrastructure: four lessons from the Fireworks breach

Traditional cloud security assumptions break when applied to AI infrastructure. In a standard SaaS company, development and staging environments hold synthetic dummy data. In an AI company, R&D environments are often wired into the same high-throughput storage fabrics and artifact registries that manage production model checkpoints. Securing the next generation of AI infrastructure means dismantling the convenience-first identity patterns that let this intrusion work.

Replace long-lived credentials with workload identity federation

Fireworks called out a chronic industry anti-pattern in its post-incident reflection: static, long-lived credentials scattered across cloud-based AI platforms. A static AWS IAM access key (AKIA…), a downloaded GCP service account JSON keyfile, or a non-expiring API token baked into a Docker image environment variable is permanent standing privilege. If an attacker compromises a third-party R&D node or pulls a misconfigured public container layer, a static key gives them access from any IP address in the world.

The fix is Workload Identity Federation (WIF) with ephemeral, cryptographically signed tokens. Under WIF, a workload on an external cloud provider, a Kubernetes cluster or a CI/CD runner never holds a static cloud secret. It authenticates to its local platform identity provider (through OpenID Connect or SPIFFE/SPIRE workload attestors) to get a short-lived signed JWT assertion, then trades that assertion with the core cloud provider’s Security Token Service (STS) for a temporary access token. The token’s time-to-live is scoped to minutes, say 15 to 60, and bound by strict attribute conditions such as a specific cluster, namespace and verified private VPC endpoint. A compromised development machine has no static key to carry back to the attacker’s own command-and-control infrastructure, and a lateral hop between environments fails unless the workload’s attestation matches an explicit trust policy.

Break transitive IAM chains and enforce zero standing privilege

The Fireworks attacker chained several identity hops to assume a privileged cloud service account. Defending against automated, AI-accelerated IAM traversal means treating internal service accounts with the same suspicion as untrusted outside users.

Service accounts in R&D or third-party cloud environments should have no IAM trust relationships with production or customer-data-bearing projects. Keep development and production in separate cloud organizations or isolated accounts and projects, and use hard organizational service control policies (SCPs) that explicitly deny cross-environment sts:AssumeRole or service account impersonation.

Bind privileged service accounts to network boundaries too. Every one that touches model storage or customer metadata should be locked down with VPC Service Controls in GCP, or VPC endpoint policies and IAM condition keys (aws:SourceVpce, aws:SourceIp) in AWS. If a service account is only meant to be used by an inference loader cluster in Subnet X, an attacker who steals its token from an R&D jump box in Subnet Y should get an immediate 403 Access Denied from the storage API, because the call did not come from the authorized VPC endpoint.

Encrypt model weights per tenant

Standard Server-Side Encryption (SSE-S3 or default cloud-managed encryption) does nothing once an attacker assumes a platform-level storage service account. The storage engine decrypts objects for any principal with GetObject permission, so the tensor shards arrive in cleartext.

To stop a compromised platform service account from mass-exfiltrating customer weights and uploaded datasets, AI platforms need to separate storage access from decryption authority. Encrypt each customer’s weights and datasets with a unique Data Encryption Key (DEK) derived from a tenant-specific Key Management Service (KMS) master key or Customer-Managed Encryption Key (CMEK). Then write the KMS key policy so that kms:Decrypt is not granted broadly to a storage management service account. Decryption should require an encryption context (kms:EncryptionContext:tenant_id) that exists only while an authenticated request from that customer is in flight, or it should come from a hardware-attested Confidential Computing enclave, such as NVIDIA H100 Confidential Computing with AMD SEV-SNP or Intel TDX host isolation.

Had the customer weights at Fireworks been encrypted with tenant-isolated keys requiring runtime enclave attestation, the hijacked service account could have downloaded 7% of the blobs, or 100%, and walked away with computationally indistinguishable random noise.

Run continuous agentic red-teaming and watch egress

Quarterly human compliance audits cannot keep pace with infrastructure that changes daily and adversaries who use autonomous LLM agents to probe for misconfigurations. Fireworks found exposed credentials in other companies’ public Docker images during its own response, which shows how easily secrets and over-scoped permissions creep into complex engineering pipelines.

Teams building or consuming AI infrastructure should run automated internal scanners that map IAM privilege graphs, hunt for unrotated tokens in container registries and evaluation job definitions, and simulate multi-hop lateral movement paths before an outside actor finds them. Buckets holding high-value intellectual property such as model weights also need strict egress rate limits and automated circuit breakers. A service account that suddenly starts sequential partial reads across several customer prefixes, even at 6.9% of a model’s total byte size, should trigger a SOAR (Security Orchestration, Automation and Response) playbook that revokes active STS sessions in seconds instead of waiting for a human to escalate.