Le guide de sécurité en cinq couches de Mend cible les risques de l’IA en production au-delà des garde-fous de prompts

Mend.io a publié une approche de sécurité en cinq couches qui a été relayée par Google News, mais son message central remet en question la manière dont de nombreuses équipes protègent l’IA en production. Les garde-fous de prompts ne suffisent pas à sécuriser des agents qui détiennent des identifiants, appellent des outils, conservent une mémoire et modifient des systèmes externes.

Le guide, couvert par MarkTechPost le 3 août, organise la surface d’attaque autour des couches d’interaction, d’agent, d’intégration, de modèle et de code. Sa valeur pratique tient à ce qu’il traite une application d’IA comme un système exécutable, et non comme un simple chatbot présentant des risques d’entrée inhabituels.

Cette distinction crée le véritable conflit. Les développeurs veulent que les agents accomplissent davantage de tâches avec moins d’interruptions. Les équipes de sécurité ont besoin de limites déterministes lorsque ces agents rencontrent des documents hostiles, des outils empoisonnés, des permissions excessives ou des chemins d’exécution inattendus.

MCP, abréviation de Model Context Protocol, fournit aux applications d’IA une interface standard permettant de découvrir et d’appeler des outils externes. Il peut connecter un modèle à des bases de données, des systèmes de fichiers, des API, des applications métier et des environnements de développement.

Le protocole améliore l’interopérabilité, mais cette commodité augmente le nombre de frontières de confiance au sein de chaque flux de travail. Un agent peut désormais transformer un texte non fiable en action lourde de conséquences en quelques secondes.

La question n’est plus de savoir si un modèle produit une réponse inappropriée. Il s’agit de déterminer si un modèle manipulé peut utiliser un outil autorisé à des fins non autorisées.

Google News met l’accent sur la sécurité de l’IA en production

L’événement important est le passage d’une discussion sur le comportement des modèles à la sécurisation de l’ensemble du chemin entre l’entrée et l’exécution.

Le guide de sécurité pour la production mis en avant par Google News présente la sécurité des agents comme un problème d’ingénierie à cinq couches. La couche d’interaction couvre les prompts, les documents récupérés, les fichiers utilisateurs et les autres informations entrant dans l’application.

La couche agent comprend la planification, la mémoire, la sélection d’outils et les tâches déléguées. La couche d’intégration couvre les serveurs MCP, les API, les bases de données, les plugins et les autres connexions qui transmettent les décisions de l’agent vers des systèmes externes.

La couche modèle comprend le modèle de langage, sa configuration et ses limites comportementales. La couche code comprend la logique applicative, les dépendances, l’infrastructure, les identifiants et les pipelines de déploiement.

Ce cadre est important, car les défaillances traversent souvent plusieurs couches. Une instruction malveillante peut entrer par un document, influencer le raisonnement du modèle, déclencher un outil MCP autorisé et exposer des données via une requête API ordinaire.

Chaque composant peut sembler fonctionner comme prévu. La défaillance de sécurité résulte de leur composition.

La sécurité applicative traditionnelle reste importante dans cette pile. Les équipes doivent corriger les dépendances, protéger les secrets, valider les entrées, isoler les charges de travail et réviser le code. Toutefois, ces contrôles n’expliquent pas pleinement pourquoi un agent a sélectionné un outil valide au mauvais moment.

Le modèle traite les instructions et les données à travers le même support fondamental. Une page récupérée peut contenir des informations répondant à la question d’un utilisateur, des instructions qui redirigent l’agent, ou les deux.

Cela crée une injection indirecte de prompts, dans laquelle des directives malveillantes arrivent par un contenu externe plutôt que par le prompt visible de l’utilisateur. Un agent qui lit des e-mails, des pages web, des tickets de support ou des documents internes peut rencontrer ce type de contenu dans le cadre de son travail normal.

L’attaque peut rester invisible pour la personne qui a lancé la tâche. L’agent peut résumer le document attendu tout en appelant discrètement un autre outil ou en intégrant des informations empoisonnées dans sa mémoire.

