SUDP : laisser un agent agir avec vos identifiants sans jamais les lui confier

De quoi s’agit-il ?

En mai 2026, des chercheurs de l’Imperial College London, d’Oxford et de Stanford ont publié SUDP : Secret-Use Delegation Protocol for Agentic Systems (préprint arXiv, version v2 datée du 1er mai 2026). Ce n’est pas une attaque. C’est une tentative de corriger l’un des angles morts de la sécurité des agents : que deviennent les clés d’API, les jetons OAuth et les clés de signature dont un agent a besoin pour agir concrètement ?

Le constat des auteurs est direct. La pratique d’ingénierie actuelle relève de l’autorisation par exposition : pour qu’un agent envoie un message, pousse du code ou appelle une API payante, on place un secret réutilisable — ou un artefact qui en dérive — à l’intérieur du runtime de l’agent. Or ce runtime est précisément la frontière que des entrées non fiables peuvent atteindre. Une injection de prompt passagère ou un outil compromis cesse alors d’être une action ponctuelle : elle devient une compromission durable du compte, puisque l’attaquant se retrouve à côté d’un identifiant réutilisable.

Comment ça marche

SUDP commence par nommer le problème sous-jacent comme une abstraction claire, que les auteurs appellent Agent Secret Use (ASU) : un demandeur autonome non fiable doit pouvoir provoquer une opération autorisée par l’utilisateur et adossée à un secret, sans jamais être exposé à une autorité réutilisable sur ce secret. Les interfaces à jeton porteur classiques ne peuvent satisfaire les deux moitiés — confier la clé à l’agent fonctionne mais fuit ; la lui retirer fait rejeter l’appel par le service.

Le protocole résout la tension en répartissant le travail entre trois rôles. Le Demandeur est le runtime de l’agent : il propose une opération précise et canonisée, et ne détient aucun secret. L’Autorisateur est l’utilisateur muni d’un authentificateur matériel (WebAuthn / FIDO) : il examine l’opération exacte proposée et émet une autorisation signée, fraîche, liée cryptographiquement à un hachage de cette opération, à usage unique, et désignant l’identifiant habilité à agir. Le Dépositaire détient le secret scellé, consomme l’autorisation exactement une fois pour réaliser l’action bornée auprès du service externe, puis efface la clé de la mémoire. Seul le résultat revient à l’agent.

La conséquence est tout l’intérêt de la conception : l’autorité réutilisable ne franchit jamais la frontière du demandeur. Comme chaque exécution est couverte par une autorisation fraîche, signée par l’utilisateur et liée à une seule opération canonique, des propriétés comme la résistance à la substitution, la liaison à l’opération et la résistance au rejeu tiennent par construction, et non par une relecture minutieuse du code. Même un agent entièrement détourné par injection ne peut au mieux que proposer une opération que l’utilisateur devra encore constater et approuver — jamais obtenir un identifiant réutilisable ailleurs ou plus tard.

Pourquoi c’est important

Ce protocole vise directement la branche « accès aux données privées » de la fameuse lethal trifecta, et à un niveau où la plupart des mitigations actuelles n’opèrent pas. Les séparateurs instruction/données, les moteurs de politique par outil, les bacs à sable et les garde-fous raisonnent sur ce que fait l’agent ou où il le fait ; SUDP contraint plutôt l’usage qu’un secret peut avoir, à la frontière où vit ce secret. Les deux approches se composent : un garde-fou comportemental qui échoue laisse tout de même l’attaquant borné par la portée de l’opération signée par l’utilisateur.

Les limites sont énoncées honnêtement dans le papier. SUDP offre la confidentialité de stockage et l’isolation des époques de clé sous des hypothèses explicites de scellement et d’effacement, mais la confidentialité persistante (forward secrecy) du secret sous-jacent exige toujours que l’environnement le fasse tourner et le révoque. Le protocole suppose aussi que le service externe accepte l’appel médiatisé par le dépositaire, et que l’utilisateur lit réellement l’opération qu’il approuve — un descripteur d’opération canonisé et lisible par un humain joue ici un rôle essentiel.

Défenses

Les enseignements pratiques dépassent ce seul protocole. Considérez « l’agent détient la clé d’API » comme un défaut de conception, pas comme une commodité : tout identifiant réutilisable placé dans un runtime pilotable par le modèle est à une injection d’une compromission durable. Préférez l’autorisation par opération à l’identifiant par session — liez l’approbation à une action précise et canonique plutôt que d’accorder à l’agent une autorité permanente pour toute une tâche. Gardez les secrets derrière un médiateur (un dépositaire ou un proxy d’identifiants) qui les consomme en interne et ne renvoie que des résultats, de sorte que l’agent propose sans jamais posséder. Ancrez l’approbation humaine dans un authentificateur résistant au phishing et rendez l’opération approuvée lisible par la personne qui la signe. Enfin, continuez à faire tourner et à révoquer les secrets sous-jacents : la médiation limite le rayon d’impact, mais la forward secrecy du véritable identifiant dépend toujours de son retrait par l’environnement.

Statut

Aspect	Détail
Divulgation	Préprint arXiv (2604.24920), v2 datée du 1er mai 2026
Auteurs	Xiaohang Yu, Hejia Geng, Xinmeng Zeng, William Knottenbelt (Imperial College London, Oxford, Stanford)
Classe	Recherche défensive — protocole d’autorisation pour l’usage des secrets par les agents
Méthode	Formalisation du problème « Agent Secret Use » ; protocole à trois rôles (Demandeur / Autorisateur / Dépositaire) ; autorisations fraîches à usage unique liées à une opération canonique
Garanties	Autorisation vérifiable, liée à l’opération, à usage unique ; confidentialité du stockage et isolation des époques de clé sous hypothèses explicites
Limites énoncées	La forward secrecy en clair exige toujours la rotation/révocation côté environnement ; suppose que le service accepte l’appel médiatisé et que l’utilisateur relit l’opération
Exploité dans la nature	Sans objet — proposition de protocole défensif