De l’intelligence à l’autorité

L’intelligence artificielle ne se contente plus de répondre à des questions et de générer du contenu. De plus en plus, les systèmes d’IA peuvent interpréter des instructions, élaborer des plans, choisir des outils et exécuter des tâches sans être continuellement guidés par un humain.

Cette distinction est importante.

Un système d’IA qui recommande une action est différent d’un système autorisé à l’exécuter. La différence ne tient pas nécessairement à l’intelligence ou au degré de sophistication. Elle tient à l’autorité.

Les systèmes autonomes ne se limitent pas aux grands modèles de langage de pointe. Ils comprennent des systèmes spécialisés d’apprentissage automatique, la robotique, les véhicules autonomes, les agents logiciels et des combinaisons de technologies qui prennent des décisions ou exécutent des actions de manière indépendante dans des conditions de fonctionnement définies.

Leurs avantages potentiels sont considérables. Ils peuvent soutenir la découverte scientifique, les activités industrielles, les soins de santé, le développement logiciel et la cybersécurité. Ils peuvent aussi entraîner des conséquences imprévues, exposer des informations sensibles ou déclencher des actions allant au-delà de ce que leurs opérateurs avaient prévu.

Dans les défis de sécurité liés à la conception des systèmes autonomes, Mohammad Hamad et Sebastian Steinhorst examinent les défis de sécurité associés à la réponse autonome aux incidents, à l’évaluation des risques, au contrôle d’accès, à la fiabilité des données et aux interactions entre systèmes autonomes. Leurs recherches, qui portent en grande partie sur les systèmes cyberphysiques, montrent que les défis liés à la sécurisation des actions indépendantes des machines vont au-delà des agents LLM actuels.

Les conséquences plus générales de l’autonomie méritent un examen approfondi, notamment en raison des risques de dommages physiques. Les éléments disponibles doivent toutefois être interprétés avec prudence. Les incidents impliquant des véhicules automatisés, par exemple, ne peuvent pas être automatiquement attribués aux mêmes mécanismes que ceux qui concernent les agents autonomes de cybersécurité. Le degré d’autonomie, les conditions de fonctionnement, l’intervention humaine et les éléments établissant un lien de causalité sont autant de facteurs importants.

De même, le fait que l’IA autonome puisse causer des dommages ne prouve pas que la gouvernance accuse nécessairement un retard. Nous ne devrions pas non plus supposer que les systèmes autonomes sont, par nature, difficiles à sécuriser.

La question fondamentale n’est pas de savoir si l’IA peut accomplir des tâches complexes, mais si les cadres architecturaux, de sécurité et organisationnels qui régissent les systèmes autonomes peuvent définir des limites appropriées à l’autorité déléguée et fournir des preuves vérifiables du respect de ces limites.

La cybersécurité offre un point de vue particulièrement utile sur cette question, car les professionnels de la sécurité remettent en question depuis des décennies les hypothèses relatives à la confiance, aux autorisations, aux accès et au comportement des systèmes.

Le jeu du chat et de la souris à la vitesse des machines

La cybersécurité est depuis longtemps décrite comme un jeu du chat et de la souris.

Les attaquants découvrent des failles, les défenseurs mettent en place des protections et les deux camps s’adaptent. Le cycle se poursuit au gré de l’évolution des technologies, des tactiques et des environnements d’exploitation.

L’IA autonome ne modifie pas nécessairement les règles fondamentales de ce jeu. Elle peut changer qui — ou quoi — y participe, la vitesse à laquelle les actions sont menées et le volume de travail qui peut être effectué sans intervention humaine continue.

Un système autonome de sécurité offensive pourrait repérer des services exposés, examiner des vulnérabilités, élaborer des pistes d’attaque possibles et vérifier si celles-ci sont exploitables. Un système défensif pourrait s’appuyer sur des capacités similaires pour examiner des menaces, repérer des failles et valider les mesures correctives.

Ce potentiel à double usage est essentiel pour comprendre les implications de l’IA autonome en matière de sécurité.

Le Projet Glasswing d’Anthropic illustre la découverte de vulnérabilités assistée par l’IA. Dans sa mise à jour de recherche de mai 2026, Anthropic a fait état de résultats importants en matière de découverte de vulnérabilités, tout en soulignant les difficultés opérationnelles liées à leur vérification, à leur divulgation et à l’application de correctifs.

Cette distinction est importante. Découvrir une vulnérabilité ne revient pas à confirmer qu’elle est exploitable, à la corriger ou à démontrer que le système concerné est sécurisé.

