What happened
Cloudflare runs a service called Workers AI, which lets customers use AI models hosted on Cloudflare's infrastructure. On September 8, 2026, a security researcher, Gadi Evron of Knostic, reported that very long prompts sent to one model, GLM-5.3, sometimes returned text that belonged to other users. Cloudflare says it reproduced the problem, took the model offline within 40 minutes of declaring an incident, fixed it, and restored the model on September 9. It says the exposure began when the model launched on August 27, and that 155 responses were affected, all to prompts longer than 681,280 tokens. It says no other model on Workers AI was affected. Cloudflare's explanation has two parts. It had configured the model to accept more text than the memory set aside for processing could hold, and it knew about the mismatch before launch. Separately, a bug in SGLang, the open-source software Cloudflare uses to run the model, failed to reject oversized requests properly. Instead, the response was built from memory that still held earlier customers' data. The request looked successful and the reply read coherently. Cloudflare says that after excluding its own testing and the researcher's, the affected requests look like ordinary long-context use, not someone repeatedly exploiting the bug, and that it found no evidence of deliberate exploitation. It published the report on October 26 together with the SGLang team, as a coordinated disclosure.
Why it matters for business owners
Most businesses use AI the shared way: a vendor runs the model, many customers use it at once, and a promise of separation sits between your data and everyone else's. That is normal and usually fine. This case shows what that promise depends on in practice: configuration, testing, and software that the vendor often did not write. The researcher reported seeing personal names, company names, invoice numbers, payment amounts, and source code details in the leaked responses. These were the kinds of things employees paste into AI tools every day. It is also worth noticing how it was found. The researcher first saw odd output while working through a third-party gateway, then traced it to Cloudflare. A business using a chain of tools may not know which company actually runs the model that handles its data. This was a narrow event. One model, a specific kind of very long request, and a window of about two weeks. Cloudflare says the platform fix shipped on September 9. The takeaway is not that Cloudflare is unsafe or that shared AI is unsafe. It is that isolation is something a vendor has to keep proving, and you only find out how well they do it when something goes wrong.
What owners should not misunderstand
Do not read this as proof that private or on-premise AI is always safer. Running your own model puts the configuration and software risk on your team. Cloudflare's own write-up describes how subtle the failure was. Owning the hardware changes who must catch that kind of mistake. It does not remove the mistake. Do not assume your data was involved. Cloudflare reports 155 responses, on one model, to very long prompts. Most businesses never send prompts that long. Do not assume the vendor will always tell you quickly. In this timeline, Cloudflare received the report on September 8 and published on October 26, roughly seven weeks later, after fixing the problem and working with the open-source maintainers. Coordinated disclosure is common, and it is reasonable. But it means a vendor's public account can trail the event. Do not treat a successful response as a correct one. In Cloudflare's account, the faulty requests returned a normal success status and a fluent answer. Its own pre-launch testing checked response codes and speed, not whether the output made sense. That is a lesson for any business testing an AI tool: check the content, not only whether it ran.
The operational lesson
You cannot inspect your vendor's servers. What you can control is what you send and what you have agreed in writing. Start with data. List the kinds of information your team puts into AI tools: customer names, invoices, contracts, employee details, source code. Not all of it carries the same risk if it ever appeared in someone else's reply. A public product description is not an unpublished contract. Then look at the chain. For each AI tool your business depends on, find out which company runs the model and where it is hosted. The tool you pay for may sit on top of a gateway, which sits on top of a model host. Finally, look at the promise. A vendor's terms usually describe how it protects your data. They matter less than what it commits to do if that protection fails: how fast it will tell you, what it will tell you, and who you contact.
What a serious business should do next
Make a one-page list of the AI tools in use, who runs the underlying model, and what kinds of data go in. Include tools staff adopted on their own. Sort the data into tiers. Decide what may go into any shared AI service, what needs a vendor with written commitments, and what should not leave your systems at all. Ask each important vendor, in writing: how do you keep one customer's data separate from another's, how do you test that after changes, how quickly will you notify us of an incident that could involve our data, and what will you tell us. Check whether your own tools pass traffic through gateways or resellers, and whether those parties keep logs of your prompts. When you test a new tool or model, test the content of the answers, including unusual cases such as very long inputs, not only whether it runs without errors. If you handle regulated or contract-restricted data, ask your lawyer or compliance adviser what your notice obligations are if a vendor reports an incident. Atlacis does not give legal advice. Do not rush to move everything on-premise because of one disclosure. Decide by data sensitivity and workflow, not by headline.
The Atlacis view
Atlacis helps owners slow down, understand the workflow, map the risk, and choose the right tool or system before spending. Cloud, private, and on-premise AI each fail in different ways, and the right mix depends on what data is involved and who can carry the operating risk. If you are not sure which of your data should go to a shared AI service and which should not, a short conversation can help you sort it and decide what to ask your vendors.
The short version
- On October 26, 2026, Cloudflare disclosed that 155 responses from its GLM-5.3 Workers AI model, between August 27 and September 9, contained data from other customers' requests.
- Cloudflare says it fixed the issue on September 9, says only that model was affected, and found no evidence of deliberate exploitation.
- The cause was a configuration mismatch plus a bug in open-source inference software. The faulty replies returned a normal success status.
- Know which AI tools your business uses, who runs the underlying model, and what data goes in.
- Ask vendors in writing how they separate customers' data, and how fast and how fully they will tell you about an incident.
- Private or on-premise AI moves this risk to your team. It does not remove it.