En bref : fuite de réponses d'API IA entre locataires
- Pas un canal privé : Traiter la réponse d'une API LLM comme un canal privé entre vous et le modèle est l'erreur. Ce sont des données qui reviennent d'une pile massive partagée de caches, routeurs et pools, et un mauvais jour la sortie d'un locataire finit dans la session d'un autre.
- Panne d'état partagé : L'incident de l'API Claude du 2026-06-05 a touché Opus 4.5 à 4.8 et Sonnet 4.6 pendant des heures. Il correspond à l'échec redis-py de 2023 chez OpenAI qui a exposé des données de facturation limitées pour 1,2 % des abonnés ChatGPT Plus, et cside surveille la couche navigateur où se croisent sortie IA, scripts tiers et sessions authentifiées.
- Assainir et valider : Si vous affichez de la sortie modèle dans le navigateur, assainissez-la avant qu'elle ne touche le DOM et validez la forme sur chaque réponse. Si vous manipulez des données réglementées, choisissez des conditions de rétention zéro et journalisez les métadonnées requête-réponse pour distinguer une erreur modèle d'une fuite entre locataires.
Peu de temps ? Découvrez la détection d'agents IA de cside. Elle couvre tout ce qui suit en un seul déploiement.
Pendant quelques heures dans l'après-midi du 2026-06-05, l'API Claude semble avoir renvoyé des réponses qui n'appartenaient pas à l'utilisateur qui les avait demandées. Vous envoyez une requête et vous récupérez une sortie qui ressemble à la réponse au prompt de quelqu'un d'autre.
La page d'état d'Anthropic a enregistré l'événement comme « erreurs élevées sur de nombreux modèles Claude », touchant Opus 4.5 à 4.8 et Sonnet 4.6. Elle ne décrit pas, à ce jour, une fuite de données. La lecture d'un croisement de données entre utilisateurs provient de captures d'écran qui circulent et de témoignages directs, il faut donc la considérer comme une interprétation précoce, pas comme une violation confirmée.
La classe de défaillance compte plus que le fait de savoir si un fournisseur a eu un mauvais après-midi. Quand ce genre de chose arrive, cela remonte presque toujours à un état mutable partagé sous charge, un risque que porte aujourd'hui tout fournisseur d'IA en pleine montée en charge.
Ce qui semble s'être passé
D'après la page d'état d'Anthropic, l'incident s'est étalé sur l'après-midi du 2026-06-05 : l'investigation a été ouverte vers 15:19 UTC, le problème a été identifié à 15:43 UTC, et il a été marqué comme résolu à 18:28 UTC. Les modèles touchés étaient Claude Opus 4.5, 4.6, 4.7 et 4.8, ainsi que Sonnet 4.6. L'étiquette officielle était « erreurs élevées », la catégorie générique que les fournisseurs utilisent pour tout, des délais d'attente aux réponses mal formées.
Les signalements qui ont attiré l'attention décrivent quelque chose de plus précis. Des utilisateurs ont déclaré que certains appels à l'API renvoyaient un contenu sans aucun rapport avec leur propre prompt et, dans au moins un cas très partagé, la tâche d'une personne est apparue dans la réponse d'un utilisateur totalement étranger. Plusieurs personnes ont dit avoir reçu ce qui ressemblait à la sortie d'inférence d'un autre client, et l'avoir vérifié soigneusement avant de conclure qu'il s'agissait d'une erreur en amont et non d'un bug de leur côté.
Deux choses sont vraies en même temps. Anthropic n'a pas confirmé d'exposition de données entre utilisateurs, et les preuves publiques sont cohérentes avec elle. Une lecture responsable tient les deux : cela ressemble à une fuite de réponses entre clients (cross-tenant), et ce n'est pas encore officiellement confirmé comme tel. Je ne reproduis pas ici les captures divulguées, car elles contiennent le prompt et la sortie d'un autre client, c'est-à-dire exactement les données qui ne devraient pas circuler davantage.
La classe de défaillance : état mutable partagé sous charge
La fuite entre clients survient lorsque les données d'un client apparaissent dans la session d'un autre. C'est l'un des bugs les plus anciens et les plus dangereux des systèmes multi-locataires, et il vient rarement d'une violation spectaculaire. Il vient généralement d'un morceau d'état partagé et mutable qui devait être isolé par requête et qui, dans les mauvaises conditions, ne l'a pas été.
Une API d'IA moderne s'exécute comme une pile de couches partagées, pas un programme unique répondant à une requête à la fois : répartiteurs de charge, routeurs de requêtes, passerelles, files d'attente, caches en mémoire et pools de connexions, tous au service de chaque client en même temps pour maintenir une faible latence et un faible coût. Chacune de ces couches conserve un état. Chacune est un endroit où une requête peut récupérer la mauvaise réponse si une clé de cache entre en collision, si une connexion est réutilisée après avoir dû être abandonnée, ou si une requête annulée laisse derrière elle un objet périmé.
Le symptôme est presque toujours le même : vous demandez vos données et vous recevez celles de quelqu'un d'autre. La cause est presque toujours banale : une petite erreur dans la façon dont un objet partagé est réutilisé, déclenchée par la charge ou par un cas limite comme une requête annulée ou expirée.
Nous avons déjà vu ce schéma exact
Le précédent le plus clair est OpenAI, en mars 2023. Le 2023-03-20, une modification de ses serveurs a provoqué un pic de requêtes Redis annulées, qui a déclenché un bug dans la bibliothèque cliente redis-py. Pendant une fenêtre ce jour-là, certains utilisateurs de ChatGPT pouvaient voir les titres de conversation d'autres utilisateurs actifs et, dans certains cas, le premier message d'une conversation nouvellement créée.
Le même incident a exposé des données de facturation limitées. OpenAI a notifié environ 1,2 % des abonnés ChatGPT Plus qu'un autre utilisateur avait pu voir leurs nom et prénom, adresse de facturation, type de carte, date d'expiration et les quatre derniers chiffres de leur carte. Les numéros de carte complets n'ont jamais été exposés. Comme Help Net Security l'a rapporté à l'époque, et comme OpenAI l'a confirmé dans son propre post-mortem, la cause racine était une couche partagée de cache et de connexions qui renvoyait des données au mauvais client après des requêtes annulées.
C'est la même classe de défaillance que le symptôme décrit dans les signalements concernant Claude : une couche partagée et mutable qui remet les données d'un client à un autre sous charge. Entreprise différente, bibliothèque différente, même schéma.
Pourquoi la montée en charge rend cela plus probable, pas moins
Voici la partie structurelle inconfortable. Les fournisseurs d'IA ajoutent de la capacité plus vite que presque toute infrastructure de l'histoire de l'informatique. La demande dépasse le matériel, alors les équipes continuent d'empiler des couches pour tenir : plus de cache pour réduire le coût des tokens, plus de routage pour répartir la charge entre régions et versions de modèle, plus de proxys et de passerelles pour gérer les quotas et le basculement.
Chacune de ces couches est un gain de performance et un nouvel endroit par lequel l'état peut fuir. Un cache qui sert la mauvaise clé, un routeur qui réutilise une connexion, un proxy qui replie une réponse dans un autre flux : chacun est à un seul bug d'une fuite entre clients. Plus un fournisseur passe à l'échelle agressivement, plus il exploite de ces couches et plus il y pousse de charge.
C'est donc moins une histoire sur Anthropic qu'une histoire sur tout le monde. Les fournisseurs qui courent le plus vite pour ajouter de la capacité sont précisément les plus exposés à cette classe de bug, car la vitesse et l'infrastructure partagée sont la façon de servir des millions de requêtes à bas coût. C'est une propriété de l'architecture sur laquelle toute l'industrie se construit, pas le signe qu'une entreprise est négligente.
Sécurité des API d'IA dans les applications affichées dans le navigateur
Le risque de fuite entre clients décrit ci-dessus réside du côté du fournisseur d'API, mais la sécurité des API d'IA ne s'arrête pas là. Quand la sortie du modèle atterrit dans le navigateur, un nouvel ensemble de risques s'ouvre, que le SLA de votre fournisseur d'IA ne couvre pas.
Les applications modernes canalisent les réponses d'IA directement dans la page : réponses en streaming, éléments d'interface générés par IA, résultats d'appels d'outils affichés en ligne. Chacun de ces patterns crée une surface où une réponse altérée, retardée ou croisée peut causer de réels dommages dans la session réelle d'un utilisateur.
Injection de réponse. Si une réponse croisée inclut du balisage et que l'application l'affiche sans assainissement, ce balisage s'exécute dans une session authentifiée. L'incident du fournisseur est déjà résolu, mais le risque d'injection est structurel : tout chemin où la sortie brute du modèle touche le DOM est une cible, que la source soit une fuite côté fournisseur ou une injection de prompt provenant du contenu traité par le modèle.
Interférence de scripts tiers. Des scripts s'exécutant sur la même page que votre intégration d'IA peuvent intercepter les appels sortants à l'API, lire les payloads de réponse avant que votre code ne les traite, ou exfiltrer la sortie du modèle depuis le DOM. Un extrait d'analytique ou un widget de support compromis dispose du même accès réseau et DOM que votre application. La sécurité des API d'IA ne peut pas se limiter au seul appel API ; l'environnement de la page où il atterrit compte également.
Exfiltration de données via le contexte d'IA. Les applications qui donnent aux agents d'IA accès aux données utilisateur, aux tokens de session ou à un état sensible créent un canal que des attaquants peuvent exploiter en intégrant des instructions dans le contenu que le modèle traite; il s'agit d'une injection de prompt au niveau de la couche applicative. Le modèle répond à la question qui lui est posée ; il n'a pas conscience d'être utilisé comme vecteur d'exfiltration de données.
Fuite entre sessions au sein de votre produit. Lorsque plusieurs utilisateurs partagent un contexte de page (widgets d'IA intégrés dans un SaaS multi-locataires, mise en commun de sessions), la garantie d'isolation du fournisseur d'API ne couvre que son infrastructure. Si votre application mélange l'état de session entre utilisateurs, la fuite entre clients se produit à votre niveau.
Aucun de ces risques ne nécessite de compromettre le backend du fournisseur d'IA. Ils exploitent l'écart entre « l'appel API a réussi » et « la réponse a atterri en sécurité dans la bonne session utilisateur ».
Ce que cela signifie si vous construisez sur des API de LLM
Le point pratique est un changement de mentalité. La réponse d'une API de LLM est une donnée qui revient d'un système massivement partagé et en évolution rapide, pas un canal de confiance et privé entre vous et le modèle. Un mauvais jour, elle peut être erronée, périmée ou croisée avec un autre client.
Traitez-la ainsi :
- Supposez qu'une réponse peut de temps en temps appartenir à la mauvaise requête. Ne concevez pas de flux où une seule réponse croisée corrompt en silence l'enregistrement d'un utilisateur ou l'expose à quelqu'un d'autre.
- N'envoyez pas à une API de LLM des données que vous ne toléreriez pas de voir apparaître ailleurs, sauf si votre contrat et les contrôles du fournisseur les couvrent réellement. Les conditions de rétention zéro et d'isolation pour les entreprises comptent ici.
- Validez et limitez les réponses avant d'agir dessus. Vérifiez la forme, le type et la plausibilité, comme vous valideriez n'importe quelle entrée non fiable.
- Journalisez suffisamment pour détecter les fuites. Si vous ne stockez jamais les métadonnées de requête et de réponse, vous ne pouvez pas distinguer une erreur du modèle d'une réponse qui n'a jamais été la vôtre.
Quoi faire cette semaine
- Cartographiez chaque endroit où une réponse d'API de LLM entre dans votre système, et marquez celles qui s'affichent directement dans le navigateur.
- Traitez ces réponses comme une entrée non fiable : validez la structure, échappez tout ce qui est affiché dans la page et n'injectez jamais de HTML brut du modèle sans l'assainir.
- Décidez explicitement quelles données vous êtes prêt à envoyer à chaque fournisseur, et confirmez les conditions de rétention et d'isolation qui s'appliquent.
- Ajoutez une journalisation et des alertes capables de distinguer une réponse mal formée d'une réponse qui ne correspond pas à la requête envoyée.
- Surveillez la couche du navigateur, où la sortie d'IA, les scripts tiers et les données utilisateur se rencontrent désormais dans la même session.
Comment cside s'intègre
cside ne s'exécute pas dans le backend d'Anthropic ni d'aucun fournisseur, et ne peut pas réparer un cache qui renvoie les données du mauvais client. Ce qu'il traite, c'est la même classe de problème un cran plus près de votre utilisateur : le navigateur, où les réponses d'IA, les scripts tiers et les sessions authentifiées partagent désormais la même page.
cside offre une visibilité en temps réel sur ce qui s'exécute réellement dans cette session de navigateur : quels scripts se chargent, comment ils changent après le déploiement, quelles données ils lisent et où ils les envoient. À mesure que de plus en plus d'applications affichent la sortie du modèle directement dans la page, cette visibilité est la façon de détecter les conséquences côté client d'une réponse erronée ou croisée, comme un contenu affiché dans la mauvaise session ou un script qui cherche des données qu'il ne devrait jamais toucher.
Le point plus large est celui que cside a toujours défendu à propos des scripts tiers, désormais généralisé à l'infrastructure d'IA. Chaque couche que vous ajoutez pour aller plus vite est une couche par laquelle des données peuvent apparaître au mauvais endroit. Vous ne pouvez pas supprimer ces couches, mais vous pouvez instrumenter celle qui est la plus proche de votre utilisateur.
Commencez par la sécurité côté client pour la surveillance des scripts en temps réel, ou par Privacy Watch pour voir exactement ce que le code de vos pages collecte et envoie.
À lire aussi sur cside
- Comment des scripts tiers compromis peuvent injecter des prompts aux agents IA
- L'inférence sur l'appareil arrive dans votre pile de sécurité
- L'IA comprime le cycle des exploits
- Bonnes pratiques pour sécuriser les scripts tiers
À la date du 2026-06-05. Les détails de l'incident de l'API Claude reflètent la page d'état d'Anthropic et les signalements publics d'utilisateurs disponibles à cette date. Anthropic a qualifié l'événement d'erreurs élevées et n'a pas, à ce jour, confirmé d'exposition de données entre utilisateurs.
