Fireworks AI, Notion, Apify, Chainalysis and Chainstack: one week of AI and developer platform breaches, and what it says about vendor risk

In the week ending 13 November 2026, four AI and developer platforms confirmed breaches that reached customer data. The one with the widest reach was Fireworks AI, an inference platform for open-weight models. An attacker got into a third-party cloud provider that hosted Fireworks research machines, used that access to reach Fireworks development machines, and took billing data, some customer datasets and incomplete model weights. Notion, which used Fireworks for an AI feature, says chat transcripts from fewer than 1% of its workspaces were exposed, even though Fireworks had committed to zero data retention for Notion's data. In the same days, Apify confirmed an intrusion on 9 and 10 November, Chainalysis said an attacker using "offensive agentic techniques" exposed password hashes and live tokens, and Chainstack traced a dev-to-production breach to an open-source AI attack framework.

If you use any of these services, the short version is this. Rotate the keys and tokens each company names. Revoke and re-grant OAuth connections. Regenerate 2FA recovery codes where an account was in scope. Treat anything your staff pasted into an AI tool as possibly exposed. Then go and look at which other AI vendors hold your prompts and transcripts, because a contract that says "zero retention" did not stop the data from being kept in this case.

Below, we separate what each company confirmed from what is only reported (press coverage or a customer's copy of a notice), explain the mechanics, and end with a vendor checklist and a remediation list you can run today.

Key takeaways

• Fireworks AI was breached twice in October. Fireworks found the first intrusion on 6 October (secrets in evaluation job environment variables). The second began on 23 October at a third-party cloud provider hosting Fireworks research machines and reached development machines on 24 October. TechCrunch calls it the company's second breach in as many months.
• Notion's exposure came through a vendor, not its own systems. Notion says transcripts used for its Insights feature, from fewer than 1% of workspaces, were exposed, and that "data was retained from the Fireworks endpoints that we used" despite a zero data retention commitment.
• Apify lost credentials that bypass passwords. Apify confirmed that a compromised credential let an attacker obtain further credentials. A customer's copy of the notice, reported by SecurityWeek, lists salted password hashes, 2FA recovery codes, phone numbers and tokens tied to Google and GitHub sign-ins.
• Chainalysis widened its own scope. Its first notice found no access to credentials or session tokens. By 4 November it said names, usernames, password hashes and live tokens for all users were exposed.
• Chainstack published the clearest root cause. A Grafana instance with default admin credentials, then an unauthenticated MCP tool server with cluster-admin rights, then production secrets. Chainstack assesses "with high confidence" that the attacker used the ARTEX agentic framework.
• AI shows up in two ways. At Fireworks, AI was the prize: the motive was reselling stolen model access ("LLMJacking"). At Chainalysis and Chainstack, the companies say AI tooling was the weapon, which means old gaps get found faster.

The week at a glance

Fireworks AI and Notion: an inference vendor breach reaches a downstream customer

What Fireworks says happened

Fireworks runs open-weight models for developers and companies. Its public bulletins describe two linked events.

The first is in the October 2026 security incident bulletin. Fireworks identified the activity at 9am PDT on 6 October and began containment. An unauthorized party had used internal Fireworks credentials and reached "environment variables used in evaluation jobs in a limited number of customer accounts." Fireworks believes environment variables, "including API keys and tokens stored as secrets, were captured" in some of those accounts. Notifications started on 7 October. Fireworks rotated employee API keys on 9 October, then revoked more user API keys and rotated service account tokens on 10 October. At that point it reported no evidence of access to customer models or datasets, and said it does not store prompts or outputs by default.

The second is in the update bulletin, last revised 9 November. Its timeline:

• 23 October: a third-party cloud provider that hosted Fireworks R&D machines had a security incident.
• 24 October: the unauthorized party used that access to reach Fireworks development machines and ran an unauthorized workload "that caused additional customer data impact." Fireworks says it detected the activity the same day.
• 25 October: Fireworks reported no further evidence of successful unauthorized access to the platform customers use.

The affected internal application exposed three categories of data: resource metadata (identifiers, display names, descriptions, creation times); billing information (billing and shipping addresses, invoice and payment history, account balance, credit usage); and, for certain customers, "a subset of incomplete model weights and datasets." For a limited set of accounts, Fireworks also found "impact to secrets." Card numbers are not stored by Fireworks and were not affected.

The cloud provider is not named in the bulletin, in BleepingComputer's report or in TechCrunch's. We will not guess.

Fireworks says it has not detected impact to its Inference, Training SDK or Nexus products, which it describes as zero data retention by default. It is working with Palo Alto Networks Unit 42, has notified law enforcement, and has disabled self-serve dataset uploads and downloads for Batch Inference and dataset-based training while the investigation runs. The bulletin says findings are "based on our investigation to date" and may change.

Motive: LLMJacking

Fireworks links the activity to a "financially motivated" group whose aim is to sell tokens from unauthorized model access through illicit routing gateways. The bulletin uses the term "LLMJacking" and cites research by Google Threat Intelligence Group and Mandiant, published in early November. That research describes "LLM Mixers" that "proxy, aggregate, and resell unauthorized LLM access to underground subscribers," single-day fraudulent charges above $100,000 in some incidents, and cumulative charges reaching $1 million at some organizations before access was cut. Stolen or exposed cloud identity tokens were the dominant way in.

That motive shapes exposure. A group that wants model access goes for API keys and service account tokens. Datasets and transcripts may be collateral. Collateral still counts.

What Notion says

Notion's notice, titled "Notice about the Fireworks AI incident that may impact some Notion workspaces," states: "One of our vendors, Fireworks AI, notified us of a security incident impacting fewer than 1% of Notion workspaces."

Notion used Fireworks in two ways: classification jobs for Insights, a feature that helps admins understand how members use Notion AI, and general inference to serve open-weight models in the product. Notion also says it used volunteered data to experiment with training task-specific models on Fireworks. The exposed data is chat transcripts, which include "any input to or output from the model that was written to the chat." AI Meeting Notes data was not affected unless someone used it as input in a Notion AI chat.

Notion says it did not add metadata that ties a transcript to a specific workspace, and BleepingComputer quotes Notion explaining that "unattributable means the chats weren't labeled with who wrote them or which workspace they came from." Unattributable is not the same as harmless. A transcript that contains a customer name, a contract figure or a pasted credential identifies itself.

As of 3 November, Notion had disconnected its systems from Fireworks, deleted all data in the Fireworks system, stopped sending traffic and halted training runs. Insights is disabled during the investigation, and open-weight models are no longer served through Fireworks.

The notification sequence comes from reporting and is not fully consistent. The Record reports that Fireworks first alerted Notion on 2 November and said on 6 November that "malicious actors may have accessed potential customer data." BleepingComputer reports that the first dataset flagged held only synthetic test data, and that a dataset Fireworks provided on 8 November showed customer transcripts. Either way, Notion cut the connection within a day of the first alert, before the scope was clear. That is the right instinct.

The zero data retention gap

Here is the sentence every AI buyer should read twice. Notion writes: "Unfortunately, during our investigation we learned that data was retained from the Fireworks endpoints that we used." Notion's notice says Fireworks had given it a contractual commitment to zero data retention. Notion also clarifies that its own zero data retention commitment to enterprise customers covers third-party model API requests, not stored features such as chat history and Insights, and that it plans to audit critical vendors, including inference providers and data processors, for data minimization and retention compliance.

Neither company has said exactly which Fireworks surface held the transcripts. Fireworks says its real-time Inference product is zero retention by default and was not affected, and that datasets were accessed for some customers. Notion used Fireworks for batch classification and training experiments as well as live inference. Our reading, which neither company has confirmed, is that the transcripts sat in a dataset or batch workflow rather than on the real-time inference path. If that reading is right, the lesson is precise: "zero retention" is usually a property of one endpoint, and the moment you upload a dataset, run a batch job or fine-tune, you are storing data with the vendor on purpose.

Apify: one compromised credential, then many

Apify, a Czech web scraping and automation company with about 91,000 customers according to SecurityWeek, published its account on its status page.

• 9 and 10 November: an unauthorized third party accessed parts of Apify's internal systems.
• 11 November, 12:13 UTC: Apify detected the activity and cut off access. It added monitoring and, as a precaution, revoked some OAuth connections to third-party services, including GitHub.
• 12 November: Apify said "an unauthorized third party used a compromised credential to obtain a number of account credentials and accessed related Apify accounts." It rotated "various critical internal secrets," notified authorities, and said its investigation found no evidence that the revoked OAuth connections were the attack vector. Later that day it said it had notified customers whose "personal information or stored data was accessed," and that customers with no email have not been identified as affected so far.
• 13 November: Apify said "API tokens are now stored only as hashes," added network restrictions between internal services and stronger internal authentication, began a review of its whole stack, and promised a post-mortem with root cause within a week.

What Apify has not published is the exact list of data. SecurityWeek reports, citing an Apify customer who shared a breach notification on Reddit, that the notice listed names, email addresses, billing details, account activity and IP addresses, plus "salted password hashes, 2FA recovery codes and phone numbers," and "authentication tokens associated with Google and GitHub sign-ins." Card data in that notice was limited to cardholder names, expiration dates and the last four digits. Treat that list as reported until Apify's post-mortem confirms it.

The reported data set is the worrying part. Password hashes alone are a slow problem. Recovery codes and sign-in tokens are fast ones, as the analysis below explains.

Chainalysis: an "agentic" intrusion and a scope that grew

Chainalysis, the blockchain analytics company, kept a running log on its incident page. It is a useful case study in how early statements can change.

• 30 October: Chainalysis said it was the target of a cybersecurity incident involving "an external actor using offensive agentic techniques to gain unauthorized access." It reported no evidence of access to investigation content, authentication credentials or session tokens, and asked users to turn on two-factor authentication.
• 2 November: Reactor and Data Solutions went offline as a precaution.
• 4 November, 9:50am EST: "an 'on-path attack' exposed a subset of customer passwords." Affected accounts were locked, and within the hour KYT, address screening and the login page went offline after abnormal activity.
• 4 November, 11:00pm EST: the scope widened to "certain customer information including names, usernames, password hashes and live tokens for all Chainalysis users." Chainalysis said it had no evidence that investigation data was accessed or attribution data manipulated, and asked customers to send trusted IP addresses for an allowlist.
• 6 November: phased restoration began; "all users will be required to reset their passwords and rotate API keys, as applicable."
• 7 November: Reactor, KYT and Address Screening returned with enhanced security measures.
• 10 November: Data Solutions returned.

The Hacker News covered the 6 November state of play. Its headline says all users' credentials were exposed. The company's own text says a subset of passwords on 4 November morning, and password hashes plus live tokens for all users that night. Both statements are Chainalysis's; the page does not reconcile them, so we report both.

Chainalysis has not published technical detail behind "agentic." It is the company's own characterization, and we treat it as a claim, not an established fact.

Chainstack: the most complete root cause of the week

Chainstack, a blockchain infrastructure provider, published a detailed incident report on 3 November and updated it on 11 November. The Hacker News summarized it for the wider audience.

The path, in Chainstack's words and timeline (UTC):

• 26 October: the attacker reached a development environment through an internet-exposed Grafana instance "deployed for testing with its default administrator credentials unchanged," then found "an unauthenticated MCP (Model Context Protocol) tool server whose service account had cluster-admin rights."
• 29 October: development cloud credentials and machine identities were reused to reach production. A compromised access gateway identity was used at 17:08, and production Kubernetes secrets were listed and read at 17:49.
• 31 October: bulk reads from the production secrets manager ran from 01:40 to 08:31. A compromised VPN peer key disrupted database replication from 03:39, which is what triggered detection. Chainstack cut the access paths the same day.
• 2 November: investigation closed; last observed use of a copied credential at 06:28.

Exposed data: organization names, account holder names, member email addresses and password hashes. The hashing algorithm is not stated. On node credentials, Chainstack writes: "We have no evidence they were read, but we are treating them as exposed and ask customers to rotate them." It says customer nodes, the console and the API were not modified, checked against audit logs and image digests. It also says "we found no evidence that a software vulnerability was exploited." Note that the report's summary mentions "a third-party component" while the technical section describes a misconfigured Grafana instance; we report both as written.

On attribution, Chainstack is careful in a way we want to copy. It assesses "with high confidence that the attacker used ARTEX," an open-source framework "that orchestrates LLM agents to automate intrusions," based on file naming markers, tunneling tools and rapid parallel behaviour that match public reporting. It then adds that public reporting ties ARTEX to several unrelated groups, "so this does not identify who was behind this intrusion." Tooling, not actor.

Analysis: the inference provider is a data processor

Most companies treat an LLM API like a utility: send text, get text, nothing kept. The Fireworks and Notion case shows why that framing breaks down.

Map every surface where your data can live

An inference provider usually offers several products under one account, and each has its own retention behaviour:

• Real-time inference. Prompts and outputs in flight. This is where "zero data retention" commitments most often apply.
• Batch inference. You upload a file of inputs, the provider runs it later and stores results for you to download. Data sits at rest by design.
• Datasets and fine-tuning. Training data you upload, and the weights you produce. Fireworks says incomplete weights and datasets were accessed for some customers.
• Evaluation jobs and secrets. Many platforms let you store API keys as secrets so evaluation or agent jobs can call other services. Fireworks' first incident hit exactly these environment variables.
• Logs, abuse monitoring and support copies. Some providers keep inputs for a period for abuse review unless you are approved for a zero retention mode.
• Billing and account data. Invoices, addresses and usage history, which Fireworks also lost.

A zero retention clause that covers the first bullet says nothing about the other five. Notion's own clarification, that its enterprise commitment covers model API requests but not stored features, shows how easily the scope of that promise gets lost between a vendor contract and a customer promise.

Sub-processors all the way down

Under GDPR, a processor "shall not engage another processor without prior specific or general written authorisation of the controller" (Article 28(2)). In this incident the chain was at least three deep: Notion's customers (controllers) to Notion, Notion to Fireworks, and Fireworks to a third-party cloud provider hosting R&D machines. The breach began at the bottom of that chain, at a party most Notion customers had never heard of.

Two points follow. First, a vendor's sub-processor list is a security document too. Read it for where your data is stored and for which other environments, such as research machines, can reach it. Second, Article 33(2) requires a processor to notify the controller "without undue delay after becoming aware of a personal data breach." Fireworks detected the second intrusion on 24 October; reporting places its first alert to Notion on 2 November. We do not know what Fireworks knew about Notion data in between and draw no conclusion about compliance. But your contract should define that gap in hours.

Development environments are part of production risk

Fireworks lost data through development machines; Chainstack through a test Grafana and development credentials reused in production; Apify through one credential that unlocked others. The common failure is an internal environment that holds, or can mint, credentials for systems with customer data.

Analysis: token and OAuth sign-in theft, and why 2FA recovery codes matter

Tokens skip the login

Passwords and second factors protect the act of logging in. Tokens are what you get after logging in. A stolen access token, refresh token or session token lets an attacker act as the user without seeing a login screen, so MFA never triggers. Google's LLMJacking research names exposed or stolen cloud identity tokens, including service account keys, GitHub personal access tokens and active session tokens, as the dominant way in, and describes one actor tricking users into pasting a token payload that "bypassed password and MFA controls."

That is why Chainalysis forced password resets and API key rotation for every user, and added IP allowlists, after live tokens for all users were in scope. A password reset does not always kill existing sessions or keys. Revoking them does.

OAuth sign-in tokens are a second front door

When you "Sign in with Google" or connect GitHub to a platform, the platform may hold tokens that act against your Google or GitHub account, within the scopes you granted. For a platform that builds code from private GitHub repositories, as Apify does for some Actors, those scopes can include read access to private repos. If the reported Apify data set is accurate, the risk runs both ways: the token could be replayed against Apify, and, depending on its scope, against the connected GitHub or Google account.

Apify revoked some OAuth connections as a precaution and asked customers who build from private repos to reconnect. That is the right fix on the vendor side. On your side, revoking the grant at the identity provider (GitHub's authorized OAuth apps list, Google's third-party connections page) guarantees the old token is dead, whatever the vendor's internal state.

2FA recovery codes are a password-sized bypass for MFA

Recovery codes exist so you can get into your account when you lose your phone. That makes each one a single-use key that replaces the second factor. If an attacker holds a recovery code and can recover or guess the password, MFA is gone for that account.

The reported Apify notice lists salted password hashes and 2FA recovery codes together. Salting slows offline cracking but does not stop it for weak or reused passwords. The notice, as reported, does not say whether the recovery codes were stored hashed. Until Apify says otherwise, assume they were usable. Regenerating them invalidates the old set immediately and costs a user about a minute.

Phone numbers add a third risk. They feed SIM-swap attempts against SMS-based recovery and make targeted phishing more convincing. Apify's own warning is apt: it "will never ask for your password, 2FA codes, or payment details."

Analysis: agentic and AI-assisted attack claims, kept in proportion

Two of this week's victims say AI tooling was used against them. Both claims deserve to be reported, and both deserve care.

What is established. Chainstack's assessment rests on concrete markers it lists and links to public reporting. Google Threat Intelligence Group and Mandiant describe ARTEX, in a 31 October analysis, as "an autonomous, multi-agent LLM-driven pentesting and offensive command-and-control (C2) platform." They observed execution sequences in bursts of roughly 2 to 25 seconds, and pauses consistent with human steps such as offline password cracking. In several cases the adversaries supplied stolen credentials and then let the framework run the later stages.

What is claimed but not shown. Chainalysis has not published evidence for "offensive agentic techniques." That is no reason to doubt it, only to label it as the company's characterization.

What it does and does not change. Google's own assessment is sobering but measured: current use of these frameworks is "still in early stages," with open source tools "used in low-sophisticated ways, resulting in broad and noisy, but still successful campaigns," and they "trade stealth for velocity." Look at what the agent exploited at Chainstack: a default password on an exposed dashboard and an unauthenticated tool server with cluster-admin. Those are not new vulnerability classes. An agent finds them faster and acts on them faster.

Two consequences follow for defenders:

1. Time to exploit shrinks, so time to fix must too. A misconfiguration that a human attacker might find in weeks can be found and used in minutes. Google's guidance is to move to short-lived workload credentials, restrict admin APIs and consoles to trusted networks, and monitor for "identity velocity, API bursts, and volumetric anomalies."
2. Your own AI tooling is attack surface. The unauthenticated MCP server at Chainstack was the bridge from a test dashboard to cluster-admin. Every MCP server, agent runner and model gateway you deploy needs authentication, least privilege and an owner.

And AI as the target. Fireworks is the other half of the story. LLMJacking groups are not using AI to break in; they break in to steal AI. The defences overlap (credential hygiene, scoped keys, spend caps), but the detection signal differs: Google suggests watching gateway logs for "anomalous, low-volume requests (such as max_tokens=1 or zero-temperature pings)," which is how stolen keys get validated before resale.

What customers of each company should do now

These steps combine each company's own guidance with our suggestions, which we label.

Fireworks AI customers

From Fireworks' bulletins:

• Read your notification if you received one; Fireworks says it includes recommended actions. Contact security-notice@fireworks.ai with questions.
• Create new Fireworks API keys for any revoked keys you still need, and update applications, which will fail authentication until you do.
• Rotate every third-party credential listed in your notice with the provider that issued it. Fireworks is explicit that deleting a stored secret does not revoke the credential.
• Review access logs for systems those credentials could reach, and rotate even if you see nothing suspicious.
• Look for unfamiliar API keys, users, evaluators, training jobs or datasets, and report them.

Our suggestions: delete every stored dataset, batch result and fine-tune you no longer need, and set spend alerts on any model API whose key lived in a Fireworks secret.

Notion customers

• If neither Notion nor your workspace owner contacted you, Notion says "no action is needed right now."
• If you were affected, workspace owners can review data from the sidebar help menu under Security incident review, in a desktop browser.
• Notion recommends treating the data "as if it were exposed." If anyone pasted passwords, API keys or other credentials into Notion AI during the period, rotate them now.

Our suggestion: tell staff, in one plain sentence, never to paste credentials into any AI assistant.

Apify customers

From Apify's status page:

• Follow the instructions in any email from Apify.
• If you build Actors from private GitHub repositories, reconnect GitHub (Change provider, then GitHub, then authorize). Reconnect other integrations if prompted.
• Set storage access to Restricted (Console, Settings, General resource access). Apify notes that while it is open, "anyone who knows a storage ID can read that storage."
• Watch for phishing.

Our suggestions, given the reported data: change your Apify password and any password you reused; regenerate 2FA recovery codes and move off SMS-based 2FA where you can; in GitHub and Google, revoke Apify's existing OAuth grant before re-authorizing; regenerate Apify API tokens used in pipelines; and review GitHub audit logs for unexpected clones of the repositories Apify could read.

Chainalysis customers

From Chainalysis's incident page:

• Reset your Chainalysis password and any password reused elsewhere.
• Rotate API keys "as applicable" before registering transactions.
• Provide trusted IP addresses for the allowlist and reconnect using the steps in Chainalysis's emails.
• Turn on two-factor authentication.

Our suggestion: keep the IP allowlist after the incident closes.

Chainstack customers

From Chainstack's report:

• Change your password, and any password reused elsewhere.
• Rotate node credentials in the console; existing endpoints keep working until you do.
• Regenerate platform API keys if you use the platform API.
• Be wary of phishing; Chainstack "will never ask for passwords, tokens or keys."

Our suggestion: compare node request volumes before and after 26 October.

A vendor review checklist for AI providers

Notion's plan to audit its inference providers is the right one, and it applies to anyone who sends data to a model provider directly or through a SaaS product. Use these questions in procurement and at every renewal. Ask for answers in writing, tied to the specific products you will use.

Data retention

• For each product you will use (real-time inference, batch, datasets, fine-tuning, evaluation, agents), what is stored, where, and for how long?
• Are prompts or outputs kept for abuse monitoring, debugging or support? For how long, and who can read them?
• Are customer datasets, batch results and uploaded files deleted automatically, or only on request?
• Can you delete stored data yourself, and does deletion cover backups?

Zero retention modes

• Which endpoints does the zero retention commitment cover, by name? Which does it not cover?
• Is it on by default, or only for approved accounts? Is it in the contract or only in documentation?
• How can you verify it is in effect for your traffic, rather than as a published policy?
• Does it apply when the provider routes to a sub-processor or fallback?

Regions

• Where is inference processed, and where is stored data held, for each product?
• Can you pin processing to a region, and does that pin cover storage, logs and support access too?
• Where do research and development environments run, and can they reach production data?

Sub-processors

• Who are the sub-processors, including cloud and infrastructure providers for non-production environments?
• How much notice do you get before a new one is added, and can you object?
• Do the provider's development, research or evaluation systems hold customer data or credentials that reach it?

Breach notice SLAs

• How many hours after detection will you be notified of a suspected incident, not just a confirmed one?
• Will the notice say which of your data, by product and dataset, was in scope?
• Will they share indicators, timelines and a written root cause, and by when?
• Is there a named security contact and a tested channel that is not the account you might need to rotate?

Two more questions belong on every list. Can API keys be scoped by model, environment and spend? Google's LLMJacking guidance recommends exactly that, so "a compromised token for a basic utility model cannot be used to invoke expensive, high-tier frontier models." And does the vendor's SOC 2 Type II report scope include the non-production environments that can reach your data?

Fix it without waiting for upstream

None of these steps waits for a vendor's post-mortem. They work for this week and for the next vendor breach.

1. Rotate OAuth tokens. For every platform you connected through Google, GitHub or Microsoft sign-in, revoke the grant at the identity provider, then re-authorize only the ones you still use, with the narrowest scopes offered. Start with grants that include private repository or mail access.
2. Revoke sessions. Sign out all sessions on affected accounts and revoke API keys and personal access tokens, not just passwords. Where the vendor offers it, add IP allowlists for API keys used by servers.
3. Regenerate recovery codes. For any account at a vendor that reported a breach, generate a new set of 2FA recovery codes, store them in your password manager or vault, and move from SMS to an authenticator app or hardware key.
4. Review connected apps. Pull the list of third-party apps authorized in your GitHub organization, Google Workspace and Microsoft tenant. Remove anything unused, unknown or owned by someone who has left. Require admin approval for new grants.
5. Use short-lived credentials. Replace long-lived API keys and service account keys with workload identity federation or tokens that expire in hours. Where a provider only offers long-lived keys, scope them tightly and set spend caps and alerts so a stolen key shows up on a dashboard before it shows up on an invoice.
6. Restrict data sent to inference providers. Decide which data classes may go to which model providers. Strip or mask personal data and identifiers before inference where the task allows it. Prefer endpoints with written zero retention terms, and do not upload datasets, batch files or fine-tuning data you would not be comfortable losing.
7. Log prompts. Keep a record, in your own environment and under your own retention rules, of which application sent what class of data to which model provider and when. Metadata is often enough: model, provider, caller, data classification, token counts. When a vendor tells you "fewer than 1% of workspaces," this record is how you find out whether you are in that 1%.

A configuration example for step 6, from a gateway that supports it: requiring zero retention on a request so it is refused rather than sent to a model whose provider does not offer it.

{
  "model": "your-approved-model",
  "messages": [{"role": "user", "content": "..."}],
  "provider": {"zdr": true}
}

How Safeguard helps with this class of problem

None of this section is about these specific incidents. Each company above found and disclosed its own breach, and Safeguard played no part in that. What follows is how Safeguard customers put controls around the same risks: which AI vendors hold your data, what you send them, and how you prove it.

Route model traffic by policy and data handling. Safeguard's API Platform, which the console calls Safeguard Console, is an OpenAI-compatible AI gateway. Zero data retention is a routing rule: set it on one request or require it for the whole workspace, and the gateway sends traffic only to models whose provider offers it, refusing the rest with an error (docs). A request cannot switch off a workspace requirement. Where routing is on, provider allow and deny lists limit which providers can receive a prompt, and a third-party provider must be on Safeguard's sub-processor list before its models are served. Each model's page on safeguard.sh/models states its data policy, retention and processing region, so you can approve only models whose region fits your policy and pin traffic to those providers (regions and data residency).

Keep a record without keeping the text. By default, Safeguard does not store prompt or output text. Each request adds a metadata row to the workspace request log: model, provider, region where the catalog sets one, token counts, cost, and whether the request ran under zero retention (privacy and data). Safeguard never uses prompts, outputs or request logs to train models. That is step 7 of the list above, built in.

Guard runtime guardrails. Guard runs inside your application and checks requests, queries, commands and outbound calls against guardrails you write. It can block prompts carrying personal data before they reach a model provider, redact personal data from responses, and limit outbound calls to an allow list of hosts. Each guardrail starts in monitor mode so you can see what it would block before you enforce it. Guard also gives every AI agent its own identity, so an agent signs in as its own client and its access can be scoped and revoked on its own.

AI security checks. Safeguard's AI gateway engine checks prompts, responses and tool calls for prompt injection, jailbreaks, excessive agency and personal data egress, in monitor or enforce mode.

Third-party risk management. TPRM keeps a central vendor directory with contract and SLA tracking, risk tiers, risk scoring and ongoing monitoring with alerts (docs). Put your inference providers in it, record their zero retention scope, regions, sub-processors and breach notice terms from the checklist above, and set the review cadence by tier.

Asset discovery. You cannot review a vendor you do not know you use. Asset Discovery inventories repositories, images, packages, AI models in model registries, vendors and runtime workloads, and flags a vendor API called from production that is not listed in TPRM. That is how an unapproved model provider surfaces.

Policies and gates. Policies and gates turn the rules above into checks enforced at build, CI and release, so a new integration with an unapproved provider is stopped before it ships rather than found after.

Compliance evidence. The vendor review and data flow records feed Safeguard's compliance suite, which maps controls and evidence to frameworks including SOC 2, ISO/IEC 27001, GDPR and the EU AI Act. Safeguard itself is SOC 2 Type I and Type II audited, with reports available through the Trust Center.

To see how these fit your own AI vendor list, start at https://safeguard.sh.

FAQ

Was Notion itself hacked?

No. Notion says the incident was at a vendor, Fireworks AI, which held chat transcripts used for Notion's Insights feature. Notion says fewer than 1% of workspaces were affected, disconnected from Fireworks by 3 November, and deleted the data held there.

What data did the Fireworks AI breach expose?

Fireworks says the second intrusion exposed resource metadata, billing information (addresses, invoices, payment history, balance and credit usage), a subset of incomplete model weights and datasets for some customers, and secrets for a limited set of accounts. Its first intrusion, found on 6 October, exposed environment variables, including API keys and tokens stored as secrets, in evaluation jobs. Card numbers were not affected.

Was the Fireworks attack AI-driven?

Nothing published says so. Fireworks attributes it to a financially motivated group trying to resell stolen model access, a practice called LLMJacking. In that case AI was the target, not the tool.

Does zero data retention protect my prompts at an AI vendor?

Only on the endpoints it covers. Notion reports that data was retained from the Fireworks endpoints it used despite a zero retention commitment. Ask each vendor, in writing, which products the commitment covers, and assume anything uploaded as a dataset, batch file or fine-tuning input is stored.

What did the Apify breach expose?

Apify confirms that personal information or stored data was accessed for customers it notified, and that a compromised credential was used to obtain more credentials. A customer's copy of the notice, reported by SecurityWeek, lists salted password hashes, 2FA recovery codes, phone numbers, and tokens tied to Google and GitHub sign-ins. Apify has promised a post-mortem within a week.

Why do stolen 2FA recovery codes matter?

Each recovery code replaces your second factor once. An attacker with a code and a cracked or reused password can sign in without your phone. Regenerating codes invalidates the old ones.

Was the Chainalysis breach really an agentic AI attack?

That is how Chainalysis describes it: "an external actor using offensive agentic techniques." The company has not published technical evidence, so treat it as the company's characterization. Chainstack, by contrast, lists the specific markers behind its assessment that the ARTEX framework was used.

Sources

• TechCrunch, "Cyberattack on Fireworks AI allowed hackers to access Notion customers' chat transcripts," 12 Nov 2026: https://techcrunch.com/2026/11/12/cyberattack-on-fireworks-ai-allowed-hackers-to-access-notion-customers-chat-transcripts/
• Fireworks AI, October 2026 security incident bulletin: https://fireworks.ai/security/bulletins/october-2026-security-incident
• Fireworks AI, Update on October 2026 security incident (last updated 9 Nov 2026): https://fireworks.ai/security/bulletins/october-2026-security-incident-update
• Notion, "Notice about the Fireworks AI incident that may impact some Notion workspaces": https://www.notion.com/help/security-incident-involving-a-third-party-ai-vendor
• BleepingComputer, "Fireworks AI discloses new breach after cloud provider hack," 10 Nov 2026: https://bleepingcomputer.com/news/security/fireworks-ai-discloses-new-breach-after-cloud-provider-hack
• BleepingComputer, "Notion says Fireworks breach exposed customer AI chat transcripts," 11 Nov 2026: https://www.bleepingcomputer.com/news/security/notion-says-fireworks-breach-exposed-customer-ai-chat-transcripts/
• The Record, "AI company Fireworks says hackers stole data in October attacks": https://therecord.media/ai-company-fireworks-says-hackers-stole-data-in-oct-attacks
• Google Threat Intelligence Group and Mandiant, "LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources": https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models
• Google Threat Intelligence Group and Mandiant, "ARTEX and Friends: Enter Agentic Offensive Frameworks," 31 Oct 2026: https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks
• Apify status page incident: https://status.apify.com/incidents/sxd1dj5j6749
• SecurityWeek, "Apify confirms customer data accessed in cyberattack," 13 Nov 2026: https://www.securityweek.com/apify-confirms-customer-data-accessed-in-cyberattack/
• Chainalysis, security incident updates (30 Oct to 10 Nov 2026): https://www.chainalysis.com/blog/security-incident-october-30/
• The Hacker News, Chainalysis breach coverage, 6 Nov 2026: https://thehackernews.com/2026/11/chainalysis-breach-exposes-all-users.html
• Chainstack, security incident report (created 3 Nov, updated 11 Nov 2026): https://chainstack.com/security-incident-nov-2026/
• The Hacker News, Chainstack coverage, 3 Nov 2026: https://thehackernews.com/2026/11/chainstack-reports-production-systems.html
• Regulation (EU) 2016/679 (GDPR), Articles 28 and 33: https://eur-lex.europa.eu/eli/reg/2016/679/oj