Le cadre en cinq couches de Mend.io sert donc de méthode d’inventaire. Il invite les équipes à identifier chaque point où des instructions, des autorisations, du code, des données et de l’état peuvent entrer dans le système ou en sortir.

Cet inventaire doit inclure plus que les modèles déployés. Il doit répertorier les configurations d’agents, les prompts système, les serveurs MCP, les outils disponibles, les périmètres de permission, les magasins de mémoire, les fournisseurs de modèles, les dépendances et les responsables désignés.

Sans cette cartographie, les équipes ne peuvent pas déterminer si un composant compromis peut en atteindre un autre. Elles ne peuvent pas non plus révoquer les accès avec confiance lorsqu’une intégration change de comportement.

L’événement n’est pas une nouvelle version du protocole ni une vulnérabilité unique divulguée. Il s’agit d’une frontière de production plus claire : la sécurité des agents doit couvrir l’ensemble de la chaîne d’exécution.

Cette frontière met simultanément sous pression les développeurs, les équipes de plateforme, les ingénieurs sécurité et les fournisseurs d’IA. Chaque groupe ne contrôle qu’une partie du système, tandis que les défaillances les plus graves traversent ces divisions organisationnelles.

Les agents IA transforment le langage en actions privilégiées

Un LLM devient un problème de sécurité matériellement différent lorsque sa sortie contrôle un logiciel doté d’une autorité réelle.

Un chatbot classique produit du texte qu’une personne peut examiner. Un agent peut interpréter un objectif, sélectionner un outil, construire des arguments, inspecter le résultat et continuer à agir sans nouvelle décision humaine.

Cette boucle modifie les conséquences d’une mauvaise réponse du modèle. Une phrase inventée est gênante, mais une instruction inventée transmise à une base de données ou à un outil de déploiement peut devenir un incident opérationnel.

Prenons un agent de recherche interne chargé de comparer des propositions de fournisseurs. Il lit des documents déposés, recherche dans le stockage partagé, interroge les dossiers d’achats et rédige une recommandation.

Une proposition malveillante peut dissimuler des instructions demandant à l’agent de récupérer des tarifs confidentiels dans un autre dossier. Si l’outil de stockage dispose de permissions étendues, la décision erronée du modèle devient une véritable voie de divulgation.

Un agent de programmation crée un problème similaire. Il peut lire des dépôts, installer des dépendances, exécuter des tests, modifier des fichiers et ouvrir des pull requests. Le texte non fiable d’une issue ou la documentation d’un package peuvent influencer le même modèle qui détient ces capacités.

MCP facilite la création cohérente de ces connexions. Cela profite aux développeurs, mais signifie également qu’une description d’outil, une réponse d’outil ou un serveur distant peut influencer les choix ultérieurs d’un agent.

Les recommandations de sécurité des agents de l’OWASP identifient l’injection de prompts, l’abus d’outils, l’exfiltration de données, l’empoisonnement de la mémoire, l’autonomie excessive et les défaillances en cascade parmi les principaux risques. Ces catégories sont liées, et non isolées.

La mémoire est particulièrement importante. La mémoire persistante d’un agent conserve des informations pour les sessions futures, ce qui permet à une application de retenir des préférences, des travaux antérieurs ou des connaissances accumulées.

Si du contenu non fiable entre dans ce stockage sans validation, une attaque peut survivre après la fin de la conversation initiale. Des utilisateurs ultérieurs peuvent recevoir des faits empoisonnés ou déclencher un comportement influencé par un document antérieur.

Les systèmes multi-agents augmentent le rayon d’impact potentiel. Un agent peut transmettre des instructions, des résumés, des identifiants ou des résultats d’outils à un autre agent disposant de permissions différentes.

Un agent de recherche compromis peut ne pas avoir d’accès en écriture à la base de données. Il pourrait néanmoins fournir des conclusions manipulées à un agent opérationnel qui, lui, y a accès.

