Salt Security et CrowdStrike offrent à leurs clients communs une visibilité sur l'ensemble du parcours agentique, du modèle jusqu'au système où l'action est exécutée.
Un employé de banque pose une question courante à un assistant IA : « Quel est le solde de mon compte épargne ? ». L'assistant répond correctement. La requête était légitime. La réponse était exacte. Un contrôle de sécurité au niveau du modèle inspecte les deux et ne détecte aucune anomalie, car il n'y en a aucune.
Examinons maintenant ce qui s'est passé entre-temps.
Pour répondre à cette question, l'agent a fait appel à un serveur MCPinterne. Ce serveur s'est connecté à un service de profil utilisateur et à un service de gestion de comptes. Ces services ont appelé des API qui ont renvoyé des numéros de sécurité sociale sans aucune authentification. La passerelle API sur le chemin n'avait aucune limitation de débit activée. Le code source du serveur MCP contenait des clés API codées en dur. Des services réservés à un usage interne étaient accessibles depuis Internet. Et l'agent lui-même disposait d'un accès aux outils bien plus étendu que ce qu'exige la fonction d'un guichetier.
Chacune de ces découvertes constitue un problème de sécurité majeur. Aucune n'est visible à partir de la requête ou de la réponse. C'est précisément cette lacune que la sécurité agentique vise à combler, et c'est pourquoi Salt Security a étendu son intégration avec la plateforme CrowdStrike Falcon sur l'ensemble du parcours agentique.
Qu'est-ce que le parcours agentique ?
Le parcours agentique est la séquence complète qu'un agent IA suit, de la décision à la conséquence. Il commence par le raisonnement du modèle sur une requête. Il se poursuit à travers les outils et les serveurs MCP auxquels l'agent se connecte, les API que ces connexions invoquent et les données que ces API renvoient. Il se termine au niveau du système où l'action prend réellement effet : une mise à jour d'enregistrement, un paiement émis, un fichier récupéré, un ticket clôturé.
La sécurité applicative traditionnelle a été conçue pour des logiciels qui exécutent des instructions précises. Le chemin de l'entrée à la sortie était écrit par un développeur et pouvait être examiné avant le déploiement. Les agents sont différents. Ils décident quels outils utiliser et dans quel ordre, improvisant des séquences qu'aucun humain n'a conçues à l'avance. Le chemin est assemblé au moment de l'exécution ; il ne peut donc pas être entièrement examiné au préalable et change d'une requête à l'autre.
Cela a une conséquence directe sur la sécurité. L'autorisation n'est plus une propriété statique d'une application. C'est une question dynamique : que fait l'agent en ce moment, à quoi est-il connecté et cela correspond-il toujours à ce qui lui a été autorisé ?
Deux questions, pas deux couches
Sécuriser les agents IA implique de répondre à deux questions distinctes, et une entreprise doit obtenir des réponses aux deux.
La première est de savoir si l'agent a été manipulé. L'injection de requêtes (prompt injection) et le jailbreaking sont des techniques réelles, et c'est au niveau de la protection du modèle qu'elles sont détectées. Une organisation qui exécute des agents sans cette protection laisse une porte grande ouverte.
La seconde est de savoir ce que l'agent peut réellement faire et si ses actions actuelles restent dans le périmètre autorisé. L'exemple de la banque illustre parfaitement ce second type de problème. Aucune de ces découvertes n'impliquait une requête manipulée. L'agent n'a pas été piégé. Il s'est comporté exactement comme on lui a demandé, et le risque provenait de ses connexions et de ce qu'il était autorisé à atteindre. Un agent qui n'a jamais été attaqué peut tout de même causer des dommages graves si ses autorisations étaient trop larges au moment de son déploiement.
Aucune de ces questions n'est un sous-ensemble de l'autre, et aucune ne suffit à elle seule. C'est la raison pour laquelle il est préférable de les traiter ensemble plutôt que comme des programmes séparés.
Ce que l'intégration apporte aux clients communs
Grâce à l'application certifiée Salt sur CrowdStrike Falcon Foundry, les clients déploient Salt en utilisant leurs agents Falcon existants, sans passerelles, proxys ou configurations supplémentaires.
Gestion de la posture de sécurité agentique (AG-SPM) de Salt assure ensuite la découverte continue des agents dans l'environnement, des serveurs MCP et des outils auxquels ils se connectent, des API qu'ils peuvent appeler et des autorisations associées à chaque étape. Elle met en lumière ce qui n'aurait jamais dû être déployé : des serveurs MCP oubliés exposés sur l'internet public, des intégrations fantômes situées dans des dépôts privés, ou des API connectées aux agents qui n'ont jamais été examinées.
La détection et réponse agentiques (AG-DR) de Salt surveillent ces interactions en temps réel. Elle établit des bases de référence comportementales pour l'activité pilotée par les agents et détecte lorsqu'un agent dépasse son périmètre prévu, suit un chemin d'exécution non sécurisé, extrait des données dans un volume inadapté à sa fonction ou est manipulé pour effectuer une action non autorisée.
Les deux sont unifiés par le graphe de sécurité agentique de Salt, qui cartographie chaque relation découverte entre les agents, les serveurs MCP et les API pour offrir une vue unique de la manière dont un agent raisonne, se connecte et agit.
Ces résultats sont intégrés au SIEM nouvelle génération de CrowdStrike Falcon, où l'inventaire des agents, les conclusions sur la posture et les détections comportementales sont corrélés avec la télémétrie des terminaux, des identités et du cloud que les équipes collectent déjà dans Falcon. Lorsque Salt détecte un comportement qui s'écarte d'une base de référence établie, les clients peuvent déclencher des réponses automatisées via la gestion du pare-feu de CrowdStrike Falcon. Le résultat concret est un flux de travail unique plutôt qu'une console séparée pour la sécurité agentique.
À quoi cela ressemble en pratique
Revenons à l'agent bancaire. Avec une visibilité sur l'ensemble du parcours, la même requête produit une image de sécurité différente :
- Les serveurs MCP et les outils utilisés par l'agent sont inventoriés, y compris ceux qui n'ont jamais été officiellement déployés.
- Les API invoquées par ces connexions sont découvertes, ainsi que celles qui renvoient des données sensibles et celles qui manquent d'authentification.
- Les autorisations excessives accordées à l'agent sont mises en évidence en tant que constat de posture plutôt que découvertes après un incident.
- Des détections comportementales se déclenchent lorsque l'activité de l'agent s'écarte de sa base de référence établie.
- Le tout est centralisé dans le SIEM nouvelle génération de Falcon, aux côtés du reste de la télémétrie de sécurité.
L'organisation passe de la validation de ce que l'agent a dit à la compréhension de ce que l'agent a fait.
Pour commencer
Salt est disponible pour les clients CrowdStrike via un application Foundry certifiée qui exploite les agents Falcon existants, sans passerelles, proxys ou configuration supplémentaires. Salt est également intégré nativement à Falcon Next-Gen SIEM et peut déclencher une réponse automatisée via Falcon Firewall Management. Pour plus d'informations sur l'intégration Crowdstrike, cliquez ici.