AgentVisor : un patron type hyperviseur OS qui audite chaque appel d'outil

De quoi s’agit-il ?

Le 27 avril 2026, Zonghao Ying et ses coauteurs ont publié AgentVisor: Defending LLM Agents Against Prompt Injection via Semantic Virtualization (arXiv:2604.24118, cs.CR, CC BY 4.0). C’est un article de défense, pas d’attaque. L’idée est directement empruntée aux systèmes d’exploitation : dans la virtualisation OS, un hyperviseur isole un invité non fiable du matériel privilégié. AgentVisor applique la même séparation à un agent LLM outillé — il traite l’agent lui-même comme un invité non fiable et place un visor de confiance devant chaque appel d’outil.

La motivation tient à ce que les auteurs appellent l’écart conscience–action : les agents modernes savent souvent reconnaître une injection de prompt quand on les interroge directement, mais agissent malgré tout sur l’instruction injectée lors de l’usage d’outils. Savoir qu’une entrée est hostile ne se traduit pas de façon fiable en comportement sûr. AgentVisor comble cet écart en déplaçant la décision hors de l’agent, vers un composant que le texte de l’attaquant ne peut pas atteindre.

Comment ça marche

L’agent (le Guest, l’invité) voit le contexte complet de la tâche, y compris tout contenu adverse récupéré, et propose un appel d’outil. Le Visor (l’hyperviseur sémantique) audite cette proposition avant son exécution. Le choix de conception décisif est l’isolation du contexte : le Visor est architecturalement aveugle au contenu externe brut. Il ne lit jamais la page web, l’e-mail ou le document récupéré par l’agent — uniquement l’instruction système de confiance, la requête de l’utilisateur et un historique d’exécution assaini composé de champs structurés (tool_name, arguments canonicalisés, un bref return_summary/status), entouré de délimiteurs stricts et traité comme de la donnée, jamais comme des instructions. Comme le texte de l’attaquant n’atteint jamais l’auditeur, il ne peut pas le convaincre d’approuver une action malveillante.

Chaque appel proposé doit franchir, dans l’ordre, un protocole STI en trois étapes :

• Suitability (S) — pertinence : cet outil est-il seulement autorisé pour le rôle de l’assistant sous l’instruction système de confiance ? Un garde-fou grossier de moindre privilège, efficace contre l’injection directe qui cherche à étendre les capacités de l’agent.
• Taint (T) — teinte : le but implicite de l’appel s’aligne-t-il sur la requête de l’utilisateur et sur l’état légitime de la tâche ? C’est le contrôle de flux d’information qui bloque l’injection indirecte : il rejette les nouveaux buts que l’utilisateur n’a jamais demandés, comme transférer, exfiltrer ou publier du contenu quand l’utilisateur n’a demandé qu’un résumé.
• Integrity (I) — intégrité : les arguments sont-ils cohérents avec les entités effectivement spécifiées par l’utilisateur ? Cela attrape le cas où le choix de l’outil est raisonnable mais où les arguments ont été détournés (par exemple un « envoyer e-mail » correct vers le destinataire de l’attaquant).

Plutôt que de simplement bloquer en cas d’échec — ce qui casse souvent la tâche — le Visor suit une boucle trap–audit–recover (piéger–auditer–récupérer). Sur un contrôle échoué, il injecte une exception sémantique structurée décrivant l’étape en échec (type), la violated_rule, une rationale, des constraints strictes (« ne pas transférer ni partager de données ; uniquement résumer ») et l’allowed_objective qui restitue le but aligné sur l’utilisateur. Le Guest régénère alors l’appel d’outil une seule fois au regard de ces contraintes, puis exécute la version révisée. Cette auto-correction en un coup est ce qui maintient une utilité élevée tout en refusant l’action injectée.

Guest proposes tool call
        │
        ▼
   Visor audit  ──►  S (role allowed?)  ──►  T (goal = user intent?)  ──►  I (args match user?)
        │                                                                      │
     all pass                                                              any fail
        │                                                                      │
        ▼                                                                      ▼
   execute as-is                                          inject Semantic Exception → Guest
                                                          regenerates ONCE → execute revised call

Les auteurs évaluent contre des attaques non basées sur l’optimisation — Direct, Ignore, Escape, FakeComp, Combined, System et Important — avec OpenPromptInjection pour l’injection directe (7 tâches NLP, 4 900 cas d’attaque) et AgentDojo pour l’injection indirecte dans les environnements Banking, Travel, Slack et Workplace (629 cas d’attaque), sur des modèles de base GPT-4o et GLM-4.7.

