Agent libOS : faire du runtime, et non du wrapper d'outil, la frontière d'autorité

Dans la plupart des stacks d’agents actuelles, le fait que le modèle voie un outil write_file est exactement le même fait que celui du runtime ayant l’autorité d’écrire sur le disque. Un papier du 2 juin 2026, Agent libOS (arXiv:2606.03895, cs.OS), soutient que cette confusion est la raison structurelle pour laquelle la sécurité au niveau des wrappers échoue sans cesse — et esquisse un runtime où les deux sont délibérément séparés.

De quoi s’agit-il ?

Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents a été déposé sur arXiv par Yingqi Zhang le 2 juin 2026. Ce n’est ni une nouvelle attaque, ni un nouveau modèle. C’est un design de runtime : un substrat inspiré des library-OS, posé au-dessus d’un OS hôte classique, qui traite chaque agent comme un AgentProcess — un sujet ordonnançable doté d’une identité de processus, d’une filiation parent-enfant, d’un cycle de vie, de capacités explicites, d’une mémoire d’objets typée, de files d’approbation humaine, de points de contrôle et de journaux d’audit.

La règle centrale du papier tient en une phrase : les outils sont des wrappers façon libc ; les primitives du runtime sont la frontière d’autorité. Autrement dit, le schéma d’outil exposé au modèle n’est qu’une surface de commodité, comme un appel à la bibliothèque standard du C. Savoir si l’opération sous-jacente peut réellement toucher un fichier, un objet, l’horloge, un humain ou le registre d’outils se décide une couche plus bas, à la primitive, sous des capacités et une politique explicites.

Comment ça marche

Agent libOS scinde trois décisions qu’un registre d’outils classique fusionne en silence. La visibilité — le processus peut-il voir le schéma de l’outil — est régie par une table d’outils propre au processus. L’invocation — le processus peut-il soumettre cet appel — est vérifiée par un broker. L’autorité — l’opération résultante peut-elle atteindre une ressource protégée — est vérifiée par le gestionnaire de primitives. L’invariant qui en découle est brutal : la visibilité d’un outil n’implique pas l’autorité sur une ressource. Un processus peut voir write_text_file et ne détenir d’autorité d’écriture sur aucun chemin.

L’analogie OS est poussée jusqu’aux opérations de cycle de vie. spawn crée un enfant avec son propre namespace et une vue mémoire réduite à l’objectif, et non une copie de la transcription du parent. fork atténue la vue mémoire et le budget de l’enfant et, dans le prototype, n’hérite pas de l’autorité d’écriture fichier du parent sauf octroi explicite. exec remplace l’image et la table d’outils d’un agent mais conserve l’identifiant de processus et n’octroie pas automatiquement les capacités de la nouvelle image : il ne peut donc pas escalader. La mémoire d’objets suit la tradition object-capability : connaître le nom d’un objet stocké ne permet pas de le lire sans la capacité adéquate. Rien de tout cela n’est un comportement différentiable du modèle — c’est de la plomberie, appliquée de façon déterministe.

L’auteur est explicite sur le périmètre. Le prototype est un substrat Python avec ordonnancement asynchrone, mémoire d’objets locale au namespace, approbation humaine intégrée au runtime, octrois de permission à usage unique, outils Deno/TypeScript générés à la volée derrière un broker d’appels système, et une suite de 123 tests de régression couvrant le confinement, la révocation, l’atténuation au fork/exec et la « pureté des wrappers ». Ce n’est ni une isolation de niveau noyau, ni une vérification formelle, ni un planificateur qui marque davantage sur les benchmarks de tâches.

Pourquoi c’est important

Le modèle de menace est la partie à lire deux fois. Agent libOS vise précisément les modes de défaillance que le domaine redécouvre en boucle : l’injection de prompt qui induit un outil à haut risque, l’injection via la sortie d’outil qui modifie une décision ultérieure, l’évasion de chemin hors d’un espace de travail, la fuite de capacités via fork, les outils générés qui importent des API dangereuses, et la « confusion entre l’appartenance à la table d’outils et l’autorité sur une ressource externe ». Ce dernier point, c’est le Triangle Mortel et le problème du deputé confus énoncés comme un bug système plutôt qu’un bug de modèle.

