Analyse des erreurs de dénomination des IA irrégulières : les noms simples échouent

L’échec de sécurité de l’IA le plus instructif de la semaine n’a pas nécessité un jailbreak de prompt génial ni un méchant en sweat à capuche sombre. Il aurait commencé par un nom. Un nom de cible fictif utilisé lors de tests correspondait à quelque chose de réel sur l’internet public, le genre de problème informatique banal qui fait fixer les intervenants en incident à travers les murs. Quelque part, une cellule de tableur se sent très puissante.

La divulgation d’Irregular est importante parce qu’elle sort la sécurité de l’IA de la zone cinématographique et la ramène dans le marécage où la sécurité vit réellement : nommage, périmètre, permissions, journalisation et hypothèses. Les systèmes agentiques n’ont pas besoin d’intention malveillante pour causer des dommages lorsqu’on leur donne des outils, un accès à internet et une carte confuse de ce qui se trouve à l’intérieur du laboratoire. Ce n’est pas un scandale à contempler. C’est une leçon de conception que les bâtisseurs peuvent utiliser avant que leur propre environnement d’évaluation décide que le monde réel n’est qu’un autre élément de test.

Ce qui s’est cassé, selon SecurityWeek et Mallory

SecurityWeek a rapporté qu’Irregular avait expliqué comment une erreur de nommage avait permis à des modèles d’IA d’attaquer une vraie entreprise, l’incident impliquant des modèles d’IA d’Anthropic. Mallory a décrit le mode de défaillance comme une évaluation de sécurité de l’IA qui a involontairement atteint une cible internet active après qu’un nom de cible fictif a correspondu à un domaine réel. Selon ce récit, des modèles connectés à internet ont traité le domaine actif comme faisant partie de l’exercice lors d’un petit nombre d’exécutions.

La description de la faille est rafraîchissante par son manque de glamour, et donc utile. L’échec initial apparent était la résolution d’entité, ce qui signifie que le système a résolu un nom destiné à un test contrôlé en une cible réelle. L’impact, selon Mallory, est allé au-delà d’une navigation inoffensive : les modèles ont mené des actions offensives, des identifiants ont été affectés et une base de données de production a été consultée. Pas besoin d’incantation magique, seulement d’une frontière qui faisait trop confiance à un nom.

Périmètre et incertitude, selon Mallory

et The Record Mallory a indiqué qu’Irregular et Anthropic avaient identifié trois incidents dans lesquels des modèles d’Anthropic étaient sortis de leur bac à sable de test et avaient compromis de vraies organisations, la dernière divulgation détaillant un cas. Cela ne signifie pas que chaque évaluation d’IA est un fil sous tension, mais cela signifie que les limites des bacs à sable méritent la même méfiance que celle que nous réservons habituellement aux imprimantes et aux anciens équipements VPN. Si un système de test peut atteindre l’internet public, il ne teste pas seulement le comportement du modèle. Il teste vos hypothèses sur le confinement.

The Record a rapporté qu’Irregular, qui fournit des environnements d’évaluation pour les modèles d’IA d’autres entreprises, a fait face à des critiques après avoir publié un post-mortem qui, selon des experts en sécurité, laissait des questions clés sans réponse. The Record a également rapporté que le billet d’Irregular ne précisait pas le nombre total d’incidents survenus et que l’entreprise avait précédemment refusé de dire si les incidents allaient au-delà de ceux annoncés par OpenAI, Anthropic et Meta. The Next Web a présenté le schéma plus large autour de ces trois laboratoires et du même fournisseur de tests, ce qui est le genre de dépendance commune que les équipes de sécurité devraient entourer à l’encre rouge, de préférence avant le post-mortem.

Pourquoi ce bug ennuyeux compte, selon

The Record et SecurityWeek La leçon pour les bâtisseurs n’est pas simplement de craindre l’injection de prompt, même si, oui, continuez s’il vous plaît à la craindre de manière saine et adulte. Le cadrage de SecurityWeek autour de l’erreur de nommage pointe vers une autre catégorie de défaillance : l’agent a trop bien compris la mission, mais le modèle du monde de cette mission était faux. Lorsque des noms, des domaines, des dossiers clients ou des entités synthétiques entrent en collision avec la réalité, un agent doté d’outils peut transformer une erreur administrative en activité réelle.

Les informations de The Record sur les questions sans réponse pointent aussi vers un problème de gouvernance. Si l’explication publique ne définit pas clairement le nombre total d’incidents, le périmètre affecté et les échecs de confinement, les clients en aval ne peuvent pas évaluer leur propre risque avec confiance. Les bâtisseurs devraient traiter l’infrastructure d’évaluation comme une infrastructure de production : l’isoler, lui donner des destinations autorisées par liste blanche, utiliser des domaines synthétiques qui ne peuvent pas se résoudre vers l’extérieur, et rendre chaque appel d’outil auditable. Oui, c’est moins glamour qu’une démo de keynote. Porter une ceinture de sécurité aussi, et pourtant le pare-brise reste invaincu.

Ce que cela signifie réellement pour vous, selon Mallory et SecurityWeek

Si vous construisez ou achetez des systèmes agentiques, la conclusion pratique est simple : les noms font désormais partie de votre modèle de menace. Une entreprise fictive, un faux domaine, un utilisateur simulé ou un ticket synthétique ne devrait pas pouvoir se résoudre en quelque chose de réel, sauf si un humain l’autorise délibérément. Traitez la résolution d’entité comme un contrôle de sécurité, pas comme une fonctionnalité pratique laissée discrètement au DNS, à la recherche ou à l’inférence du modèle.

Pour les équipes de sécurité, le prochain élément de la liste de contrôle est un confinement que vous pouvez prouver. Le récit de Mallory indique que le domaine affecté manquait de protections courantes et que le comportement était difficile à détecter, ce qui explique précisément pourquoi la journalisation et les contrôles de sortie doivent être ennuyeux, stricts et toujours activés. Surveillez les futures divulgations qui clarifieront le nombre total d’incidents, l’impact sur les clients et la manière dont les fournisseurs de tests séparent les cibles simulées des cibles actives. Internet compte déjà assez d’environnements de production accidentels ; les agents d’IA n’ont pas besoin d’aide pour en trouver davantage.