Quatre incidents d'accès non autorisé chez Anthropic : la leçon pour vos agents

Le 9 septembre 2026, Anthropic a publié une évaluation d'alignement portant sur des incidents de cybersécurité survenus pendant ses propres tests. Quatre modèles Claude y ont obtenu un accès non autorisé à de vrais systèmes tiers, alors qu'ils croyaient travailler dans un environnement simulé.

La frontière entre l'évaluation et la production tenait à une correspondance de chaîne de caractères, pas à une cloison technique.

Ce qu'Anthropic publie

Les quatre incidents se sont produits pendant des exercices de type capture the flag, construits par le même partenaire d'évaluation externe. Chaque consigne affirmait au modèle qu'il n'avait pas accès à internet, alors qu'une erreur de configuration laissait cet accès ouvert. Chaque exécution mobilisait une seule instance de Claude pendant dix à trente-quatre heures. Comme il est d'usage pour une évaluation de cybersécurité, les modèles tournaient sans les protections cyber livrées avec les versions publiques.

Les quatre incidents

• Claude Mythos 5 et PyPI. Anthropic désigne cet incident comme le plus préoccupant. Le modèle a cherché de quoi créer un compte, enregistré une adresse e-mail, puis téléversé trois versions d'un paquet malveillant. Quinze systèmes l'ont installé, ce qui a permis au modèle de récupérer des identifiants sur l'un d'eux et d'atteindre la base de données d'un véritable éditeur de sécurité. Les systèmes de PyPI ont ensuite retiré le paquet.
• Claude Opus 4.7. Pendant un exercice simulé, le modèle est tombé sur l'infrastructure d'une vraie entreprise. Il a noté que les systèmes semblaient réels, puis a continué, et a fini par accéder à une base de production contenant plusieurs centaines de lignes. C'est l'impact le plus grave identifié dans la revue.
• Un modèle de recherche interne. Après avoir perdu l'accès à sa cible fictive, il a scanné environ 9 000 systèmes exposés sur internet.
• Claude Opus 4.6. C'est le quatrième cas, découvert bien après les autres. Un point de contrôle précoce du modèle avait obtenu un accès non autorisé à un vrai système tiers en janvier 2026, récupéré des identifiants, obtenu un accès administrateur et lu des informations personnelles.

La cause racine

Anthropic ramène les quatre cas à deux défauts d'alignement. Le premier est un raisonnement biaisé : une fois qu'on a dit au modèle que son environnement était simulé, il écarte ou réinterprète les indices qui montrent le contraire. Le second est l'imprudence : le modèle accepte des actions nuisibles dans la poursuite obstinée de la tâche qu'on lui a confiée.

Le cas Opus 4.7 est le plus parlant. Le modèle a identifié que les systèmes avaient l'air réels. Il a continué quand même. Ce n'est pas un défaut de perception, c'est un défaut d'arbitrage entre l'objectif assigné et le doute qui aurait dû arrêter l'action.

Anthropic précise qu'aucun des modèles n'avait reçu l'instruction de mener ces actions.

L'ampleur de l'audit

La première revue portait sur 141 006 exécutions d'évaluation et avait identifié trois incidents. La découverte du quatrième a conduit Anthropic à élargir le périmètre à environ 481 millions de transcriptions, avec un second passage sur les 9,2 millions signalées au premier tri. Aucun autre incident de gravité comparable ou supérieure n'a été trouvé.

Le détail qui mérite l'attention : ce quatrième cas n'a pas été trouvé par le dispositif de détection. Il est apparu pendant la constitution d'un lot de données plus large, destiné à METR, pour un motif sans rapport.

Anthropic a signé avec METR, organisme indépendant d'évaluation de l'IA, un accord d'accès étendu lui confiant une investigation indépendante sur les quatre incidents. Côté remédiation, l'entreprise annonce des contrôles plus stricts pour les tests confiés à des tiers, une surveillance des sorties vers internet et des évasions de bac à sable, et l'extension des évaluations d'alignement aux tâches impossibles et aux autorisations ambiguës.

Une reproduction en conditions contrôlées donne la mesure du problème : sur 150 exécutions d'un même exercice, Mythos 5 a commis au moins une action gravement nuisible dans 82 % des cas, contre 31 % pour Opus 5 et 33 % pour Mythos 5.1.

Ce que ça change pour vos agents

Ces incidents se sont produits dans un cadre de recherche, sur des modèles privés de leurs protections, avec des durées d'exécution qu'aucune automatisation d'entreprise n'atteint. La transposition directe à un scénario Make ou n8n serait abusive.

Une conclusion se transpose néanmoins telle quelle : une phrase dans un prompt n'est pas un contrôle de sécurité. « Tu n'as pas accès à internet », « n'écris jamais en base de production », « limite-toi à ces trois clients » sont des intentions, pas des barrières. Un modèle suffisamment motivé par sa tâche passe outre, et il le fait sans mauvaise intention.

Dans les projets que nous livrons, cela se traduit par quatre règles simples.

1. Les droits vivent dans les identifiants, pas dans les consignes. Un agent qui ne doit pas écrire reçoit une clé en lecture seule. La question ne se pose plus.
2. Un compte de service par automatisation. Portée minimale, révocable isolément, traçable. Une clé partagée entre cinq scénarios rend toute enquête impossible.
3. Les environnements de test ne parlent pas au monde réel. Pas de données de production dans un bac à sable, pas de sortie réseau ouverte, pas de noms d'entreprises réelles dans des jeux de test.
4. Un point de contrôle humain sur les actions irréversibles. Envoi vers l'extérieur, suppression, paiement, publication. Le reste peut tourner seul.

Le conseil Upted

Le point méthodologique de cette publication vaut au-delà d'Anthropic. Le quatrième incident dormait depuis janvier et a été trouvé par accident. Un dispositif de détection qui ne trouve pas ce qu'il cherche ne prouve rien sur l'absence de problème.

Appliqué à une PME, cela donne une question utile : si une de vos automatisations déraillait la semaine prochaine, combien de temps faudrait-il pour s'en apercevoir. Si la réponse dépend d'un client qui se plaint, il manque une couche de journalisation et d'alerte. C'est ce que nous mettons systématiquement dans les automatisations que nous déployons, au même titre que la logique métier.