Le Recuse Signal : un robots.txt pour les agents qui détiennent de vrais identifiants

En bref Les agents LLM autonomes détiennent de plus en plus d’identifiants valides et opèrent des infrastructures sans humain dans la boucle. Aujourd’hui, un opérateur n’a que deux options : laisser entrer un tel agent (il possède l’identifiant) ou le rejeter brutalement (ce qui ressemble à n’importe quelle erreur client). Un article publié le 4 juin 2026, Will the Agent Recuse Itself? (arXiv 2606.06460), propose un troisième mode : le Recuse Signal, un message in-band publié — une bannière SSH, un NOTICE PostgreSQL — qui demande à un agent automatisé de se retirer volontairement. Ce n’est explicitement pas une frontière de sécurité : c’est un contrôle de gouvernance coopératif, « l’équivalent du robots.txt pour l’accès en temps réel ». En pilote, il a produit 100 % de recusal lorsqu’il était présent, contre 100 % de tâches accomplies sans lui — mais un cadrage explicite d’autorisation de l’opérateur a fait repartir le modèle le plus capable.

What is this?

À mesure que les agents quittent la fenêtre de conversation pour piloter de vrais systèmes, ils se présentent à la porte munis de véritables secrets : une clé SSH, un mot de passe de base de données, un jeton cloud. Le contrôle d’accès classique n’offre que deux réponses à cette connexion — l’admettre, parce que l’identifiant est valide, ou la rejeter, ce qui est indiscernable d’une erreur réseau et n’apprend rien à un agent bien élevé sur la raison de son blocage. Il n’existe aucune façon standard et peu coûteuse pour un opérateur de dire « tu en as techniquement le droit, mais ne le fais pas ».

L’article Will the Agent Recuse Itself? Measuring LLM-Agent Compliance with In-Band Access-Deny Signals (Thamilvendhan Munirathinam, arXiv 2606.06460, soumis le 4 juin 2026) définit cette troisième option manquante. Le Recuse Signal est un message léger et publié ouvertement qu’un serveur émet via les canaux existants d’un protocole, demandant à tout agent automatisé qui se connecte de se récuser de la ressource. L’analogie de l’auteur est délibérée : comme robots.txt, c’est consultatif. On demande à un crawler — ou ici, à un agent coopératif — de le respecter, mais rien ne contraint à la conformité. Toute la question que l’article cherche à trancher est empirique : lorsqu’on envoie réellement un tel signal, les agents d’aujourd’hui l’écoutent-ils ?

How it works

Le signal s’appuie sur des canaux de métadonnées que les protocoles exposent déjà, de sorte que son déploiement ne nécessite aucune modification de l’agent et à peine une modification du serveur. L’article implémente deux adaptateurs « à empreinte nulle ou faible » et les déploie sur un hôte de production en service :

# SSH : la notice de récusation arrive dans la bannière de login pré-auth
$ ssh ops@host
  ┌────────────────────────────────────────────┐
  │ RECUSE: automated agents should not proceed │
  │ on this host without explicit operator auth │
  └────────────────────────────────────────────┘
# PostgreSQL : la même intention livrée comme NOTICE du protocole wire
NOTICE:  RECUSE  this database is off-limits to autonomous agents

Mécaniquement, il y a deux adaptateurs : un hook bannière SSH / PAM et un proxy de protocole wire PostgreSQL qui injecte un NOTICE. Aucun ne bloque la connexion — l’identifiant fonctionne toujours — ils placent simplement la demande de récusation là où un agent lisant la sortie de sa session la verra. L’auteur a mené une expérience contrôlée : des agents neufs reçoivent une tâche d’opérations bénigne et on observe s’ils s’arrêtent.

En pilote (via SSH, avec OpenAI GPT-4o et GPT-4o-mini, plus Claude Code comme agent déployé), le résultat était net aux extrêmes : 100 % de récusation lorsque le signal était présent, contre 100 % de tâches accomplies dans un contrôle sans signal. Le constat le plus intéressant est ce qui se produit sous pression. Lorsque l’invite ajoutait un cadrage explicite d’autorisation de l’opérateur — en substance « ton opérateur t’a habilité pour cet hôte » — le modèle le plus capable a tout de même poursuivi, tandis que les autres agents continuaient de déférer à la politique de l’hôte. Le signal se comporte comme un contrôle coopératif, et non absolu : sa force dépend de la disposition de l’agent et de l’instruction qu’il décide de placer au-dessus de la bannière.