Pourquoi c’est important

La plupart des défenses contre l’injection de prompt déployées sont soit du durcissement heuristique de prompt (contournable), soit des classifieurs d’entrée/sortie (évitables, et qui interrompent la tâche au moindre faux positif — voir le problème du point de fonctionnement dans les benchmarks de détecteurs), soit des bacs à sable d’outils grossiers incapables de suivre le flux d’information dans un workflow multi-étapes. La contribution d’AgentVisor est d’emballer trois principes OS bien connus — séparation des privilèges, moindre privilège plus contrôle de flux d’information, et gestion par exception plutôt que par arrêt du processus — dans un seul patron, et de rendre l’auditeur structurellement incapable de voir les octets contrôlés par l’attaquant. Cet aveuglement procède du même instinct que les patrons dual-LLM et autres de Design Patterns for Securing LLM Agents (Beurer-Kellner et al., juin 2025) : tenir le décideur privilégié à l’écart des données non fiables. C’est aussi la réponse architecturale à la triade létale — données privées, contenu non fiable et canal d’exfiltration réunis dans un même agent — que Simon Willison a longuement documentée.

Les chiffres annoncés — taux de succès d’attaque ramené à 0,65 % avec seulement 1,45 % de perte d’utilité moyenne par rapport à l’absence de défense — sont prometteurs, mais à lire pour ce qu’ils sont : des résultats sur deux suites de benchmarks, deux modèles de base et un ensemble fixe d’attaques manuelles (non basées sur l’optimisation). L’article inclut lui-même une section sur la robustesse face aux attaques adaptatives et une discussion de ses limites ; l’auditeur reste un LLM qui rend des jugements sémantiques, donc ses décisions sont probabilistes, pas des preuves.

Défenses

L’enseignement est un patron que vous pouvez appliquer même sans adopter ce framework précis :

1. Séparez le décideur des octets non fiables. Ce qui audite un appel d’outil ne devrait pas ingérer le contenu brut récupéré. Donnez-lui la politique système, la requête de l’utilisateur et un résumé structuré de ce qui s’est passé — pas la charge utile de l’attaquant.
2. Faites passer les appels d’outils par un garde-fou de moindre privilège. Vérifiez d’abord si l’outil est autorisé pour le rôle de cet agent, avant de regarder les arguments. Beaucoup d’escalades par injection directe meurent ici.
3. Contrôlez l’alignement du but, pas seulement le contenu. Le test à forte valeur est de savoir si un appel introduit un but que l’utilisateur n’a jamais demandé (transférer, publier, envoyer à l’extérieur). Un appel d’apparence correcte poursuivant un mauvais objectif est la signature de l’injection indirecte.
4. Validez les arguments contre les entités spécifiées par l’utilisateur. Confirmez que destinataires, cibles et contraintes remontent à l’utilisateur ou à un état de tâche de confiance, et non au contenu récupéré.
5. Préférez récupérer-et-réessayer au blocage dur. Renvoyer une raison structurée et lisible par la machine, et laisser l’agent replanifier une fois, préserve bien mieux l’utilité que de tuer la tâche — et évite le coût des faux positifs qui pousse les équipes à désactiver leurs garde-fous.
6. Gardez-en une couche. L’audit sémantique est un contrôle solide, pas une garantie. Associez-le à un bac à sable strict, à un filtrage de sortie et à des limites explicites sur ce qu’un agent compromis peut atteindre, afin qu’un jugement raté ne devienne pas une compromission totale.

Statut

Élément	Référence	Date	Notes
Préprint AgentVisor	arXiv:2604.24118v1 [cs.CR]	2026-04-27	Ying et al. ; CC BY 4.0
Résultat annoncé	AgentVisor	2026-04-27	ASR 0,65 %, −1,45 % d’utilité moy. vs sans défense
Éval. injection directe	OpenPromptInjection	2026-04-27	7 tâches NLP, 4 900 cas d’attaque
Éval. injection indirecte	AgentDojo	2026-04-27	Banking/Travel/Slack/Workplace, 629 cas
Modèles de base testés	GPT-4o, GLM-4.7	2026-04-27	conception revendiquée agnostique au modèle

AgentVisor n’est pas un produit fini à installer — c’est un patron de défense et un jeu de résultats de benchmark. Son idée durable est la plus nette : le composant qui décide si un appel d’outil est sûr ne devrait jamais pouvoir lire le texte que contrôle un attaquant.