La menace cachée des agents IA exige un nouveau modèle de sécurité

Les systèmes d’IA agents sont devenus mainstream au cours de la dernière année. Ils sont maintenant utilisés pour plusieurs fonctions, notamment l’authentification des utilisateurs, le déplacement de capitaux, la déclenchement de flux de conformité et la coordination à travers les environnements d’entreprise avec une surveillance humaine minimale.

Cependant, un problème plus silencieux émerge avec l’autonomie croissante, non au niveau des invites ou des politiques, mais au niveau de la confiance infrastructurelle. Les systèmes agents sont dotés d’une autorité interne alors qu’ils s’exécutent sur des environnements de calcul qui n’ont jamais été conçus pour protéger les décideurs autonomes de l’infrastructure qui se trouve en dessous.

La sécurité traditionnelle suppose que les logiciels sont passifs, mais les systèmes agents ne le sont pas. Ils raisonnent, se souviennent et agissent en continu, de manière autonome et avec une autorité déléguée.

Il ne faut pas oublier que les agents IA ont probablement accès à des données personnelles, en fonction de leur cas d’utilisation, telles que des e-mails et des enregistrements d’appels, entre autres choses.

En outre, alors que les protections basées sur le matériel, telles que les machines virtuelles confidentielles et les enclaves sécurisées, existent, elles ne sont pas encore la fondation par défaut pour la plupart des déploiements d’IA agente. Par conséquent, de nombreux agents s’exécutent encore dans des environnements où les données sensibles sont exposées à l’infrastructure sous-jacente pendant l’exécution.

Les agents sont des insiders, pas des outils

Les équipes de sécurité savent déjà à quel point il est difficile de contenir les menaces internes, un problème mis en évidence dans le rapport de Verizon de 2025 sur les violations de données, qui montre que l’intrusion dans les systèmes a été responsable de plus de 53 % des violations confirmées l’an dernier. Dans 22 % de ces cas, les attaquants ont utilisé des informations d’identification volées pour accéder, ce qui montre à quel point ils réussissent souvent en utilisant des identités légitimes au lieu d’exploiter des failles techniques.

Maintenant, considérez un agent, qui est composé de logique d’invite, d’outils et de plugins, d’informations d’identification, ainsi que de politiques. Non seulement il peut exécuter du code et parcourir le Web, mais il peut également interroger des CRM, lire des e-mails et pousser des tickets, entre autres choses. Ce que la combinaison de fonctions a apporté, c’est les surfaces d’attaque traditionnelles dans une interface moderne.

Le danger posé par de telles menaces internes n’est pas spéculatif. Le projet Open Web Application Security (OWASP) liste maintenant l’injection d’invite comme une vulnérabilité critique pour les applications LLM, notant son danger particulier pour les systèmes agents qui enchaînent des actions. L’équipe de renseignement sur les menaces de Microsoft a également publié des avis warning que les systèmes d’IA avec un accès à des outils peuvent être détournés pour effectuer un vol de données si les garanties ne sont pas appliquées de manière architecturale.

Ces rapports offrent un rappel opportun que les agents qui ont un accès légitime aux systèmes et aux données peuvent être retournés contre leurs propriétaires. Cependant, le paysage des risques pour les systèmes agents n’est pas unitaire. Les menaces au niveau de l’application, telles que l’injection d’invite et l’abus d’outils, proviennent de l’incapacité du modèle à distinguer les instructions de confiance des entrées utilisateur non fiables, une limitation de conception que aucune durcissement de la mémoire ne peut réparer.

Un problème différent et tout aussi important existe au niveau de l’infrastructure : certains agents s’exécutent en mémoire en clair, ce qui signifie que les informations sensibles, telles que les historiques de chat, les réponses API et les documents, peuvent être vues pendant leur traitement et peuvent rester accessibles plus tard. OWASP identifie ce risque comme une divulgation d’informations sensibles (LLM02) et une fuite de invites de système (LLM07) et suggère d’utiliser l’isolement de contexte, la segmentation de namespace et le sandbox de mémoire comme mesures de sécurité importantes.

