Your AI vendor's breach is your customer's transcript

A breach at your AI vendor does not expose your systems. It exposes your customers' words, and the vendor may not be able to tell you whose words they were. That is the detail buried in Notion's disclosure of November 12, 2026: the stolen chat transcripts were, in the company's own phrasing, "unattributable" for the vast majority of impacted workspaces. Not unencrypted, not unfiltered. Unattributable, meaning the record did not carry who wrote it or which workspace it came from.

One word, and it rewrites the question you should be asking about every automation that touches an inbound message. Not "are we secure", which nobody can answer honestly. Instead: how many copies of a single customer conversation exist, where do they sit, how long do they live, and could you prove which customer each one belonged to?

Most teams running a chatbot, a WhatsApp intake flow or an AI-assisted sales pipeline have never counted those copies. The count is usually four, and the fourth one is the one that lives longest.

What the Fireworks AI incident actually exposed

The timeline matters, because it shows how long a vendor takes to know what it lost, and how little the customer can do while it works that out.

Fireworks AI is an inference provider that serves open-weight models, used inside products you would recognize. Its own bulletins describe two incidents in two months. On October 6, 2026 it detected unauthorised use of internal credentials that exposed environment variables, including API keys and secrets, in a limited number of customer accounts. Then on October 23 an attacker reached Fireworks' development machines through a third-party cloud provider hosting its research infrastructure, ran an unauthorised workload, and widened the impact to account and billing information, secrets, datasets and incomplete models for a limited set of accounts.

Notion's disclosure is the clearest account of what that looks like from the customer side. Notified on November 2, it assessed the first dataset as synthetic testing data. It disconnected from Fireworks on November 3 and deleted the data it held there on November 4. On November 6, Fireworks told Notion that customer data may have been accessed. The final impacted dataset arrived on November 8. Customers were contacted on November 9, and the advisory was revised again on November 12.

The affected data was Notion AI chat transcripts from an Insights feature, covering fewer than 1% of workspaces. Notion's explanation of "unattributable" is precise and worth reading twice: the chats were not labelled with who wrote them or which workspace they came from, the transcripts did not contain tool call results, and beyond the transcript itself there was no information tying the chat back to a workspace, a user or a company.

Now read the line Notion published alongside it: "If you haven't heard from us, we haven't identified your workspace as affected, and no action is needed right now."

That is an honest sentence from a company doing the work in public. It is also, for unattributable data, not a guarantee. If the dataset cannot be tied to a workspace, then silence is not evidence of safety, and every customer has to decide for themselves whether to rotate the credentials they pasted into a chat window. Notion says exactly that to the customers it could identify. The rest are left to infer it.

The four places a copy of one conversation lives

Here is the part almost no automation plan accounts for. A single inbound WhatsApp message that gets summarised by a model and written into a CRM does not create one record. It creates a copy at each hop, under four different sets of terms, with four different people who could plausibly claim to own it.

Two details in that table deserve their own paragraph.

The first is the orchestration layer, because it is the hop teams forget they own. A workflow tool's execution history is a full-text archive of your customer conversations, including the model's replies. n8n's defaults prune it after two weeks and after ten thousand runs, which sounds short until you remember that the same payloads are usually copied into a backup, or pulled into a spreadsheet for a quality review, and those copies have no expiry at all.

The second is that vendor retention is often not a number. Google's paid Gemini API terms commit to logging prompts and responses "for a limited period of time, solely for detecting and preventing violations" of its prohibited use policy, and stop there. OpenAI publishes 30 days for abuse monitoring and offers zero data retention to approved organizations, but eligibility is per endpoint: conversation objects, threads and vector stores are retained until you delete them and are not eligible at all. "We have ZDR" is therefore a statement about a contract and a subset of endpoints, not about the architecture you actually deployed.

Attribution is a design decision, and it is the one Notion lost

The uncomfortable lesson in the Fireworks incident is not that a vendor got breached. Vendors get breached, and an attacker who reached a development machine through a cloud account is not a failure you can audit for from outside.

The lesson is that attribution was lost in the data pipeline before the breach, and its absence is what turned a scoped incident into an unanswerable one. Once the transcript has no tenant identifier, the vendor cannot scope it, cannot notify the right customer, cannot prove the negative, and cannot even give you a useful export. The customer's only remaining move is to assume the worst about a conversation they cannot identify.

That is fixable in your own stack, cheaply, before anything goes wrong. Stamp a stable customer or workspace identifier and a conversation identifier into every model request you send, and keep the join between that identifier and the actual customer in a table you own. Do not rely on the vendor to preserve it, and do not rely on it surviving in the vendor's UI. The record you need at 2am is one where a dataset, a conversation and a customer resolve to each other without anyone's help.

This is the same discipline as deciding what an agent is allowed to write, which we covered in the booking boundary post. Permissions decide what an agent can change. Attribution decides whether you can ever reconstruct what it did.

Retention is the only lever you control

You cannot stop a breach at a vendor. You can decide how much of your customer's history is sitting there when it happens, and you can decide whether the deletion path works before you need it.

That is a different kind of work from a security questionnaire. It is three concrete moves, in this order.

Cut the copies you did not mean to make. Every transcript exported to a spreadsheet for a quality review, every debug log that captured a full request body, every "let's keep a sample" folder, is a copy with no owner and no expiry. In client work the copy that surprises teams most is never the model provider, it is the export somebody made to check whether the bot was answering well.

Set the pruning you assumed was already set. Execution history in an orchestration tool is a retention setting, not a law of nature. Check the window, check the run-count cap, and check whether backups inherit it. A 14-day default is defensible. A backup that keeps the same payloads for a year is not the same policy.

Run a deletion test with a real record. Write one synthetic conversation through the whole chain, then delete it at each hop and ask for confirmation in writing. If a vendor can only offer a policy page and not a confirmed deletion of a specific record, you have learned something more useful than any certification badge: you have learned what your incident response will actually look like.

That test also produces the artefact that makes the next vendor conversation short. Ask each provider five questions before you wire them in:

1. Can you attribute the data you hold on our behalf to our account and to a specific end user? What does that record contain?
2. What is the retention window in days, and where is it documented?
3. Is short or zero retention available on the exact endpoints we will call, or only on some of them?
4. What is the deletion request path, and what confirmation do you return?
5. If a breach happens, what do you send us: the data with attribution, or a summary we cannot map to customers?

A vendor that answers all five is a vendor you can put in front of a customer's conversation. A vendor that answers three is a vendor whose breach notice will read like the one Notion had to publish.

What to change this month

The order that matters is not technical. It is ownership, then copies, then the test.

Name one person per hop. If nobody owns the orchestration layer's execution history, it will never be pruned deliberately, only accidentally. If nobody owns the CRM's note field, it becomes a second transcript archive with a compliance problem attached.

Then delete the copies nobody asked for, and run the deletion test on the one that remains. That sequence is unglamorous, and it is the only one that changes what happens on the day a vendor emails you about a dataset you cannot read.

A breach at your vendor is not a security failure on your side. Losing the ability to attribute a conversation is. You cannot notify a customer you cannot identify, and you cannot rotate a credential you cannot prove was exposed.

If you are wiring a model into a channel that carries customer conversations, our automation and chatbot work starts with the map rather than the model, and it is usually a shorter conversation than the one you would have after an incident. The intake layer post covers where that map begins, and the evaluation harness post covers how to test what the model does once it is live.