Les équipes ne peuvent pas résoudre ce problème en demandant à chaque modèle d’ignorer les instructions malveillantes. Les modèles doivent traiter le langage naturel pour accomplir leur travail, et les attaquants peuvent varier la formulation, le contexte, l’encodage et les canaux de diffusion.

La cible de sécurité doit donc être la frontière d’action. Avant l’exécution d’un outil, un logiciel déterministe doit décider si l’agent, l’utilisateur, la ressource, l’opération et les paramètres constituent une combinaison autorisée.

Une opération de lecture ne doit pas devenir silencieusement une écriture. L’accès à un dépôt ne doit pas donner accès à tous les dépôts. L’autorisation de rédiger un e-mail ne doit pas permettre automatiquement son envoi.

Les opérations à fort impact exigent un traitement plus rigoureux. Les virements financiers, les modifications de production, l’administration des comptes, la suppression de données, la publication externe et l’accès aux identifiants doivent nécessiter une autorisation explicite ou une approbation humaine.

L’approbation doit être liée à l’action réelle. Une confirmation vague telle que « continuer » est moins robuste qu’une approbation affichant la destination, l’opération, la ressource concernée et les paramètres importants.

Les identifiants de courte durée réduisent également l’exposition. Un agent doit recevoir l’autorité minimale nécessaire à la tâche en cours et perdre cette autorité lorsque la tâche est terminée.

Cette approche peut ajouter de la friction, en particulier lorsque les développeurs mesurent le succès à l’aune de l’exécution des tâches et de la vitesse. Pourtant, l’alternative consiste à laisser un raisonnement probabiliste tenir lieu de système de contrôle d’accès.

Les modèles de langage peuvent proposer des actions. Ils ne doivent pas définir unilatéralement leur propre autorité.

MCP standardise les connexions, pas une gouvernance complète

MCP résout un problème de compatibilité, tandis que les équipes de production doivent toujours construire autour de lui la couche de politiques et de responsabilité.

Un client MCP peut récupérer les définitions des outils disponibles sur un serveur et les présenter à un modèle. Le modèle utilise ces descriptions et ces schémas de paramètres pour sélectionner et invoquer un outil.

Cette structure réduit le travail d’intégration sur mesure. Un client compatible peut se connecter à de nombreux serveurs via un protocole partagé, au lieu d’apprendre une interface distincte pour chaque service.

Cependant, une découverte standardisée ne rend pas chaque outil découvert digne de confiance. Un serveur peut être compromis, usurpé, mal configuré ou mis à jour après un examen de sécurité initial.

L’empoisonnement d’outils exploite cette confiance. Des instructions malveillantes placées dans la description d’un outil peuvent influencer le modèle tout en restant invisibles dans l’interaction ordinaire de l’utilisateur.

Une réponse d’outil peut contenir des instructions similaires. L’agent peut traiter cette réponse comme des données, mais le modèle de langage peut interpréter le texte intégré comme une directive affectant les actions ultérieures.

Les dernières règles d’autorisation MCP incluent des exigences portant sur la validation des jetons, la liaison à l’audience, le vol de jetons, la sécurité des communications, les risques de redirection et les attaques de type confused deputy.

Ces exigences renforcent les mécanismes d’authentification et d’autorisation. Elles ne déterminent pas si une action métier précise est appropriée au regard de l’objectif actuel de l’utilisateur.

Un jeton d’accès valide établit une autorité reconnue dans son périmètre. Il ne prouve pas qu’un modèle est parvenu à la bonne décision après avoir lu du contenu non fiable.

Les systèmes de production ont besoin d’un point de contrôle entre l’intention du modèle et l’exécution de l’outil. Cette couche peut évaluer l’identité, l’opération demandée, la ressource, les paramètres, le risque de session, la classification des données et les actions antérieures.

Microsoft a décrit cette lacune lors de la présentation d’une approche open source de gouvernance à l’exécution. Son benchmark interne de gouvernance a testé 60 prompts, dont 45 cas adversariaux et 15 cas valides.

