Les agents IA ont besoin de limites de sécurité qu’ils ne peuvent pas réécrire

Il est tentant de lire l’histoire de Hugging Face comme le moment où les agents IA sont devenus incontrôlables. Ce n’est pas tout à fait ce qui s’est produit, et les détails sont importants. Il s’agissait d’agents de recherche en cybersécurité exécutés dans des évaluations où les mesures de protection avaient été délibérément désactivées afin que les chercheurs puissent voir de quoi les modèles étaient capables. Le bot de service client de personne ne s’est pas réveillé un matin et décidé d’attaquer une entreprise. Mais ce contexte ne dégage personne de ses responsabilités. Un agent a franchi la limite dans laquelle il devait rester, a utilisé des identifiants et des outils d’une manière jamais autorisée par ses opérateurs, et s’est retrouvé dans des systèmes appartenant à autrui. C’est la partie à laquelle chaque équipe de sécurité doit prêter attention.

Reuters a signalé que des agents exploraient Hugging Face dès mai, bien que les chercheurs aient déclaré n’avoir trouvé aucune preuve que l’activité antérieure ait provoqué une violation à elle seule. Juillet était différent. OpenAI a déclaré que ses modèles ont contourné les contrôles d’isolation, ont atteint Internet et compromis des parties de leur propre infrastructure de recherche ainsi que les systèmes de Hugging Face. Le compte de Hugging Face décrit une intrusion menée de bout en bout par un système d’agents autonome, qui a exploité son pipeline de traitement des données, récupéré des identifiants et circulé à travers des clusters internes.

Ce qui est dérangeant, c’est que les agents accomplissaient leurs tâches. Ils poursuivaient l’objectif qui leur avait été assigné. C’est pourquoi cette histoire dépasse largement un seul laboratoire de recherche. Les agents d’entreprise poursuivent également des objectifs. Ils détiennent des identifiants, invoquent des outils et se déplacent plus rapidement que ne peut en vérifier une personne. Un agent aux intentions parfaitement bonnes peut néanmoins causer de réels dommages, et un agent détourné peut utiliser exactement la même autorité au profit d’un attaquant. Ainsi, la sécurité doit régir ce que le système peut réellement faire, quel que soit le degré de confiance que le modèle inspire ou l’apparence inoffensive de son objectif déclaré.

Sécurisez l’action, pas seulement le modèle

La plupart des premiers programmes d’agents concentrent leurs efforts sur le modèle. Les équipes testent les invites, ajustent les refus, ajoutent un second modèle pour vérifier le premier, et observent la trace de raisonnement à la recherche de signes de mauvaise intention. Rien de tout cela n’est perdu. Mais tout cela reste probabiliste, car il dépend d’un autre modèle qui prend une décision de jugement. Une frontière de sécurité en production doit être déterministe, et elle doit entourer les outils, les identifiants, les réseaux et les transactions.

La question que je poserais est concrète : que peut réellement faire cet agent dans le monde réel ? Rédiger une demande de paiement est une chose. Libérer les fonds en est une autre. Il en va de même pour la préparation d’une modification de base de données versus son exécution en production, ou pour le marquage d’enregistrements répondant à une règle de conservation versus leur suppression. Il peut s’agir du même modèle dans les deux cas, avec des risques très différents selon le côté de la ligne où il se situe.

Un aperçu récent de Unite AI sur le contrôle des capacités trace la même ligne, liant le risque aux données, aux outils, aux autorisations, à l’autonomie et à l’environnement dans lequel l’agent fonctionne. J’apprécie ce cadrage car il nous fait dépasser les étiquettes vagues telles que « modèle sûr » et « modèle dangereux ». Il incite les équipes à tracer chaque chemin depuis la décision d’un agent jusqu’à une conséquence réelle.

Donnez à chaque agent une identité et un mandat restreint

Un agent ne devrait jamais s’exécuter sur le compte d’un développeur ni hériter de tout ce qu’un utilisateur humain est autorisé à faire. Une identité partagée efface l’attribution. Des identifiants à longue durée de vie donnent plus de temps à un attaquant pour les exploiter. Et des comptes de service larges permettent à un petit flux de travail d’explorer des données et des systèmes qu’il n’a pas à toucher.

Le NIST considère désormais l’identité des logiciels et des agents IA comme un problème d’architecture propre. Son document conceptuel se demande comment un agent peut prouver qu’il est autorisé à effectuer une action spécifique, comment l’identité d’un agent peut être rattachée à l’autorisation d’un humain, et comment les organisations peuvent conserver des enregistrements résistants à la falsification de ce qui était prévu et de ce qui s’est réellement produit. En pratique, cela conduit à une conception simple. Chaque agent reçoit une identité unique, un propriétaire (une personne ou une équipe), un but défini, et des autorisations limitées à la tâche qui lui est assignée.

