Imagine pasting a long contract into an AI tool and asking for a summary. The answer comes back, and somewhere in the middle are a few lines that have nothing to do with your contract. They read like fragments of someone else’s conversation, a prompt and half a reply that belong to a stranger.
That isn’t a thought experiment. On October 26, 2026, Cloudflare published an incident report describing exactly this kind of failure on its Workers AI platform. For a small number of requests, responses contained text from other customers’ sessions. No attacker was involved, and nobody tricked the model into revealing a secret. The infrastructure around the model simply failed to keep customers’ data apart.
If your business sends customer or company information to a hosted AI service, this is worth understanding. In this post we’ll walk through what happened, why it’s a different problem from the one we covered in our guide to zero data retention, what went right in the response, and what to ask your own vendors.
What Happened
Cloudflare’s report says that between August 27 and September 9, 2026, the GLM-5.3 model on Workers AI, a text model from Z.ai built for coding workflows, returned data from other customers’ recent requests in some responses. The model is one of many available through the platform, and Cloudflare says no other Workers AI model was affected.
A security researcher told Cloudflare about the problem on September 8, and a fix was in place by September 9. The full post-mortem was published on October 26, alongside a write-up from SGLang, the open-source inference engine involved, after Cloudflare coordinated the disclosure with SGLang’s developer and the researcher.
The Number That Defines the Scale
155 responses contained data from other customers’ sessions, and every one of them was a reply to a prompt longer than 681,280 tokens.
That threshold matters. This wasn’t a flaw that hit everyone who used the service. It affected very long prompts to one model over about two weeks. Cloudflare says it found no evidence of deliberate exploitation, and that the pattern matched ordinary long-context usage in timing and volume. In other words, the 155 responses weren’t the result of someone probing for a weakness. They were people doing ordinary work, with ordinary tools, who happened to send a prompt long enough to trigger the fault.
Narrow doesn’t mean harmless. Each of those responses carried pieces of someone else’s prompts and partial generations. For a customer who had sent confidential material, one stray fragment is one too many.
It also helps to think about what a very long prompt usually contains. Prompts of several hundred thousand tokens tend to be big documents, long conversation histories or large collections of files, the kind of material people send when they want an AI tool to read a whole contract, a codebase or a year of correspondence. That’s an inference from how people use long context, not something Cloudflare has said about the 155 responses, and the public reports don’t describe what the leaked fragments contained. But it’s a reminder that the requests most likely to hit an edge case are often the ones carrying the most material.
There’s one more point about scale. The figure of 155 is the number Cloudflare confirmed, and it was found because a security researcher noticed the problem and reported it. From the outside, every one of these replies looked normal, because the service returned an ordinary success response. A customer receiving one would have had no signal that anything was wrong unless they happened to read the output closely and recognise that it didn’t belong. That’s why a small number can still deserve serious attention: a flaw that’s invisible to the people it affects is hard to size by counting complaints.
Two Small Issues, One Serious Exposure
The cause was a combination of two things, neither dramatic on its own.
The first was a configuration mismatch. Cloudflare deployed the model with a context window of 1,048,576 tokens, but the memory pool on the GPUs that process the prompt could hold only 681,280 tokens, around 65% of what the specification promised.
The second was a bug in the inference engine. In the way the service splits work between GPUs that read the prompt and GPUs that write the reply, an oversized request that should have been rejected kept its reserved memory pages. The part generating the answer then read from pages that still held data from earlier requests. Worse, the client received an ordinary success response instead of an error, so nothing looked wrong from the outside.
Cloudflare’s own post-mortem acknowledges a gap in its testing: it had checked response codes and engine performance at long context lengths, but not whether the model’s output made sense. A reply built from the wrong data still returns a perfectly healthy status code.
One commentator summed up the lesson as “tenant isolation is a vendor property.”
Why This Isn’t a Zero Data Retention Problem
In our post on what “zero data retention” actually means, we explained that the phrase is about what a provider stores after a request is complete. This incident is about something different: what happens while requests are being processed.
The leaked text came from data left behind in shared GPU memory by earlier requests, not from stored logs or training sets. That’s our reading of the incident rather than a claim from Cloudflare, but it points to a real distinction. A vendor can have a strict retention policy and still have a gap in isolation between customers while data is in flight. Retention answers “how long do you keep my data?” Isolation answers “who else can see it while you’re using it?” You need good answers to both.
What Went Right, and What’s Still Unclear
It would be unfair to read this only as a failure. Several things were handled well. The researcher reported the problem responsibly, the fix followed within a day, the disclosure was coordinated with the open-source project, and the post-mortem is candid about the testing gap that let it through. That transparency is what lets other teams check their own setups. The fix is in SGLang version 0.5.22, and anyone running that engine in the split configuration has a concrete check to make.
Public coverage also leaves a question open: whether and how affected customers were notified. That’s the kind of detail worth asking any vendor about before an incident, not after.
Questions to Ask Your AI Vendor
How do you isolate customers from each other during processing? Ask about memory, caches and shared hardware, not just stored data.
What do you test beyond uptime and status codes? The Cloudflare report shows why testing the content of outputs matters.
Do advertised limits match real capacity? A model’s stated context window isn’t the same as the length a service can safely handle.
What’s your incident disclosure process? Ask how quickly you’d be told, and what you’d be told, if your data were affected.
Can you tell me which of my requests were exposed? Logs that let a vendor answer that question are valuable, so ask whether they exist.
What You Can Do on Your Side
You can’t control a vendor’s infrastructure, but you can reduce your own exposure. Most of these steps are inexpensive, and together they limit how much a failure on someone else’s side can cost you.
Send less. The simplest protection is not putting sensitive data into a prompt that doesn’t need it. Remove names, account numbers and personal details wherever the task allows. If you need an AI tool to summarise a customer email, for example, it rarely needs the customer’s full name and address to do it. Replacing real details with placeholders before sending, and putting them back afterwards, is a habit that costs very little. Data that never leaves your systems can’t appear in someone else’s session.
Don’t use maximum context by default. The affected requests were unusually long. Keeping prompts as short as the job requires lowers both cost and risk. It’s tempting to paste in an entire document or a full conversation history because the tool allows it, but sending only the relevant section is usually enough, and it keeps you well away from the extreme ends of what a service handles.
Test with canary strings. Include a unique, harmless marker in test prompts and watch for it appearing where it shouldn’t. A made-up phrase that means nothing outside your test, sent in one session and searched for in others, can reveal cross-session leaks that ordinary checks would miss. Cloudflare’s own post-mortem showed that checking status codes and speed wasn’t enough, and a canary test is a simple way to check content.
Review outputs before they reach customers. A human check, or an automated one, on anything customer-facing can catch a reply that contains something unexpected. Decide which outputs matter most, such as replies to customers, summaries of contracts or messages that go out under your name, and put the review step there first. An automated check for unfamiliar names, numbers or email addresses is a sensible starting point.
Keep a record of what you send. Log which workflows send data to which AI service, and roughly what kind of data is in each. If a vendor ever reports an incident, being able to say quickly whether your data could have been involved turns a stressful week of guessing into a short check. Keep the record at the level of categories and workflows, not the sensitive content itself.
Give each AI tool only the access it needs. If an assistant connects to your files, email or customer system, limit it to the folders and records its job requires. A narrower connection means less is exposed if something in the chain goes wrong, whether the cause is a vendor bug or a mistake of your own.
Have a plan for an incident. Decide in advance who investigates, who tells customers and who talks to the vendor. Write down the first three things you’d do and who does them, so nobody is deciding that from scratch under pressure. If personal data may be involved, data protection rules on breach notification may apply, so involve your legal counsel. This isn’t legal advice, and the obligations depend on your situation. Our EU AI Act checklist covers related obligations.
An AI Data Isolation Checklist
- Listed every AI service that receives customer or company data
- Asked each vendor how customers are isolated during processing, not only in storage
- Confirmed the vendor’s incident notification process in writing
- Removed or masked sensitive details from prompts wherever possible
- Set sensible limits on prompt length instead of defaulting to the maximum
- Added a canary test to your evaluation routine
- Put a review step on customer-facing AI output
- Named an owner for AI incidents and agreed who tells customers
- Checked your contracts for data-handling and disclosure commitments
Frequently Asked Questions
What happened in the Cloudflare Workers AI incident? Between August 27 and September 9, 2026, 155 responses from the GLM-5.3 model on Cloudflare’s Workers AI platform contained data from other customers’ requests. Cloudflare published its incident report on October 26, 2026.
Which requests were affected? Only responses to very long prompts, those over 681,280 tokens, on the GLM-5.3 model. Cloudflare says no other Workers AI model was affected.
Was it a hack? No. Cloudflare found no evidence of deliberate exploitation. The cause was a configuration mismatch combined with a bug in the inference engine, and the model wasn’t tricked into revealing anything.
Does zero data retention protect against this? Not by itself. Retention concerns what’s kept after a request. This incident concerned data left in shared memory during processing, so you need to ask about isolation as well.
Should I stop using hosted AI services? Not necessarily. The sensible response is to ask better questions, send less sensitive data, and have a plan if something goes wrong.
Ask About the Whole Journey
The Cloudflare incident is a good reminder that AI risk isn’t only about what a model says. It’s also about the plumbing underneath, the memory, caches and queues that sit between your request and the reply. Vendors will keep improving, and incidents like this will keep surfacing, which makes the questions you ask before you rely on a service more valuable than any promise on a sales page. We build that kind of scrutiny into how we approach AI integration at Kilowott Intelligence, and you can see how we work in our approach.
It’s also worth noticing how this story unfolded. The flaw sat in the system for about two weeks, a researcher found it, and the vendor fixed it within a day and then published an honest account of its own testing gap. That’s roughly how responsible security should work, and it’s a useful benchmark. When you assess an AI provider, how it behaves after something goes wrong tells you as much as how it describes itself when everything is working. A vendor that explains what failed, what it changed and what you should check is easier to trust than one that says nothing at all.
The same goes for you. If you’re building AI into a product, a support tool or an internal workflow, your customers will judge you by how you handle the same moment. Do you know what data goes into each prompt? Could you tell a customer which of their requests, if any, were exposed? Could you do it quickly and calmly? Those aren’t questions to answer for the first time in the middle of an incident.
