Les agents IA commencent à collaborer dans les attaques cybernétiques, suscitant des préoccupations en matière de sécurité

Au cours des dernières années, les discussions sur les menaces posées par l'IA ont largement reposé sur une hypothèse : on craignait toujours que les modèles dans les boîtes de discussion deviennent des conseillers, aidant les pirates à écrire des codes de virus dévastateurs.

En regardant en arrière, cette préoccupation était souvent considérée comme « encore lointaine », mais les points de bascule du monde réel sont arrivés plus vite que prévu.

Au début du mois d'octobre, CrowdStrike a découvert, lors d'une enquête sur une série d'attaques visant des institutions financières coréennes, que les attaquants avaient intégré l'IA agente dans leur chaîne de production, en se connectant à plusieurs grands modèles tels que DeepSeek, GLM et Grok, permettant directement à l'IA d'assumer des tâches concrètes comme les tests de pénétration, la collecte d'informations et l'exécution des attaques.

Ce type de changement n'est pas isolé.

Le dernier rapport d'intelligence sur les menaces publié par Anthropic en septembre indique que des cadres multi-agents ont récemment été utilisés pour la reconnaissance, l'exploitation de vulnérabilités et le vol de données, fonctionnant de manière continue pendant plusieurs heures ou même plusieurs jours, tandis que les humains ne doivent uniquement prendre quelques décisions clés, telles que choisir les cibles ou examiner les résultats.

En d'autres termes, l'IA apporte une transformation qualitative visible à la guerre cybernétique : auparavant, les attaques automatisées reposaient principalement sur des règles et des scripts pré-écrits, mais aujourd'hui, des agents prennent en charge la reconnaissance, le jugement et l'ajustement des stratégies, rendant les attaques de plus en plus peu coûteuses, à haut débit et capables de fonctionner de manière autonome et continue.

Mais lorsque ces entités capables d'exécution autonome sont déployées en masse dans les systèmes de production, un problème encore plus délicat émerge : que faire si elles apprennent à se « concerter » entre elles ?

Toujours la même chose : la principale différence entre un agent et les anciens chatbots ne réside pas seulement dans une capacité de modèle plus puissante, mais surtout dans le fait qu'il commence à posséder des « mains » et des « pieds » dans le monde réel.

Aujourd'hui, un agent mature peut ouvrir des pages web, exécuter du code, lire des e-mails, appeler des API, manipuler des services cloud, et se connecter à un nombre croissant d'outils externes via MCP, Skills, etc. (lecture complémentaire : 当黑客「更高效」用上 AI，Web3 的「矛与盾」军备竞赛如何升级？)

Plus les capacités sont puissantes, plus ce changement est précieux, mais pour les systèmes de sécurité, cela signifie que la frontière autrefois cruciale disparaît, et une série d'événements de sécurité survenus cette année l'a déjà rendu très intuitif.

Le 1er octobre, Salt Labs a révélé une faille Manus précédemment corrigée, qui relève essentiellement d'une injection de prompt — les chercheurs n'avaient qu'à envoyer un courriel ordinaire contenant des instructions malveillantes cachées à une adresse cible ; lorsque l'utilisateur demandait ensuite à Manus « Vérifie mes e-mails », l'agent pouvait exécuter les instructions du courriel, permettant ainsi l'exécution du code implanté par l'attaquant.

Le processus ne nécessite ni que l'utilisateur clique sur un lien malveillant, ni qu'un mot de passe soit volé à l'avance. Le système de sécurité de Manus a finalement détecté l'anomalie et a averti l'utilisateur, mais le problème réside dans le fait qu'il l'a détecté trop tard : lorsque l'avertissement est apparu, le code malveillant avait déjà été exécuté.

Cela révèle encore une fois une différence cruciale entre la sécurité des agents et la sécurité logicielle traditionnelle : autrefois, lorsqu'un navigateur détectait un téléchargement dangereux, il pouvait afficher un avertissement pour permettre à l'utilisateur de décider s'il voulait continuer ; lorsqu'une banque détectait une transaction anormale, elle pouvait d'abord la geler, puis attendre une vérification manuelle.