Un plus grand nombre de découvertes peut améliorer la visibilité, tout en alourdissant la tâche des personnes et des processus chargés d’y remédier.

L’issue en matière de sécurité dépend de la suite des événements.

Si les attaquants et les défenseurs peuvent automatiser une partie de leur travail, la question pertinente n’est pas simplement de savoir quel camp dispose du modèle le plus performant. Il s’agit de déterminer si les défenseurs peuvent transformer les découvertes en mesures correctives efficaces et en vérifier les résultats de manière indépendante.

Les tests d’intrusion traditionnels ne deviennent pas obsolètes parce que l’IA peut mener des actions offensives. Leur portée doit s’élargir pour inclure les systèmes qui interprètent des instructions, utilisent des outils, combinent des autorisations et poursuivent des objectifs en plusieurs étapes.

L’objectif reste le même : repérer les failles, en établir l’importance, les corriger et prouver que les mesures de protection sont efficaces.

Joints architecturaux : à la rencontre des frontières de sécurité

L’un des risques les plus subtils des systèmes autonomes apparaît lorsque des composants autorisés individuellement interagissent d’une manière qui produit des résultats imprévus.

J’appelle ces points d’interaction des jonctions architecturales.

Prenons un exemple classique. Une organisation restreint l’accès à un fichier à l’aide des autorisations NTFS. Un service distinct de partage dans le cloud permet à un utilisateur autorisé de partager ces informations à l’extérieur de l’organisation.

Chaque système peut fonctionner selon ses propres règles. Pourtant, leur interaction peut entraîner un partage d’informations qui enfreint les limites de sécurité que l’organisation entendait imposer.

Il s’agit d’une illustration de politiques potentiellement contradictoires, et non d’une affirmation selon laquelle un produit de partage de fichiers serait vulnérable.

Le problème ne tient pas nécessairement à une défaillance de l’un ou l’autre des contrôles pris isolément. Il peut s’agir d’un défaut d’application de la politique de sécurité prévue à l’ensemble du processus.

L’IA autonome peut être confrontée à des situations similaires lorsqu’elle relie des modèles, des applications, des identités, des outils, des référentiels et des services externes.

Un agent peut être autorisé à lire un document, à créer un référentiel et à téléverser des fichiers. Cela ne signifie pas nécessairement qu’il est habilité à combiner ces opérations d’une manière qui expose des informations confidentielles.

La recherche fournit une raison concrète d’examiner ces interactions.

Dans AgentDojo, des chercheurs ont évalué des attaques par injection de prompt contre des agents d’IA utilisant des outils, au moyen de 97 tâches réalistes et de 629 cas de test de sécurité. Leurs résultats ont montré que des instructions malveillantes introduites dans des sorties d’outils non fiables pouvaient compromettre certaines propriétés de sécurité, même si les attaques et les agents ne réussissaient pas systématiquement.

Cette recherche ne permet pas d’établir la fréquence de réussite de ces attaques dans les environnements de production. Elle montre toutefois pourquoi l’évaluation des seules réponses d’un modèle ne suffit pas à comprendre le comportement d’un système connecté à des outils.

Un risque connexe est parfois qualifié de blanchiment des autorisations : une action semble légitime parce qu’elle passe par un outil ou un intermédiaire autorisé, alors même que le comportement résultant de la combinaison des opérations enfreint les limites d’autorité prévues.

À mesure que plusieurs agents collaborent, ces relations nécessitent des règles explicites régissant la participation, l’échange d’informations et les actions autorisées.

Les responsabilités doivent également être réparties à l’échelle de l’architecture.

Les fournisseurs de modèles, les opérateurs de plateformes, les développeurs d’agents et les organisations qui les déploient peuvent contrôler différentes parties du système. Un modèle de responsabilité partagée efficace précise qui contrôle chaque frontière, qui peut autoriser des exceptions, qui surveille l’exécution et qui intervient en cas de problème.

L’autonomie ne supprime pas les responsabilités. Elle rend d’autant plus important de savoir à qui elles incombent.

Rigueur offensive : mettre à l’épreuve ce que nous croyons savoir

Cela nous amène à un concept que je décris sous le nom de rigueur offensive.

La rigueur offensive est une approche méthodique des tests adversariaux, de l’examen critique et de la validation fondée sur des preuves, qui remet en question les hypothèses de sécurité. Elle évalue le comportement des systèmes dans des conditions réalistes, plutôt que de s’appuyer uniquement sur des conceptions architecturales, des contrôles documentés ou des protections supposées.