Microsoft a rapporté un taux de violation des politiques de 26,67 % lorsque le système reposait uniquement sur des instructions de sécurité dans les prompts. L’entreprise a fourni la méthodologie et des éléments de reproduction, mais le résultat demeure sa propre évaluation.

Cette conclusion illustre néanmoins un principe de conception important. Les performances en matière de suivi d’instructions ne doivent pas être considérées comme une frontière de sécurité déterministe.

Un plan de contrôle à l’exécution peut autoriser, refuser ou faire remonter chaque demande d’outil. Il peut également inspecter les définitions d’outils avant de les exposer au modèle et analyser les réponses avant de les renvoyer à l’agent.

Une telle couche devrait imposer des schémas, des contraintes de paramètres, des listes de ressources autorisées, des limites de débit, des plafonds de coût et une profondeur maximale de chaîne. Elle devrait arrêter les échecs répétés au lieu de laisser un agent entrer dans une boucle de nouvelles tentatives incontrôlée.

Par exemple, un agent de support client peut avoir besoin de consulter le dossier d’un compte et de préparer une recommandation de remboursement. Il n’a pas besoin d’un accès illimité à la base de données ni d’une autorisation immédiate pour effectuer chaque remboursement qu’il propose.

La couche de politique peut limiter les lectures au client concerné, masquer les champs sensibles, plafonner le montant du remboursement et exiger une approbation humaine avant le paiement. Le modèle reste utile sans se voir accorder une large autorité opérationnelle.

L’isolation compte également. Les outils à privilèges élevés ne devraient pas partager le même contexte d’agent que des serveurs MCP externes arbitraires.

Un agent qui lit du contenu web public ne devrait pas automatiquement obtenir un accès aux outils d’administration internes. Séparer ces capacités réduit le risque que du contenu externe hostile atteigne des surfaces d’exécution sensibles.

Les équipes de sécurité devraient aussi maintenir un registre des serveurs approuvés. Chaque entrée devrait identifier le propriétaire du serveur, la source du code, l’emplacement de déploiement, la méthode d’authentification, les outils disponibles, l’accès aux données, la version et le statut de revue.

Les mises à jour doivent déclencher une revue lorsqu’elles modifient les descriptions d’outils, les schémas, les dépendances, les autorisations ou les destinations réseau. Un serveur ayant passé une revue plusieurs mois auparavant ne devrait pas bénéficier d’une confiance permanente.

Les serveurs MCP nécessitent également les protections habituelles des services. Les équipes ont besoin d’un transport sécurisé, d’authentification, de correctifs, de gestion des dépendances, de validation des entrées, d’isolation des secrets, de journalisation et de réponse aux incidents.

Le protocole ne remplace pas ces contrôles. Il crée un nouvel endroit où ils doivent être appliqués de manière cohérente.

Le véritable compromis oppose autonomie et confinement

Chaque capacité supplémentaire améliore l’utilité d’un agent tout en augmentant les dommages qu’une manipulation réussie peut causer.

Ce compromis explique pourquoi la sécurité des agents ne peut pas devenir une simple liste de contrôle ajoutée juste avant le déploiement. La conception du produit détermine l’autorité maximale du système bien avant qu’un scanner de sécurité ne l’examine.

Un agent sans outils peut produire du texte nuisible ou inexact. Un agent ayant accès aux fichiers peut exposer des documents. Un agent ayant accès au shell peut exécuter des commandes, tandis qu’un agent connecté aux systèmes de production peut modifier une infrastructure active.

Les autorisations étendues s’introduisent souvent dans les prototypes par commodité. Les développeurs veulent vérifier si un agent peut achever un workflow de bout en bout avant d’investir dans une autorisation détaillée.

Ces prototypes peuvent se rapprocher de la production plus vite que prévu. Des identifiants temporaires restent dans la configuration, des serveurs MCP expérimentaux deviennent une infrastructure partagée et des schémas d’outils permissifs se transforment en dépendances non documentées.

Le modèle à cinq couches aide à révéler ces raccourcis. Toutefois, un inventaire seul ne les contient pas.

