La première vague de sécurité de l'IA ressemblait beaucoup à un WAF pour les LLM : inspecter l'invite, filtrer la sortie, bloquer les schémas malveillants évidents.
C'était utile. Ça l'est toujours.
Mais elle a été conçue pour des systèmes qui se contentaient de communiquer.
Les agents sont différents. Ils utilisent des outils, appellent des API, accèdent aux données et apportent des modifications.
La confusion que je constate souvent est simple : de nombreuses équipes pensent que sécuriser le modèle signifie sécuriser l'agent. Ce n'est pas le cas.
La sécurité de l'IA protège la conversation. La sécurité des agents protège les conséquences.
Le marché a utilisé « sécurité de l'IA » comme un fourre-tout pour presque tout : injection d'invite, contournements, sorties dangereuses, accès au modèle, politique d'utilisation de l'IA, passerelles LLM, DLP de base et gouvernance des modèles. Ce sont de vrais problèmes. Mais ils ne représentent pas l'ensemble du problème.
Un chatbot parle. Un agent agit. Une mauvaise réponse d'un chatbot est un problème, mais une mauvaise action d'un agent peut devenir un incident. C'est la distinction que l'industrie apprend encore à faire.
Un chatbot peut halluciner, divulguer quelque chose dans une réponse ou être manipulé pour dire quelque chose de dangereux. Un agent peut faire tout cela, mais il peut aussi appeler un outil, récupérer des données client, émettre un remboursement, mettre à jour un ticket, modifier une configuration, déclencher un flux de travail ou interagir avec un système qui gère réellement l'entreprise.
Le modèle ne se contente plus d'avoir une conversation. Il fait désormais partie d'un chemin d'exécution.
L'agent n'est pas une entité unique. C'est un corps.
La façon la plus simple d'expliquer un agent est de le comparer au corps humain. Le LLM est le cerveau. Il raisonne, interprète l'intention et décide de la prochaine action. L'invite est les oreilles. Elle reçoit la requête. La réponse est la bouche. Elle communique le résultat. Les outils et les serveurs MCP sont les mains. Ils confèrent des capacités à l'agent. Les API sont les boutons. Elles représentent la manière dont l'agent interagit avec l'entreprise. Les systèmes derrière ces API sont ce que les boutons contrôlent.
La plupart des conversations sur la sécurité de l'IA se concentrent sur les oreilles, le cerveau et la bouche. L'invite était-elle malveillante ? La réponse était-elle sûre ? Le modèle a-t-il dit quelque chose qu'il n'aurait pas dû dire ? Des questions importantes. Mais incomplètes.
Car les mains peuvent encore détenir les clés.
Vous pouvez mettre un casque sur le cerveau, installer un filtre dans les oreilles et surveiller ce que dit la bouche. Mais si les mains peuvent toujours appuyer sur le bouton de remboursement, exporter la liste des clients, mettre à jour le compte ou appeler une API interne avec une autorisation faible, vous avez toujours un problème sérieux.
Vous avez sécurisé la conversation. Vous n'avez pas sécurisé l'action.
L'invite peut paraître inoffensive alors que le chemin est dangereux.
Imaginez un agent de support client. Un client demande : « On m'a facturé deux fois. Pouvez-vous m'aider ? » L'invite semble normale. Le modèle décide d'aider. L'agent appelle un outil de facturation. L'outil de facturation appelle une API interne. L'API renvoie les données du compte. L'agent émet un crédit. La réponse finale semble inoffensive : « J'ai examiné votre compte et émis un crédit. »
Du point de vue de la couche modèle, tout peut sembler correct. Pas de contournement évident. Pas de sortie toxique. Pas de données sensibles dans la réponse finale. Mais le chemin intermédiaire peut raconter une tout autre histoire.
Peut-être que l'outil de facturation était trop permissif. Peut-être que le serveur MCP avait une clé API codée en dur. Peut-être que l'API n'avait pas de limite de débit. Peut-être que l'API de remboursement n'a jamais été conçue pour un accès autonome.
Imaginez maintenant que cela se produise à la vitesse de la machine des centaines de milliers de fois avant que quiconque ne s'en aperçoive.
Le modèle n'a rien dit de dangereux. L'agent a agi et a eu un impact sur les revenus.
C'est là le fossé. Le risque ne réside pas seulement dans l'invite ou la réponse. Il se trouve dans le chemin d'exécution entre les deux.
La visibilité, la gouvernance et la protection à l'exécution ne sont pas la même chose.
La sécurité des agents a trois fonctions : la visibilité, la gouvernance et la protection à l'exécution. La visibilité vous indique ce qui existe, la gouvernance vous dit ce qui devrait être autorisé, et la protection à l'exécution vous dit ce qui se passe réellement lorsque l'agent est actif.
La visibilité peut vous indiquer quels agents existent, où ils s'exécutent, quels outils ils utilisent et quelles API ils peuvent atteindre. La gouvernance peut vous dire quels outils sont activés, quelles identités sont utilisées, quelles politiques sont manquantes et quelles actions sont trop permissives. La protection à l'exécution répond à la question en direct : L'agent est-il en train de faire quelque chose de dangereux en ce moment ?
Un tableau de bord n'est pas une protection à l'exécution. Un inventaire n'est pas une protection à l'exécution. Un document de politique n'est pas une protection à l'exécution. Ils sont nécessaires, mais ils ne sont pas la même chose que d'observer les actions en temps réel.
Les agents ont besoin de visibilité. Les agents ont besoin de gouvernance. Mais les agents ont aussi besoin de freins.
Le code vous dit ce qui a été construit. La configuration vous dit comment il est gouverné. L'exécution vous dit ce qui s'est passé.
Pour comprendre le risque agentique, vous avez besoin de trois sources de vérité.
Le code montre ce qui a été construit : secrets codés en dur, outils non sécurisés, contrôles d'autorisation manquants, modèles d'API risqués.
La configuration montre comment il est gouverné : quels outils sont activés, quelles identités sont utilisées, quelles politiques s'appliquent, qui en est propriétaire et quelles API sont accessibles.
L'exécution montre ce qui s'est passé : quelle invite a mené à quel appel d'outil, quel outil a appelé quelle API, quelles données sont revenues et quelle action a été entreprise.
C'est important car tous les agents ne vivent pas au sein d'une plateforme d'IA gérée et propre. Le cas simple est un plan de contrôle connu où vous pouvez extraire la configuration et construire un tableau de bord utile. Utile ? Oui. Suffisant ? Non.
Le cas plus difficile est un agent qui ressemble à un logiciel : un LLM s'exécutant dans EC2 ou Kubernetes, utilisant un serveur MCP personnalisé, appelant des API internes derrière un équilibreur de charge F5, et atteignant des systèmes plus anciens jamais conçus pour un accès autonome.
Ce n'est pas un produit d'IA simple et clair. C'est une application de production.
Et comme toute application de production, vous avez besoin du chemin complet : de l'invite au modèle, du modèle à l'outil, de l'outil à l'API, de l'API aux données, et inversement.
C'est le graphe agentique : ce qui a été construit, comment cela a été gouverné, et ce qui s'est réellement passé.
La question doit changer.
« Sécurisez-vous l'IA ? » est désormais une question faible et insuffisante. En fait, presque tout le monde peut répondre oui.
La meilleure question est : où s'arrête votre visibilité ? Voyez-vous le modèle, ou aussi les outils et les API ? Offrez-vous la visibilité, la gouvernance et la protection en temps réel, ou seulement l'une d'entre elles ? Pouvez-vous suivre le chemin de l'invite à l'outil, de l'outil à l'API, jusqu'à l'action en aval ? Pouvez-vous protéger un agent fonctionnant comme une charge de travail normale dans EC2, Kubernetes, des conteneurs, des machines virtuelles, ou sur site ? Pouvez-vous relier le code, la configuration et l'exécution en une seule vue ?
Et peut-être le plus important : où votre réponse devient-elle : « Nous ne voyons pas cette partie » ?
Chaque contrôle de sécurité a une limite. Les bons fournisseurs savent où se trouve cette limite. Les grandes équipes de sécurité la demandent directement.
Les agents ont toujours les clés de la voiture.
La première vague de sécurité de l'IA était nécessaire. Elle nous a fourni des garde-fous pour les invites, les modèles et les sorties. Mais les agents ont changé la question de la sécurité.
Il ne suffit plus de demander : « Qu'a dit le modèle ? » Nous devons demander ce que l'agent a fait, quel outil il a utilisé, quelle API il a appelée, quelles données sont revenues, quelle action a été entreprise, si elle était attendue, si elle était autorisée et si elle était sûre.
C'est la ligne de démarcation entre la sécurité de l'IA et la sécurité agentique.
Et à l'heure actuelle, de nombreuses entreprises ont protégé le modèle tandis que les agents ont toujours les clés de la voiture.
Prêt à découvrir votre graphe de sécurité agentique ? Salt Security propose une évaluation gratuite de la sécurité agentique afin que vous puissiez cartographier l'intégralité de votre surface d'attaque agentique en quelques minutes, et non en plusieurs mois. Obtenez votre évaluation gratuite sur salt.security/agentic-assessment