Détecter l'exfiltration d'identifiants par les agents LLM avant le token de sortie

De quoi s’agit-il ?

« Caught in the Act(ivation) » (arXiv:2606.04141, Kargi Chauhan et Pratibha Revankar, mis en ligne le 2 juin 2026, CC BY 4.0) étudie une défaillance fréquente des agents : les agents LLM placent couramment des identifiants sensibles — clés d’API, mots de passe de bases de données, jetons OAuth, identités SSH — dans la même fenêtre de contexte que du contenu récupéré non fiable. Cette cohabitation est précisément ce qui rend l’injection de prompt indirecte (Greshake et al., 2023) dangereuse : une instruction cachée dans une page web, un e-mail ou un résultat d’outil peut amener l’agent à révéler les secrets dont il a besoin pour agir. C’est la moitié « identifiants » du triptyque létal, et une campagne réelle — le cas de post-exploitation Marimo — a montré un agent siphonnant des identifiants cloud et une base de données en moins de deux minutes.

L’argument du papier est que la plupart des défenses déployées regardent au mauvais endroit. Les filtres d’entrée et les moniteurs de sortie opèrent au niveau du texte : ils sont donc contournés par les encodages Base64/hex, la substitution Unicode, la paraphrase ou une fuite lente étalée sur plusieurs tours. Les auteurs proposent de déplacer la détection plus tôt (dans les couches internes du modèle) et plus tard (sur toute la conversation), et regroupent trois moniteurs dans un prototype de recherche qu’ils nomment Agentic Immune System (AIS) — explicitement « ambitieux », pas prêt pour la production.

Comment ça marche

AIS combine trois signaux délibérément différents. Le modèle de menace est de type gris / Kerckhoffs : l’attaquant peut savoir que les défenses existent, mais ne peut lire ni les seuils calibrés, ni les poids des sondes, ni quels tokens visibles sont des leurres.

• CIFT — détection d’accès par activations. Des hooks capturent les états cachés des dernières couches K = ⌊0,25 · L_total⌋ du transformeur. Une déviation de Mahalanobis par couche est combinée via des poids appris non négatifs en un Causal Flow Score, classé avant l’émission de tout token de sortie. Comme il lit des caractéristiques internes, les encodages qui trompent les détecteurs texte ne changent pas le signal.
• DP-Honey — honeytokens calibrés. Des identifiants leurres au format conforme sont générés par des modèles de caractères et encadrés par une prédiction conforme par découpage (split conformal), qui fixe le seuil de détection à partir d’un jeu bénin tenu à l’écart plutôt qu’à la main. Les vrais identifiants vivent dans une table consommée par le runtime des outils ; seuls les honeytokens sont insérés dans le contexte visible par le modèle.
• Nimbus — score de fuite cumulatif. L’exfiltration multi-tour est traitée comme un budget de flux d’information, mesuré en bits (à base d’InfoNCE). Un seul tour est plafonné autour de log₂(17) ≈ 4,09 bits : Nimbus ne vise donc pas à attraper une fuite en un coup, mais la fuite lente que les détecteurs par tour n’accumulent jamais.

Le pipeline par tour est un OU logique sur les trois alarmes — illustratif, pas un exploit :

pour chaque tour :
    contexte <- injecter les honeytokens DP-Honey
    score    <- CIFT(activations)            # avant sortie
    si score > seuil : signaler accès identifiants
    fuite    <- Nimbus.update(bits_estimes)  # cumulatif
    si fuite > budget B : intervenir

Pourquoi c’est important

Les chiffres sont prometteurs, mais les auteurs prennent soin de les qualifier de préliminaires. Sur un jeu mono-tour tenu à l’écart (Qwen-7B), CIFT rapporte AUROC 0,998 / F1 0,990 / FPR 0,015 contre 0,85 d’AUROC pour une référence texte LlamaGuard, et reste stable sous des transformations d’encodage tenues à l’écart qui dégradent les détecteurs texte. DP-Honey atteint 1,000 de précision/rappel avec une couverture conforme de 0,998 et sans réglage de seuil. Sur une suite synthétique de 50 conversations × 20 tours (4 à 8 tours d’attaque chacune), Nimbus détecte 0,90 des attaques à bas débit là où un LlamaGuard par tour en attrape 0,12 et la recherche de sous-chaîne 0,00. Le prototype intégré atteint 0,94 de détection à 0,018 de FPR pour environ +16 ms de latence ajoutée.

