Cloudflare's AI cache report: whose data belongs in this answer?

A successful response can still be the wrong response

A useful question for anyone building an AI application is surprisingly ordinary: whose information is this response allowed to contain? That question matters before debating model quality, response speed or prompt design. A fluent answer can look successful while violating the most basic requirement of a service shared by different customers. Availability and correctness are different promises, and a green health check cannot prove both.

Cloudflare's 26 October report describes a tenant-isolation incident in its GLM-5.3 Workers AI deployment. The affected period was 27 August to 9 September, not the week of publication. Cloudflare reports 155 affected responses, says no other Workers AI model was affected, and says it found no evidence of deliberate exploitation. The model was restored on 9 September after remediation. This week's news is the detailed disclosure of an already corrected incident.

According to that report, a configuration mismatch combined with an inference-engine error path allowed stale KV cache data to influence another request. Cloudflare corrected the configuration and patched rejection handling. The useful engineering lesson is that producing a response does not prove that the state used to produce it belonged to that request.

Source: Cloudflare incident report, 26 October

Think about a shared classroom desk

For an everyday analogy, imagine a classroom where students share desks between sessions. Each student receives a clean worksheet, but rough notes are stored in a drawer. If the next student opens that drawer, they may use somebody else's working without realizing it. The desk is available, the worksheet is readable and the lesson continues. The failure is about ownership of leftover state. This is an analogy for reasoning about isolation, not a description of Cloudflare's implementation.

Now translate the classroom into a small programming exercise. Two fictional customers each submit a harmless, distinctive marker to a toy service you control. Write down the rule that one customer's result must never contain the other's marker. That rule is more precise than the service should be secure. It names an observable property and makes the boundaries of the test understandable to someone reviewing it later.

The exercise becomes more interesting when a request fails halfway through. What state remains? Who owns cleanup? Can the next request see a partially prepared object? These questions apply to pooled database connections, reusable buffers and background workers as well as model inference. A component can be efficient and correct on its normal path while its cancellation path quietly breaks an assumption made elsewhere.

Test the promise that matters to the customer

For a hypothetical document assistant, an HTTP success code answers a narrow question: did the server return a nominally successful response? A product test needs to ask additional questions. Did the answer use the intended document? Did it respect the customer's access? Did an interrupted request leave the system ready for the next one? Separating these questions helps a team avoid treating one convenient metric as proof of the whole experience.

A practical review can start with a state diagram on a whiteboard. Give a request a beginning, a successful ending and a failed ending. For each piece of reusable state, write down who creates it, who may read it and when it stops belonging to that request. If the team cannot agree on one of those transitions, that is useful information before a test is written or a service is scaled.

Our takeaway is to make isolation part of the definition of correctness. Keep the public incident's scope precise, resist turning one provider's report into a claim about every model, and use the report to improve questions about your own software. The best outcome of reading an incident review is a clearer contract you can test, especially when the system is busy, interrupted or recovering from an error.