Chaque agent a besoin d’une limite de confiance définie. Cette limite devrait préciser qui peut l’invoquer, quelles données il peut recevoir, quels outils il peut utiliser, quelles ressources il peut atteindre et quels résultats nécessitent une approbation.

Les équipes devraient distinguer les modes lecture, rédaction, recommandation et exécution. Ces libellés doivent correspondre à des autorisations applicables, et non à une simple formulation dans le prompt.

Un agent de recherche peut lire des sources approuvées et rédiger des conclusions. Un agent d’exploitation peut préparer un plan de déploiement. Un processus contrôlé distinct peut vérifier et exécuter ce plan.

Cette séparation réduit l’autonomie, mais elle crée aussi des transitions vérifiables. Les enquêteurs peuvent voir à quel moment une information est devenue une recommandation, puis à quel moment cette recommandation est devenue une action.

L’observabilité soutient le même objectif. Les journaux devraient enregistrer l’utilisateur à l’origine de la demande, l’identité de l’agent, la version du modèle, la version du prompt ou de la politique, le serveur MCP, le nom de l’outil, les arguments, la classification de la réponse, le dossier d’approbation et le résultat final.

Les données sensibles ne devraient pas être copiées sans précaution dans ces journaux. La télémétrie de sécurité doit fournir suffisamment de contexte pour l’enquête sans créer un nouveau dépôt de secrets exposés.

L’identité de l’agent mérite une attention particulière. Partager un compte de service entre de nombreux agents rend difficile l’attribution des responsabilités ou la révocation d’un seul workflow compromis.

Des identités distinctes permettent des autorisations par agent et des pistes d’audit plus claires. Elles aident également les équipes de sécurité à identifier des comportements anormaux, par exemple lorsqu’un agent de recherche demande soudainement un accès en écriture.

Les orientations gouvernementales considèrent désormais MCP comme une infrastructure nécessitant une conception de sécurité délibérée. Les recommandations de sécurité MCP de la NSA de mai 2026 abordent l’authentification, l’autorisation, l’isolation, la validation des serveurs, la gestion du cycle de vie et les risques couvrant les composants du protocole.

Cette attention signale un changement de maturité. MCP n’est plus seulement une commodité pour les développeurs discutée à travers des démonstrations locales. Les organisations l’évaluent pour des environnements où des outils compromis peuvent affecter des données et des opérations sensibles.

Les contrôles de sécurité des agents de Google Cloud soulignent un point similaire. Ces recommandations préconisent une identité d’agent distincte, des rôles à privilèges minimaux et des restrictions empêchant l’accès des outils en lecture-écriture aux ressources de production.

Ce sont des principes de sécurité familiers. Leur application devient plus difficile, car les agents sélectionnent dynamiquement leurs actions et combinent des outils individuellement valides en workflows que les développeurs n’avaient pas énumérés.

L’enchaînement d’outils non sécurisé survient lorsque le résultat d’une opération autorisée permet une séquence nuisible. Un outil de recherche, un lecteur de fichiers et un outil de messagerie sortante peuvent chacun sembler peu risqués lorsqu’ils sont examinés séparément.

Ensemble, ils peuvent créer une voie d’exfiltration de données. L’agent recherche des informations sensibles, les lit et les transmet à l’extérieur de l’organisation.

La politique doit donc examiner les séquences aussi bien que les appels individuels. Une requête peut être valide isolément, mais suspecte après un autre événement au cours de la même session.

Des contrôles tenant compte du contexte peuvent bloquer des combinaisons impliquant une entrée non fiable et une sortie privilégiée. Ils peuvent aussi exiger une nouvelle autorisation lorsqu’un agent passe de la collecte d’informations à une action externe.

Cette conception est plus exigeante que l’ajout d’un filtre autour du prompt utilisateur. Elle requiert une coordination entre les équipes produit, plateforme, identité, sécurité applicative et opérations.

Ce coût organisationnel fait partie du compromis. Les entreprises ne peuvent pas revendiquer de larges capacités autonomes tout en attribuant la responsabilité de la sécurité uniquement au fournisseur du modèle.