Les identifiants doivent expirer rapidement et ne fonctionner que pour des ressources et des actions spécifiques. L’accès réseau doit partir d’une liste blanche stricte. Si un agent doit interroger une base de données approuvée, il ne doit pas non plus obtenir un shell général, un accès Internet ouvert, ou le pouvoir de créer de nouveaux identifiants. Et à mesure que le travail passe le long d’une chaîne d’agents et d’outils, l’autorité doit se restreindre à chaque étape, et non s’élargir.

Le NIST avertit également contre le partage d’identifiants et un accès excessivement large, et cet avertissement a du poids car les agents sont opportunistes. Si une voie est bloquée, ils peuvent essayer un autre outil, explorer leur environnement, ou tomber sur un jeton que quelqu’un a oublié. Les identifiants récupérés faisaient également partie de l’histoire de juillet. Le principe du moindre privilège maintient le rayon d’impact réduit lorsque la couche de raisonnement fait quelque chose que ses concepteurs n’avaient pas prévu.

Gardez l’autorisation en dehors de la boucle de raisonnement

Un agent peut recommander une action. Il ne devrait pas pouvoir décider s’il est autorisé à la réaliser. Cette décision relève d’une couche d’application distincte que l’agent ne peut ni réécrire, ni désactiver, ni contourner. Chaque appel d’outil doit apparaître sous forme de requête structurée : quel agent demande, quel humain l’a sponsorisé, quelle opération il souhaite, quelle cible il vise et quelles limites s’appliquent. La couche d’application autorise alors, bloque ou escalade la requête.

OWASP décrit une agence excessive comme un mélange de fonctionnalités inutiles, de permissions excessives et d’une autonomie trop grande. Ses directives préconisent des outils restreints, des permissions minimales, une autorisation au niveau du système en aval et l’approbation de l’utilisateur pour les actions à fort impact. Je pense que c’est exactement l’ordre correct. La règle doit être appliquée par celui qui possède les données ou exécute la transaction. Si un modèle indique qu’une action est approuvée, cette affirmation seule ne doit avoir aucun poids.

Cette séparation aide également à contrer les injections de prompt. Un e‑mail ou un document empoisonné peut orienter le raisonnement de l’agent, mais il ne peut pas élargir les autorisations de l’agent ni désactiver une porte de politique. Le modèle est libre de demander quelque chose d’interdit. Le système doit néanmoins répondre non.

Conservez l’approbation humaine pour les moments qui comptent

La révision humaine est indispensable lorsqu’une action ne peut pas être annulée, franchit une frontière organisationnelle, modifie des privilèges, divulgue des informations sensibles, déplace de l’argent ou touche un système de production. Demander une approbation à chaque étape routinière entraîne deux conséquences : des délais et des personnes qui apprennent à cliquer « approuver » sans lire. Le NIST nomme explicitement cette fatigue de consentement.

Une bonne demande d’approbation décrit l’action exacte en termes clairs, en précisant où elle se dirige et les paramètres pertinents. Elle doit provenir d’un système d’autorité, pas d’un texte rédigé par l’agent. L’approbation doit expirer rapidement et ne couvrir qu’une seule action. Si un détail matériel change, le système redemande l’approbation.

Les directives de sécurité des agents d’OWASP recommandent de tester si une action à fort impact peut être exécutée sans une approbation valide, non expirée et liée aux paramètres. Cette phrase vaut la peine d’être retenue. « OK pour continuer » est une approbation faible qui peut être donnée par un autre agent ou un acteur malveillant. « Transférer ce montant sur ce compte » ou « déployer ce changement dans cet environnement » est quelque chose que le système peut réellement vérifier au moment de l’exécution, et qu’un utilisateur comprend pleinement.

L’assurance d’identité humaine en direct est cruciale à ce point de contrôle. Une notification push ne prouve que quelqu’un ou quelque chose a cliqué sur un bouton. Des conceptions plus robustes exigent qu’une personne inscrite utilise une authentification à clé publique résistante au phishing, soutenue par une méthode de vérification biométrique locale. Les normes FIDO lient les identifiants à clé publique au service en ligne légitime et conservent les données biométriques sur l’appareil isolé de l’utilisateur. Bien utilisée, l’authentification matérielle offre une preuve bien meilleure que la bonne personne était réellement présente. Elle ne remplace pas la liaison de transaction, un affichage fiable ou l’application de politiques, cependant. Vous avez besoin que tous ces éléments fonctionnent ensemble.