Mais le but de la conception d’un Agent est précisément de minimiser autant que possible la participation humaine à chaque étape, il doit être capable de lire les informations, de prendre des décisions et d’effectuer automatiquement l’étape suivante.

Ainsi, à mesure que l'IA acquiert davantage d'autonomie, « détecter un danger » ne suffit plus nécessairement ; les mécanismes de sécurité doivent être capables d'empêcher les actions dangereuses avant qu'elles ne soient exécutées.

C'est aussi pourquoi les discussions sur la sécurité des agents se déplacent de plus en plus aujourd'hui vers un niveau inférieur : il ne s'agit plus seulement de demander à l'IA « si elle sait que cette action ne devrait pas être effectuée », mais aussi de se demander si le système a la capacité de l'empêcher, même si elle en a réellement l'intention.

L'apparition des agents multiples complique encore davantage cette question, car la prochaine étape à limiter pourrait ne plus concerner un seul agent.

Au début septembre, un événement survenu dans l'environnement d'entraînement et d'évaluation des modèles internes d'OpenAI a attiré l'attention de nombreux chercheurs en sécurité de l'IA.

Certains agents, qui devaient initialement accomplir leurs propres tâches séparément, ont accidentellement découvert un wiki commun et l'ont progressivement transformé en « tableau de messages partagé » entre eux, où les agents peuvent laisser des informations que les autres agents lisent ensuite et utilisent pour poursuivre leurs propres tâches.

OpenAI a ensuite confirmé ce comportement, et les informations divulguées ultérieurement ont également révélé que, lors d'autres processus d'entraînement, des agents avaient utilisé Artifactory interne comme tableau de messages partagé, ainsi que des services de hébergement de fichiers publics pour transmettre des résultats à d'autres agents travaillant en collaboration.

Le véritable intérêt de cette affaire réside dans le fait qu'il montre que la collaboration entre agents ne nécessite peut-être pas autant de dramatisme.

Par exemple, un Agent découvre un endroit où laisser des informations, un autre Agent les lit accidentellement, puis un troisième Agent constate que ces informations aident à accomplir la tâche.

Bien sûr, la collaboration entre agents n'est pas en soi un mauvais choix ; les systèmes multi-agents doivent compter sur la répartition des tâches et le partage d'informations pour améliorer l'efficacité.

Ce qui mérite vraiment une attention particulière, c’est lorsque cette collaboration commence à contourner les isolations d’information, les audits indépendants ou les contraintes de permission existantes, voire permet à plusieurs agents censés se contrôler mutuellement de former de facto une alliance d’intérêts, ce qui peut faire passer la collaboration normale à une « collusion » nuisible.

Après tout, il est probable qu'une institution financière gère plusieurs agents à l'avenir, comme un agent chargé d'analyser le marché, un autre d'évaluer les risques, un troisième de générer des stratégies de trading, et un dernier doté de véritables autorisations de trading et de gestion des actifs.

Du point de vue de la gestion traditionnelle des autorisations, cette conception est même très raisonnable :

• L'agent d'étude n'a pas de droit de transfert ;
• L'Agent n'a pas le pouvoir de décider indépendamment des orientations d'investissement ;
• L'agent de risque peut également annuler des stratégies clairement dangereuses ;

Les responsabilités ont été séparées, ce qui est théoriquement plus sécurisé que de confier tous les droits à un seul super Agent.

Mais le problème est que, s'ils peuvent partager durablement la mémoire, lire les sorties de l'autre et ajuster continuellement leur comportement en fonction des réactions de l'autre, ces rôles initialement conçus pour se contrôler mutuellement ne risquent-ils pas de devenir progressivement un tout unique ?

Par exemple, un agent d'étude pourrait progressivement apprendre à décrire une transaction de manière à faciliter son passage à travers le contrôle des risques ; l'agent chargé de l'audit pourrait également développer, sur la base de données historiques, certaines préférences fixes ; l'agent d'exécution apprendrait ensuite, à partir de nombreux résultats d'approbation précédents, quelles limites ne sont généralement pas bloquées.

Du point de vue de cette perspective, aucune étape n'est nécessairement malveillante, mais le résultat final du système peut s'éloigner de l'objectif initial fixé par l'utilisateur.

