Resumen: fuga de respuestas de IA entre clientes (cross-tenant)
- No es un canal privado: Tratar la respuesta de una API de LLM como un canal privado entre tú y el modelo es el error. Son datos que vuelven desde una pila enorme compartida de cachés, routers y pools, y en un mal día la salida de un cliente termina en la sesión de otro.
- Fallo de estado compartido: El incidente de la API de Claude del 2026-06-05 afectó a Opus 4.5 a 4.8 y a Sonnet 4.6 durante horas. Coincide con el fallo de redis-py de 2023 en OpenAI que expuso datos de facturación limitados del 1,2 % de los suscriptores de ChatGPT Plus, y cside vigila la capa del navegador donde se cruzan la salida de IA, los scripts de terceros y las sesiones autenticadas.
- Sanea y valida: Si renderizas la salida del modelo en el navegador, sanéala antes de que toque el DOM y valida la forma en cada respuesta. Si manejas datos regulados, elige condiciones de retención cero y registra metadatos de petición y respuesta para poder distinguir un error de modelo de una fuga entre clientes.
¿Poco tiempo? Consulta la detección de agentes IA de cside. Cubre todo lo de abajo en un solo despliegue.
Durante unas horas de la tarde del 2026-06-05, la API de Claude parece haber estado devolviendo respuestas que no pertenecían al usuario que las había solicitado. Envías una petición y recibes una salida que parece responder al prompt de otra persona.
La página de estado de Anthropic registró el evento como «errores elevados en muchos modelos de Claude», que afectaban a Opus 4.5 a 4.8 y a Sonnet 4.6. No describe, a fecha de hoy, una filtración de datos. La lectura de que hubo datos cruzados entre usuarios procede de capturas de pantalla que circulan y de informes de primera mano, así que conviene tratarla como una interpretación temprana, no como una brecha confirmada.
La clase de fallo importa más que si un proveedor tuvo una mala tarde. Cuando ocurre algo así, casi siempre se debe a un estado mutable compartido bajo carga, un riesgo que hoy mismo arrastra cualquier proveedor de IA que escale rápido.
Qué parece haber ocurrido
Según la página de estado de Anthropic, la incidencia se extendió a lo largo de la tarde del 2026-06-05: la investigación se abrió alrededor de las 15:19 UTC, el problema se identificó hacia las 15:43 UTC y se marcó como resuelto sobre las 18:28 UTC. Los modelos afectados fueron Claude Opus 4.5, 4.6, 4.7 y 4.8, además de Sonnet 4.6. La etiqueta oficial fue «errores elevados», el cajón genérico que usan los proveedores para todo, desde tiempos de espera hasta respuestas mal formadas.
Los informes que llamaron la atención describen algo más concreto. Algunos usuarios dijeron que ciertas llamadas a la API devolvían contenido que no tenía nada que ver con su propio prompt y, en al menos un caso muy compartido, la tarea de una persona apareció dentro de la respuesta de un usuario completamente ajeno. Varias personas dijeron haber recibido lo que parecía la salida de inferencia de otro cliente, y que lo comprobaron con cuidado antes de concluir que era un error en el servidor y no un fallo de su lado.
Dos cosas son ciertas a la vez. Anthropic no ha confirmado una exposición de datos entre usuarios, y la evidencia pública es coherente con ella. Una lectura responsable sostiene ambas: esto parece una filtración de respuestas entre clientes (cross-tenant), y todavía no está confirmada oficialmente como tal. No reproduzco aquí las capturas filtradas, porque contienen el prompt y la salida de otro cliente, que son justo los datos que no deberían circular más.
La clase de fallo: estado mutable compartido bajo carga
La filtración entre clientes ocurre cuando los datos de un cliente afloran en la sesión de otro. Es uno de los errores más antiguos y peligrosos de los sistemas multiinquilino, y rara vez procede de una brecha espectacular. Suele venir de una pieza de estado compartido y mutable que debía aislarse por petición y que, en las condiciones equivocadas, no lo hizo.
Una API de IA moderna funciona como una pila de capas compartidas, no como un único programa que responde a una petición cada vez: balanceadores de carga, enrutadores de peticiones, gateways, colas, cachés en memoria y pools de conexiones, todos sirviendo a la vez a cada cliente para mantener baja la latencia y el coste. Cada una de esas capas guarda estado. Cada una es un lugar donde una petición puede recoger la respuesta equivocada si una clave de caché colisiona, una conexión se reutiliza después de que debería haberse descartado o una petición cancelada deja atrás un objeto obsoleto.
El síntoma es casi siempre el mismo: pides tus datos y recibes los de otra persona. La causa es casi siempre anodina: un pequeño error en cómo se reutiliza un objeto compartido, disparado por la carga o por un caso límite como una petición cancelada o con el tiempo de espera agotado.
Ya hemos visto este mismo patrón
El precedente más claro es OpenAI, en marzo de 2023. El 2023-03-20, un cambio en sus servidores provocó un pico de peticiones canceladas a Redis, que activó un fallo en la biblioteca cliente redis-py. Durante una ventana de ese día, algunos usuarios de ChatGPT pudieron ver los títulos de las conversaciones de otros usuarios activos y, en algunos casos, el primer mensaje de una conversación recién creada.
La misma incidencia expuso datos de facturación limitados. OpenAI notificó a alrededor del 1,2 % de los suscriptores de ChatGPT Plus que otro usuario podía haber visto su nombre y apellidos, dirección de facturación, tipo de tarjeta, fecha de caducidad y los últimos cuatro dígitos de la tarjeta. Los números completos de tarjeta nunca quedaron expuestos. Como informó Help Net Security en su momento, y como confirmó OpenAI en su propio análisis, la causa raíz fue una capa compartida de caché y conexiones que devolvía datos al cliente equivocado tras peticiones canceladas.
Esa es la misma clase de fallo que el síntoma descrito en los informes sobre Claude: una capa compartida y mutable que entrega los datos de un cliente a otro bajo carga. Distinta empresa, distinta biblioteca, misma forma.
Por qué escalar lo hace más probable, no menos
Aquí está la parte estructural incómoda. Los proveedores de IA están añadiendo capacidad más rápido que casi cualquier infraestructura en la historia de la informática. La demanda supera al hardware, así que los equipos siguen añadiendo capas para aguantar: más caché para recortar el coste de tokens, más enrutamiento para repartir la carga entre regiones y versiones de modelo, más proxies y gateways para gestionar cuotas y conmutación por error.
Cada una de esas capas es una mejora de rendimiento y un nuevo lugar por el que el estado puede filtrarse. Una caché que sirve la clave equivocada, un enrutador que reutiliza una conexión, un proxy que mezcla una respuesta en otro flujo: cada uno está a un solo fallo de provocar una filtración entre clientes. Cuanto más fuerte escala un proveedor, más de estas capas opera y más carga empuja a través de ellas.
Así que esto es menos una historia sobre Anthropic que una historia sobre todos. Los proveedores que más corren por añadir capacidad son justo los más expuestos a esta clase de fallo, porque la velocidad y la infraestructura compartida son la forma de servir millones de peticiones de forma barata. Es una propiedad de la arquitectura sobre la que construye toda la industria, no una señal de que una empresa sea descuidada.
Seguridad de la API de IA en aplicaciones renderizadas en el navegador
El riesgo de fuga entre clientes descrito antes reside en el lado del proveedor de la API, pero la seguridad de la API de IA no termina ahí. Cuando la salida del modelo aterriza en el navegador, se abre un nuevo conjunto de riesgos que el SLA de tu proveedor de IA no cubre.
Las aplicaciones modernas canalizan las respuestas de IA directamente hacia la página: respuestas en streaming, elementos de interfaz generados por IA, resultados de llamadas a herramientas renderizados en línea. Cada uno de esos patrones crea una superficie donde una respuesta manipulada, retrasada o cruzada puede causar daño real dentro de la sesión real de un usuario.
Inyección de respuesta. Si una respuesta cruzada incluye marcado y la aplicación lo renderiza sin saneamiento, ese marcado se ejecuta dentro de una sesión autenticada. El incidente del proveedor ya está resuelto, pero el riesgo de inyección es estructural: cualquier ruta por la que la salida en bruto del modelo toque el DOM es un objetivo, ya sea que la fuente sea una fuga del lado del proveedor o una inyección de prompt desde el contenido que el modelo procesó.
Interferencia de scripts de terceros. Los scripts que se ejecutan en la misma página que tu integración de IA pueden interceptar las llamadas salientes a la API, leer los payloads de respuesta antes de que tu código los procese o exfiltrar la salida del modelo desde el DOM. Un fragmento de analítica o un widget de soporte comprometido tienen el mismo acceso de red y DOM que tu aplicación. La seguridad de la API de IA no puede limitarse solo a la llamada a la API; el entorno de la página donde aterriza también importa.
Exfiltración de datos a través del contexto de IA. Las aplicaciones que dan a los agentes de IA acceso a datos del usuario, tokens de sesión o estado sensible crean un canal que los atacantes pueden abusar incrustando instrucciones en el contenido que el modelo procesa: inyección de prompt en la capa de aplicación. El modelo responde a la pregunta que tiene delante; no es consciente de que se está usando como vector de exfiltración de datos.
Fuga entre sesiones dentro de tu producto. Cuando varios usuarios comparten un contexto de página, como widgets de IA integrados en SaaS multiinquilino o pools de sesión compartidos, la garantía de aislamiento del proveedor de API cubre solo su infraestructura. Si tu aplicación mezcla el estado de sesión entre usuarios, la fuga entre clientes ocurre en tu capa.
Ninguno de estos riesgos requiere comprometer el backend del proveedor de IA. Explotan la brecha entre «la llamada a la API tuvo éxito» y «la respuesta aterrizó de forma segura en la sesión del usuario correcto».
Qué significa esto si construyes sobre APIs de LLM
La conclusión práctica es un cambio de mentalidad. La respuesta de una API de LLM son datos que vuelven de un sistema enormemente compartido y en constante cambio, no un canal privado y de confianza entre tú y el modelo. En un mal día pueden ser erróneos, obsoletos o estar cruzados con otro cliente.
Trátalos así:
- Asume que una respuesta puede pertenecer de vez en cuando a la petición equivocada. No diseñes flujos en los que una sola respuesta cruzada corrompa en silencio el registro de un usuario o lo exponga a otra persona.
- No envíes a una API de LLM datos que no tolerarías ver aflorar en otro sitio, salvo que tu contrato y los controles del proveedor realmente lo cubran. Aquí importan las condiciones de retención cero y de aislamiento empresarial.
- Valida y limita las respuestas antes de actuar sobre ellas. Comprueba la forma, el tipo y la plausibilidad, igual que validarías cualquier entrada no confiable.
- Registra lo suficiente para detectar filtraciones. Si nunca guardas metadatos de petición y respuesta, no puedes distinguir entre un error del modelo y una respuesta que nunca fue tuya.
Qué hacer esta semana
- Mapea cada lugar por el que una respuesta de una API de LLM entra en tu sistema y marca cuáles se renderizan directamente en el navegador.
- Trata esas respuestas como entrada no confiable: valida la estructura, escapa anything renderizado en la página y nunca inyectes HTML del modelo en bruto sin sanearlo.
- Decide de forma explícita qué datos estás dispuesto a enviar a cada proveedor y confirma las condiciones de retención y aislamiento que se aplican.
- Añade registro y alertas que distingan una respuesta mal formada de una que no coincide con la petición que enviaste.
- Vigila la capa del navegador, donde la salida de IA, los scripts de terceros y los datos del usuario coinciden ahora en la misma sesión.
Cómo encaja cside
cside no se ejecuta dentro del backend de Anthropic ni del de ningún proveedor, y no puede arreglar una caché que devuelve los datos del cliente equivocado. Lo que aborda es la misma clase de problema un paso más cerca de tu usuario: el navegador, donde las respuestas de IA, los scripts de terceros y las sesiones autenticadas comparten ahora la misma página.
cside ofrece visibilidad en tiempo de ejecución de lo que realmente se ejecuta en esa sesión del navegador: qué scripts se cargan, cómo cambian tras el despliegue, qué datos leen y a dónde los envían. A medida que más aplicaciones renderizan la salida del modelo directamente en la página, esa visibilidad es la forma de detectar las consecuencias en el lado del cliente de una respuesta errónea o cruzada, como contenido renderizado en la sesión equivocada o un script que busca datos que nunca debería tocar.
El punto más amplio es el que cside siempre ha defendido sobre los scripts de terceros, ahora generalizado a la infraestructura de IA. Cada capa que añades para ir más rápido es una capa por la que los datos pueden aflorar en el lugar equivocado. No puedes eliminar esas capas, pero sí instrumentar la más cercana a tu usuario.
Empieza con seguridad del lado del cliente para la monitorización de scripts en tiempo de ejecución, o con Privacy Watch para ver exactamente qué recopila y envía el código de tus páginas.
Lecturas recomendadas en cside
- Cómo los scripts de terceros comprometidos pueden inyectar prompts a los agentes de IA
- La inferencia en el dispositivo llega a tu stack de seguridad
- La IA está comprimiendo el ciclo de los exploits
- Buenas prácticas para asegurar los scripts de terceros
A fecha de 2026-06-05. Los detalles de la incidencia de la API de Claude reflejan la página de estado de Anthropic y los informes públicos de usuarios disponibles en esa fecha. Anthropic ha caracterizado el evento como errores elevados y no ha confirmado, a fecha de hoy, una exposición de datos entre usuarios.