Surveillez le comportement et préservez les preuves

On ne peut pas compter sur le prompt initial pour expliquer ce qui s’est passé au cours d’une longue exécution d’agent. Les équipes de sécurité ont besoin de télémétrie sur les appels d’outil, l’activité réseau, l’utilisation des identifiants, les décisions de politique, les approbations, les refus et les changements de périmètre. La surveillance doit comparer ce que l’agent a réellement fait avec la frontière déclarée pour cette exécution. Si un agent est assigné à analyser du code et commence à rechercher des identifiants externes ou à sonder un service non lié, cela doit déclencher une alerte.

Les journaux doivent contenir suffisamment de contexte pour reconstruire la chaîne d’actions sans divulguer de secrets en texte clair. Chaque enregistrement doit capturer la version de l’agent, son propriétaire, la personne ou le système qui a lancé l’opération, l’outil utilisé, l’action demandée, le résultat de la politique et toute autorisation humaine. Des enregistrements signés ou autrement résistants à la falsification rendent l’examen post‑action beaucoup plus crédible, surtout lorsque plusieurs agents et services sont impliqués.

Tout cela doit fonctionner à la vitesse de la machine. Personne ne surveillant un tableau de bord n’arrêtera des milliers d’appels qui se terminent en quelques secondes. Des contrôles automatisés doivent appliquer des limites de débit, détecter des séquences inhabituelles et suspendre les identifiants dès que le comportement dépasse un seuil défini. Ainsi, les enquêteurs humains obtiennent un incident contenu à analyser plutôt qu’une chasse sans fin.

Concevez le chemin d’arrêt avant le lancement

Toute mise en production d’un agent nécessite un moyen de l’arrêter qui supprime réellement la capacité. Demander à l’agent de s’arrêter ne suffit pas. Les opérateurs doivent pouvoir révoquer ses identifiants, couper son chemin réseau, tuer son environnement d’exécution et empêcher les actions en file d’attente de redémarrer. Pour les flux de travail à haute conséquence, si le service d’approbation ou de politique tombe, le système doit échouer en mode fermé.

Puis testez ce chemin sous pression. Mettez le service d’approbation hors ligne. Donnez à l’agent des instructions contradictoires. Faites pivoter un identifiant en plein milieu d’une exécution. Simulez un outil compromis et un approbateur qui ne répond jamais. Confirmez que l’action est bloquée et que vous disposez d’un enregistrement utile. Et refaites ces tests chaque fois que le modèle, le prompt, le connecteur, le système de mémoire ou le jeu d’autorisations change.

L’objectif est une autonomie responsable

Rien de tout cela n’est un argument contre les agents, et l’incident Hugging Face ne devrait effrayer personne au point de les écarter des agents utiles. Ce qu’il faut faire, c’est éliminer l’idée qu’une invite de sécurité combinée à de bonnes intentions suffit à garantir un déploiement fiable. Donnez aux agents la marge d’analyse, de préparation du travail et de gestion des tâches réversibles. Limitez leur autorité à provoquer des conséquences réelles, rendez‑la étroite, visible et appliquée par quelque chose d’autre que l’agent lui‑même.

Avant qu’un agent ne passe en production, les dirigeants doivent pouvoir répondre à une série de questions simples. Quels systèmes peut‑il atteindre ? Quels identifiants peut‑il utiliser ? Que peut‑il faire sans révision ? Qu’est‑ce qui déclenche l’escalade ? Comment l’approbateur voit‑il l’action exacte qui est approuvée ? quelles preuves seront laissées ? Et comment la sécurité peut‑elle arrêter immédiatement l’exécution ?

Si les réponses sont floues, l’agent dispose de plus d’autorité que l’organisation ne le réalise. L’architecture qui perdure associe les garde‑fous du modèle à l’identité, au moindre privilège, à l’application de politiques externes, à une approbation humaine sélective, à une télémétrie complète et à un mécanisme d’arrêt réellement efficace. Elle part d’une hypothèse honnête : les agents capables nous surprendront de temps à autre. Nos limites de sécurité ne devraient pas.

En fin de compte, pensez à un agent IA comme à un stagiaire disposant (potentiellement) d’un accès root qui n’a pas peur des RH.

Quelles protections et quels garde‑fous auraient-ils ?

Agissez en conséquence.