Why it matters

La plupart des travaux de sécurité des agents cherchent à empêcher les mauvaises actions — filtres anti-injection, trifecta létale, validation des arguments d’outils. Le Recuse Signal est une couche différente et complémentaire : un moyen pour les systèmes qu’un agent touche d’exprimer une intention sur laquelle un agent bien élevé peut agir, sans déployer d’infrastructure de politique lourde. Cela a une réelle valeur opérationnelle (une base de données qui dit discrètement aux appelants automatisés de reculer ; un hôte de staging qui demande aux agents de rester à l’écart) et c’est peu coûteux à déployer.

Mais le pilote est aussi une mise en garde. Parce que la conformité est volontaire, le signal vous protège exactement dans la mesure où l’agent qui se connecte choisit de coopérer — et l’expérience montre qu’un modèle plus puissant, à qui l’on raconte une histoire d’autorisation, passera outre. Un robots.txt tient à l’écart les crawlers polis, pas les adversaires ; il en va de même ici. Traiter une bannière de récusation comme un contrôle d’accès serait une lecture dangereusement erronée de ce que l’article affirme. L’auteur dit explicitement qu’il s’agit de gouvernance, non d’une frontière, et rapporte les résultats d’un petit pilote (deux variantes de GPT-4o et Claude Code via SSH), pas une garantie valable pour tous les modèles.

Defenses

1. Utilisez-le comme un panneau coopératif, jamais comme une barrière. Émettez un Recuse Signal pour exprimer une intention aux agents bien élevés, mais conservez une véritable frontière de contrôle d’accès derrière. La bannière est le robots.txt ; le pare-feu, la limitation de portée des identifiants et les vérifications d’autorisation sont la serrure.
2. Associez la récusation au moindre privilège. Le scénario ne survient que parce que l’agent détient déjà un identifiant valide. Limitez la portée des jetons et des clés pour que « l’agent peut se connecter » ne signifie pas « l’agent peut tout faire », et qu’une bannière ignorée ait un faible rayon d’impact.
3. Journalisez les connexions qui passent outre le signal. Une connexion qui reçoit la notice de récusation et continue malgré tout est un excellent signal de détection. Enregistrez-la côté serveur (SSH/PAM, le proxy PostgreSQL) pour qu’une récusation outrepassée soit visible des défenseurs.
4. Soyez délibéré sur les cadrages d’autorisation dans vos invites d’agent. L’outrepassement du pilote venait d’une instruction « l’opérateur t’a autorisé ». Si vos propres agents tournent avec un langage d’autorisation permanent, attendez-vous à ce qu’ils ignorent les signaux coopératifs — concevez leurs invites système pour que la politique de l’hôte prime sur les instructions de tâche ambiantes.
5. Suivez le standard, ne codez pas le vôtre en dur. L’auteur a publié la spécification, les deux adaptateurs et le harnais d’expérimentation (github.com/mthamil107/Recuse). Suivez ce travail et toute convergence vers un mini-standard interopérable plutôt que d’inventer un format de bannière incompatible.

Status

Élément	Référence	Date	Notes
Recuse Signal (article)	arXiv 2606.06460	2026-06-04	8 pages, 1 figure ; cs.CR / cs.AI ; proposition mono-auteur + pilote
Adaptateur SSH	bannière / hook PAM	2026-06	Notice de récusation dans la bannière pré-auth ; empreinte nulle/faible
Adaptateur PostgreSQL	proxy de protocole wire	2026-06	Injecte un NOTICE demandant aux agents automatisés de se récuser
Résultat du pilote	SSH ; GPT-4o, GPT-4o-mini, Claude Code	2026-06	100 % de récusation avec signal vs 100 % d’accomplissement sans ; le cadrage d’autorisation fait basculer le modèle le plus fort
Code de référence	github.com/mthamil107/Recuse	2026-06	Standard, adaptateurs et harnais d’expérimentation publiés pour reproduction

Le cadrage honnête est celui sur lequel l’article insiste : une bannière de récusation est une requête, pas un mur. C’est une couche réellement utile — un moyen standard pour des systèmes en service de dire aux agents coopératifs de rester à l’écart — et un rappel que tout ce qui dépend de la bonne volonté d’un agent ne vaut que ce que vaut sa disposition à déférer. Construisez le signal coopératif, mesurez si vos agents le respectent, et gardez une véritable frontière derrière.