Ainsi, les utilisateurs ne devraient pas traiter ces agents comme de simples applications, étant donné qu’ils sont des exécuteurs dynamiques et raisonnables qui nécessitent un modèle de sécurité qui prend en compte leur nature unique en tant qu’entités non humaines avec une agence. Cette approche doit inclure à la fois des contrôles logiciels pour limiter la façon dont le modèle agit et des protections matérielles pour garder les données en sécurité pendant leur utilisation.

L’architecture de la confiance a une faille critique

Les pratiques de sécurité actuelles se concentrent sur la protection des données au repos et en transit. La dernière frontière, les données en cours d’utilisation, reste presque entièrement exposée. Lorsqu’un agent d’IA raisonne sur un jeu de données confidentiel pour approuver un prêt, analyser des dossiers de patients ou exécuter une transaction, ces données sont généralement déchiffrées et traitées en clair dans la mémoire du serveur.

Dans les modèles de cloud standard, quiconque a un contrôle suffisant sur l’infrastructure, y compris les administrateurs d’hyperviseur ou les attaquants co-locataires, peut potentiellement regarder ce qui se passe pendant l’exécution d’une charge de travail. Pour les agents d’IA, cette exposition est particulièrement dangereuse, puisqu’ils ont besoin d’accéder à des informations sensibles pour faire leur travail, ce qui peut potentiellement devenir la surface d’attaque.

Comme l’a démontré Lumia Security, les attaquants ayant accès à une machine locale peuvent obtenir des JWT et des clés de session directement à partir de la mémoire du processus des applications de bureau ChatGPT, Claude et Copilot. Ces informations d’identification volées peuvent leur permettre de se faire passer pour un autre utilisateur, de voler l’historique des conversations et d’injecter des invites dans des sessions en cours qui peuvent modifier le comportement de l’agent ou planter de fausses mémoires.

Un exemple de ceci pourrait être l’incident de dump de mémoire d’AWS CodeBuild en juillet 2025. Les attaquants ont ajouté secrètement du code malveillant à un projet, et lorsque le système l’a exécuté, le code a regardé dans la mémoire de l’ordinateur et a volé des jetons d’authentification cachés qui s’y trouvaient. Avec ces jetons, les attaquants pouvaient modifier le code du projet et potentiellement accéder à d’autres systèmes.

Pour les institutions financières, la manipulation silencieuse est existentielle. Les banques, les assureurs et les sociétés d’investissement absorbent déjà des coûts de violation de données d’environ 10 millions de dollars, et ils comprennent que l’intégrité est tout aussi importante que la confidentialité. Selon un rapport récent d’Informatica, le « paradoxe de confiance » a été expliqué comme suit : les organisations déployant des agents autonomes plus rapidement qu’elles ne peuvent vérifier leurs sorties. Le résultat est une automatisation qui peut intégrer des erreurs ou des préjugés directement dans les processus de base, fonctionnant à une vitesse de machine.

Le calcul confidentiel et le cas pour l’isolement

Les correctifs incrémentiels ne résoudront pas le problème en question, bien que des contrôles d’accès plus stricts et une meilleure surveillance puissent aider. Cependant, aucun des deux ne peut changer le problème sous-jacent. Le problème est architectural, et tant que le calcul se produit en mémoire exposée, les agents seront vulnérables au moment où ils comptent le plus, qui est la prise de décision.

Le calcul confidentiel, défini par le Consortium de calcul confidentiel (CCC) comme la protection des données en cours d’utilisation via des environnements d’exécution de confiance basés sur le matériel (TEEs), répond directement à la faille de base.

Pour les agents d’IA, cet isolement au niveau du matériel est transformateur, car il permet aux informations d’identification de l’agent, à ses poids de modèle, à ses invites propriétaires et aux données sensibles des utilisateurs qu’il traite de rester chiffrées, non seulement sur un disque ou sur un réseau, mais également activement en mémoire pendant l’exécution. La séparation brise définitivement le modèle traditionnel où le contrôle de l’infrastructure garantit le contrôle de la charge de travail.