Ce que la sécurité en production ne peut toujours pas garantir

Les contrôles en couches réduisent l’exposition, mais aucun cadre actuel ne prouve qu’un agent restera sûr dans chaque combinaison de modèle, d’outil et de contexte.

La première incertitude concerne la qualité de l’évaluation. Les tests de sécurité peuvent mesurer des attaques connues, mais les entrées de production évoluent continuellement et les adversaires s’adaptent aux défenses publiées.

Une suite de red teaming devrait inclure l’injection de prompt directe et indirecte, l’utilisation non autorisée d’outils, l’élévation de privilèges, l’empoisonnement de mémoire, l’exfiltration de données, le contournement d’approbation, l’exécution récursive et la propagation multi-agents.

Les équipes devraient exécuter ces tests avant le déploiement et après tout changement significatif. Un nouveau modèle, un prompt système, une conception de mémoire, un serveur MCP, un schéma d’outil, une source de récupération ou une politique peut modifier la surface d’attaque.

Réussir un test ne garantit pas une sécurité permanente. Cela montre que des contrôles définis ont résisté à des attaques définies dans des conditions précises.

Les faux positifs créent un autre problème. Si les contrôles interrompent trop de tâches légitimes, les utilisateurs cherchent des solutions de contournement ou réclament des autorisations plus larges.

Les faux négatifs sont plus dangereux, mais plus difficiles à observer. Un agent peut accomplir la tâche demandée tout en divulguant des données, en enregistrant une mémoire empoisonnée ou en effectuant une action inutile.

L’approbation humaine n’est pas une solution complète. Les utilisateurs peuvent s’habituer aux confirmations, surtout lorsqu’une application présente des prompts fréquents ou peu clairs.

Les attaquants peuvent également manipuler les informations présentées à l’approbateur. Les interfaces d’approbation doivent obtenir les détails de l’action à partir de données d’exécution fiables, et non de la seule explication du modèle.

Le risque de chaîne d’approvisionnement reste également non résolu. Les déploiements MCP peuvent inclure des serveurs, des SDK, des registres, des packages, des modèles, des conteneurs et des services hébergés maintenus par différentes parties.

Un package signé peut établir l’origine et l’intégrité. Il ne peut pas garantir que le comportement signé est sûr ni qu’un service distant restera inchangé.

Les organisations devraient privilégier des déploiements reproductibles, des versions figées, du code source revu, des registres contrôlés et des processus de mise à jour documentés. Les serveurs distants nécessitent une validation continue, et non une approbation unique.

La révocation d’urgence doit être praticable. Les équipes devraient pouvoir désactiver un agent, un serveur, un outil, un identifiant ou une autorisation sans attendre une publication de l’application.

Les systèmes de mémoire ont besoin de contrôles équivalents. Les opérateurs doivent disposer de moyens pour inspecter, mettre en quarantaine, faire expirer et supprimer les entrées suspectes tout en préservant les éléments de preuve nécessaires à l’enquête.

Le scepticisme s’applique également aux affirmations des fournisseurs. Les produits de sécurité promettent de plus en plus une protection des prompts, du red teaming automatisé, la découverte d’agents, la gestion de posture ou l’application de politiques à l’exécution.

Ces capacités peuvent contribuer à la défense, mais les acheteurs devraient demander où se situe chaque contrôle et ce qui se passe lorsqu’il échoue. Un détecteur qui signale uniquement du texte suspect ne peut pas remplacer l’autorisation de l’action qui en résulte.

Les équipes devraient demander des preuves mesurables. Parmi les questions utiles figurent les catégories d’attaques testées, la disponibilité des données d’évaluation, le traitement des contournements et la fermeture par défaut en cas d’échec de l’application des contrôles.

Elles devraient également examiner la latence et la disponibilité. Un service de politique placé avant chaque appel d’outil devient une infrastructure critique.

