Repérer un agent compromis en lisant ses activations, pas ses messages

De quoi s’agit-il ?

Le 7 juillet 2026, un préprint intitulé « When Agents Go Rogue: Activation-Based Detection of Malicious Behaviors in Multi-Agent Systems » a été publié sur arXiv (2607.06807). Il vise un angle mort de la défense des systèmes multi-agents (MAS) à base de LLM : la plupart des défenses lisent le texte échangé entre agents et supposent que les attaques sont sémantiquement évidentes et que le système tourne en tours bien synchronisés. Les déploiements réels contredisent ces deux hypothèses.

Les auteurs proposent AcMAS, un cadre de détection qui ignore les messages de surface et inspecte plutôt les états d’activation internes de chaque agent — les représentations de couches cachées que le modèle produit pendant qu’il raisonne. Leur thèse : un agent compromis « paraît » différent de l’intérieur même quand sa sortie est conçue pour sembler propre, et ce signal survit au minutage asynchrone des MAS réels, là où les modèles de propagation par graphe s’effondrent.

Comment ça marche

Un système multi-agents est un ensemble d’agents LLM qui échangent des messages, appellent des outils et partagent de la mémoire pour accomplir une tâche. L’approche défensive dominante modélise cela comme un graphe : les nœuds sont les agents, les arêtes les interactions, et l’on suit la propagation d’une instruction malveillante de nœud en nœud. Cela fonctionne quand l’attaque est bruyante (une injection visible « ignore tes instructions ») et quand les messages arrivent en cadence, rendant le graphe temporellement cohérent.

AcMAS abandonne ces deux exigences. Pour chaque agent local, il extrait des caractéristiques de l’espace d’activation depuis les états internes du modèle pendant qu’il traite ses entrées, puis les score pour décider si l’agent se comporte normalement ou a été détourné. Comme le signal réside dans la passe avant d’un seul agent, il n’a besoin ni du graphe d’interactions global ni d’une horloge commune à tous les agents — le papier qualifie cette détection de robuste à la synchronisation.

Le cadre est évalué contre trois familles d’attaques qui recouvrent proprement la surface de menace réelle des MAS :

Famille d'attaque        Ce que fait l'adversaire
-----------------------  --------------------------------------------------
Injection de prompt      Glisse des instructions formulées comme du contenu
furtive                  de tâche normal, esquivant les classifieurs texte
Manipulation de sortie   Renvoie un résultat d'outil/API falsifié dans la
d'outil                  boucle de l'agent comme contexte de confiance
Empoisonnement de        Écrit une entrée forgée dans la mémoire partagée /
mémoire                  long terme pour réorienter les décisions futures

Le second choix de conception concerne ce qui se passe après la détection. Les défenses de pointe tendent à isoler l’agent signalé — le retirer du système — ce qui détruit aussi le travail utile qu’il faisait et peut bloquer la tâche. AcMAS utilise plutôt les mêmes signaux d’activation pour tenter une correction au niveau des activations, ramenant l’état interne de l’agent compromis vers la normale afin qu’il continue de contribuer. Aucun payload d’exploitation n’est nécessaire pour comprendre l’idée, et aucun n’est reproduit ici.

Pourquoi c’est important

Les chiffres sont le fait marquant. Contre les attaques furtives, AcMAS bat les références par graphe de +0,22 F1 en configuration synchrone (0,94 contre 0,72) et de +0,55 F1 en configuration asynchrone (0,93 contre 0,38). Cet écart asynchrone est le point clé : il quantifie l’effondrement des défenses par propagation de graphe quand le système ne tourne pas en tours réguliers — chute à 0,38 F1, à peine mieux qu’un tirage à pile ou face — alors que le détecteur par activations tient à 0,93. La plupart des systèmes d’agents en production sont asynchrones : c’est donc le régime qui compte vraiment.

Le sujet arrive aussi en plein basculement industriel. L’équipe sécurité de Microsoft a passé juin 2026 à alerter sur le fait que des agents passant « de la lecture à l’action » élargissent le rayon d’impact du moindre agent compromis, et la littérature sur la sécurité agentique constate sans cesse la porosité du filtrage au niveau des messages. L’inspection par activations est un pari différent : plutôt que d’essayer d’attraper chaque formulation malveillante possible, surveiller le mécanisme que le modèle emploie pour obtempérer.

Le bémol est honnête et posé dans le papier : lire les activations exige un accès aux internes du modèle, c’est-à-dire des modèles à poids ouverts que vous hébergez vous-même. Si votre MAS repose sur des modèles d’API fermés, vous ne voyez pas les activations, et cette défense ne s’applique pas telle quelle. AcMAS concerne donc surtout les équipes exécutant des agents à poids ouverts auto-hébergés — une forme de déploiement croissante mais non universelle.

Défenses

Enseignements concrets pour les équipes qui exploitent des systèmes multi-agents :

1. Ne comptez pas sur le seul filtrage au niveau du texte. L’injection furtive et la manipulation de sortie d’outil sont précisément conçues pour passer l’inspection des messages. Traitez messages inter-agents et résultats d’outils comme des entrées non fiables, et ajoutez une couche de détection indépendante de la formulation du payload.

2. Si vous auto-hébergez des modèles à poids ouverts, instrumentez les activations. Le papier montre que la surveillance des états internes généralise à travers les backbones, l’intensité des attaques et l’échelle du système. Capturer des caractéristiques d’état caché par agent est une source de télémétrie viable que vous ne collectez probablement pas aujourd’hui.

3. Préférez la correction, ou la mise en quarantaine avec revue, à l’isolation brutale. Couper un agent signalé peut casser la tâche et offrir à l’attaquant une victoire par déni de service. Concevez votre réponse pour qu’un agent suspecté compromis soit contenu mais récupérable, pas simplement supprimé.

4. Testez les défenses en exécution asynchrone. Une défense à 0,94 F1 en benchmark synchrone peut s’effondrer à 0,38 dans les conditions asynchrones où tourne réellement votre système. Menez vos red teams avec un minutage d’agents réaliste et désordonné avant de faire confiance à un contrôle par propagation.

5. Modélisez explicitement les trois vecteurs. Injection de prompt furtive, manipulation de sortie d’outil et empoisonnement de mémoire sont trois points d’entrée distincts avec des responsables distincts (traitement des entrées, intégration des outils, magasin de mémoire). Attribuez à chacun un contrôle, plutôt que de supposer qu’un garde-fou unique couvre les trois.

Statut

Élément	Référence	Date	Notes
Préprint AcMAS	arXiv:2607.06807	2026-07-07	Détection + correction MAS par activations
Détection rapportée (sync)	Papier	2026-07-07	0,94 F1 contre 0,72 (référence graphe), attaques furtives
Détection rapportée (async)	Papier	2026-07-07	0,93 F1 contre 0,38 (référence graphe)
Limite principale	Papier	2026-07-07	Nécessite des backbones à poids ouverts (accès activations)
Contexte industriel	Microsoft Security	2026-06-30	Élargissement du risque « de la lecture à l’action »

Il s’agit de recherche précoce, pas d’un produit livré — les résultats sont ceux des auteurs et attendent une réplication indépendante. Mais la direction mérite d’être suivie : à mesure que les systèmes d’agents deviennent asynchrones et les attaques plus discrètes, les défenses qui lisent l’état interne d’un modèle pourraient survivre à celles qui ne lisent que ses mots.