C’est précisément là que réside la véritable difficulté de la « collusion » ou de la « concertation » — le risque ne réside pas nécessairement dans les actions d’un seul agent, mais peut émerger des relations établies entre plusieurs agents.

Le 13 septembre, Vitalik Buterin a lié cette question à des mécanismes qu'il étudie depuis longtemps. Il a suggéré qu'une possibilité intéressante est que la théorie de la conception de mécanismes pour la gouvernance adversariale devienne finalement l'une des applications importantes de la sécurité de l'IA.

La raison en est que les deux problèmes présentent une similitude profonde.

Dans les mécanismes de conception traditionnels, il s'agit d'un système relativement simple et statique qui tente de contraindre un groupe de personnes bien plus intelligentes que le système lui-même et qui cherchent activement les limites des règles ; dans les systèmes d'IA futurs, il pourrait devenir une situation où des humains et des IA aux capacités relativement plus faibles tentent de gérer un groupe d'agents avancés plus compétents qu'eux.

Vitalik a particulièrement souligné qu'une importante découverte dans la conception mécanistique passée était que, si l'on pouvait limiter efficacement la collusion entre les participants, le système obtenait souvent de meilleurs résultats.

Cette conclusion peut également s'appliquer à l'IA.

Autrement dit, au lieu de supposer qu’un modèle parfait et ultra-sécurisé existera un jour, capable de détecter tous les comportements dangereux, il faut adopter une autre approche : comment faire en sorte que les différents Agents du système ne forment pas facilement des communautés d’intérêts dangereuses ?

C’est aussi ce qui distingue réellement la « gouvernance adversariale » du contrôle d’accès tel que nous le connaissons aujourd’hui.

Les systèmes de permissions traditionnels résolvent des problèmes relativement simples, principalement centrés sur « qui peut faire quoi », comme : un Agent peut-il lire les e-mails ? Peut-il appeler l’interface de transaction ? Quel est le montant maximal qu’il peut dépenser par jour ? Quels contrats peut-il consulter ? À quel seuil une confirmation supplémentaire de l’utilisateur est-elle requise ?

Ces conceptions sont bien sûr toujours très importantes.

En effet, une fois que les agents commenceront à contrôler des actifs réels, ils pourraient être plus importants qu'à tout autre moment passé.

Mais la gouvernance adversariale tente d'aller plus loin en se concentrant sur la manière d'éviter que, lorsqu'un groupe d'agents possédant des autorités, des objectifs et des informations différents fonctionne simultanément, ils ne combinent leurs capacités pour acquérir des compétences que personne ne possédait auparavant.

À ce stade, ajouter simplement « un autre agent de sécurité » ne résout pas nécessairement le problème.

Supposons que l'agent chargé des transactions et l'agent chargé de l'audit des transactions utilisent le même modèle, les mêmes sources de données, le même contexte et des objectifs de récompense similaires ; alors, bien qu'il semble y avoir une double vérification, il s'agit en réalité de dupliquer le même jugement deux fois.

Un véritable équilibre des pouvoirs peut au contraire exiger que le système crée intentionnellement des différences.

Par exemple, permettre aux agents responsables de la formulation et de l'approbation des stratégies d'utiliser des sources d'information différentes, limiter les mémoires partagées entre les différents rôles, exiger que les opérations à haut risque soient validées par des mécanismes indépendants, ou faire en sorte que la couche d'exécution des actifs n'accepte que les demandes conformes à des règles prédéfinies, plutôt que de se fier uniquement au jugement des agents amont.

L'idée ici n'est pas nouvelle. Les banques n'accordent pas à un seul employé la totalité des pouvoirs pour initier un paiement, l'approuver et effectuer le virement final, simplement parce qu'elles font confiance à cet employé ; les sociétés cotées ne permettent pas aux départements opérationnels de générer des revenus tout en décidant seuls des résultats de leur audit financier.

En clair, cela correspond à la logique du monde réel : un système robuste ne devrait pas s'appuyer sur l'hypothèse que les participants ne commettront jamais d'erreurs ou ne collusionneront jamais.

