The Cloudflare GLM-5.3 Data Leak: How to Protect Customer Data When You Use AI APIs

On October 26, Cloudflare published a post-mortem on the Cloudflare GLM-5.3 data leak: for almost two weeks, its hosted GLM-5.3 model sometimes answered one customer's request with fragments of another customer's prompt. Only 155 responses were affected, and Cloudflare found no sign of deliberate exploitation. But it is a clear reminder that when your product sends customer data to an AI API, some of the risk sits on hardware you will never see. This guide explains what happened in plain terms, and the six controls we use so a provider bug does not become your breach.

What happened

Cloudflare's post-mortem is unusually open about the details:

• •What leaked: between August 27 and September 9, 2026, 155 responses from the glm-5.3 model on Workers AI contained data from other customers' requests made to the same model shortly before. That stale data could include other users' prompts and partial generations.
• •When it triggered: every affected response came from a prompt longer than 681,280 tokens.
• •Who found it: security researcher Gadi Evron of Knostic reported it through Cloudflare's HackerOne program on September 8.
• •How fast it was fixed: Cloudflare declared an incident the next day, took the model offline within 40 minutes, and restored it with a fix the same evening.

Cloudflare says no other Workers AI model was affected. The post does not say whether affected customers were notified.

Why it happened, in plain terms

Large language models keep a working memory of the prompt they are processing, called the KV cache. GLM-5.3 was deployed to accept prompts of up to 1,048,576 tokens, but the cache pool on the machines that read the prompt only had room for 681,280. Cloudflare's own summary is direct: nothing forced the two numbers to agree, and it was their job to check.

That mismatch alone should have produced an error. A second bug, in the open-source SGLang inference engine, turned it into a leak. Over-length requests were marked as rejected but not stopped, so the model carried on generating from cache memory that still held earlier requests. The customer got a normal-looking success response built partly from someone else's data.

Cloudflare also admits that its pre-launch testing checked status codes and speed at long context lengths, but not whether the answers made sense. It has since resized the pool to about twice the context length, patched the engine with the SGLang maintainers, and added checks that compare pool size and context length on every deployment.

What it means for teams building AI features

Three lessons apply well beyond Cloudflare:

1. 1.Tenant isolation at AI providers is software, not physics. Requests from many customers share the same GPUs and caches. Isolation depends on code being right, and new inference engines are young code.
2. 2.Edge cases hide in the extremes. This only hit prompts over 681,280 tokens. Products that stuff whole databases or document archives into one giant prompt live in exactly that territory.
3. 3.You may not hear about it quickly. The fix landed on September 9. The public explanation came on October 26.

None of this means you should stop using hosted models. It means designing your AI features so that a provider bug exposes as little as possible.

Six controls that protect customer data

1. Minimize what you send. Send the fields a task needs, not the whole record. A support-reply feature needs the ticket thread, not the customer's billing address. Smaller prompts are also cheaper, which our guide to reducing LLM API costs covers in detail, and they keep you far away from the extreme context lengths where this bug lived.

2. Redact before the call. Strip identifiers and secrets on your servers, before a prompt leaves them. Simple patterns catch a lot:

// Strip obvious identifiers before a prompt leaves your servers.
const PATTERNS: [RegExp, string][] = [
  [/[\w.+-]+@[\w-]+\.[\w.]+/g, "[email]"],
  [/\+?\d[\d\s().-]{8,}\d/g, "[phone]"],
  [/\b(?:sk|pk|rk)_(?:live|test)_[A-Za-z0-9]{10,}\b/g, "[api-key]"],
];

export function redact(text: string): string {
  return PATTERNS.reduce((out, [re, label]) => out.replace(re, label), text);
}

Pattern matching will not catch everything, so treat it as a safety net on top of minimizing, not a replacement for it. Secrets in particular should never reach a prompt. If one does, our guide on how to rotate secrets after a breach gives the order to replace them in.

3. Isolate by customer in your own code. The most common cross-customer AI leak is not a provider bug. It is a retrieval step that searches every customer's documents instead of one. Filter every vector search and database query by tenant ID on the server, and never let the model choose whose data to fetch.

4. Put the contract in writing. Before production, confirm in your agreement with each AI provider how long prompts and outputs are kept, whether they are used for training, and which subprocessors handle them. Keep a simple register: which feature sends which data to which provider. You will need it the day a post-mortem like this one lands.

5. Detect data that does not belong. Plant unique canary strings in test accounts and alert if one ever appears in another account's output. In production, flag responses that contain names, emails, or IDs that were not in the prompt. Cloudflare's miss was not checking output, and you can check yours.

6. Plan your response. Under the GDPR and UK GDPR, a personal data breach must generally be reported to the regulator within 72 hours of you becoming aware of it, unless it is unlikely to put people at risk. US state laws and customer contracts add their own notice rules. Decide in advance who reads provider security notices, who decides whether you are affected, and who tells customers.

Questions to ask your AI provider

Before you send customer data to a hosted model, get written answers to these:

• •How long do you keep prompts and outputs, and can we turn retention off?
• •Is our data ever used to train or evaluate models?
• •How are requests from different customers isolated on shared hardware?
• •How, and how fast, will you notify us of a security incident that affects our data?
• •Which subprocessors and regions handle our requests?

Vague answers are an answer too. For sensitive data, prefer providers with clear retention controls and a track record of public post-mortems.

How we build AI features that handle customer data

We put every model call behind one small service inside the client's app, the same layer we describe in our guide to adding AI features to an existing web app. That one place is where minimizing, redaction, tenant filtering, logging, and provider choice happen, so a change of provider or a new rule is a single edit rather than a hunt through the codebase.

Our AI agent development service builds agents and AI features this way from the first sprint, with human review wherever the AI's output reaches a customer.

The bottom line

The Cloudflare GLM-5.3 data leak was small, quickly fixed, and openly explained. It still shows that sending customer data to an AI API means trusting code you cannot inspect. You cannot fix your provider's inference engine, but you can decide what reaches it: minimize, redact, isolate by customer, get the terms in writing, watch the output, and know what you will do when the next post-mortem lands.

Want a review of how your product sends data to AI providers? Tell us about it and we will send a fixed-scope proposal.