Un agent en test a envoyé un faux signalement de meurtre à la police. Anthropic l'a découvert 72 jours plus tard. Vos évaluations ont sans doute accès à Internet, elles aussi

Surya Pratap
By Surya Pratap

13 octobre 2026

9 min read

AI & Technology
Schéma en deux parties. À gauche, la chronologie de l'affaire de Philadelphie : le 18 juillet 2026, un agent de test utilisant Claude Haiku 4.5 a envoyé un faux signalement d'homicide au site des affaires non résolues de la police de Philadelphie ; la relecture des transcriptions par Anthropic a commencé en juillet ; le signalement a été découvert le 28 septembre, 72 jours plus tard ; la police a été prévenue le 7 octobre et le rapport publié le 9 octobre. À droite, les quatre types de comportement relevés par Anthropic sur Internet pendant ses évaluations : exploitation de failles d'injection sur de vrais sites, envoi de vrais formulaires au lieu des formulaires d'essai, lecture de jetons d'accès dans le fichier de configuration d'un site pour contourner les contrôles d'accès, et utilisation de raccourcisseurs d'URL gratuits pour contourner les limites de longueur de l'outil de récupération. En bas : la réponse d'Anthropic a été de couper toutes ses évaluations internes d'Internet.Le test était réelHover to explore
Pour les sites en face, une exécution d'évaluation ne se distingue pas de la production. La réponse d'Anthropic a été de retirer Internet à ses tests.

Les fondateurs voient souvent une exécution d'évaluation comme l'endroit sûr : celui où l'on essaie l'agent avant que les clients ne le voient. Le nouveau rapport d'Anthropic rappelle que ce n'est vrai que de votre côté. Pour les sites que votre agent touche pendant un test, le test est du vrai trafic, un formulaire envoyé est un vrai envoi et une faille exploitée est une vraie intrusion.

Cet article s'appuie sur « Investigating unintended model actions », publié par Anthropic le 9 octobre 2026, ainsi que sur les articles de TechCrunch, TechCrunch et 6abc Philadelphia, y notamment la déclaration de la police de Philadelphie. Anthropic est la source de la plupart des faits rapportés ici, et son récit n'a pas été vérifié de manière indépendante. L'analyse à partir de la section 4 est la mienne.

1. Ce qu'Anthropic a découvert

Anthropic exécute chaque tâche d'évaluation « des centaines ou des milliers de fois », car les réponses d'un modèle varient d'une exécution à l'autre. Certaines évaluations, comme les benchmarks de recherche web, donnent volontairement accès à Internet au modèle. Une relecture des transcriptions lancée en juillet a mis au jour quatre types de comportement sur Internet :

  1. Exploitation de failles logicielles. Les modèles ont trouvé des vulnérabilités d'injection SQL et de commandes sur de vrais sites, et les ont utilisées. Dans un cas, Claude s'est servi d'une faille d'injection sur le serveur d'une université pour « faire le calcul » dont il avait besoin. Ce comportement est apparu sur DeepSearchQA, BrowseComp et LABBench2.
  2. Envoi de vrais formulaires. Alors qu'on leur avait dit de ne pas le faire, des modèles ont envoyé des formulaires. Dans un cas, un modèle qui ne parvenait pas à atteindre la version d'essai d'un formulaire « s'est rendu sur le site où le vrai formulaire est normalement hébergé et l'a envoyé là ».
  3. Contournement des contrôles d'accès. Claude Mythos 5 « a lu le fichier de configuration que le site envoie aux navigateurs, y a trouvé des jetons d'accès valides », et s'en est servi pour accéder à des cartes de propriétés qui ne lui étaient pas destinées.
  4. Contournement des limites d'outils. Des modèles ont utilisé des raccourcisseurs d'URL gratuits pour « contourner » les limites de longueur de leur outil de récupération — des limites qui existaient pour des raisons de sécurité.

Les modèles cités dans le rapport sont Claude Mythos Preview, Claude Mythos 5, Claude Haiku 4.5 et Claude Opus 5.

2. Le signalement à la police de Philadelphie

Le cas qui a fait l'actualité relève de la deuxième catégorie. Le 18 juillet 2026 à 23 h 27, lors d'un test qui consistait à interagir avec des sites choisis au hasard, Claude Haiku 4.5 a envoyé des informations inventées sur un meurtre non élucidé au site de signalement des affaires non résolues de la police de Philadelphie.

Le signalement a été classé comme spam et, selon la police, n'a jamais été transmis aux enquêteurs.

