Solution · AI Operations

Ton agent IA n'a pas besoin de se tromper pour faire des dégâts. Il suffit que quelqu'un de l'extérieur lui parle.

La gouvernance des agents décide de ce que le tien a le droit de faire. La sécurité décide de ce que quelqu'un qui ne travaille pas ici peut lui faire faire : une instruction cachée dans un e-mail que l'agent lit, un outil que personne n'a audité, un secret qui voyage dans le contexte. On monte cette couche —isolation, identité, filtrage et traçabilité forensique— et on l'exploite.

On le monte chez moi Voir comment ça marche

Le problème

Un agent avec des permissions est une nouvelle surface d'attaque. Ni ton prestataire de sécurité ni ta couche de gouvernance ne la couvrent.

Ton agent lit des e-mails, des tickets, des documents ou des pages web. Tout ça, c'est du texte écrit par quelqu'un d'extérieur, et le modèle ne distingue pas ce que tu lui as demandé de ce qui arrive dans le contenu.
Les identifiants de l'agent ne sont pas les siens : ce sont ceux d'un utilisateur technique avec plus de droits que n'importe qui dans l'équipe, planqués dans une variable d'environnement que personne n'a fait tourner depuis le premier jour.
Chaque outil que tu lui branches élargit ce qu'il peut faire et, autant, ce qu'on peut lui faire faire. Personne ne vérifie qui a publié ce connecteur, ce qu'il demande à chaque appel, ni ce qui a changé dans sa dernière version.
Le contexte traîne des données d'un dossier au suivant parce que la session n'est jamais nettoyée, ou parce que l'index d'où il récupère l'information ne filtre pas selon les droits de celui qui pose la question.
Si demain on te demande ce qu'a fait l'agent, sur quelles données et sous quelle version, la réponse est éparpillée dans les journaux de trois systèmes qui ne partagent aucun identifiant.

Le coût de ne rien changer

La liste de référence du secteur ne laisse plus de place au doute : dans l'OWASP Top 10 for LLM Applications, édition 2025, l'injection d'instructions occupe la première place pour la deuxième édition consécutive, l'exposition d'informations sensibles la deuxième, la chaîne d'approvisionnement la troisième, et l'agentivité excessive —donner à l'agent plus de capacité que sa tâche n'en exige— la sixième. Ce n'est pas un risque futur : c'est exactement la grille avec laquelle te regardera quiconque auditera ton système, que ce soit ton grand client, ton assureur ou ton régulateur. Et le coût de ne pas avoir de réponse ne se paie pas en tickets ouverts : il se paie en donnée sortie, en action exécutée et en explication que tu ne peux pas fournir faute de trace.

La solution

On monte la couche de sécurité de l'agent —isolation, identité, filtrage et traçabilité forensique— et on l'exploite comme une fonction continue

1On modélise la menace agent par agent, l'étape que presque personne ne fait : d'où vient le texte qu'il lit, quelles données il atteint, quelles actions il peut exécuter, et ce qui se passe si un tiers contrôle l'un de ces trois éléments. C'est de là que sort la liste de ce qu'il faut blinder, dans l'ordre — et pas l'inverse.
2On sépare instruction et donnée. Ce qui vient de l'extérieur entre comme contenu, jamais comme ordre : des gabarits que le contenu ne peut pas réécrire, un filtrage en entrée, et une validation de la sortie avant qu'elle touche un système réel. Que le modèle se laisse convaincre, ça se gère ; que sa sortie s'exécute sans contrôle, non.
3On donne à chaque agent son identité propre au lieu d'une clé maîtresse partagée : identifiants à durée de vie courte, moindre privilège par outil et par donnée, et action sensible adossée à une autorisation cadrée plutôt qu'à un jeton éternel dans un fichier d'environnement.
4On isole l'exécution des outils : environnement cadré, liste blanche de destinations et de domaines, et revue réelle de chaque connecteur installé —qui le publie, quelles permissions il demande, ce qui change à chaque version. La chaîne d'approvisionnement est le troisième risque de la liste et aussi le plus facile à glisser.
5On coupe la fuite par le contexte : la récupération d'information filtre selon les droits de celui qui pose la question, la session se nettoie entre les dossiers, et les secrets comme les données personnelles sont masqués avant tout envoi vers un modèle externe.
6On termine par la traçabilité forensique et la réponse : un identifiant de dossier qui traverse modèle, outils et systèmes, une rétention pensée pour pouvoir enquêter, un frein par agent et une procédure de réponse écrite. Et on l'exploite : des tests adverses périodiques contre les agents vivants, pas un audit unique qui vieillit en trois mois.

Ce qui change

Ce que tu arrêtes de perdre

