Fireworks AI Breach: How to Limit Third-Party AI Data Exposure

If you use AI vendors, treat every analytics, evaluation, R&D, and backup copy of your data as its own security boundary. A protected live inference path does not protect copies made for another purpose.

Fireworks AI had two intrusions in October 2026, according to its security bulletins. The first was disclosed in October. The October 23 to 24 intrusion was publicly disclosed on November 9.

On November 10, Notion explained in its advisory that an exposed dataset contained AI chat transcripts used for its Insights analytics feature. Notion says fewer than 1% of its workspaces were affected.

Notion describes the transcripts as unattributable for the vast majority of affected workspaces: they lacked workspace IDs, user labels, and tool results. Unattributable does not mean harmless, because the text itself can hold credentials or personal data. Both investigations were still open as of November 11, 2026.

This guide covers how to inventory secondary copies, make failover policy-aware, isolate routes, and shut down one AI feature without taking down your product.

Incident timeline and confirmed scope

Fireworks says the October 24 intrusion exposed resource metadata and billing information. For select accounts, it also exposed secrets, datasets, and incomplete model weights. Fireworks says it does not store payment card numbers and that none were affected.

Fireworks reported no detected impact to its core Inference, Training SDK, or Nexus services. Its bulletin lists the incident under active monitoring. Fireworks says it engaged Palo Alto Networks' Unit 42 for forensics and notified law enforcement.

What remains unknown

• Incident relationship: neither public notice ties Notion's transcripts to one specific October intrusion.
• Threat actor: it is not public whether the same group is behind both intrusions.
• Cloud provider: Fireworks has not named the provider that hosted its R&D machines.
• Prompt contents: how many credentials or how much personal data the transcripts held is unknown.
• Customer scope: Fireworks has not published how many customers were affected.

The risk is the copy, not the call

Map AI data by purpose, not only by vendor. The same prompt can land in systems with different users, credentials, retention periods, deletion methods, and subprocessors.

Zero data retention (ZDR) is a commitment not to keep covered request and response data. Its scope depends on the endpoint and the purpose.

According to Notion's incident FAQ, its enterprise ZDR commitment covers requests sent to third-party model vendors to generate responses. It does not cover features that need stored requests and responses, such as chat history and Insights.

Notion says it sent those stored requests and responses to Fireworks for the Insights analysis. Fireworks had given a contractual ZDR commitment for this use, but Notion's investigation found data retained from the endpoints it used. Notion says it is now auditing critical vendors, such as inference providers and data processors, to verify their data minimization and ZDR practices.

So for each AI feature, ask which later processes receive the same content, why they need it, and how every copy is removed. Our article on security risks in LLM routers covers routing failures and abuse. The rest of this guide covers secondary copies and containment.

Inventory and control every secondary copy

Keep one inventory shared by application, security, data, and vendor-management teams. For each copy, record its data, purpose, storage location, retention, credentials, subprocessors, deletion method, and evidence owner. If you still have untracked AI workloads, our playbook for moving from shadow AI to governed AI helps you find them first.

Use field-level allowlists when input is structured. Regular-expression redaction cannot prove that a free-text prompt holds no secrets or personal data, so limit which workloads receive raw text at all.

Include fourth parties. Ask each vendor for its current subprocessor list, change-notification terms, incident-notification service levels, regional commitments, and deletion evidence.

When a copy is deleted, the verifier named in the inventory should document what was removed and what remains, including backups, forensic evidence, derived analytics tables, and subprocessor copies.

Make failover policy-aware

Automatic failover can widen exposure if it checks only availability. A backup destination should also satisfy the request's data class, region, retention requirement, and credential scope.

This example fails closed when no destination meets every condition:

providers = [
    {"name": "primary", "classes": {"confidential"}, "regions": {"eu"},
     "retention": 0, "scopes": {"assistant"}, "available": False},
    {"name": "backup", "classes": {"public", "internal"}, "regions": {"us"},
     "retention": 30, "scopes": {"assistant"}, "available": True},
]