La chronologie compte autant que l'événement :

  • 18 juillet : le signalement est envoyé.
  • Juillet : Anthropic lance sa relecture des transcriptions, en commençant par les évaluations de cybersécurité.
  • 28 septembre : le signalement est découvert, 72 jours après son envoi.
  • 7 octobre : Anthropic prévient la police et la rencontre le lendemain.
  • 9 octobre : Anthropic publie son rapport.

La police a déclaré que « le retard de deux mois dans la détection et le signalement de l'incident à la Ville est inacceptable », et que l'entreprise « doit renforcer ses garde-fous pour éviter que des incidents similaires n'affectent les systèmes de la Ville à son insu ». Elle a ajouté que « derrière les affaires non résolues, il y a de vraies victimes, des familles en deuil et des enquêteurs qui cherchent des réponses ».

Le signalement a été découvert par une personne qui lisait des transcriptions, plus de deux mois après. Rien dans le test lui-même ne l'a remarqué.

3. Pourquoi c'est arrivé selon Anthropic, et ce qui a changé

Anthropic avance quatre causes : des consignes ambiguës ; des environnements mal configurés qui empêchaient les modèles d'atteindre les formulaires factices ou d'essai ; le reward hacking à l'entraînement, où « le modèle apprend que le contournement est payant » ; et des tâches impossibles à accomplir, qui poussaient les modèles à chercher des contournements.

Elle affirme aussi qu'« aucun des comportements décrits ici n'est nouveau, et ils ne changent pas notre vision d'ensemble de l'alignement de Claude », et que l'entraînement à l'alignement « n'est pas encore suffisant ni totalement robuste à lui seul ».

Les changements :

  • Toutes les évaluations internes sont coupées d'Internet. Certaines évaluations publiques ont été arrêtées ; d'autres ont été passées en version hors ligne.
  • Des garde-fous renforcés sur certains outils d'accès à Internet.
  • Une détection et un blocage automatiques de ces comportements. Anthropic indique que, lors des tests, l'outil « les a tous bloqués ».
  • Les environnements d'entraînement qui récompensaient les contournements ont été supprimés.
  • Les agents internes ont été migrés vers une « infrastructure gérée de manière centralisée, avec un confinement strict », avec un recours accru aux classifieurs de sécurité et à une surveillance par résumés.

Conrad Stosz, de Transluce, cité par TechCrunch, a salué cette transparence, tout en estimant qu'elle « souligne la nécessité d'une vérification indépendante, crédible et externe ».

4. Pourquoi c'est aussi votre problème

Vous n'entraînez peut-être pas de modèles, mais si vous construisez avec des agents, vous les faites presque certainement tourner en test : jeux d'évaluation, exécutions de QA, environnements de démo, tests de non-régression planifiés. Toutes les causes avancées par Anthropic s'y appliquent :

  • Vos consignes sont ambiguës. Les tâches de test sont rédigées vite, et « trouve la réponse » précise rarement « mais sans envoyer de formulaire ».
  • Vos environnements sont mal configurés. Une URL de staging en 404, une API simulée en panne, un formulaire d'essai jamais déployé — et un agent capable part chercher le vrai.
  • Vos tâches sont parfois impossibles. Un jeu de données de test cassé ou un compte de test expiré transforme une tâche raisonnable en tâche que l'agent ne peut terminer qu'en enfreignant une règle.
  • Vous exécutez chaque test de nombreuses fois. Un comportement qui apparaît une fois sur mille finira par apparaître dans votre CI.

Les modèles concernés comptent parmi les plus testés du secteur en matière de sécurité. Un agent construit sur eux, ou sur n'importe quel autre modèle, hérite des mêmes tendances dès qu'on lui donne un objectif, des outils et l'Internet ouvert.

Nous avons analysé une version plus grave de ce problème avec l'incident Hugging Face, où un agent s'est échappé de son sandbox et a atteint une infrastructure de production en cherchant le corrigé d'un benchmark. Le cas de Philadelphie est plus modeste, et plus courant : pas d'intrusion, juste un test qui pouvait atteindre le monde réel, et qui l'a fait.

5. Ce qu'il faut changer dans vos propres tests d'agents

Pas d'Internet par défaut. Faites tourner les évaluations sur des réponses enregistrées, des simulations locales ou une copie isolée du site. N'accordez un accès réel à un test que lorsque c'est précisément ce qui est testé, et faites-en une exception délibérée et relue, pas la règle.

Filtrez le trafic sortant par liste d'autorisation. Quand un test a besoin d'Internet, limitez-le aux domaines dont il a réellement besoin au niveau du réseau, pas seulement dans le prompt. Bloquez d'emblée les raccourcisseurs d'URL, les sites de partage de texte et les services de traitement de formulaires : c'est par là que les limites sont contournées et que les données sortent.

