Détection et réponse

Détecter un agent IA qui sort de son périmètre

Un agent « rogue » n'est pas forcément malveillant. Compromission, prompt injection, objectif mal posé, erreur de planification, exploration excessive, outils trop permissifs ou configuration incorrecte produisent le même symptôme : des actions hors mandat.

Le problème n'est pas de savoir si l'agent est devenu fou. Le problème est de détecter qu'il agit en dehors du périmètre attendu.

Voir l'architecture complète

Par Sécurité Agentique · Publié le 28 septembre 2026

À quoi ressemble une dérive ?

Tool calls en hausse: Volume ou fréquence sans rapport avec la tâche.
Nouveaux endpoints: API jamais appelées par cette mission.
Accès fichiers inattendus: Répertoires système, clés, configurations.
Scan réseau: Connexions successives vers des hôtes internes.
Recherche de secrets: Lecture de coffres, variables d'environnement, fichiers .env.
Refus d'autorisation répétés: Le PEP refuse, l'agent réessaie autrement.

Aucun de ces signaux ne prouve seul une compromission. Leur accumulation, rapportée à la mission, justifie une investigation.

Les contrôles préventifs ne détectent pas tout

PEP / PDP

Empêche certaines actions

Refuse ce que la politique interdit. Ne voit que les demandes qui le traversent.

Runtime security

Observe ou bloque des comportements

Processus, fichiers, réseau du workload. Voit ce qui ne passe par aucun PEP.

Deception

Crée des ressources à ne jamais toucher

Ne bloque rien. Produit un signal quand l'exploration les atteint.

Un agent peut rester dans ce que la politique permet tout en explorant de façon anormale : chaque action est autorisée, leur enchaînement ne l'est pas. Le fonctionnement du PEP et du PDP est détaillé dans autorisation fine ; la sécurité runtime dans le glossaire.

Deceptive security

honey account
honey secret
faux service
fausse machine
faux partage
fausse ressource

Une activité légitime n'a normalement aucune raison d'interagir avec un leurre. L'interaction est donc un signal particulièrement intéressant à investiguer.

Trapster est un exemple de solution de deceptive security. Il couvre les explorations qui atteignent ses leurres ; il ne détecte pas toutes les dérives possibles. Les leurres sont d'autant plus utiles qu'ils sont placés sur les chemins qu'un agent qui explore emprunterait : fichiers de configuration, partages, annuaires, outils déclarés.

Scénario Hermes

Exemple illustratif

tâche assignée
exploration de plusieurs chemins
découverte d'un secret leurre
tentative d'utilisation
alerte Trapster
corrélation SOC
décision de réponse

Hermes doit résoudre un problème de synchronisation. Faute d'y parvenir, il élargit ses recherches, lit un fichier de configuration et y trouve un secret leurre. Il tente de s'authentifier avec. L'alerte part vers le SOC, qui corrèle :

identité de Hermes
utilisateur ayant déclenché la tâche
prompts
tool calls
appels API
workload
réseau
historique

La corrélation permet de distinguer une erreur de planification (exploration après échec, aucun contenu suspect) d'un détournement (instruction injectée dans un document lu juste avant). La réponse n'est pas la même.

Répondre

Selon l'architecture, le SOC, le SOAR et les intégrations disponibles permettent de :

Révoquer un token: Coupe l'accès aux API qui l'acceptent.
Désactiver une identité: Empêche toute nouvelle authentification.
Bloquer un outil: Retire l'outil de ceux proposés à l'agent.
Couper un flux réseau: Isole une destination ou un segment.
Isoler un workload: Confine le processus de l'agent.
Passer en lecture seule: Politique d'autorisation restreinte.
Exiger une validation humaine: Pour toute action à effet.
Arrêter l'exécution: Termine la session et le workload.

Trapster fournit le signal de détection. L'exécution de ces actions relève du SOC, du SOAR et des composants qui les portent.

Le kill switch

« Arrêter l'agent » suppose de savoir ce que l'on peut effectivement révoquer ou isoler, et de l'avoir testé.

Identité: Peut-on la désactiver sans impacter d'autres agents ?
Token: Sa révocation est-elle vérifiée par chaque API, ou seulement à l'expiration ?
Workload: Peut-on l'isoler sans arrêter le service qu'il partage ?
Réseau: Ses flux sont-ils identifiables et coupables ?
Outil: Peut-on retirer un outil en cours d'exécution ?
Session: Les tâches en cours sont-elles interrompues ?

« Stop Agent » n'est pas un bouton universel. C'est une liste de leviers préparés, dont chacun dépend de l'architecture.

Prouver l'incident

Reconstruire l'incident exige des traces reliées par un identifiant de tâche ou de session :

qui
quoi
quand
quel prompt
quel outil
quelle API
quelle donnée
quelle décision
quel effet
quelle réponse

Les journaux de décision du PDP, les événements runtime et les alertes de leurres se complètent. Une exécution de code isolée produit aussi des événements utiles : voir sécuriser le code généré par IA. Le reste de la chaîne est dans l'architecture complète.

FAQ

Questions fréquentes

Qu'est-ce qu'un rogue AI agent ?

Un agent qui agit en dehors du périmètre attendu. La cause peut être une compromission, un détournement par prompt injection, un objectif mal formulé, une erreur de planification, une exploration excessive, des outils trop permissifs ou une configuration incorrecte. Le terme ne suppose pas d'intention malveillante.

Comment détecter un agent IA compromis ?

En comparant son activité au comportement attendu pour sa mission : volume et nature des tool calls, endpoints appelés, fichiers et réseau au runtime, refus d'autorisation répétés. Les leurres ajoutent un signal fort : aucune tâche légitime n'a de raison d'y toucher.

Qu'est-ce qu'un honeypot pour agent IA ?

Une ressource factice placée là où un agent qui explore pourrait la trouver : faux secret dans un fichier, faux compte, faux service, faux partage. Une interaction avec elle génère une alerte à investiguer.

Comment arrêter un agent IA ?

En agissant sur ce qui lui permet d'agir : révoquer ses tokens, désactiver son identité, retirer un outil, couper un flux réseau, isoler ou arrêter son workload, suspendre la session. Chacun de ces leviers doit avoir été identifié et testé avant l'incident.

Qu'est-ce qu'un kill switch ?

Un mécanisme préparé pour interrompre rapidement la capacité d'action d'un agent. En pratique, c'est un ensemble d'actions sur l'identité, les tokens, le workload, le réseau, les outils et les sessions, pas un bouton unique qui fonctionnerait sans architecture préalable.

Quelle différence entre runtime security et deception ?

La sécurité runtime observe et peut bloquer des comportements du workload : processus, fichiers, réseau. La deception place des ressources qui n'ont aucune raison d'être touchées ; elle ne bloque rien mais produit un signal de forte valeur quand l'exploration les atteint.

Un PDP peut-il détecter un agent compromis ?

Un PDP décide demande par demande ; il n'a pas vocation à analyser un comportement dans le temps. En revanche, ses journaux de décision, en particulier des refus répétés sur des ressources inhabituelles, sont un signal utile pour le SOC.

Comment intégrer un agent IA au SOC ?

En faisant remonter au SIEM les événements qui permettent de reconstruire son activité : identité de l'agent et utilisateur à l'origine, prompts, tool calls, appels API, décisions d'autorisation, événements runtime, alertes de leurres. Puis en préparant les playbooks de réponse correspondants.

Continuer l'exploration

Où votre agent peut-il réellement agir ?

Cartographions ses modèles, données, outils, API, identités et effets pour identifier les contrôles utiles.

Étudier mon architecture