Agents IA et cybersécurité : le cas Anthropic
Des agents IA ont atteint des outils internes d’Anthropic via des logiciels tiers. Comprenez les faits, les risques et les mesures concrètes à prendre.
Des agents IA ont atteint des systèmes internes d'Anthropic : ce que révèle l'incident
En moins de douze heures, des agents d'intelligence artificielle auraient trouvé des chemins d'accès vers des outils internes d'Anthropic. L'histoire est impressionnante, mais le scénario n'est pas celui d'un accès direct au modèle. D'après les éléments publiés par le Washington Post et les explications de l'entreprise, l'accès n'aurait pas transité par Claude. Les agents auraient plutôt profité de faiblesses dans des logiciels tiers utilisés pour des fonctions commerciales, RH et informatiques.
Anthropic affirme que les conversations des clients, le code source et les paramètres des modèles n'ont pas été consultés. De son côté, Cathedral, la startup à l'origine du test, dit avoir limité son intervention au strict nécessaire. Reste que les deux parties contestent certains points du déroulé - et surtout de l'interprétation. Du coup, ce dossier mérite mieux qu'un simple réflexe alarmiste : il rappelle que des agents capables d'enchaîner des actions peuvent accélérer la découverte de failles, sans pour autant effacer les causes « classiques » des incidents.
Que s'est-il passé chez Anthropic ?
Cathedral, une jeune entreprise de cybersécurité, dit que ses agents IA ont atteint, en moins de douze heures, des systèmes internes d'Anthropic. Le test s'inscrivait dans un programme rémunéré de type bug bounty : l'objectif n'était pas d'exploiter une faille à des fins malveillantes, mais de la signaler.
D'après un projet de rapport cité par le Washington Post, les agents auraient pu accéder à des comptes rendus de réunions, à des informations liées aux salaires et aux offres d'emploi, ainsi qu'à des messages Slack concernant des modèles avancés. Anthropic a confirmé l'accès à un périmètre limité de systèmes commerciaux, RH et informatiques. Ces outils contenaient notamment des coordonnées professionnelles et des informations de base sur des comptes utilisateurs.
Ce qui a été consulté, et ce qui ne l'a pas été
La ligne de séparation est importante. Anthropic assure que les conversations des utilisateurs de Claude, les réponses du modèle, le code source et les paramètres des modèles n'ont pas été consultés. L'entreprise dit aussi ne disposer d'aucune preuve que d'autres acteurs que Cathedral aient exploité ces faiblesses.
Anthropic indique en outre que ses dispositifs de surveillance ont détecté une partie de l'activité avant le signalement, puis que l'accès de Cathedral a été coupé le jour même. Les logiciels concernés auraient ensuite été désactivés, le temps que leurs fournisseurs confirment avoir corrigé. Dans les informations disponibles, les noms des fournisseurs ne sont pas précisés.
Un désaccord sur le déroulement du test
Anthropic reproche à Cathedral d'avoir présenté le risque comme plus large que ce que cela représentait réellement - notamment en invoquant la sécurité nationale - et de ne pas avoir déclaré toute son activité dans le cadre du programme. Cathedral, de son côté, estime que l'accès aux données a été réduit au minimum, conformément aux pratiques attendues en recherche en sécurité.
Autrement dit : les éléments rapportés décrivent un accès à certains outils professionnels, pas une prise de contrôle de Claude, ni une extraction de ses modèles. Ils ne permettent pas non plus d'affirmer que des données sensibles ont été utilisées en dehors du test. La vitesse annoncée - moins de douze heures - impressionne, mais elle ne dit pas, à elle seule, à quel point les faiblesses étaient faciles à exploiter ni si l'opération serait reproductible.
Pourquoi les logiciels tiers sont-ils le point sensible ?
Dans ce cas, l'accès ne viendrait pas d'une faille dans le modèle Claude. Il s'agirait plutôt de faiblesses dans des logiciels administratifs et commerciaux fournis par des tiers. On parle d'outils « classiques » : gestion des prospects, suivi des recrutements, collaboration, gestion des identités ou administration informatique. Dans beaucoup d'entreprises, ces services sont reliés aux systèmes internes pour éviter les doubles saisies et fluidifier le travail.
Le problème, c'est que cette intégration crée souvent une dépendance de sécurité. Un outil SaaS n'héberge pas forcément le « cœur » du produit d'une entreprise, mais il peut recevoir des autorisations lui permettant de consulter des informations internes. Si ses droits sont trop larges, si sa configuration n'est pas assez verrouillée, ou si une vulnérabilité existe chez le fournisseur, il peut devenir un point d'entrée indirect vers des données que l'organisation pensait mieux isolées.
Le risque vient souvent de l'accumulation des accès
Dans la pratique, les incidents ne naissent pas toujours d'une faille spectaculaire. Plus souvent, ils résultent d'une suite de petites décisions : un compte de service resté actif après un projet, une intégration autorisée à lire trop de données, des droits jamais réévalués, ou des journaux d'activité trop peu détaillés.
Un outil RH peut, par exemple, avoir besoin de consulter les dossiers de recrutement, sans pour autant lire des documents financiers. Un outil de gestion commerciale peut avoir accès aux coordonnées des clients, mais pas à des conversations internes sur des modèles en développement. En clair : le niveau d'accès dépend du travail à faire, pas de ce que l'outil pourrait techniquement recevoir.
Le problème dépasse le secteur de l'IA
Les organisations françaises et européennes utilisent les mêmes catégories d'outils, qu'elles soient au CAC 40, en PME ou dans la French Tech. Donc l'incident concerne aussi celles qui ne travaillent pas spécifiquement sur des agents IA. Toute entreprise qui relie des outils externes à ses systèmes internes doit savoir quelles données sont exposées et quelles autorisations sont réellement accordées.
Le RGPD rappelle notamment l'obligation de limiter les données personnelles au nécessaire et de maîtriser les relations avec les sous-traitants. Ce cadre ne remplace pas une analyse technique, mais il pousse vers la même logique opérationnelle : qui accède à quoi, pourquoi, et pendant combien de temps. La conformité ne suffit pas à bloquer une attaque, mais elle aide à documenter les flux et à clarifier les responsabilités.
Que change l'usage d'agents IA en cybersécurité ?
Un agent IA ne fait pas que répondre. Selon la façon dont il est configuré, il peut enchaîner des étapes, utiliser des outils et poursuivre un objectif sans qu'un humain valide chaque action au moment où elle se produit. En cybersécurité, cette capacité peut accélérer certaines phases : examiner des interfaces, tester des hypothèses et exploiter les résultats obtenus à l'étape suivante.
Mais il ne faut pas surinterpréter : c'est surtout une question de rythme et d'échelle, pas une disparition des vulnérabilités « classiques ». L'agent doit de toute façon s'appuyer sur des accès disponibles, des logiciels connectés et des faiblesses exploitables. Le résultat dépend aussi de l'environnement (permissions, garde-fous, qualité de la configuration) et des compétences de la personne qui le met en place. Un agent ne contourne pas « magiquement » toutes les protections.
Pourquoi le temps de découverte compte
Si un système est examinable plus vite, les équipes de défense ont moins de temps pour repérer une configuration risquée avant qu'elle soit testée. À l'inverse, ces mêmes capacités peuvent aussi servir à mieux contrôler les actifs : vérifier plus fréquemment les configurations, repérer des erreurs et trier plus rapidement les alertes.
Là encore, tout dépend de la gouvernance. Un agent lancé avec des droits trop larges et sans limites claires peut créer du risque lui-même : consulter des données sensibles, multiplier les requêtes, ou effectuer une action non prévue. L'automatisation n'assainit pas une procédure mal conçue ; elle exécute juste plus vite ce qu'on lui a donné (y compris les erreurs).
Un contexte déjà documenté par Anthropic
Anthropic a aussi évoqué, par le passé, des usages offensifs de ses modèles dans d'autres contextes. En novembre 2025, l'entreprise a déclaré que des pirates soutenus par l'État chinois avaient utilisé Claude Code dans des attaques visant une trentaine d'organisations, l'IA prenant en charge une grande partie du travail tactique, selon son estimation. Anthropic a également indiqué, en juillet, que des modèles Claude avaient compromis de vraies organisations au cours de trois incidents observés pendant ses tests.
Ces annonces ne prouvent pas que « toutes les attaques deviennent automatiquement plus efficaces » grâce à l'IA. Elles montrent toutefois une réalité : des outils d'IA peuvent s'inscrire dans des opérations concrètes, avec des effets qui varient selon le contexte. Pour les équipes sécurité, la question est donc moins « utilise-t-on des agents ? » et plus « avec quels droits, dans quel périmètre, et sous quelle supervision ? ».
Comment réduire les risques dans une entreprise ?
L'objectif n'est pas de bannir, de façon aveugle, les logiciels tiers ou les agents IA. Dans beaucoup d'organisations, ces outils répondent à un besoin réel. La démarche utile consiste plutôt à limiter l'impact d'un accès compromis, puis à détecter rapidement les comportements anormaux.
1. Cartographier les outils et les données accessibles
Commencez par l'inventaire : les applications connectées aux systèmes internes, leurs propriétaires, les données consultées et les méthodes d'authentification. Prévoyez aussi une chasse aux ajouts « hors radar » : les applications dites « fantômes » échappent facilement aux contrôles.
Pour chaque intégration, posez trois questions simples : quelles données peut-elle lire ou modifier ? Quel processus métier justifie cet accès ? Qui doit le réexaminer ? Sans ces réponses, l'entreprise mesure mal l'impact si quelque chose dérape.
2. Réduire les permissions et la durée des accès
Appliquez le principe du moindre privilège : chaque compte et chaque application ne doivent avoir que les droits nécessaires à leur fonction. Quand c'est possible, séparez lecture et écriture, limitez les autorisations par périmètre et supprimez les comptes qui ne servent plus.
Les accès temporaires sont souvent plus sûrs que les droits permanents, surtout pour des besoins ponctuels. Oui, ça demande plus de gestion. Mais ça réduit le nombre de chemins disponibles si un compte ou un fournisseur est compromis. C'est un compromis généralement rentable quand l'outil donne accès à des données RH, commerciales ou de recherche.
3. Encadrer les agents qui peuvent agir
Un agent de test ne devrait pas avoir le niveau d'accès d'un administrateur général. Fixez à l'avance les systèmes qu'il peut examiner, les actions autorisées, les volumes de requêtes, et les données qu'il ne doit pas ouvrir. Pour les opérations sensibles ou irréversibles, prévoyez une validation humaine.
En production, les essais doivent être explicitement autorisés, documentés et coordonnés avec les équipes sécurité. Un programme de bug bounty doit aussi préciser le périmètre, les méthodes permises, les obligations de signalement et la conduite à tenir si des données sensibles sont découvertes. Sans ces règles, même un test mené de bonne foi peut perturber un service - ou déclencher un désaccord sur la conformité du protocole.
4. Détecter et préparer la réponse
Centralisez les journaux d'accès des applications critiques et surveillez ce qui s'écarte de l'ordinaire : export massif, consultation de dossiers inhabituels, création soudaine de jetons, activité en dehors des plages attendues. Une alerte ne sert à rien si personne ne sait qui la traite ni dans quel délai.
Préparez aussi une procédure de révocation : couper l'intégration, invalider des jetons, contacter le fournisseur et déterminer quelles données ont pu être consultées. L'affaire chez Anthropic illustre justement l'intérêt de pouvoir suspendre un logiciel le temps que l'éditeur confirme un correctif. Évidemment, ça peut gêner temporairement l'activité ; mais l'interruption se justifie quand le risque d'exposition dépasse le coût du « downtime ».
Checklist de contrôle avant de connecter un nouvel outil ou un agent :
- Les données accessibles sont-elles nécessaires au cas d'usage ?
- Les droits sont-ils limités à un périmètre précis ?
- L'activité est-elle journalisée et surveillée ?
- Une personne est-elle responsable de l'intégration ?
- Peut-on révoquer rapidement les accès en cas d'incident ?
- Les tests de sécurité sont-ils autorisés et bornés par écrit ?
Ce que les dirigeants doivent retenir
L'incident a aussi été lu à travers un prisme politique. Un responsable de l'administration américaine, cité anonymement par le Washington Post, a évoqué des inquiétudes de sécurité nationale et estimé que la capacité observée pourrait intéresser des adversaires étatiques. Anthropic conteste cette lecture, estimant que Cathedral aurait exagéré les implications.
Le bon réflexe, c'est de séparer le signal du raccourci. Le signal : une petite équipe, avec des agents capables d'enchaîner des actions, dit avoir trouvé rapidement des chemins vers des outils d'entreprise. Le raccourci : en déduire automatiquement que des acteurs étrangers ont les mêmes accès, ou que les systèmes centraux d'Anthropic ont été compromis. Les informations publiées ne suffisent pas à démontrer ces scénarios.
Pour un dirigeant, la décision utile ne dépend pas seulement de l'adoption ou non de l'IA. Elle dépend surtout de la maîtrise des accès : connaître les outils reliés aux données stratégiques, limiter les permissions, tester les procédures de réponse et fixer des règles de supervision pour les agents. La même approche vaut pour la santé, la banque, l'administration ou une PME : l'impact dépend de la sensibilité des données et de la capacité à contenir un accès - pas du nom de la technologie.
À retenir : l'IA peut accélérer la recherche de failles, mais dans ce cas, le risque se situe surtout dans l'écosystème logiciel et dans les autorisations accordées. La priorité est de réduire les accès inutiles et de rendre chaque connexion visible, contrôlable et révocable.
Conclusion
L'affaire Cathedral-Anthropic ne démontre pas que Claude ou les modèles d'Anthropic ont été compromis. Elle met en lumière un risque plus banal, mais très répandu : des logiciels tiers, intégrés au quotidien, peuvent créer des chemins vers des données internes quand leurs accès sont mal maîtrisés.
Les agents IA peuvent accélérer la découverte de ces chemins, mais ils ne remplacent ni les failles, ni les erreurs de configuration qui rendent l'accès possible. Pour les organisations, la réponse la plus solide reste opérationnelle : cartographier les connexions, appliquer le moindre privilège, encadrer les agents et préparer une révocation rapide. La première étape, la plus concrète, consiste à regarder les applications qui accèdent aujourd'hui à vos données sensibles.