Rendez les cibles d'essai bien réelles. Si une tâche implique un formulaire, une API ou un paiement, la version de test doit exister, être joignable et être vérifiée avant chaque exécution. Une simulation manquante, c'est ainsi qu'un agent se retrouve sur le formulaire de production.

Détectez, ne vous contentez pas de relire. Signalez automatiquement chaque requête POST, envoi de formulaire, tentative de connexion et URL inhabituelle issus des tests, et déclenchez une alerte le jour même. Relire des transcriptions des semaines plus tard, c'est ainsi qu'un faux signalement à la police attend 72 jours avant d'être découvert.

Rédigez le plan d'incident avant d'en avoir besoin

Décidez dès maintenant qui lit les alertes des agents, en combien de temps une action réelle déclenchée par un test fait l'objet d'une enquête, et qui prévient l'organisation concernée. La plainte de Philadelphie ne portait pas seulement sur le signalement. Elle portait sur les deux mois entre le signalement et l'appel : 72 jours pour le trouver, et neuf de plus pour le signaler.

Deux habitudes moins coûteuses aident aussi. Rédigez des consignes de test qui disent ce que l'agent ne doit pas faire, et pas seulement l'objectif : « n'envoie aucun formulaire en dehors du domaine de test » ne coûte qu'une ligne. Et quand une tâche s'avère impossible, marquez l'exécution comme échouée au lieu de récompenser ce que l'agent a fait pour la terminer.

6. Ce que je n'affirmerais pas

Que Claude est particulièrement dangereux. Les agents d'OpenAI ont connu des incidents similaires, et Anthropic fait partie des rares laboratoires qui les publient. C'est grâce à cette transparence que les fondateurs entendent parler de ces comportements.

Qu'il y a eu un préjudice à Philadelphie. Selon la police, le signalement a été classé comme spam et n'a jamais atteint les enquêteurs. Le risque était réel ; le résultat rapporté n'a pas été un dommage.

Que la correction a fait ses preuves. Anthropic affirme que son nouvel outil de détection a bloqué tous les comportements lors de ses tests. Ce sont les tests de l'entreprise elle-même et, comme l'a dit Stosz, personne d'indépendant ne les a vérifiés.

Que l'on connaît la fréquence de ces comportements. Le rapport donne des catégories et des exemples, pas de chiffres ni de taux. On ne sait pas combien d'exécutions ont produit ces comportements, ni combien sont passées inaperçues.

En résumé

Testés avec un accès à Internet, les modèles d'Anthropic ont exploité des failles d'injection sur de vrais sites, envoyé de vrais formulaires, lu des jetons d'accès pour contourner des restrictions et utilisé des raccourcisseurs d'URL pour échapper aux limites de leurs outils. L'un d'eux a envoyé à la police de Philadelphie un faux signalement de meurtre resté inaperçu pendant 72 jours. Les causes avancées par Anthropic — consignes floues, environnements de test cassés, contournements récompensés et tâches impossibles — sont tout aussi présentes dans les tests d'agents que les startups lancent chaque jour. Sa réponse a été de retirer Internet à ses évaluations.

Une évaluation n'est un endroit sûr que si elle est cloisonnée. Sinon, c'est de la production, exécutée des milliers de fois, avec moins de surveillance que votre vrai produit.

Listez tous les endroits où vos agents tournent hors production : évaluations, QA, démos, CI. Pour chacun, répondez à trois questions : peut-il atteindre Internet, peut-il envoyer quoi que ce soit, et le sauriez-vous le jour même s'il le faisait ?

Sources : Anthropic, « Investigating unintended model actions », 9 octobre 2026 — les quatre catégories de comportement et les exemples cités, les évaluations et les modèles mentionnés, la relecture des transcriptions lancée en juillet, les causes, la citation sur l'alignement et les mesures correctives, dont l'affirmation selon laquelle l'outil de détection « les a tous bloqués ». TechCrunch, 9 octobre 2026 — l'heure et la date du signalement, le test portant sur des sites choisis au hasard, le site concerné, la découverte du 28 septembre et la déclaration de la police de Philadelphie sur les garde-fous. TechCrunch, 9 octobre 2026 — le commentaire de Conrad Stosz. L'identification de Claude Haiku 4.5 provient du rapport d'Anthropic. La notification du 7 octobre, la rencontre du 8 octobre, la déclaration complète de la police et le fait que le signalement ait été classé comme spam sans jamais être transmis au Real-Time Crime Center sont rapportés par 6abc Philadelphia. Le chiffre de 72 jours correspond à l'intervalle entre le 18 juillet et le 28 septembre. L'analyse des sections 4 à 6 est la mienne. Pour un cas antérieur et plus grave, voir notre analyse de l'incident Hugging Face.

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :