Workers AI's GLM-5.3 report: check the boundary behind an unexpected response

Cloudflare’s 26 October report concerns @cf/zai-org/glm-5.3 between 27 August and 9 September 2026; other Workers AI models were unaffected, according to Cloudflare. It dates technical restoration to 9 September and attributes exposure to KV-pool misconfiguration plus unsafe rejection handling in disaggregated SGLang deployments. Its operator recommendation is v0.5.22 or later, not a universal safety guarantee. (Cloudflare)

Knostic’s 27 October account explains its investigation of foreign session context rather than hallucination. It records 24 September as notification that the report was resolved. That is a communication milestone, distinct from the technical restoration timestamp. (Knostic)

Identify what you observed before naming the cause

Treat an unexpected response as an observation to investigate. It could reflect the application's own retrieval, a reused conversation, a tool result, an inappropriate prompt or a serving problem. A convincing-looking identifier alone does not establish its origin. Equally, calling it a hallucination does not resolve an apparent access-boundary failure.

Create a restricted incident record containing your request reference, exact model identifier, provider route, time, expected behaviour and the minimum response evidence needed for triage. If a response may contain someone else's information, limit who can access it and use a redacted description in ordinary project communication. Do not search for more affected customers or collect unrelated material to make the example more persuasive.

Ask for evidence that matches your responsibility

These questions help allocate investigation; they are not interchangeable attestations. An API customer usually cannot inspect the provider's GPU memory management. A provider's broad remediation statement is not a local record of which application outputs were accepted. Keep those evidence requests separate, with a person responsible for each answer.

Make an isolation check an explicit acceptance condition

For a deployment you control, or a test environment covered by an agreed provider scope, a proposed check can use two synthetic tenants with distinct harmless markers. Normal requests should return only the context intended for their tenant. Requests that the system cannot accept should fail through the documented rejection path without generating a response from unrelated state.

This is an unexecuted test design, not a reproduction of the published incident. Define permitted load, synthetic inputs, stop conditions and evidence retention before running it. Do not exercise oversized or adversarial requests against a shared production service merely because a public write-up contains a reproduction.

• Record the configuration and serving build used for each test, rather than relying only on a deployment label.
• Check the returned content and the association between request, tenant and result, as well as transport status.
• Include rejection, cancellation and interrupted-work cases relevant to your architecture, within the authorized test scope.
• Decide which mismatch stops acceptance and how the operator will preserve useful evidence without exposing other data.
• Repeat the agreed checks after a material configuration change; an old result applies to the configuration it actually tested.

Choose a resumption condition that can be reviewed

A useful condition is a short set of evidence-backed statements: the affected route has been identified; the operator has supplied a relevant remediation reference; the application's own context boundaries have been examined; and any questionable downstream actions have been reconciled. Where you control the deployment, add the agreed acceptance results for its actual configuration.

A hypothetical document-processing workflow illustrates the distinction. If a response was only displayed in a test interface, its business consequence may be limited. If it was copied into a customer record or used to trigger an action, review that receiving record and action separately. Neither consequence is established by this article, and we have not identified an affected KIURO customer.

Allow for investigation time, isolated test capacity, API consumption and operating ownership in the work estimate. No fixed cost or single package version certifies every architecture. The next useful step is to complete the responsibility matrix for the inference route you actually use and agree who can pause, investigate and resume its business workflow.