Un préprint met le doigt sur un angle mort des agents IA en sécurité
Un nouvel article publié sur arXiv, intitulé « An Organization-Scoped LLM Agent Runtime Architecture for Regulated Cybersecurity Operations », propose une architecture d’exécution pour agents LLM conçue spécifiquement pour les opérations de cybersécurité réglementées. Le texte, signé par George Fatouros, Georgios Makridis, George Kousiouris, John Soldatos et Dimosthenis Kyriazis, est un préprint : il n’a donc pas encore été évalué par les pairs. Il faut le lire comme une proposition d’architecture et non comme une preuve expérimentale définitive.
Son intérêt est toutefois majeur. Les auteurs ne cherchent pas à démontrer qu’un modèle de langage peut mieux classer une alerte, résumer un incident ou produire un rapport. Leur question est plus fondamentale : comment empêcher un agent LLM de sortir du périmètre opérationnel, juridique et documentaire de l’organisation qui l’emploie ?
Dans un centre des opérations de sécurité, un agent IA n’est pas un simple assistant de rédaction. Il peut interroger un SIEM, enrichir une alerte XDR, consulter des actifs, corréler des journaux, générer une conclusion de conformité, suggérer une réponse ou préparer un rapport qui engage l’entreprise. Dès lors, le problème n’est plus seulement la qualité de la réponse. C’est la capacité du système à prouver que chaque récupération d’information, chaque appel d’outil, chaque souvenir persistant et chaque recommandation sont restés dans le périmètre autorisé.
Le cœur de la proposition : un « Security Context » typé
L’architecture décrite dans le préprint repose sur une idée centrale : créer un contexte de sécurité typé à chaque point d’entrée du système. Ce contexte accompagne ensuite l’agent à travers tous les composants : récupération documentaire, appels d’outils, mémoire, sous-agents spécialisés, constats, rapports et audit.
Autrement dit, l’agent ne devrait jamais « décider » seul ce qu’il a le droit de consulter ou d’exécuter. Le runtime doit transporter et faire respecter des attributs comme l’organisation, l’unité d’affaires, le niveau de classification, le type d’incident, la juridiction applicable, le rôle de l’analyste, les autorisations temporaires et les limites de diffusion.
La différence avec beaucoup de prototypes actuels est nette. Dans un agent classique, le modèle reçoit une instruction, récupère du contexte, choisit un outil et produit une sortie. Dans l’approche proposée, chaque frontière de composant devient un point d’application de politique. Une requête vers le SIEM, une recherche dans une base de connaissance, une écriture en mémoire ou la génération d’un rapport doit être validée contre le Security Context.
Les auteurs décrivent aussi une couche d’adaptation des outils, un noyau d’exécution partagé, des sous-agents logiques spécialisés, des constats structurés avec références de preuve, des seuils d’approbation humaine et un journal d’audit append-only. Le choix est intéressant : l’architecture se veut indépendante du modèle et déployable localement, ce qui répond directement aux contraintes de secteurs comme la finance, la défense, la santé ou les infrastructures critiques.
Pourquoi le périmètre organisationnel devient le vrai pare-feu
Le concept rappelle le Zero Trust du NIST, mais appliqué à l’agent LLM. Dans le NIST SP 800-207, la confiance implicite doit être remplacée par une décision d’accès granulaire et continue. Transposé aux agents, cela signifie que le modèle ne doit pas recevoir un « super-pouvoir » global sous prétexte qu’il agit pour un analyste authentifié.
C’est précisément là que de nombreux déploiements d’IA en cybersécurité restent fragiles. Les entreprises connectent rapidement des modèles à des sources internes, puis ajoutent des outils : tickets, EDR, CMDB, scanners, dépôts de code, messagerie, bases de politiques. Mais si l’agent partage la session, les droits ou les secrets d’un utilisateur sans réduction de privilège, il devient une surface d’attaque à haute valeur.
Le risque n’est pas théorique. Le National Cyber Security Centre britannique explique que les LLM ne séparent pas intrinsèquement les données des instructions. Une consigne malveillante cachée dans un courriel, un ticket, une page Web ou un document récupéré peut influencer le comportement du modèle. Le NCSC qualifie ce type de système de « deputy » intrinsèquement confusable : un composant privilégié qui peut être amené à agir au bénéfice d’un attaquant.
OWASP place d’ailleurs la prompt injection au premier rang de ses risques pour applications LLM, aux côtés de la divulgation d’information sensible, de l’excessive agency, des faiblesses des bases vectorielles et de la fuite de prompt système. Pour un agent SOC, l’excessive agency est particulièrement dangereuse : le modèle peut techniquement utiliser des outils autorisés, mais dans une séquence non prévue, avec un périmètre trop large ou un effet de bord non auditable.
De la sécurité du modèle à la sécurité du runtime
Les travaux de Microsoft sur la défense contre la prompt injection indirecte vont dans le même sens : il faut combiner des défenses probabilistes et déterministes. Les filtres, Prompt Shields, critiques d’agent ou techniques de marquage de données peuvent réduire le risque. Mais les garanties fortes viennent surtout de l’architecture : isolation du contenu non fiable, analyse de chaîne d’outils, contrôle de flux d’information, privilèges courts et approbation humaine pour les actions sensibles.
C’est ici que le préprint arXiv apporte une pièce conceptuelle utile. Il ne prétend pas résoudre la prompt injection au niveau du modèle. Il propose plutôt de déplacer la garantie vers le substrat d’exécution. Le modèle peut être remplaçable, perfectible ou faillible ; le runtime, lui, doit appliquer les règles d’organisation.
La même logique se retrouve dans les recommandations récentes des agences Five Eyes sur l’adoption prudente des services d’IA agentique, publiées par les agences de cybersécurité d’Australie, des États-Unis, du Canada, de Nouvelle-Zélande et du Royaume-Uni. Ces recommandations insistent sur les risques de privilège, de conception, de comportement, de structure et de responsabilité. Elles appellent à limiter les droits, compartimenter les composants, journaliser les actions et maintenir une visibilité opérationnelle.
AWS, dans ses recommandations sur les systèmes agentiques, insiste également sur l’identité propre des agents, les autorisations de moindre privilège, la traçabilité des chaînes de délégation et l’audit des actions. Le message commun est clair : un agent n’est pas seulement une interface conversationnelle, c’est un acteur logiciel qui doit avoir une identité, un périmètre, des droits, des limites et des preuves.
MCP, outils et mémoire : les nouveaux points de fuite
Le Model Context Protocol illustre bien le dilemme actuel. MCP standardise la façon dont les applications LLM se connectent à des ressources, prompts et outils. C’est une avancée pour l’interopérabilité, mais aussi une expansion de la surface d’attaque. La spécification MCP elle-même rappelle que les outils peuvent représenter des chemins vers l’exécution de code et que les hôtes doivent obtenir un consentement explicite avant l’invocation d’outils.
Dans la version plus récente de ses mécanismes d’autorisation, MCP introduit des exigences autour d’OAuth, de la validation d’audience des jetons et de l’interdiction du token passthrough. Ce sont des fondations nécessaires, mais insuffisantes pour un environnement réglementé. Un agent SOC doit aussi savoir si une donnée récupérée appartient à la bonne entité juridique, si elle est couverte par une règle de résidence, si elle peut être incluse dans un rapport, ou si elle doit être masquée avant d’être exposée à un sous-agent.
La mémoire est un autre point critique. Une mémoire d’agent contaminée peut réintroduire plus tard des instructions, hypothèses ou données qui n’auraient plus dû être disponibles. Dans un runtime borné à l’organisation, la mémoire doit être partitionnée, datée, classifiée, révocable et auditable. Elle ne doit jamais devenir un entrepôt implicite où se mélangent clients, filiales, incidents, juridictions et niveaux de sensibilité.
Ce que cela change pour les SOC réglementés
Pour les équipes de cybersécurité, la conséquence est pratique : avant de demander quel modèle utiliser, il faut demander quel runtime l’encadrera. Un agent LLM utilisable dans un SOC réglementé devrait répondre à plusieurs exigences minimales.
D’abord, toutes les entrées doivent créer un contexte de sécurité explicite, y compris les alertes SIEM et XDR. Ensuite, la récupération documentaire doit être filtrée par politique, et pas seulement par similarité vectorielle. Les appels d’outils doivent être typés, limités, journalisés et soumis à des seuils d’approbation. La mémoire doit être compartimentée. Les rapports doivent citer des preuves internes traçables plutôt que produire une synthèse libre. Enfin, l’audit doit permettre de reconstruire la chaîne complète : données vues, outils appelés, décisions prises, humains ayant approuvé, versions de modèle et politiques appliquées.
C’est aussi un enjeu de conformité. Le NIST AI RMF et son profil pour l’IA générative insistent sur la gouvernance, la mesure, la gestion des risques, la confidentialité, la sécurité de l’information et la traçabilité. Mais ces cadres restent généraux. Le défi des prochains mois sera de traduire ces principes en mécanismes exécutables dans les plateformes d’agents.
Prospective : vers un « Kubernetes de la confiance agentique » ?
L’absence d’un substrat d’exécution standardisé pour agents LLM est aujourd’hui un angle mort critique. Les entreprises disposent de SIEM, d’IAM, de DLP, de CASB, de SOAR et de journaux d’audit, mais elles n’ont pas encore l’équivalent mature d’un plan de contrôle pour agents IA. C’est ce vide que le préprint arXiv met en évidence.
À terme, les déploiements sérieux pourraient ressembler à une couche d’orchestration spécialisée : identités d’agents, politiques déclaratives, isolation par contexte, attestations d’outils, mémoire gouvernée, approbations humaines, observabilité et preuves exportables pour l’audit. Les modèles deviendraient des moteurs interchangeables à l’intérieur d’un cadre plus strict, plutôt que le centre de gravité de toute la sécurité.
La limite de la proposition est évidente : elle reste conceptuelle et doit être testée sur des environnements réels, avec des SIEM, XDR, politiques internes et contraintes réglementaires hétérogènes. Son biais est celui d’un papier d’architecture : il formalise un besoin et propose une voie, mais ne démontre pas encore une adoption industrielle ni une résistance exhaustive aux attaques.
Mais son apport est précieux. Il rappelle que la sécurité des agents LLM ne se gagnera pas seulement avec de meilleurs prompts, de meilleurs classificateurs ou de meilleurs modèles. Elle exigera des runtimes capables de faire respecter, techniquement et auditablement, une frontière que le langage naturel ne garantit pas : celle de l’organisation.