L’attestation à distance fournit des preuves cryptographiques vérifiables qu’une requête d’inférence spécifique s’est exécutée à l’intérieur d’un environnement d’exécution de confiance basé sur le matériel, qu’il s’agisse d’un CPU ou d’un GPU. La preuve est générée à partir de mesures matérielles et livrée avec la réponse, permettant une vérification indépendante de l’endroit et de la manière dont la charge de travail a été exécutée.

Les enregistrements d’attestation ne révèlent pas le code qui a été exécuté. Au lieu de cela, chaque charge de travail est associée à un ID de charge de travail ou à un ID de transaction unique, et l’enregistrement d’attestation du TEE est lié à cet identifiant. L’attestation confirme que le calcul s’est exécuté à l’intérieur d’un environnement de confiance sans divulguer son contenu.

La configuration crée une nouvelle base pour la conformité et la traçabilité, permettant de relier les actions d’un agent à une version spécifique de code qui a été attestée et à un ensemble connu de données d’entrée.

Vers une autonomie responsable

Les implications du système décrit ci-dessus vont au-delà de la sécurité de base. Considérez les lois qui régissent la finance, les soins de santé et les informations personnelles. De nombreux pays appliquent des règles de souveraineté des données qui restreignent où les informations peuvent être traitées. En Chine, la loi sur la protection des informations personnelles et la loi sur la sécurité des données exigent que certaines catégories de données, telles que les données personnelles importantes, soient stockées sur le territoire national et examinées avant d’être transférées à l’étranger.

De même, plusieurs pays du Golfe, tels que les Émirats arabes unis et l’Arabie saoudite, ont adopté des approches similaires, en particulier pour les données financières, gouvernementales et d’infrastructure critique.

Le calcul confidentiel peut renforcer la sécurité et la traçabilité en protégeant les données pendant leur traitement et en permettant l’attestation de l’environnement d’exécution. Cependant, il ne modifie pas l’endroit où le traitement a lieu. Lorsque les règles de souveraineté des données exigent un traitement local ou imposent des conditions sur les transferts transfrontaliers, les environnements d’exécution de confiance peuvent prendre en charge les contrôles de conformité, mais ne remplacent pas les exigences légales.

En outre, le calcul confidentiel permet une collaboration sécurisée dans les systèmes multi-agents, où les agents de différentes organisations ou de différents départements doivent souvent partager des informations ou valider des sorties sans exposer des données propriétaires.

Et lorsque la technologie est associée à une architecture de confiance zéro, le résultat est une fondation beaucoup plus solide. La confiance zéro valide en continu l’identité et l’accès, tandis que le calcul confidentiel protège la mémoire du matériel contre les extractions non autorisées et empêche les informations sensibles d’être récupérées en clair.

Ensemble, ils défendent ce qui compte vraiment, par exemple la logique de décision, les entrées sensibles et les clés cryptographiques qui autorisent l’action.

Nouvelle base pour les systèmes autonomes

Si chaque interaction expose les gens à un risque, ils ne laisseront pas l’IA gérer des choses comme les dossiers médicaux ou prendre des décisions financières. De même, les entreprises n’automatiseront pas leurs tâches les plus importantes si cela peut entraîner des problèmes de réglementation ou la perte de données importantes.

Les constructeurs sérieux reconnaissent que les correctifs au niveau de l’application seuls sont insuffisants dans les environnements à haute assurance.

Lorsque les agents sont dotés d’une autorité financière, de données réglementées ou d’une coordination inter-organisationnelle, l’exposition au niveau de l’infrastructure devient plus qu’une préoccupation théorique. Et sans exécution confidentielle dans de tels contextes, de nombreux agents restent une cible molle, avec leurs clés volables et leur logique malléable. La taille des violations de données modernes montre exactement où mène ce chemin.

La confidentialité et l’intégrité ne sont pas des fonctionnalités optionnelles à ajouter après le déploiement. Elles doivent être conçues à partir du silicium. Par conséquent, pour que l’IA agente puisse évoluer en toute sécurité, la confidentialité renforcée par le matériel ne peut pas être considérée comme un simple avantage concurrentiel, mais comme la base.