Les pratiques qui la sous-tendent sont bien établies. Les tests d’intrusion, la modélisation des menaces, les exercices d’équipe rouge et la validation de la sécurité mettent depuis longtemps les hypothèses de défense à l’épreuve.

La rigueur offensive articule ces pratiques autour d’une question centrale :

Quels éléments démontrent que les limites de sécurité prévues sont bien respectées ?

Une organisation peut avoir des politiques restreignant les informations sensibles, un modèle configuré pour rejeter les demandes interdites et un agent disposant de permissions limitées.

Ce sont des mesures de protection importantes. Leur existence ne suffit toutefois pas, à elle seule, à démontrer que le système dans son ensemble se comporte de manière sécurisée dans des conditions adversariales.

Un modèle peut rejeter une instruction malveillante alors qu’un outil autorisé permet tout de même une action imprévue. Une politique peut sembler adéquate alors que les interactions entre les systèmes créent une voie de contournement inattendue.

J’appelle parfois cela l’« illusion des garde-fous » : prendre la présence de garde-fous pour la preuve que le système ne peut pas franchir les limites qu’ils étaient censés faire respecter.

Les garde-fous sont utiles. Il reste néanmoins à démontrer leur efficacité.

Prenons le cas d’un agent autonome autorisé à enquêter sur une compromission présumée. Il peut récupérer des journaux, examiner l’activité des utilisateurs et recommander des mesures de confinement.

Dans le cadre d’un test de sécurité autorisé, un testeur adversarial introduit des instructions trompeuses dans les informations que l’agent est censé traiter.

Le test ne devrait pas se limiter à déterminer si l’agent a suivi ces instructions.

Il devrait examiner si l’agent a tenté une action non autorisée, si des contrôles indépendants en ont empêché l’exécution, si la tentative a été consignée et si le système a réagi de manière appropriée.

Offensive Rigor relie cinq activités :

1. Établir l’hypothèse : déterminer la propriété de sécurité que l’architecture est censée garantir.
2. Mettre l’hypothèse à l’épreuve : tester des vecteurs d’attaque réalistes, des entrées manipulées et des combinaisons de capacités légitimes.
3. Recueillir des éléments de preuve : déterminer ce que le système a tenté de faire, ce qui a été exécuté et quels contrôles sont intervenus.
4. Corriger la faiblesse : remédier au modèle, au flux de travail, aux autorisations, à l’architecture ou au processus opérationnel à l’origine de la défaillance.
5. Vérifier la correction : tester à nouveau le vecteur d’attaque concerné et confirmer que la propriété de sécurité visée est garantie.

C’est là que réside la différence entre tester la réponse d’un modèle et tester la sécurité du système dans son ensemble.

Il faut également examiner ce qui se passe après une première compromission. Un attaquant peut tenter de collecter des identifiants, d’élever ses privilèges, de maintenir sa présence ou de se déplacer latéralement en détournant des capacités déjà disponibles dans un environnement.

Le fait qu’un outil soit légitime ne rend pas légitime chacun de ses usages.

Offensive Rigor n’a pas pour objectif de partir du principe que les systèmes autonomes sont vulnérables. Il s’agit de déterminer, par des tests, où se situent leurs limites de sécurité.

Autonomie conditionnelle : distinguer l’intelligence de l’autorité

Une réponse architecturale consiste à distinguer ce qu’un système d’IA peut faire de ce qu’il est autorisé à faire.

Je décris cette approche comme une autonomie conditionnelle.

L’autonomie conditionnelle reconnaît que le degré d’indépendance approprié dépend de la tâche, de l’environnement opérationnel, des conséquences potentielles, du niveau d’incertitude et des éléments disponibles pour justifier une action.

Un agent qui résume des informations publiques n’a pas nécessairement besoin du même niveau de supervision qu’un agent autorisé à désactiver des comptes, à modifier des règles de pare-feu ou à changer l’infrastructure de production.

Ce dernier peut nécessiter des règles d’engagement explicites, des autorisations appliquées de manière indépendante, un niveau d’autorisation renforcé et l’approbation d’un humain pour les actions lourdes de conséquences.

Ces limites ne devraient pas être élargies simplement parce qu’un agent estime qu’un accès plus étendu l’aiderait à atteindre son objectif.

Un agent peut revoir la manière d’accomplir une tâche autorisée sans acquérir de pouvoirs supplémentaires.

