TL;DR: cross-tenant AI API response bleed
- Not a private channel: Treating an LLM API response as a private channel between you and the model is the mistake. It is data returning from a massive shared stack of caches, routers, and pools, and on a bad day one tenant's output ends up in another tenant's session.
- Shared-state failure class: The Claude API incident on 2026-06-05 hit Opus 4.5 through 4.8 and Sonnet 4.6 for hours. It matches the 2023 redis-py failure at OpenAI that exposed limited billing data for 1.2% of ChatGPT Plus subscribers, and cside watches the browser layer where AI output, third-party scripts, and authenticated sessions meet.
- Sanitize and validate: If you render model output in the browser, sanitize before it touches the DOM and validate shape on every response. If you handle regulated data, choose zero-retention terms and log request-response metadata so you can tell a model error from a tenant leak.
Short on time? See cside's AI-agent detection. It covers everything below in one deployment.
For a few hours on the afternoon of 2026-06-05, the Claude API appears to have been returning responses that did not belong to the user who asked for them. You send a request, and you get back output that reads like an answer to someone else's prompt.
Anthropic's status page logged the event as "elevated errors on many Claude models," covering Opus 4.5 through 4.8 and Sonnet 4.6. It does not, as of writing, describe a data leak. The cross-user read comes from circulating screenshots and firsthand reports, so treat it as an early interpretation, not a confirmed breach.
The failure class matters more than whether one provider had a bad afternoon. When this kind of thing happens, it almost always traces back to shared mutable state under load, a risk every fast-scaling AI provider is carrying right now.
What appears to have happened
According to Anthropic's status page, the incident ran through the afternoon of 2026-06-05: investigation opened around 15:19 UTC, the issue was identified by 15:43 UTC, and it was marked resolved by 18:28 UTC. The affected models were Claude Opus 4.5, 4.6, 4.7, and 4.8, along with Sonnet 4.6. The official label was "elevated errors," the generic bucket providers use for anything from timeouts to malformed responses.
The reports that drew attention describe something more specific. Users said that some API calls came back with content that had nothing to do with their own prompt, and in at least one widely shared case, one person's task appeared inside a completely unrelated user's response. Several people said they had received what looked like another customer's inference output, and that they checked carefully before concluding it was an upstream error rather than a bug on their end.
Two things are true at once. Anthropic has not confirmed cross-user data exposure, and the public evidence is consistent with it. A responsible reading holds both: this looks like cross-tenant response bleed, and it is not yet officially confirmed as one. I am not reproducing the leaked screenshots here, because they contain another customer's prompt and output, which is exactly the data that should not travel any further.
The failure class: shared mutable state under load
Cross-tenant bleed is when one customer's data surfaces in another customer's session. It is one of the oldest and most dangerous bugs in multi-tenant systems, and it rarely comes from a dramatic breach. It usually comes from a piece of shared, mutable state that was supposed to be keyed per request and, under the wrong conditions, was not.
A modern AI API runs as a stack of shared layers, not a single program answering one request at a time: load balancers, request routers, gateways, queues, in-memory caches, and connection pools, all serving every customer at once to keep latency and cost down. Each of those layers holds state. Each is a place where a request can pick up the wrong response if a cache key collides, a connection is reused after it should have been discarded, or a cancelled request leaves a stale object behind.
The symptom is almost always the same: you ask for your data and you get someone else's. The cause is almost always boring: a small mistake in how a shared object is reused, triggered by load or by an edge case like a cancelled or timed-out request.
We have seen this exact pattern before
The clearest precedent is OpenAI, in March 2023. On 2023-03-20, a change to its servers caused a spike in cancelled Redis requests, which tripped a bug in the redis-py client library. For a window that day, some ChatGPT users could see the chat titles of other active users, and in some cases the first message of a newly created conversation.
The same incident exposed limited billing data. OpenAI notified about 1.2% of ChatGPT Plus subscribers that another user may have seen their first and last name, billing address, credit card type, expiration date, and the last four digits of their card. Full card numbers were never exposed. As Help Net Security reported at the time, and as OpenAI confirmed in its own postmortem, the root cause was a shared caching and connection layer returning data to the wrong client after cancelled requests.
That is the same failure class as the symptom described in the Claude reports: a shared, mutable layer handing one tenant's data to another under load. Different company, different library, same shape.
Why scaling makes this more likely, not less
Here is the uncomfortable structural part. AI providers are adding capacity faster than almost any infrastructure in computing history. Demand outruns hardware, so teams keep bolting on layers to cope: more caching to cut token costs, more routing to spread load across regions and model versions, more proxies and gateways to manage quotas and failover.
Every one of those layers is a performance win and a new place for state to leak. A cache that serves the wrong key, a router that reuses a connection, a proxy that folds one response into another stream: each is a single bug away from cross-tenant bleed. The harder a provider scales, the more of these layers it runs, and the more load it pushes through them.
So this is less an Anthropic story than an everyone story. The providers racing hardest to add capacity are precisely the ones most exposed to this class of bug, because speed and shared infrastructure are how you serve millions of requests cheaply. It is a property of the architecture the whole industry is building on, not a sign that one company is careless.
AI API security in browser-rendered apps
The cross-tenant bleed risk described above lives on the API provider's side, but AI API security does not stop there. When model output lands in the browser, a new set of risks opens up that your AI vendor's SLA does not cover.
Modern applications pipe AI responses directly into the page: streaming answers, AI-generated UI elements, tool call results rendered inline. Each of those patterns creates a surface where a tampered, delayed, or cross-wired response can cause real damage inside a real user's session.
Response injection. If a cross-wired response includes markup and the app renders it without sanitising, that markup executes inside an authenticated session. The provider's incident is already resolved, but the injection risk is structural: any path where raw model output touches the DOM is a target, whether the source is provider-side bleed or prompt injection from content the model processed.
Third-party script interference. Scripts running on the same page as your AI integration can intercept outgoing API calls, read response payloads before your code processes them, or exfiltrate the model's output from the DOM. A compromised analytics snippet or support widget has the same network and DOM access your application does. AI API security cannot be scoped to the API call alone; the page environment it lands in matters.
Data exfiltration through AI context. Applications that give AI agents access to user data, session tokens, or sensitive state create a channel that attackers can abuse by embedding instructions in content the model processes. This is prompt injection at the application layer. The model answers the question in front of it; it is not aware it is being used as a data-exfiltration vector.
Cross-session bleed inside your product. When multiple users share a page context (embedded AI widgets in multi-tenant SaaS, shared session pooling), the API provider's isolation guarantee covers only their infrastructure. If your application mixes session state across users, cross-tenant bleed happens at your layer.
None of these require compromising the AI provider's backend. They exploit the gap between "the API call succeeded" and "the response landed safely in the right user's session."
What this means if you build on LLM APIs
The practical takeaway is a mindset shift. An LLM API response is data coming back from a massively shared, fast-changing system, not a trusted, private channel between you and the model. On a bad day it can be wrong, stale, or cross-wired to another tenant.
Treat it that way:
- Assume a response can occasionally belong to the wrong request. Do not design flows where one cross-wired response silently corrupts a user's record or exposes it to someone else.
- Do not send data to an LLM API that you could not tolerate surfacing elsewhere, unless your contract and the provider's controls genuinely cover it. Zero-retention and enterprise isolation terms matter here.
- Validate and constrain responses before you act on them. Check shape, type, and plausibility, the way you would validate any untrusted input.
- Log enough to detect bleed. If you never store request and response metadata, you cannot tell the difference between a model error and a response that was never yours.
What to do this week
- Map every place an LLM API response enters your system, and mark which ones render directly in the browser.
- Treat those responses as untrusted input: validate structure, escape anything rendered into the page, and never inject raw model HTML without sanitizing it.
- Decide explicitly what data you are willing to send to each provider, and confirm the retention and isolation terms that apply.
- Add logging and alerting that can tell a malformed response apart from one that does not match the request you sent.
- Watch the browser layer, where AI output, third-party scripts, and user data now meet in the same session.
How cside fits
cside does not run inside Anthropic's or any provider's backend, and it cannot fix a cache that hands back the wrong tenant's data. What it addresses is the same class of problem one step closer to your user: the browser, where AI responses, third-party scripts, and authenticated sessions now share the same page.
cside gives runtime visibility into what actually executes in that browser session: which scripts load, how they change after deploy, what data they read, and where they send it. As more applications render model output directly into the page, that visibility is how you catch the client-side consequences of a wrong or cross-wired response, such as content rendered into the wrong session or a script reaching for data it should never touch.
The broader point is the one cside has always made about third-party scripts, now generalized to AI infrastructure. Every layer you add to move faster is a layer where data can surface in the wrong place. You cannot remove those layers, but you can instrument the one closest to your user.
Start with client-side security for runtime script monitoring, or Privacy Watch to see exactly what the code on your pages collects and sends.
Further reading on cside
- How compromised third-party scripts can prompt-inject AI agents
- On-device inference is coming for your security stack
- AI is compressing the exploit cycle
- Best practices for securing third-party scripts
As of 2026-06-05. The Claude API incident details reflect Anthropic's status page and public user reports available at that date. Anthropic has characterized the event as elevated errors and has not, as of writing, confirmed cross-user data exposure.