Surtout, le papier ne prétend pas résoudre l’injection de prompt sémantique. Un document malveillant — du type systématisé pour la première fois par Greshake et al. en 2023 — peut toujours persuader le modèle de demander une action dangereuse. La revendication est plus étroite et plus honnête : cette demande heurte tout de même un contrôle de capacité, une politique, une approbation humaine si requise, et un enregistrement d’audit, à la frontière de la primitive. Les conteneurs et microVM protègent l’hôte du code non fiable, mais, comme le note le papier, ils ne décident pas par eux-mêmes quelle action interne au bac à sable est autorisée au nom de quel utilisateur. C’est l’écart que tente de combler Agent libOS, et c’est l’écart que des benchmarks comme AgentDojo montrent sans cesse traversé par les défenses au niveau des wrappers.

Défenses

Le design se lit comme une check-list applicable sans adopter le prototype.

1. Cessez de traiter le registre d’outils comme une liste de contrôle d’accès. Séparez « le modèle peut voir cet outil » de « cette opération est autorisée ». Si votre seule frontière est un wrapper qui appelle l’hôte directement, une instruction injectée qui atteint le planificateur atteint l’hôte.
2. Placez le contrôle de politique à la primitive, pas au prompt. Les opérations fichier, réseau, shell, horloge, objet et enregistrement d’outil doivent chacune passer par un gestionnaire qui consulte une capacité explicite avant d’agir — au même endroit que l’audit, pas dans une boîte de confirmation enveloppant une fonction.
3. Atténuez l’autorité au fork, au spawn et à la génération d’outils. Un enfant ou un outil généré à la volée doit démarrer avec moins d’autorité que son parent, jamais avec les droits ambiants du parent par défaut. C’est la version agentique de l’abandon de privilèges.
4. Faites que les noms ne soient pas des capacités. Découverte et autorité sont distinctes : savoir qu’un objet, un chemin ou un outil existe ne doit pas conférer le droit de l’utiliser.
5. Faites de l’approbation humaine et de l’audit des opérations de première classe, reprenables. L’approbation doit être une primitive bloquante que l’ordonnanceur reprend — pas un callback greffé sur une démo — et chaque octroi, refus et effet de bord doit laisser une trace de quelle autorité l’a permis. Cela se marie naturellement avec le fait de traiter la sortie d’outil comme non fiable et avec les contrôles d’atomicité sur les appels modifiant l’état.

Statut

Élément	Référence	Date	Notes
Papier déposé	arXiv:2606.03895v1	2026-06-02	cs.OS, CC-BY 4.0, auteur unique (Yingqi Zhang)
Artefact	Prototype Python	2026-06-02	Ordonnanceur asynchrone, mémoire d’objets, broker d’appels système, outils JIT
Évaluation	123 tests de régression	2026-06-02	Confinement, révocation, atténuation fork/exec, pureté des wrappers
Règle de design	Outils = libc ; primitives = frontière d’autorité	2026-06-02	Visibilité ≠ invocation ≠ autorité
Non-objectif explicite	Injection de prompt sémantique	2026-06-02	Le runtime contient l’effet, pas la tromperie
Filiation	Injection de prompt indirecte (Greshake et al.)	2023-02	Pourquoi la sécurité au niveau des wrappers est insuffisante

Agent libOS n’empêchera pas un modèle d’être trompé. Ce qu’il offre, c’est un point d’appui pour le moment où le modèle l’est : un runtime où la demande dangereuse doit encore franchir une capacité qui ne lui a jamais été octroyée. Pour les équipes qui déploient en 2026 des agents long-courriers maniant des outils, la contribution la plus utile du papier est le vocabulaire — visibilité, invocation, autorité — pour remarquer que les frameworks d’aujourd’hui fusionnent généralement les trois en un seul.