Les agents IA ne créent pas de risque uniquement lorsqu'ils hallucinent ou produisent une réponse inexacte. Ils créent un risque lorsqu'ils entreprennent la mauvaise action.
Une seule invite utilisateur peut traverser une application, atteindre un environnement d'exécution d'agent, appeler un outil, déclencher un serveur MCP et interagir avec une API en aval. Au moment où l'action se produit, la requête originale peut être à plusieurs couches du système qui modifie réellement les données, envoie des informations ou exécute un flux de travail.
C'est le problème auquel les équipes de sécurité sont désormais confrontées. Les organisations se précipitent pour déployer des agents IA, mais beaucoup n'ont toujours pas une vision claire de ce à quoi ces agents peuvent accéder, quels outils ils peuvent appeler et quelles API ils peuvent déclencher.
L'industrie de la cybersécurité s'est également trop concentrée sur la seule couche du modèle. La sécurité des LLM est importante, mais un système agentique d'entreprise n'est pas une couche unique. Il s'étend des LLM au sommet, aux serveurs MCP au milieu, et aux API et systèmes en aval au niveau de la couche d'action. Le risque se déplace à travers les trois.
C'est pourquoi la sécurité des agents IA ne peut pas se limiter aux invites, aux modèles ou aux garde-fous. Pour sécuriser ce nouvel écosystème, les équipes de sécurité doivent comprendre comment les systèmes agentiques fonctionnent réellement et pourquoi la visibilité des API est devenue le point de contrôle.
L'architecture agentique expliquée
Lorsque nous cartographions une application agentique, le risque devient beaucoup plus facile à percevoir. Un agent n'est pas seulement un chatbot avec une meilleure interface. C'est un système capable de raisonner, de choisir des outils et d'agir sur une infrastructure métier réelle.
L'entrée
Tout commence avec l'utilisateur final.
Une invite utilisateur transite par la couche applicative, généralement via un site web, une interface produit, un proxy ou un service backend-for-frontend. De là, elle atteint l'environnement d'exécution de l'agent via un point d'accès dédié tel que /api/chat.
À ce stade, la requête peut sembler simple. Un utilisateur peut demander à l'agent de résumer un compte, de mettre à jour un ticket, d'extraire des données client, de rechercher de la documentation ou de déclencher un flux de travail. Mais une fois que la requête entre dans l'environnement d'exécution de l'agent, le système commence à décider de la suite des opérations.
Le Cerveau : LLM et Gouvernance
À l'intérieur de l'environnement d'exécution de l'agent, l'orchestrateur d'agent gère le flux de décision. Il envoie des requêtes au LLM pour le raisonnement et la génération. Il reçoit également des instructions de l'invite système, applique des politiques et achemine les entrées et sorties à travers des garde-fous.
Cette couche est importante car elle façonne la manière dont l'agent pense et répond. Elle peut aider à détecter l'injection d'invite, à bloquer le contenu dangereux et à appliquer des règles de politique de base.
Mais cette couche ne suffit pas à elle seule.
Le modèle peut décider ce qui doit se passer, mais le risque réel apparaît lorsque l'agent est autorisé à faire quelque chose. C'est là que l'architecture passe du raisonnement à l'action.
La Couche d'Action : Là où le Risque Devient Réel
C'est la couche la plus importante que les équipes de sécurité doivent comprendre.
Les agents deviennent puissants parce qu'ils peuvent utiliser des outils. Ils peuvent interroger des bases de données, rechercher sur le web, appeler des services internes, mettre à jour des enregistrements, créer des tickets, envoyer des messages ou déclencher des flux de travail automatisés.
Dans la plupart des environnements d'entreprise, ces actions se déroulent via trois voies principales.
Boîtes à outils intégrées
Les boîtes à outils intégrées donnent aux agents l'accès à des fonctionnalités courantes telles que les requêtes de base de données, la recherche web, la récupération de fichiers ou les actions spécifiques à l'application.
Ces outils rendent les agents utiles, mais ils créent également de nouvelles voies vers des données sensibles et des opérations critiques pour l'entreprise. Si un agent est incité à utiliser un outil de manière incorrecte, le résultat pourrait ne pas être une mauvaise réponse. Il pourrait s'agir d'une mauvaise action.
Outils personnalisés
Les outils personnalisés connectent directement les agents aux API internes et aux systèmes métier.
C'est là que de nombreuses organisations sous-estiment le risque. Un outil personnalisé peut exposer des flux de travail de remboursement, des dossiers clients, des données produit, des actions de support ou des fonctions d'administration internes. Si l'outil dispose d'autorisations étendues, l'agent peut hériter d'un accès bien plus large que celui que l'utilisateur devrait avoir.
Il ne s'agit pas de risques théoriques. Des chercheurs en sécurité ont déjà montré comment l'injection indirecte d'invite peut manipuler les systèmes d'IA via du contenu caché dans des pages web, des e-mails, des documents ou d'autres entrées externes. Le même schéma peut s'appliquer aux outils agentiques : un agent de support pourrait être poussé à utiliser abusivement une API de remboursement ou de gestion de compte, un agent de recherche pourrait être manipulé pour exposer des données internes sensibles via un outil de récupération trop permissif, et un agent de flux de travail pourrait être guidé pour déclencher un processus en aval sans validation suffisante.
La question n'est pas seulement de savoir si l'invite était sûre. La question est de savoir si l'action était autorisée, attendue et visible.
La couche MCP
La couche MCP devient rapidement l'une des parties les plus importantes de la pile agentique.
Le MCP, ou Model Context Protocol, est un moyen émergent pour les agents d'IA de se connecter à des outils, des données et des systèmes externes. Il offre aux agents un moyen plus standardisé de découvrir et d'appeler des outils via des serveurs MCP.
Dans un flux typique, l'environnement d'exécution de l'agent utilise un client MCP pour communiquer avec un serveur MCP via des points d'accès tels que /initialize, /tools/list et /tools/call. Le serveur MCP exécute ensuite des outils spécifiques, ce qui peut déclencher des API en aval.
Cela crée une puissante couche d'abstraction. Cela crée également un problème de visibilité.
Une équipe de sécurité peut voir un appel d'API en fin de chaîne, mais ne pas comprendre quel agent l'a provoqué, quel outil a été utilisé, quel serveur MCP l'a géré, ou quelle invite utilisateur a déclenché l'action.
C'est dans ce contexte manquant que se cache le risque agentique.
Le goulot d'étranglement de l'API : pourquoi la visibilité est importante
Une fois l'architecture comprise, un point devient clair : quelle que soit la complexité du raisonnement de l'agent, ses actions concrètes se manifestent finalement sous forme d'activité API.
L'agent peut communiquer avec le LLM, découvrir des outils via MCP, utiliser des fonctions personnalisées ou s'appuyer sur des connecteurs intégrés – toutes ces interactions sont également basées sur des API. Salt offre une visibilité sur cette couche de communication, et pas seulement sur l'appel d'API final en aval. Cela signifie que les équipes de sécurité peuvent voir le chemin plus large qu'un agent emprunte lorsqu'il raisonne, sélectionne des outils et agit à travers les systèmes métier.
Cela fait de la couche API le point de contrôle naturel pour la sécurité agentique.
Les équipes de sécurité n'ont pas seulement besoin de savoir qu'une API a été appelée. Elles doivent comprendre la chaîne complète derrière l'appel :
- Quel agent a initié l'action ?
- Quel utilisateur ou quelle invite a démarré le flux ?
- Quel serveur ou outil MCP était impliqué ?
- Quelle API en aval a été déclenchée ?
- Le comportement était-il normal, risqué ou malveillant ?
Les journaux d'API traditionnels ne peuvent souvent pas répondre à ces questions. Ils montrent le trafic, mais pas toujours le contexte agentique qui le sous-tend. C'est pourquoi la visibilité des API doit évoluer pour l'ère agentique.
L'objectif principal de Salt Security est de sécuriser le cycle de vie complet de ces systèmes avec une visibilité complète, une compréhension contextuelle des risques et une protection en temps réel.
Observabilité grâce au graphe de sécurité
Salt ne traite pas chaque appel d'API comme un événement isolé. Il construit une carte contextuelle de la chaîne d'exécution agentique, y compris la communication agent-vers-LLM, la communication agent-vers-MCP, l'activité MCP-vers-outil, l'utilisation de connecteurs et les appels d'API en aval.
C'est important car les équipes de sécurité ont besoin de relations, pas seulement d'enregistrements.
Si une API en aval se comporte anormalement, les équipes doivent retracer cette activité jusqu'à l'agent d'origine. Si un outil MCP expose des actions risquées, les équipes doivent comprendre quels agents peuvent l'atteindre. Si un agent communique avec un LLM, appelle un connecteur, invoque un outil ou déplace des données sensibles via un chemin inattendu, les équipes doivent voir l'itinéraire complet.
C'est là l'intérêt d'un inventaire agentique unifié et d'un graphe de sécurité. Il transforme l'activité brute en une carte des risques compréhensible.
Gestion contextuelle de la posture
Les systèmes agentiques ont également besoin d'une gestion de la posture qui reflète leur fonctionnement réel.
Il ne suffit pas d'inventorier les API, les agents ou les outils séparément. Les équipes de sécurité doivent savoir comment ces objets se connectent, ce que chacun peut accéder et où se trouvent les combinaisons les plus risquées.
Par exemple, un serveur MCP peut ne pas sembler dangereux en soi. Mais s'il expose des outils puissants à un agent ayant un large accès à des API sensibles, il devient un risque de haute priorité.
Salt étend la découverte à l'ensemble de l'écosystème de l'IA et met en lumière des modèles de risque spécifiques à l'IA. À mesure que les capacités de la feuille de route mûrissent, le support de frameworks tels que OWASP MCP Top 10 et OWASP AI Top 10 peut aider les organisations à évaluer les risques liés aux agents, aux objets MCP, aux outils et aux API dans leur contexte.
Protection en temps réel
La visibilité est la première étape. La protection est la suivante.
Étant donné que les actions agentiques passent finalement par la couche API, les équipes de sécurité doivent être capables de détecter les comportements à risque en temps réel et, si possible, de les arrêter avant qu'ils n'atteignent les systèmes critiques. Cela inclut des fonctionnalités telles que le blocage d'outils et d'API, la détection d'anomalies et la détection d'injections de prompts, avec des capacités supplémentaires prévues dans la feuille de route pour étendre la protection au blocage des attaquants et aux détections liées aux garde-fous.
C'est particulièrement important car les attaques agentiques peuvent ne pas ressembler à des abus d'API traditionnels. La requête peut provenir d'un agent de confiance. L'outil peut être approuvé. L'API peut être légitime. Le risque provient de la combinaison du prompt, du choix de l'outil, des permissions et de l'action en aval.
La position de Salt au point d'étranglement de l'API offre aux équipes un moyen de surveiller et de protéger la couche où l'intention de l'IA se transforme en impact commercial. Tout aussi important, Salt offre une visibilité sur le contexte plus large de l'agent, y compris la communication avec le LLM. Avec le temps, cette visibilité devrait s'étendre davantage au contexte des garde-fous.
Lorsque ces signaux basés sur l'API sont connectés, les équipes de sécurité peuvent visualiser l'architecture complète de l'agent en un seul endroit : la requête utilisateur, l'exécution de l'agent, la communication LLM, l'activité MCP, l'utilisation des outils, l'activité des connecteurs et les appels API en aval. Ce contexte complet facilite grandement le raisonnement en matière de sécurité. Au lieu d'enquêter sur des événements déconnectés, les équipes peuvent comprendre comment un agent a pris une décision, ce qu'il a tenté de faire et quels systèmes ont été affectés.
Conclusion
L'ère de la sécurité agentique est déjà là.
Les agents IA ne sont plus de simples interfaces passives qui ne font que répondre à des questions. Ils deviennent des participants actifs aux flux de travail d'entreprise. Ils appellent des outils, se connectent à des serveurs MCP, déclenchent des API et agissent sur les données commerciales.
Cela modifie le modèle de sécurité.
Construire des murs plus épais autour du LLM ne suffit pas. Les garde-fous sont importants, mais ils ne peuvent pas offrir une visibilité complète sur ce qui se passe après qu'un agent a décidé d'agir. Pour sécuriser les systèmes agentiques, les organisations doivent voir le chemin d'exécution complet : du prompt à l'agent, de l'agent au LLM, de l'agent au MCP ou à l'outil, et de l'outil à l'API. À l'avenir, le contexte des garde-fous rendra cette vue encore plus riche.
La couche API est l'endroit où ces actions deviennent visibles. Combinée à la communication LLM, au contexte MCP, à l'activité des outils et au futur contexte des garde-fous, elle donne aux équipes de sécurité l'image complète dont elles ont besoin pour évaluer les risques et enquêter sur le comportement des agents en toute confiance.
Vos agents IA sont déjà en action. Salt vous aide à visualiser le chemin complet du prompt au LLM, MCP, outils et API, afin que vous puissiez évaluer les risques en toute confiance. Demander une démo.