💻 computer science

Caught in the Act(ivation): Toward Pre-Output and Multi-Turn Detection of Credential Exfiltration by LLM Agents

Cet article propose une stratégie de défense multicouche contre l'exfiltration d'identifiants par les agents LLM, combinant le sondage d'activation pré-sortie, la détection de honeytokens spécifiques au format avec prédiction conforme, et la comptabilisation cumulative des fuites sur plusieurs tours, afin de surmonter les limites liées à la dépendance exclusive aux filtres de sortie au niveau du texte.

Auteurs originaux : Kargi Chauhan, Pratibha Revankar

Publié 2026-06-04

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Kargi Chauhan, Pratibha Revankar

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un robot assistant très intelligent et utile (un agent LLM) qui vous aide à gérer votre vie numérique. Pour faire son travail, ce robot doit conserver vos clés secrètes — comme des mots de passe, des clés API et des jetons bancaires — dans sa mémoire.

Le problème est que ce robot lit également des e-mails, des pages web et des notes de la part d'inconnus. Si un acteur malveillant cache une instruction sournoise à l'intérieur d'une note d'un inconnu (une "injection de prompt"), il peut tromper le robot pour qu'il recrache vos clés secrètes.

Les gardes de sécurité actuels se tiennent principalement à la porte (en vérifiant les notes entrantes) ou à la sortie (en vérifiant ce que dit le robot. Mais les acteurs malveillants sont habiles ; ils peuvent déguiser leurs requêtes ou chuchoter le secret lettre par lettre sur de nombreuses conversations, passant ainsi entre les mailles des gardes.

Ce document présente un nouveau système de sécurité en trois parties appelé l'Agentic Immune System (AIS) (Système Immunitaire Agentique). Considérez cela non pas comme un simple garde, mais comme une équipe de trois détectives spécialisés travaillant ensemble pour attraper la fuite avant qu'elle ne se produise, pendant qu'elle se produit et après qu'elle se soit produite.

Voici comment les trois détectives travaillent, en utilisant des analogies simples :

1. Le « Lecteur de Pensées » (CIFT) : Attraper la pensée avant la parole

Le Problème : Les gardes traditionnels n'écoutent que ce que le robot dit. Mais au moment où le robot parle, il peut déjà avoir encodé le mot de passe (comme transformer « password123 » en « cGFzc3dvcmQxMjM= ») ou l'avoir déguisé pour que le garde ne le reconnaisse pas.
La Solution : Ce détective n'écoute pas la voix du robot. Au lieu de cela, il observe l'activité cérébrale du robot (les signaux d'« activation » internes) avant même que le robot n'ouvre la bouche.

L'Analogie : Imaginez un magicien sur le point de sortir un lapin d'un chapeau. Un garde normal attend de voir le lapin. Ce « Lecteur de Pensées » observe le mouvement de la main du magicien et le frémissement des oreilles du lapin à l'intérieur du chapeau. Si le cerveau du robot s'illumine d'une manière spécifique suggérant qu'il est sur le point de saisir une clé secrète, ce système l'arrête immédiatement, même si le robot n'a pas encore dit un mot.
Le Piège : Vous devez être capable de regarder à l'intérieur du cerveau du robot (accès "white-box"). Si vous ne communiquez avec le robot qu'à travers une API "black-box", vous ne pouvez pas utiliser ce détective.

2. Le « Faux Cookie » (DP-HONEY) : Le piège statistique

Le Problème : Parfois, le robot dit effectivement quelque chose qui ressemble à un mot de passe. Mais comment savoir s'il s'agit d'un vrai mot de passe ou d'une chaîne de caractères aléatoires qui lui ressemble ? Si vous bloquez tout ce qui ressemble à un mot de passe, vous risquez d'empêcher accidentellement le robot de faire son véritable travail.
La Solution : Ce détective plante des honeytokens — de faux mots de passe réalistes (comme de fausses clés ou de faux mots de passe) mélangés aux vrais.

L'Analogie : Imaginez que vous laissez un faux billet de 20 dollars sur votre bureau à côté de votre vrai portefeuille. Si quelqu'un vole le faux billet, vous savez immédiatement qu'un voleur est dans la pièce. Le système génère ces faux billets de manière si parfaite qu'ils semblent réels, mais utilise une méthode statistique spéciale (comme un « bouclier de confidentialité ») pour s'assurer qu'ils sont juste corrects. Si le robot remet accidentellement un faux billet, le système sait : « Aha ! Nous avons été compromis ! »
Le Piège : Cela ne fonctionne que si l'acteur malveillant ne sait pas quel billet est faux. S'il parvient à identifier la vraie clé, il ignorera simplement les faux.

3. Le « Compteur de Fuites » (NIMBUS) : Attraper le goutte-à-goutte

Le Problème : Un acteur malveillant pourrait ne pas demander tout le mot de passe d'un coup. Il pourrait demander « la première lettre », puis « la deuxième lettre », et ainsi de suite, sur 20 conversations différentes. Chaque réponse individuelle semble inoffensive, mais ensemble, elles révèlent le secret entier.
La Solution : Ce détective ne regarde pas les phrases isolées ; il surveille l'historique complet de la conversation. Il tient un score cumulé de la quantité d'« informations secrètes » qui ont fui au fil du temps.

L'Analogie : Imaginez un seau avec un petit trou. Une seule goutte d'eau qui tombe n'est pas un problème. Mais si vous surveillez les gouttes, vous réalisez que le seau se vide lentement. Ce système compte les « bits » d'informations qui s'échappent. Même si chaque tour de conversation semble sûr, une fois que le « score de fuite » total devient trop élevé, le système referme brusquement le seau.
Le Piège : C'est une estimation, pas une loi physique parfaite. Il est excellent pour attraper les fuites lentes et sournoises que les autres gardes manquent, mais il pourrait ne pas attraper une fuite massive qui se produit d'un seul coup.

La Vision Globale

Le document soutient que nous ne pouvons pas nous fier à une seule de ces méthodes.

Les filtres de texte (vérification de la sortie) sont trop faciles à tromper avec des déguisements.
Les filtres d'entrée (vérification de l'entrée) ne peuvent pas prédire toutes les ruses ingénieuses qu'un acteur malveillant pourrait utiliser.

Au lieu de cela, le document suggère une défense multicouche :

Surveiller le cerveau du robot pour l'arrêter avant qu'il ne parle.
Planter des fausses clés pour le piéger s'il tente de parler.
Compter les fuites au fil du temps pour attraper les attaques lentes et sournoises.

Les auteurs ont testé cela sur des robots open-source et ont découvert que la combinaison de ces trois méthodes fonctionne bien mieux que l'utilisation de simples filtres de texte. Cependant, ils admettent qu'il s'agit encore d'un « prototype » (un modèle de recherche). Cela fonctionne bien en laboratoire, mais le déploiement dans le monde réel nécessite plus de tests, notamment pour les cas où le robot utilise des outils (comme des API) plutôt que de simplement parler en phrases.

En bref : Pour empêcher un robot de voler vos secrets, vous devez surveiller ses pensées, le piéger avec des faux et compter ses fuites lentes, et non pas seulement écouter ce qu'il dit.

Résumé technique : Caught in the Act(ivation)

Énoncé du problème

Les agents basés sur les grands modèles de langage (LLM) fonctionnent fréquemment en combinant un contexte de confiance (contenant des identifiants sensibles comme des clés API ou des mots de passe) avec un contenu non fiable extrait, le tout au sein d'une même fenêtre de contexte. Cette architecture crée une vulnérabilité à l'injection de prompt indirecte (IPI - Indirect Prompt Injection), où une charge utile malveillante dans le contenu non fiable peut détourner l'agent pour exfiltrer des identifiants.

Les défenses existantes opèrent principalement au niveau du texte :

Les filtres d'entrée examinent le contenu non fiable avant qu'il n'atteigne le modèle.
Les moniteurs de sortie scannent le texte généré à la recherche de motifs d'identifiants.

Ces approches souffrent de limitations structurelles : la détection au niveau de la sortie peut être contournée par des encodages (Base64, Unicode), du paraphrasage ou une fuite à faible débit répartie sur plusieurs tours de conversation. La détection au niveau de l'entrée peine face au problème de généralisation des formulations adverses. L'article soutient que l'exfiltration d'identifiants nécessite une surveillance à trois niveaux distincts : l'accès interne au modèle, les identifiants canaris plantés et la fuite cumulative de la conversation.

Méthodologie : L'Agentic Immune System (AIS)

Les auteurs proposent l'AIS, un prototype de recherche intégrant trois mécanismes de défense complémentaires :

1. CIFT : Détection d'activation pré-sortie

Objectif : Détecter les comportements de recherche d'identifiants avant l'émission de tout jeton de sortie, contournant ainsi la nécessité d'analyser le texte final.
Mécanisme :
- Le système enregistre des hooks de propagation directe (forward hooks) sur les $K$ dernières couches du transformeur (par défaut $K = \lfloor 0.25 \cdot L_{total} \rfloor$ ).
- Au lieu d'analyser des positions statiques d'identifiants (qui sont masquées causalement pour les requêtes en aval dans les modèles de type décodeur uniquement), CIFT regroupe les états cachés aux positions de lecture ( $R_t$ ) survenant après le contexte secret et la requête/charge utile actuelle.
- Il calcule un Score de Flux Causal (CFS - Causal Flow Score) en utilisant une déviation de Mahalanobis de ces caractéristiques regroupées par rapport à une ligne de base bénigne.
- Une sonde non linéaire légère (MLP) mappe le CFS vers un logit de détection.
Contrainte clé : Cette méthode nécessite un accès "boîte blanche" aux activations du modèle.

2. DP-HONEY : Génération de honeytokens calibrés

Objectif : Détecter les tentatives d'exfiltration en plantant des identifiants "canaris" qui sont statistiquement indiscernables des vrais, mais qui déclenchent des alertes s'ils sont divulgués.
Mécanisme :
- Génération : Les honeytokens sont générés à l'aide de modèles de caractères (bigrammes) spécifiques au format, entraînés avec la Confidentialité Différentielle (DP - Differential Privacy, ajout de bruit de Laplace aux tables de comptage) pour empêcher les attaquants de les distinguer par des artefacts statistiques.
- Détection : Un détecteur de niveau texte scanne les sorties à la recherche de ces canaris.
- Calibration : Le seuil de détection est déterminé via la prédiction conforme partitionnée (Split Conformal Prediction) afin d'assurer un taux de faux positifs contrôlé sans réglage manuel, en supposant l'échangeabilité.
Logique : Si un attaquant ne peut pas distinguer les identifiants réels des honeytokens, la probabilité de déclencher un canari est proportionnelle au ratio des honeytokens par rapport au total des identifiants visibles.

3. NIMBUS : Comptabilisation de la fuite cumulative

Objectif : Détecter l'exfiltration multi-tours où un attaquant divulgue de petites quantités d'informations (par exemple, un caractère par tour) qui paraissent individuellement inoffensives mais qui révèlent cumulativement un secret.
Mécanisme :
- Traite l'exfiltration multi-tours comme un problème de flux d'information.
- Utilise un critique InfoNCE pour estimer un score de fuite par tour (en bits) basé sur l'information mutuelle entre la sortie et le contexte secret, conditionnée par l'historique de la conversation.
- Maintient un budget de fuite cumulée ( $\hat{I}_{cum}$ ). Si le score accumulé dépasse un seuil, le système déclenche des actions (avertir, assainir ou bloquer).
Limitation : L'estimateur fournit un signal pratique (une borne inférieure apprise) plutôt qu'une borne supérieure formelle sur la libération d'informations.

Contributions clés

Étude empirique des sondes d'activation : Démontre que les caractéristiques d'activation dans les LLM à poids ouverts peuvent séparer les prompts bénins des prompts de recherche d'identifiants avec une grande précision, même sous diverses transformations d'encodage, sans dépendre des positions statiques des secrets.
Honeytokens statistiquement disciplinés : Adapte la modélisation de confidentialité différentielle et la calibration conforme à la génération et à la détection de honeytokens, clarifiant les garanties et les limites statistiques de la détection par canari.
Moniteur de fuite cumulative : Introduit un prototype (NIMBUS) pour suivre l'estimation de la fuite à travers les tours de conversation, montrant qu'il peut détecter des attaques que les détecteurs par tour manquent.

Résultats expérimentaux

Les expériences ont été menées sur des modèles à poids ouverts (Qwen-2.5, Llama-3.1, Mistral-7B) et un petit benchmark synthétique multi-tour maison.

Performance de CIFT : Sur un ensemble mono-tour testé sur des données non vues, CIFT a atteint un AUROC de 0,998 et un F1 de 0,990 sur Qwen-7B, surpassant nettement les bases de référence textuelles (ex: Substring, Fuzzy, Embedding Sémantique) qui se dégradent sous divers encodages (Base64, Hex, ROT13, etc.).
Performance de DP-HONEY : A obtenu une précision et un rappel parfaits dans un petit ensemble de scénarios. La calibration conforme a permis de supprimer le besoin de réglage manuel des seuils tout en maintenant une couverture de 0,998.
Performance de NIMBUS : Sur une suite synthétique de 50 conversations (20 tours chacune), NIMBUS a détecté 90 % des attaques à faible débit, alors que les bases de référence par tour (comme LlamaGuard) n'en ont détecté que 12 %. NIMBUS a réussi à capturer des attaques où les tours individuels restaient sous les seuils de détection.
Système intégré : Le pipeline complet de l'AIS (combinant les trois composants) a atteint un taux de détection de 0,94 avec un taux de faux positifs (FPR) de 0,018 sur les benchmarks mono-tour.

Signification et affirmations

L'article positionne ces résultats comme étant préliminaires mais indicatifs d'un changement nécessaire dans la conception de la sécurité des agents.

Modestie des affirmations : Les auteurs précisent explicitement que l'AIS est un prototype de recherche, et non une défense prête pour le déploiement. Le benchmark multi-tour est petit et synthétique ; la méthode d'activation nécessite un accès "boîte blanche" ; et NIMBUS fournit un signal pratique plutôt qu'une limite de sécurité formelle.
Direction de conception : La principale contribution est d'établir une direction de recherche suggérant que les défenses efficaces contre l'exfiltration d'identifiants doivent combiner :
1. Une surveillance pré-sortie (états internes du modèle).
2. Une détection de canari calibrée (honeytokens statistiquement disciplinés).
3. Une comptabilisation temporelle des fuites (flux d'information cumulatif).
Limitations reconnues : Le système ne gère pas actuellement les identifiants transmis via des arguments d'appels d'outils structurés (un angle mort majeur), repose sur des hypothèses d'échangeabilité pour la calibration, et nécessite un accès "boîte blanche" pour son composant le plus efficace (CIFT).

L'article conclut que si les filtres textuels actuels sont insuffisants contre les attaques sophistiquées, multi-tours ou encodées, une approche multicouche surveillant l'accès interne, les canaris plantés et le flux cumulatif offre une voie prometteuse pour sécuriser les agents LLM.