A cross-tenant cache leak needs a provenance canary, not a prompt rewrite
Cloudflare says one Workers AI model returned fragments from other customers’ requests. The incident turns tenant isolation and leak attribution into deployment tests for long-context inference.
What happened
Cloudflare disclosed on 26 October 2026 that GLM-5.3 on Workers AI exposed fragments from other customers’ prompts and outputs in 155 responses between 27 August and 9 September.
Why it matters
Teams need a repeatable way to distinguish a real cross-tenant inference leak from hallucination or training-data recall, then stop the affected serving path without overstating the incident.
What failed
Cloudflare’s incident report says GLM-5.3 on Workers AI sometimes returned fragments from another customer’s request. The company identified 155 affected responses between 27 August and 9 September 2026. It attributes the exposure to a key-value cache isolation flaw: a prefill pool could be smaller than the model’s supported context window, so a later request could read cache material that should have remained in another tenant’s boundary.
This is a serving-system incident, not evidence that the model learned those fragments during training. Cloudflare says it disabled the affected model, purged caches, rotated relevant infrastructure and worked with SGLang maintainers on fixes and hardening. It also says it found no evidence of deliberate exploitation. Those statements bound the current record; they do not establish that every exposed fragment has been identified or that another implementation could not fail differently.
Why attribution matters
Knostic’s independent account describes reproducing fragments that appeared to come from other users, including names, invoice references, file paths and agent-task records. The researchers used an ordinary authenticated paid account. Their method matters because surprising model output has at least three plausible origins: hallucination, training-data recall or live cross-tenant state. Each requires a different response.
A single strange string is weak evidence. A stronger test uses synthetic provenance canaries: unique, non-sensitive tokens placed in controlled requests for separate test tenants. The evaluator then varies context length, concurrency, cache reuse and request order while recording model, runtime and serving-region identifiers. A canary observed in the wrong tenant is direct isolation evidence without exposing a customer secret.
Build a bounded isolation test
Start with two empty test tenants and no production data. Send a long prompt containing a random canary through tenant A, then a semantically unrelated request through tenant B. Repeat across context lengths above and below any documented prefill threshold. Include control runs with caching disabled, if the platform exposes that option, and preserve raw request IDs so the provider can trace the serving path.
Treat replay as an engineering experiment, not a breach hunt. The stop condition is any foreign canary, not a subjective resemblance between prose passages. If a canary crosses, remove the affected model or cache path from service, preserve evidence, notify the provider and assess legal obligations with counsel. Do not probe other customers or insert personal data to make a leak easier to recognise.
Keep the claim narrow
The reviewed sources support a bounded cross-tenant exposure in one model and serving configuration. They do not show that all Workers AI models were affected, that attackers intentionally exploited the flaw or that source code and credentials were exposed. They also do not measure the probability of recurrence after remediation.
This extends the record-classification discipline in the Warp agent-logs incident: first identify what evidence actually crossed a boundary, then map notifications and controls to that evidence. For inference services, add a cache-isolation canary to the acceptance suite before a long-context model handles confidential work.
Preserve a comparable retest
Keep the canary suite versioned with the deployment record. A provider fix should be replayed against the same tenant pair, prompt lengths and concurrency pattern before the incident is closed, then repeated after meaningful runtime or model changes. Record negative results as bounded observations rather than proof that every cache path is safe.
Decision rule
Do not approve a multi-tenant long-context deployment from model-quality results alone. Require a passed cross-tenant canary matrix covering context length, concurrency and cache reuse, plus a provider escalation route and an emergency model-disable control. If the serving layer cannot supply request-level traceability, keep sensitive workloads in a dedicated or cache-isolated environment.