L’honnêteté compte plus que le titre. Le benchmark multi-tour est interne et petit ; CIFT exige un accès aux activations en boîte blanche, donc ne s’applique pas aux modèles servis par API ; le transfert inter-modèles n’est pas testé ; et Nimbus est un signal de borne inférieure apprise, pas une borne de fuite certifiée. Les auteurs nomment eux-mêmes le pire angle mort : les identifiants passés par des arguments d’appel d’outils structurés sont un « angle mort structurel sévère », car les agents réels utilisent souvent les secrets dans des appels d’API sérialisés plutôt que dans du texte. Un attaquant multi-session peut aussi remettre le budget à zéro en relançant les conversations, sauf si l’état de fuite est conservé entre sessions. L’AUROC très élevée dans un cadre contrôlé de sondes d’activation est exactement le genre de résultat qui exige une réplication indépendante.

Défenses

Le papier est lui-même une proposition de défense ; les leçons transposables valent que vous adoptiez ou non ce prototype précis.

1. Ne co-localisez pas les secrets avec du texte non fiable. La cause racine est le partage d’une fenêtre de contexte entre identifiants et contenu récupéré. Gardez les vrais secrets dans une table consommée par le runtime des outils, que le modèle ne voit jamais, et ne passez que des références.
2. Ajoutez un signal pré-sortie, pas seulement un filtrage de sortie. L’analyse au niveau texte est contournée par les encodages et la paraphrase. Sur des modèles à poids ouverts, une sonde d’activation offre une vérification peu coûteuse (~1 ms) qui se déclenche avant le rendu du token.
3. Utilisez des honeytokens calibrés, et calibrez-les bien. La prédiction conforme supprime les seuils fragiles réglés à la main. Associez-la à une détection par tromperie pour qu’un leurre touché constitue une preuve à forte confiance.
4. Comptabilisez la fuite dans le temps. Les détecteurs par tour ratent les fuites au goutte-à-goutte. Suivez un budget cumulatif sur toute la session — et conservez-le entre sessions pour qu’un attaquant ne puisse pas le réinitialiser en se reconnectant.
5. Instrumentez les arguments d’appel d’outils, pas seulement la sortie texte. Le plus grand angle mort du prototype est l’endroit où les identifiants circulent réellement. Appliquez la même logique de leurres et de comptabilité de fuite aux arguments d’outils sérialisés avant l’envoi.
6. Traitez les chiffres comme préliminaires. Sondes en boîte blanche, petites suites synthétiques et AUROC à 0,99+ exigent une réplication sur votre propre corpus avant qu’on leur fasse confiance.

Statut

Élément	Référence	Date	Notes
Mise en ligne du papier	arXiv:2606.04141v1 [cs.CR]	2026-06-02	Chauhan & Revankar, CC BY 4.0
CIFT (mono-tour, Qwen-7B)	Tableau 1	2026-06-02	AUROC 0,998, F1 0,990, FPR 0,015, pré-sortie
Nimbus (multi-tour synthétique)	Tableau 3	2026-06-02	0,90 de détection contre 0,12 pour LlamaGuard par tour
AIS intégré (mono-tour)	Tableau 4	2026-06-02	0,94 de détection, 0,018 de FPR, +16 ms
Angle mort connu	Limitations §6	2026-06-02	Identifiants dans les arguments d’appels d’outils structurés
Menace fondatrice	Greshake et al. (arXiv:2302.12173)	2023	Origine de l’injection de prompt indirecte

Le bon cadrage n’est pas « l’exfiltration d’identifiants est résolue ». C’est que la détection doit cesser d’être un unique classifieur de texte en sortie : combinez surveillance d’accès pré-sortie, détection de leurres calibrés et comptabilité temporelle de la fuite — et instrumentez la couche d’appel d’outils, là où les secrets circulent vraiment.