Autoriser les étapes du workflow d'un agent, pas seulement son identité

De quoi s’agit-il ?

Le 20 juillet 2026, un groupe de chercheurs a publié sur arXiv (catégorie cs.CR, cryptographie et sécurité) un papier qui recadre un problème que la plupart des piles d’agents traitent mal. À mesure que les systèmes d’entreprise et d’administration deviennent des « infrastructures fondées sur le langage, outillées et de plus en plus autonomes », soutiennent les auteurs, le modèle de sécurité hérité de la gestion de clés classique ne convient plus. Un service de gestion de clés authentifie qui a le droit d’invoquer une primitive cryptographique : il vérifie une identité, puis remet la capacité. Ce qu’il ne fait pas, c’est décider quelle étape du workflow un appelant authentifié a le droit d’exécuter à l’exécution. C’est précisément là que l’agent devient dangereux : un agent qui a passé tous les contrôles d’identité peut encore être orienté, par injection de prompt directe ou indirecte, vers une action parfaitement valide pour son identité mais contraire à ce que l’utilisateur voulait réellement. La contribution du papier est une conception qui vise à combler cet écart — une couche de gouvernance placée entre le modèle et les outils privilégiés qu’il peut atteindre.

Comment ça marche

L’observation centrale est une distinction facile à brouiller dans la conception d’un agent : l’authentification n’est pas l’autorisation, et l’autorisation par agent n’est pas l’autorisation par étape.

La plupart des agents déployés lient le privilège à l’identité. L’agent (ou son compte de service) détient un jeton, une clé d’API ou une capacité de signature ; une fois l’agent authentifié, toute action qu’il émet hérite de ce privilège. C’est le modèle lui-même qui décide quel outil appeler et avec quels arguments, à partir d’un contexte en langage naturel qu’il a lu — messages de l’utilisateur, documents récupérés, sorties d’outils, messages inter-agents. Comme ce contexte est justement le canal que l’attaquant contrôle dans une attaque par injection de prompt, la décision d’agir peut être corrompue alors même que le justificatif utilisé pour agir reste tout à fait légitime. Les contrôles d’identité passent. L’intention est trahie. Aucun contrôle du type « qui êtes-vous » ne peut distinguer les deux.

La réponse proposée par le papier s’appelle Neural Cryptographic Services (NCS) — décrite comme un plan de gouvernance de sécurité actif, fondé sur une conception neuro-symbolique, et interposé entre les agents LLM et les outils privilégiés qu’ils invoquent. L’idée à retenir, indépendamment de l’implémentation précise, est architecturale : l’autorité devrait être liée à l’étape — une action précise, dans un workflow précis, cohérente avec l’intention exprimée par l’utilisateur — plutôt qu’à l’identité persistante de l’agent. Un point de contrôle qui médie chaque appel privilégié peut évaluer si cette action est autorisée maintenant, au lieu de supposer qu’un agent authentifié est un agent de confiance. Aucun exploit n’est reproduit ici ; la valeur réside dans le modèle du problème et le placement de la défense.

Pourquoi c’est important

C’est le même mode de défaillance qui resurgit sous des noms différents dans la recherche sur la sécurité des agents. Le flux de données est traité comme de l’autorité ; une instruction arrivée via un document ou une sortie d’outil est exécutée comme si l’utilisateur l’avait tapée ; un agent de code ou de navigation doté d’un jeton large fait quelque chose hors périmètre mais « dans les clous ». La contribution du papier est de nommer proprement la cause racine — la couche d’authentification est agnostique à l’intention du workflow — et de soutenir que le correctif appartient à un plan d’autorisation dédié plutôt qu’au jugement propre du modèle.

Cela compte surtout là où le rayon d’impact est le plus grand : agents raccordés à la gestion de clés, aux paiements, aux plans de contrôle cloud, ou aux back-ends d’entreprise et d’administration, où une seule action contraire à l’intention mais valide côté identité peut déplacer de l’argent, faire tourner un secret ou modifier un enregistrement. Pour ces systèmes, « l’agent s’est authentifié avec succès » n’est pas une propriété de sûreté. L’injection de prompt reste le risque le mieux classé dans le guide OWASP pour les applications LLM précisément parce qu’elle transforme un agent de confiance et authentifié en agent piloté par l’attaquant, sans jamais casser le moindre justificatif.

Défenses

La leçon pratique est de cesser de traiter l’identité d’un agent comme un substitut de son autorisation à agir. Placez un point de contrôle déterministe entre le modèle et tout outil privilégié, et faites-lui autoriser les actions à la granularité de l’étape de workflow — pas une seule fois à la connexion. Concrètement, cela signifie lier chaque appel privilégié à une intention explicite ancrée sur l’utilisateur et à l’étape du plan à laquelle il appartient, et rejeter les appels qui satisfont l’identité mais pas l’intention, une approche que l’on retrouve dans des travaux concurrents sur l’autorisation déterministe pré-action et les workflows agentiques authentifiés. Gardez l’application des règles hors du modèle : une politique dont on peut convaincre le LLM de sortir n’est pas un contrôle. Réduisez les justificatifs à la capacité la plus étroite et à la durée de vie la plus courte que l’étape exige, afin qu’une action même détournée-mais-authentifiée ait une portée limitée. Traitez les documents récupérés, les sorties d’outils et les messages inter-agents comme des entrées non fiables qui peuvent proposer des actions mais jamais les autoriser silencieusement. Et journalisez la décision d’autorisation, pas seulement l’appel d’outil, afin qu’un écart entre intention déclarée et action exécutée soit auditable après coup. Ces contrôles se composent avec le filtrage des entrées et les défenses anti-jailbreak, sans les remplacer : l’idée est que lorsque l’injection réussit, le plan d’autorisation est ce qui se dresse entre une décision corrompue et une action privilégiée.

Statut

Élément	Détail
Contribution	Cadrage + plan de gouvernance proposé pour l’autorisation par étape
Affirmation centrale	L’authentification (« qui ») n’autorise pas l’étape du workflow (« quelle action, maintenant »)
Menace	Injection de prompt directe/indirecte produisant des actions valides côté identité mais contraires à l’intention
Conception proposée	Neural Cryptographic Services (NCS) — plan de gouvernance neuro-symbolique entre agents et outils privilégiés
Placement	Point de contrôle déterministe interposé sur chaque appel d’outil privilégié
Date clé	Papier publié sur arXiv le 20 juillet 2026

Date clé : papier annoncé sur arXiv le 20 juillet 2026. Il s’agit d’une proposition de recherche, pas d’un produit fini ; l’enseignement durable est architectural — autorisez l’étape, pas l’identité.