L'injection d'instructions cesse d'être théorique : on la teste contre tes agents vivants, avec des cas réels de ton activité, avant que quelqu'un d'autre ne la teste.
Mécanisme
L'agent cesse de partager la clé maîtresse : chacun a son identité, son moindre privilège et un identifiant à durée courte, donc un agent compromis n'ouvre pas toute la maison.
Mécanisme
La fuite par le contexte cesse de dépendre du fait que personne ne demande ce qu'il ne devrait pas : ça filtre selon les droits du demandeur et ça se nettoie entre dossiers, par conception et non par confiance.
Mécanisme
Ce qu'on mesure : part d'agents avec un modèle de menace vivant, % d'actions sensibles couvertes par un identifiant cadré ou une autorisation, découvertes des tests adverses ouvertes et fermées, et temps nécessaire pour reconstituer un dossier complet.
Ce qu'on mesure

Fiche technique

Travail supprimé: découvrir après coup qu'un agent s'est laissé berner, qu'il traînait des droits en trop, ou que son contexte a fuité —et reconstituer le dossier à la main entre des journaux qui ne collent pas
Mise en place habituelle: 3–6 semaines
Entrée: les agents que tu as déjà en production, leurs outils branchés, leurs identifiants et les sources de texte qu'ils lisent
Sortie: chaque agent avec son modèle de menace, son identité propre et le moindre privilège, des outils isolés et en liste blanche, un contexte filtré par les droits, et une trace de bout en bout exploitable pour enquêter
Compatible avec: OpenAIAnthropicAzure OpenAILangChainLlamaIndexn8nServidores MCP
Peut se connecter à: Tu gestor de secretos y tu proveedor de identidadTu SIEM o tu stack de observabilidadTu capa de gobierno de agentes, si ya la tienes montada
Ce qu’on mesure: part d'agents avec un modèle de menace vivant% d'actions sensibles avec identifiant cadré ou autorisationdécouvertes des tests adverses ouvertes et ferméestemps pour reconstituer un dossier complet
Adapté pour: les entreprises dont les agents sont déjà en production, lisent du texte de tiers ou agissent sur des systèmes réels, et qui doivent répondre à un client, à un audit ou à un régulateur
Pas adapté pour: celui qui en est encore à la preuve de concept sans données réelles ni droits d'écriture : là, ce qu'il faut, c'est bien concevoir, pas blinder

Questions fréquentes

L'adversaire. La gouvernance répond à « qu'a le droit de faire mon agent et qui répond s'il se trompe » : politiques, validations, audit, conformité. C'est la couche qui évite l'erreur interne, et elle est développée dans gouverner les agents IA de ton entreprise. La sécurité répond à une autre question : « que peut lui faire faire quelqu'un qui ne travaille pas ici ». Aucune politique n'aide là, parce que l'attaquant ne lit pas tes politiques : il faut séparer instruction et donnée, isoler les outils, cadrer les identités et laisser une trace exploitable. Les deux se complètent et l'ordre importe peu ; ce qui ne marche pas, c'est d'en avoir une et de croire qu'on a les deux.

Pour le périmètre, les accès et les postes, si, et on n'y touche pas. Là où la route s'arrête, c'est sur la surface nouvelle : un agent qui exécute des actions à partir d'un texte écrit par un tiers ne ressemble à rien de ce que couvre un pare-feu. L'injection d'instructions n'est pas un exploit réseau, c'est le modèle qui obéit à la mauvaise personne. L'isolation des outils n'est pas de la segmentation réseau, c'est décider ce qu'un processus qui improvise à l'exécution a le droit d'invoquer. Et revoir un connecteur n'est pas un scan de vulnérabilités, c'est lire quelles permissions il demande et qui l'a publié. Cette couche est dans un no man's land entre ton prestataire sécurité et ton cabinet IA : c'est pour ça qu'on la monte, et que le service derrière est la sécurité complète, classique et IA.

Non, et méfie-toi de qui te dit oui. Tant que le modèle traite instructions et données par le même canal, il existera toujours un texte capable de le convaincre ; c'est pour ça que ce risque tient la première place de la liste OWASP sur deux éditions d'affilée. Ce qu'on peut faire —et qui change vraiment le résultat— c'est que se laisser convaincre ne suffise pas à causer du dégât : moindre privilège pour que l'action dangereuse ne soit pas disponible, validation de la sortie avant qu'elle touche un système, autorisation humaine sur ce qui coûte de l'argent ou touche des personnes, et traçabilité pour le repérer tôt. La défense n'est pas un mur : ce sont des couches qui empêchent une défaillance du modèle de devenir un incident métier.

On le monte chez toi ?

Tu as ciblé le problème. On livre la solution et on la laisse mesurée.

Voir le service