Le Top 10 de l’OWASP pour les applications LLM aborde cette question dans sa catégorie LLM06:2025 : autonomie excessive. L’OWASP considère que les fonctionnalités, les autorisations et l’autonomie excessives sont des sources de risque, et recommande de limiter les capacités et d’appliquer les autorisations de manière indépendante.

L’autonomie conditionnelle applique ces principes en fonction du risque opérationnel.

L’accès à l’information devrait être limité à ce qui est nécessaire à la tâche. Les autorisations accordées aux outils devraient se limiter aux opérations approuvées. Des budgets d’action, des limites de fréquence, des exigences d’approbation et des conditions d’arrêt peuvent encadrer l’exécution.

Ces mesures de protection sont particulièrement importantes pour les tests offensifs autonomes.

Un agent de test peut légitimement découvrir des identifiants ou des informations sensibles dans le cadre d’un objectif autorisé. Mais découvrir un identifiant ne signifie pas que le modèle doit en recevoir la valeur en clair.

Un dispositif de sécurité peut isoler les identifiants sensibles du modèle et en encadrer l’utilisation au moyen d’autorisations appliquées de manière indépendante. Par exemple, un courtier d’identifiants pourrait transmettre un secret directement à un service approuvé sans l’exposer inutilement au modèle.

Cela s’inscrit dans le prolongement des principes établis du moindre privilège et de la séparation des tâches.

Cela soulève également une question intéressante au sujet des architectures « Bring Your Own Model » (BYOM) ou « Bring Your Own LLM » (BYO-LLM).

Si le modèle sous-jacent est remplacé demain, quelles garanties de sécurité resteront intactes ?

L’autorisation des tâches, l’isolation des identifiants, les restrictions de périmètre, la journalisation et l’application des politiques peuvent être prises en charge par le dispositif qui entoure le modèle, plutôt que de dépendre entièrement de son comportement.

Cela ne signifie pas que ce dispositif est automatiquement sécurisé ni que les modèles sont interchangeables. Différents modèles peuvent interpréter les instructions différemment, invoquer les outils de différentes façons et présenter des modes de défaillance distincts.

Une évaluation pertinente doit tester à la fois les contrôles censés rester invariants et les comportements qui changent lorsque le modèle est remplacé.

Parmi les propriétés de sécurité les plus durables figurent peut-être celles qui restent applicables de manière indépendante à mesure que le composant d’intelligence évolue.

Quand l’IA agit sur l’IA : le problème de la vérification

Prenons l’exemple hypothétique d’un processus opérationnel de sécurité :

Enquêter sur cet incident, recueillir les éléments de preuve, identifier les identités concernées, proposer des mesures de confinement, exécuter les actions approuvées et vérifier le résultat.

Un agent d’investigation analyse les données de télémétrie. Un autre recommande des mesures de confinement. Un agent d’exécution autorisé effectue les modifications. Un agent de vérification évalue le résultat.

Cet exemple illustre une réponse autonome aux incidents en boucle fermée, et non une défaillance documentée à l’échelle du secteur.

Supposons que le premier agent identifie à tort une identité comme étant compromise. Un deuxième agent accepte cette conclusion et désactive le compte. Un troisième confirme la désactivation du compte et signale que l’opération a réussi.

L’opération sélectionnée a été effectuée.

Mais la détermination initiale était-elle correcte ? L’action était-elle autorisée ? Le confinement a-t-il ciblé la menace réelle ? A-t-il provoqué des perturbations inutiles ?

La vérification ne peut pas se limiter à confirmer qu’un agent a effectué l’action qu’il a choisie.

De même, confier la vérification à un autre agent d’IA ne garantit pas automatiquement l’indépendance du résultat.

Différents agents peuvent s’appuyer sur les mêmes données de télémétrie inexactes, les mêmes informations compromises ou les mêmes hypothèses erronées. Leur accord ne permet pas d’établir indépendamment les faits sous-jacents.

Plus les conséquences d’une action autonome sont importantes, plus il est nécessaire de la vérifier indépendamment du système qui a pris la décision.

Cette indépendance peut reposer sur des preuves obtenues séparément, des contrôles de politiques déterministes, des environnements d’exécution cloisonnés, une vérification humaine ou une combinaison de mesures de protection.

Les contrôles appropriés doivent être proportionnés aux conséquences d’une erreur.

