Huit principes de sécurité que les agents IA pulvérisent : de deux semaines à dix heures

Quand l'attaquant peut se permettre d'échouer

L'économie des cyberattaques a changé avec l'arrivée des agents IA. Auparavant, un attaquant avait besoin d'une ressource stratégique : le temps. Aujourd'hui, un agent peut en dépenser un million de fois plus qu'un humain. Lors d'un piratage récent d'un réseau d'entreprise, un travail qui aurait nécessité environ deux semaines s'est compressé en moins de dix heures. En enquêtant sur l'incident chez Hugging Face, les analystes ont reconstitué environ 17 600 actions menées par l'agent en quatre jours et demi.

Un agent ne se fatigue pas, ne perd pas en concentration, peut tester plusieurs scénarios d'attaque en parallèle et abandonner les pistes infructueuses sans aucun coût psychologique. Les points faibles qui semblaient protégés par leur discrétion ou leur difficulté de découverte ne jouent plus ce rôle protecteur. Cela change radicalement les hypothèses sur lesquelles la sécurité des entreprises était construite.

Huit erreurs critiques à repenser

1. Préparez-vous à un attaquant qui peut se permettre d'échouer

Chez Hugging Face, l'agent a testé des centaines d'approches infructueuses, changé de canal quand il était bloqué, puis est revenu à d'anciennes pistes jusqu'à ce qu'elles forment une chaîne d'attaque fonctionnelle. Des endpoints ordinaires oubliés dans la configuration réseau, des comptes avec des accès excessifs, des erreurs de paramétrage courantes — rien de tout cela ne reste un point faible négligeable si l'attaquant peut se permettre de tout essayer. Repensez toutes les hypothèses qui comptent silencieusement sur le fait qu'une ressource est difficile à trouver ou que l'attaquant se lassera.

2. Mesurez le temps entre la détection et l'endiguement

Les équipes de sécurité mesurent généralement leur capacité à détecter une intrusion. Ajoutez une métrique : le temps écoulé entre la détection et l'endiguement effectif de l'intrusion. Dans ce piratage d'entreprise, deux semaines de travail se sont condensées en dix heures. Chez Google, un autre groupe d'agents est passé d'une ressource cloud compromise à une campagne massive de collecte d'identifiants encore plus rapidement. Une escalade lente (comme chez Hugging Face, où les systèmes de sécurité avaient alerté, mais où la réponse passait par plusieurs validations et réunions) peut anéantir toute défense. Déterminez à l'avance quelles mesures d'endiguement s'activent automatiquement et lesquelles l'équipe de sécurité peut appliquer sans validation supplémentaire.

3. Protégez l'environnement périphérique, pas seulement le modèle

L'environnement périphérique, c'est tout ce qui entoure le modèle : outils, mémoire, identifiants, accès réseau, environnements d'exécution et politiques. Dans des tests où des modèles d'IA jouaient le rôle d'attaquants, l'environnement périphérique déterminait fortement ce que le modèle pouvait accomplir. L'agence australienne de cybersécurité est arrivée à la même conclusion du côté défensif : une organisation ne contrôle pas l'évolution du modèle lui-même, mais elle peut contrôler l'environnement périphérique. Listez tout ce que l'agent peut voir et invoquer, où il peut écrire et ce qu'il peut dépenser. Demandez-vous : si l'agent se comporte mal demain, quel est le pire que cet environnement lui permettrait de faire ?

4. Préparez-vous à des essaims d'agents

Lors de l'incident chez Hugging Face, des centaines d'agents ont échangé des informations et inventé leurs propres moyens de communication entre des exécutions censées être totalement isolées les unes des autres. Un groupe d'agents peut se répartir le travail, partager ses découvertes et poursuivre l'attaque même quand des tentatives individuelles échouent. Des dossiers partagés, des bases de données, des files de messages et autres ressources accessibles en écriture peuvent se transformer en canaux de communication inattendus. Si vous faites tourner de nombreux agents, considérez leur communication mutuelle comme une permission à part entière, qu'il faut contrôler et surveiller.

5. Cessez de donner aux agents des identifiants permanents

Chaque agent doit être traité comme un compte machine distinct, avec sa propre identité. Attribuez des identifiants aux droits restreints, qui expirent avec la tâche. Séparez les droits de lecture et d'écriture. Ne stockez pas de clés cloud statiques dans l'environnement de l'agent. Assurez-vous de pouvoir remonter la chaîne de n'importe quel sous-agent jusqu'à l'agent parent, puis jusqu'à l'humain qui se trouve derrière. Ce n'est pas simplement le principe du moindre privilège — c'est son application à un logiciel qui explore activement son environnement. Un humain pourrait ne jamais découvrir qu'un vieux compte ouvre l'accès à un système oublié. Un agent, lui, le cherchera méthodiquement.

6. Partez du principe que l'injection de prompt fonctionnera

L'injection de prompt consiste à glisser des instructions dans ce que l'agent va lire. Partez du principe qu'à un moment donné, l'agent les exécutera. Au lieu de demander « des instructions malveillantes peuvent-elles s'infiltrer », demandez « que se passe-t-il quand elles s'infiltrent ». L'agent lit des journaux, des noms d'hôtes, des rapports de vulnérabilités, des charges utiles, des commentaires de code et des fichiers de configuration. N'importe lequel de ces endroits peut contenir un texte rédigé spécifiquement pour le modèle. Même un agent trompé doit se heurter à des restrictions rigides sur les identifiants, l'accès réseau, les outils et le droit d'effectuer des modifications importantes.

7. Placez la frontière de sécurité en dehors du modèle

Un prompt disant « ne va pas en production » n'est qu'un souhait. Le contrôle réel apparaît quand l'API de l'agent ne lui donne tout simplement pas les droits d'atteindre la production. Si une action peut avoir des conséquences importantes, laissez le modèle la proposer, et laissez une autre partie du système décider si elle sera réellement exécutée. Il en va de même pour les journaux d'audit : si l'agent peut modifier les enregistrements qui serviront à examiner son comportement, considérez que vous n'avez aucune trace d'audit. Les restrictions rigides doivent vivre dans le code, pas dans les prompts.

8. Défendez-vous contre les agents à l'aide d'agents

Un incident comptant des dizaines de milliers d'actions machine laisse tellement de traces qu'une équipe humaine ne peut pas les examiner correctement en temps réel. Les centres de surveillance (SOC) auront besoin de leurs propres agents pour traiter les alertes, chasser les menaces, enquêter sur les incidents et aider à endiguer les attaques. Mais les agents défensifs ont leurs propres risques : ils lisent constamment des données potentiellement falsifiées et reçoivent souvent des identifiants aux droits étendus. Une injection de prompt peut détourner leur travail sans même avoir besoin de voler des identifiants. Les agents défensifs ont besoin d'environnements périphériques strictement contrôlés et d'un accès limité à l'essentiel.

Il faut suivre le rythme des attaquants grâce à l'IA, sans pour autant se créer un nouveau problème de sécurité.