Si ce service échoue en mode ouvert, les agents peuvent agir sans contrôles. S’il échoue en mode fermé, les workflows dépendants s’arrêtent. La conception de production doit traiter explicitement les deux cas.

L’approche à cinq couches constitue donc une base, et non une garantie. Elle aide les équipes à repérer les risques qu’une revue centrée uniquement sur le modèle manquerait.

Son succès dépend de la conversion de ces couches en responsabilité, en politique applicable, en tests reproductibles et en réponse opérationnelle. Sans ces étapes, le cadre devient un autre diagramme qui documente l’exposition sans la réduire.

Trois signaux montreront si la sécurité des agents gagne en maturité

La prochaine phase se mesurera à l’aune de paramètres par défaut applicables, de tests indépendants et de preuves issues de déploiements réels.

Le premier signal sera de savoir si les clients et serveurs MCP adoptent par défaut des autorisations plus étroites. La prise en charge des normes d’autorisation modernes est importante, mais des déploiements sûrs nécessitent également des portées spécifiques aux ressources et une séparation claire entre les opérations de lecture et d’écriture.

Un écosystème plus robuste rendrait les autorisations étendues visiblement exceptionnelles. Les clients montreraient aux utilisateurs à quoi chaque serveur peut accéder, tandis que les serveurs rejetteraient les jetons destinés à une autre ressource.

Des restrictions par défaut renforceraient l’argument selon lequel une connectivité standardisée peut coexister avec le confinement. Une dépendance persistante à des identifiants ambiants et à des portées surdimensionnées l’affaiblirait.

Le deuxième signal sera l’évaluation indépendante de la gouvernance à l’exécution. Les benchmarks des fournisseurs offrent des points de départ utiles, mais les acheteurs ont besoin de tests reproductibles sur plusieurs modèles, outils et styles d’attaque.

Les évaluateurs devraient rendre compte à la fois de la prévention des attaques et de l’accomplissement des tâches légitimes. Un système qui bloque chaque appel d’outil est sûr dans un sens étroit, mais échoue à remplir son objectif opérationnel.

Les résultats devraient aussi distinguer la détection de prompts de l’application des actions. Détecter un langage suspect est différent d’empêcher une lecture de fichier, une mise à jour de base de données ou une requête sortante interdite.

Le troisième signal sera de savoir si les entreprises peuvent produire des inventaires complets d’agents et des dossiers d’incidents. Les organisations devraient savoir quels agents sont déployés, qui en est responsable, quels modèles ils utilisent et quels serveurs MCP ils peuvent atteindre.

Ils doivent également pouvoir reconstituer les actions ayant des conséquences à partir de journaux authentifiés. Des identités manquantes, des enregistrements d’outils incomplets ou des changements de permissions inexpliqués indiquent que l’adoption a progressé plus vite que la gouvernance.

C’est là que la gestion des connaissances rejoint les opérations de sécurité. Les équipes ont besoin d’archives consultables reliant les exigences, les configurations des agents, les résultats de tests, les approbations, les incidents et les décisions de remédiation.

Une base de connaissances technique contrôlée peut aider les ingénieurs à retrouver ces éléments, mais elle doit respecter les mêmes limites d’accès et de traitement des données.

L’apparition dans Google News offre au modèle de sécurité à cinq couches une visibilité accrue. Son importance durable dépendra de la capacité des équipes à transformer cette visibilité en permissions plus limitées et en contrôles d’exécution plus robustes.

Les développeurs devraient commencer par un flux de production et cartographier chaque entrée, décision du modèle, écriture en mémoire, intégration, identifiant, appel d’outil et sortie. Ils devraient ensuite déterminer où une politique déterministe interrompt les déplacements non sûrs entre ces points.

Votre organisation peut-elle expliquer ce que chaque agent en production est autorisé à faire, quelle identité l’autorise et comment un document compromis serait contenu ? Si la réponse est incomplète, la prochaine mesure n’est pas une règle de prompt supplémentaire. C’est une limite d’exécution plus étroite, un parcours d’approbation testé et une piste d’audit qui résiste au raisonnement de l’agent.