Les actions réversibles et à faible impact peuvent se prêter à une vérification automatisée. Les actions à fort impact ou difficiles à annuler peuvent nécessiter une autorisation renforcée, une confirmation indépendante et une approbation humaine explicite.

Quatre questions permettent de distinguer les propriétés de sécurité pertinentes :

• Le système a-t-il correctement interprété la tâche prévue ?
• L’action relevait-elle de l’autorité qui lui avait été déléguée ?
• L’exécution est-elle restée dans les limites autorisées ?
• Le résultat obtenu répondait-il à l’objectif de sécurité visé ?

Ces questions sont liées, mais ne sont pas interchangeables.

Un agent peut effectuer une action autorisée qui entraîne un résultat imprévu. Il peut également obtenir un résultat apparemment bénéfique au moyen d’une action non autorisée.

Aucune de ces situations ne doit être automatiquement considérée comme une réussite en matière de sécurité.

À mesure que les systèmes autonomes gagnent en capacités, le défi ne consiste pas simplement à leur permettre d’accomplir des processus complexes. Il s’agit d’établir des preuves suffisantes que leurs actions restent autorisées, appropriées et correctes.

Cela suppose également de savoir quand s’arrêter, transmettre le dossier à un niveau supérieur, annuler une action ou accepter un risque circonscrit et explicitement compris.

La confiance doit s’appuyer sur des preuves

Les conséquences de l’IA autonome pour la sécurité ne sont pas exclusivement négatives.

Les systèmes autonomes peuvent aider les équipes de défense à découvrir des faiblesses, à enquêter sur des menaces et à effectuer des travaux de validation qui mobiliseraient autrement beaucoup de temps et d’efforts humains.

De meilleurs modèles, des contrôles externes plus robustes et des pratiques opérationnelles plus mûres peuvent réduire certains risques liés à la délégation de pouvoirs.

Il serait donc prématuré de conclure que l’IA autonome est intrinsèquement peu sûre ou que la gouvernance ne peut pas suivre son évolution.

L’idée selon laquelle l’IA autonome exige de nouveaux principes de sécurité fondamentaux peut également être sérieusement contestée.

Bon nombre des problèmes sous-jacents — privilèges excessifs, entrées non fiables, autorisations insuffisantes, application incohérente des politiques et vérification insuffisante — sont étudiés depuis des décennies.

Les contrôles établis peuvent déjà offrir des solutions viables lorsqu’ils sont mis en œuvre et testés correctement.

L’autonomie peut modifier la vitesse, l’ampleur et la complexité de leur mise en œuvre. Elle ne les rend pas automatiquement inopérants.

Les éléments disponibles invitent à poser une question plus utile : dans quelles conditions peut-on faire confiance aux systèmes autonomes pour exercer les pouvoirs qui leur sont délégués, et comment démontrer que ces conditions sont réunies ?

La seule capacité des modèles ne suffira pas à y répondre.

Il faut des limites architecturales, une attribution claire des responsabilités, des autorisations appliquées de manière indépendante, une supervision adaptée et des preuves que les mesures de protection fonctionnent dans des conditions réalistes.

Il faut aussi une vision cohérente, mais évolutive, de la sécurité et des risques.

Nos principes fondamentaux de sécurité n’ont pas à changer chaque fois qu’un nouveau modèle apparaît. En revanche, nous devons continuellement remettre en question nos hypothèses sur la façon dont ces principes s’appliquent, à mesure que les capacités, les environnements opérationnels et les pouvoirs délégués évoluent.

Tel est l’objectif de la rigueur offensive.

Non pas pour prouver que les systèmes d’IA échoueront, mais pour découvrir où ils peuvent échouer, établir les conséquences et valider les mesures de contrôle destinées à prévenir ces défaillances ou à en limiter les effets.

L’avantage le plus durable ne consiste peut-être pas simplement à choisir un modèle plus performant, mais à bâtir une architecture où les modèles peuvent être remplacés sans compromettre les limites de confiance, d’autorité et de vérification.

Le jeu du chat et de la souris se poursuit. De plus en plus, les deux camps pourraient avoir des acteurs autonomes.

L’essentiel est de veiller à ce que notre capacité à repérer les faiblesses, à les corriger et à prouver les résultats ne se perde pas dans la course à l’automatisation de tout le reste.

La confiance doit s’appuyer sur des preuves.

Note de l’auteur : Les opinions et interprétations exprimées dans cet article sont les miennes et ne reflètent pas nécessairement les positions officielles, les politiques ou les capacités des produits de mon employeur.