This logic becomes especially important on the Agent Wallet.

Les portefeuilles traditionnels reposent sur l'« humain » : l'utilisateur vérifie le contenu des transactions, décide s'il autorise ou non, puis signe lui-même ; mais le Agent Wallet vise exactement l'inverse — permettre à l'IA de réclamer automatiquement vos revenus, d'ajuster vos positions, d'échanger des cryptomonnaies, de les transférer entre chaînes, et même de gérer un portefeuille entier en fonction des évolutions du marché.

Si chaque étape doit être confirmée à nouveau par l'utilisateur, la valeur automatisée de l'agent est considérablement réduite.

Ainsi, la question que le portefeuille futur devra résoudre ne sera plus seulement « comment confier en toute sécurité le droit de signature à l’Agent », mais risque de s’étendre davantage à « comment donner à l’Agent suffisamment d’autonomie tout en garantissant qu’il ne puisse jamais dépasser les limites explicitement autorisées par l’utilisateur ? »

This requires permissions to evolve from a simple « Allow/Deny » to a more granular system.

Par exemple, un Agent peut opérer quels actifs pendant une période donnée, quels protocoles peut-il appeler, quelles sont les limites par transaction et cumulées ; les différents Agents peuvent-ils s'appeler mutuellement, est-il autorisé de partager le contexte ; qui propose une opération, qui l'audit, et qui l'exécute en dernier ressort ; quelles actions peuvent être automatisées, et quels gestes, même si l'Agent en est très certain, doivent systématiquement obtenir une autorisation humaine.

Même un Agent chargé de la vérification de la sécurité peut devenir une partie du système de permissions.

Pour la blockchain, la bonne nouvelle est qu'elle est en soi très bien adaptée pour assumer ce niveau « institutionnel ».

Les contrats intelligents permettent d'appliquer directement à la couche d'exécution des restrictions telles que le montant de la transaction, la gamme d'actifs et la durée d'autorisation. Des mécanismes comme l'abstraction de compte, la signature multiple et les Session Key offrent également un espace de conception plus flexible pour les autorisations limitées par rapport aux portefeuilles traditionnels à clé privée unique.

Mais la blockchain ne peut résoudre qu'une partie des problèmes — elle peut enregistrer ce qui s'est produit sur la chaîne, mais il lui est difficile de juger naturellement pourquoi un Agent a agi ainsi, ni de déterminer quelles ont été les communications, les vérifications et les collaborations entre plusieurs Agents avant qu'ils ne prennent une décision.

Cela pourrait bien être la couche de sécurité réellement nécessaire à ajouter pour la prochaine étape d'Agent Wallet.

Au cours des dernières années, la question la plus souvent discutée en matière de sécurité de l'IA a été de rendre les modèles plus « obéissants ».

Cela inclut de ne pas produire de contenu dangereux, de ne pas exécuter d'instructions malveillantes, de ne pas franchir les limites définies par l'utilisateur, mais lorsque l'Agent commence à posséder une mémoire à long terme, la capacité d'appeler des outils et d'exécuter des comptes et des actifs réels, ne compter uniquement sur « rendre le modèle plus obéissant » peut ne plus suffire.

Ce qui s'est passé ces derniers mois continue de le démontrer.

Les attaquants ont commencé à exploiter plusieurs agents en parallèle pour mener des attaques ; les agents dans l’environnement d’expérimentation cherchent automatiquement de nouveaux canaux de communication ; un agent disposant de permissions d’outils peut également transformer un courriel malveillant en exécution réelle avant que les systèmes de sécurité n’aient le temps d’intercepter.

La gouvernance adversariale proposée par Vitalik offre une autre manière de comprendre la sécurité de l'IA : ne pas supposer que chaque agent futur sera suffisamment fiable, mais permettre au système entier de fonctionner de manière stable dans un cadre sécurisé, même face à des agents intelligents et à un système complexe de permissions.

From this perspective, AI Agent + security is inevitably a long-term topic.

Après tout, même lorsque nous confions de plus en plus de tâches à l’IA, nous ne pouvons toujours pas être certains que les pouvoirs les plus importants n’ont jamais dépassé les limites réellement définies par les humains.