def choose(request):
    evaluations = []
    for provider in providers:
        reasons = []
        if not provider["available"]: reasons.append("unavailable")
        if request["data_class"] not in provider["classes"]: reasons.append("data_class")
        if request["region"] not in provider["regions"]: reasons.append("region")
        if provider["retention"] > request["max_retention"]: reasons.append("retention")
        if request["scope"] not in provider["scopes"]: reasons.append("credential_scope")
        if not reasons: return {"decision": "allow", "provider": provider["name"]}
        evaluations.append({"provider": provider["name"], "reasons": reasons})
    return {"decision": "deny", "evaluations": evaluations}

request = {"data_class": "confidential", "region": "eu",
           "max_retention": 0, "scope": "assistant"}
print(choose(request))

In this sample, the primary is unavailable. The backup fails the data-class, region, and retention checks, so the request is denied with the reasons attached. Surface that denial instead of silently downgrading policy.

Regional restrictions, short-lived credentials, egress controls, and retention settings exist only where a provider supports them, so check each destination before approving it. Using several providers reduces dependency risk, as our guide on not relying on a single AI provider explains, but every added route needs the same governance.

Isolate routes, monitor access, and add kill switches

Separate credentials, projects, and environments by feature and route. An analytics job should not reuse the identity used for live inference, and an R&D environment should never hold a production route key.

Monitor request IDs, pseudonymous tenant identifiers, route choices, destinations, token volume, credential use, deletion events, and policy denials. Keep payloads out of routine telemetry.

Fireworks says the evidence links the activity to a financially motivated group that sells stolen access to LLMs to illicit routing gateways, a practice known as LLMjacking. To spot that kind of abuse on your own keys, use the methods in our guide to detecting abnormal LLM API credential usage.

Build a kill switch per AI or analytics feature, not one switch for the whole product. Notion says it disconnected from Fireworks, halted training runs, disabled Insights, and stopped serving open-weight models through Fireworks, while the rest of the product kept running.

Notion also lets owners of affected workspaces download the exposed content, with flags for potential sensitive information, so they can rotate credentials. Plan for that step: affected parties need usable evidence, not just a notice.

What these controls don't cover

These controls reduce what each copy holds and how fast you can contain an incident. They would not necessarily have prevented the Fireworks incidents, and some risks stay with you:

• Vendor administrators and insiders: a compromised or malicious operator can reach any data your policy let the vendor hold.
• Inaccurate commitments: contracts and attestations can be wrong. Notion had a contractual ZDR commitment from Fireworks, and data was still retained.
• Free-text prompts: users paste secrets and personal data that no filter reliably catches.
• Backups and forensic copies: they can outlive deletion from active systems, sometimes by design.

Where Eden AI fits in the trust chain

A gateway such as Eden AI sits between your application and downstream model providers, so it is one more system in your inventory. Start with our AI gateway overview, then compare the documented zero data retention and region policies, fallback, and custom API keys options with your own requirements.

For any gateway, document what it receives, stores, logs, and routes, and apply the same policy checks to it as to each downstream provider. A gateway can centralize policy decisions, but it cannot control what a provider does with data once it arrives, and it is itself a privileged trust boundary.

What to check this week

The takeaway

• Inventory copies by purpose: treat inference, analytics, evaluation, R&D, and backups as separate boundaries.
• Minimize stored data: allowlist structured fields and restrict raw prompt access.
• Isolate features and routes: use separate credentials, environments, and kill switches.
• Test containment: exercise policy-aware failover, deletion verification, and feature shutdown.

FAQ

Further reading

• Fireworks security bulletins: the primary notices for both October incidents and the hardening steps taken.
• Notion's security advisory: the response timeline and the November 11 key revocation.
• Notion's incident FAQ: how affected owners review the data, and what Notion's ZDR covers.
• LLM API Security: How to Detect Abnormal Credential Usage: practical monitoring for stolen or misused keys.
• From Shadow AI to Governed AI in 30 Days: a process for finding and governing untracked AI workloads.