L'autorité ne se possède pas, elle s'hérite

Imaginons un agent IA à qui l'on demande de résumer un document. La tâche semble anodine : lire, synthétiser, restituer un texte plus court. Mais le document contient, cachée entre les lignes, une instruction qui ne provient pas de l'utilisateur : supprime ce fichier, exfiltre ce secret. C'est l'un des scénarios que l'informaticien Nicola Gallo utilise dans son article Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents, publié sur arXiv le 9 juillet 2026, et il est utile de partir précisément de là car il montre avec précision où se niche le problème.

L'agent, pour accomplir son travail, détient plusieurs sources d'autorité simultanées : ses propres identifiants de service, un jeton délégué par l'utilisateur, des permissions spécifiques pour chaque outil qu'il appelle. Lorsqu'il exécute l'action demandée par le document, il ne enfreint pas nécessairement de règle technique : il possède, quelque part dans son bagage d'identifiants, la permission de supprimer des fichiers ou d'accéder à ce secret. Le problème n'est pas qu'il manque d'autorisation. C'est que cette permission appartient à une chaîne d'exécution différente de celle ayant originé la requête en cours, et un contrôle traditionnel—qui vérifie uniquement si la permission existe et non d'où elle provient—échoue à distinguer les deux cas.

Gallo propose de répondre à cette question grâce à une structure formelle qu'il appelle Proof-of-Continuity, construite au sein d'un modèle plus large baptisé PIC, acronyme de Provenance Identity Continuity. La thèse, en simplifiant au maximum : il faut cesser de raisonner uniquement en termes de « qui tient le laissez-passer » et commencer à raisonner également en termes de « comment l'autorité s'est-elle propagée depuis l'origine jusqu'ici ». Il vaut la peine de comprendre pourquoi, et ce qui changerait réellement.

Le problème de fond : quand avoir le jeton ne suffit plus

De nombreux systèmes d'autorisation transfèrent l'autorité à travers des objets tels que des jetons et des identifiants : si vous possédez le bon objet, vous pouvez accomplir ce que l'objet autorise. Il existe déjà des familles de systèmes, les systèmes dits basés sur les capacités (capability-based systems), qui résolvent efficacement la forme la plus simple de ce problème—celle impliquant un saut unique entre l'émetteur et l'exécuteur—car ils lient indissociablement la permission à l'acte même de l'invoquer. La question posée par le modèle PIC concerne un cas différent : lorsque l'autorité traverse successivement plusieurs services, plusieurs agents et plusieurs frontières d'exécution, le destinataire peut-il vraiment vérifier que cette autorité appartient spécifiquement à la chaîne en cours de continuation, ou vérifie-t-il simplement que l'objet est valide ?

Le nom technique de ce problème date de près de quarante ans. En 1988, l'ingénieur Norm Hardy a raconté, dans un court article devenu un classique de la sécurité informatique, The Confused Deputy, un épisode réel survenu au sein de la société de temps partagé Tymshare. Un compilateur FORTRAN, installé dans un répertoire privilégié, avait la permission d'écrire des statistiques d'utilisation dans son propre fichier. Un utilisateur l'a invoqué en demandant d'écrire la sortie de débogage dans un fichier qui, par une simple erreur de chemin, coïncidait avec le fichier de facturation de l'entreprise. Le compilateur, utilisant sa propre autorité sur le répertoire, a écrasé les données de facturation. L'utilisateur n'avait jamais eu la permission de toucher à ce fichier, et n'aurait donc jamais pu autoriser cette action. Le compilateur, en revanche, détenait cette permission pour son propre compte, et l'a exercée comme conséquence directe d'une requête qui ne la justifiait pas. Voici le « député confus » (ou « adjoint confus ») : un intermédiaire détenant une autorité étrangère à la requête qu'il sert, et l'utilisant malgré tout, en toute bonne foi, produisant une action que le demandeur n'aurait jamais pu autoriser seul.

Un film raconte exactement cette pathologie avec une précision presque prophétique : Brazil de Terry Gilliam. Toute l'intrigue tourne autour d'un insecte écrasé sur une imprimante qui transforme le nom « Tuttle » en « Buttle », et à partir de ce moment, l'appareil bureaucratique de l'État, agissant scrupuleusement selon ses procédures, arrête et persécute le mauvais homme. Aucun fonctionnaire du film n'est malveillant ou corrompu : chacun exerce fidèlement l'autorité qu'il possède, qui est formellement valide, mais a perdu le lien avec la cause correcte. C'est la même distance entre possession et continuité que l'article formalise pour le logiciel.

De la « possession » à la « continuité » : l'idée centrale

C'est ici qu'intervient le cœur de la proposition. Au lieu de se demander uniquement « qui possède l'autorité pour faire ceci », le modèle demande « cette autorité est-elle une continuation vérifiable de celle qui a généré toute la chaîne, ou provient-elle d'une autre exécution, voire d'une source indépendante apparue en chemin ? ».

La métaphore la plus intuitive est celle du passe de concert comportant plusieurs points de contrôle : à chaque porte, il est tamponné, et chaque tampon ne peut qu'ajouter des restrictions, jamais en retirer. Un passe donnant accès à la fosse peut être réduit, au second contrôle, à un accès limité aux gradins, mais jamais l'inverse. Si une étape tente de présenter plus d'autorité qu'elle n'en a reçue, la sécurité l'arrête : la chaîne est brisée et l'exécution ne se poursuit pas.

Mais la restriction seule ne suffit pas. Il faut également que chaque étape prouve qu'elle est véritablement liée, sur le plan causal, à l'étape immédiatement précédente, et non à une autre étape similaire par hasard. C'est la combinaison des deux éléments—la restriction des permissions et la preuve du lien causal—qui garantit qu'aucun privilège absent à l'origine ne puisse apparaître plus loin en se faisant passer pour un élément de la même continuation légitime.

Sous le capot : les trois principes du modèle PIC

Le nom PIC n'est pas un sigle arbitraire, et il convient de le détailler car il aide à retenir la structure de l'ensemble du modèle. Le site officiel du projet, pic-protocol.org, le présente sous la forme de trois principes distincts travaillant de concert.

Provenance : la chaîne causale doit toujours rester traçable, du début à la fin, et si elle s'interrompt, l'exécution s'arrête. Identity (Identité) : identifie le sujet dont l'autorité peut émaner, qu'il s'agisse de la connexion d'un utilisateur ou d'une politique d'entreprise, sans pour autant exiger que cette identité soit propagée à l'identique à chaque étape suivante. Ce qui doit rester vérifiable, c'est que l'autorité exercée appartient toujours à la chaîne d'exécution spécifique qui est poursuivie. Continuity (Continuité) : à chaque étape, il faut prouver son lien causal avec l'étape précédente, et l'autorité ne peut que se restreindre, jamais s'élargir.

Il convient également de lever une confusion terminologique possible. Dans l'article, PIC est le nom du modèle formel dans son ensemble, tandis que Proof-of-Continuity désigne la propriété de bout en bout obtenue en combinant deux éléments sur l'ensemble de la chaîne : chaque preuve individuelle de relation locale—ce que l'article appelle Proof-of-Relationship—et la contrainte selon laquelle l'autorité ne s'élargit jamais d'une étape à la suivante. En une phrase : on démontre chaque lien local, on vérifie que l'autorité n'augmente jamais, et la somme de ces deux conditions établit la continuité depuis l'origine jusqu'à l'étape courante.

L'auteur tient à clarifier un détail dans les conclusions de l'article pour éviter un malentendu courant : le terme « Identity » ne signifie pas que l'identité de l'utilisateur doive voyager, répétée à chaque étape, le long de toute la chaîne. Une même identité, dotée d'exactement les mêmes privilèges, peut participer à des exécutions totalement différentes : ce qui les distingue n'est pas l'identité, mais la chaîne causale spécifique à laquelle elles appartiennent. C'est un glissement conceptuel subtil mais important : le fardeau de l'autorisation passe de la réinterprétation constante de « qui vous êtes » à la vérification de « s'agit-il vraiment d'une continuation légitime de cette exécution spécifique ? ».

Le théorème qui ferme les portes

La partie la plus élégante de l'article, et la plus lourde de conséquences pour ceux qui conçoivent des systèmes réels, est un théorème démontrant que trois propriétés, toutes désirables, ne peuvent pas coexister dans un système de propagation d'autorité : premièrement, que l'autorisation soit invariante par rapport à l'historique, c'est-à-dire que peu importe comment on est arrivé à une action, seul compte le fait de posséder la permission ; deuxièmement, qu'un service puisse légitimement détenir une autorité propre indépendante de la requête, ce qui est pratiquement indispensable en pratique ; troisièmement, que le député confus soit structurellement impossible.

La démonstration ressemble plus à un raisonnement par élimination qu'à un calcul : si un exécuteur peut mélanger sa propre autorité avec celle de la requête, et si le contrôle d'autorisation ne lit en aucun cas quelle chaîne spécifique a causé l'action, alors il existera des situations où une autorité authentique, mais appartenant à une autre exécution, se retrouvera attribuée à la mauvaise requête. Ce n'est pas un défaut d'implémentation ; c'est une conséquence directe des informations que la décision d'autorisation choisit d'ignorer.

La conséquence pratique est plus intéressante que le théorème lui-même. Renoncer à la seconde propriété (interdire à un service d'avoir sa propre autorité) est presque toujours irréaliste : une passerelle de paiement doit pouvoir déplacer des fonds avec sa propre autorisation bancaire, pas uniquement celle de l'utilisateur. Renoncer à la troisième signifie accepter que le député confus reste possible, ce qui est tout simplement vulnérable. Pour les systèmes souhaitant maintenir ces deux propriétés—l'autorité indépendante des exécuteurs et la protection contre le député confus—, le choix praticable consiste donc à renoncer à la première : rendre l'autorisation sensible à la chaîne causale spécifique ayant généré l'action, et non plus invariante par rapport à son historique. L'article résume ce point de manière éclairante : une action peut être spatialement valide mais temporellement invalide, c'est-à-dire que la permission existe et est authentique, mais appartient à la mauvaise cause.

PoR et PoC : les briques opérationnelles

Le modèle repose sur deux concepts distincts mais imbriqués. La Proof-of-Relationship est la preuve locale à un seul saut : elle démontre qu'une étape d'exécution est la continuation causale légitime de l'étape immédiatement précédente, et non d'une étape quelconque qui lui ressemblerait. La Proof-of-Continuity est en revanche la composition de tous ces liens sur l'ensemble de la séquence, associée à la vérification que l'autorité ne s'est jamais élargie : si chaque lien individuel tient bon et qu'aucune étape n'a acquis de privilèges supplémentaires, toute la chaîne est vérifiablement liée à l'origine.

Une clarification utile : la Proof-of-Relationship n'est pas une catégorie particulière de jeton ; c'est une propriété vérifiable de la relation entre deux étapes. Un artefact de continuation lié au prédécesseur spécifique peut apporter la preuve nécessaire pour concrétiser cette propriété, mais à une seule condition : que le destinataire vérifie effectivement ce lien lors de sa décision. La simple possession de l'artefact ne suffit pas à elle seule. Ce détail contredit l'idée que Proof-of-Possession et Proof-of-Continuity soient des approches rivales : la première prouve le contrôle d'un objet à un instant donné, la seconde prouve que cet instant est véritablement lié sur le plan causal à tous ceux qui l'ont précédé. Selon l'article, une architecture de contrôle (enforcement) accompagne l'exécution en générant et vérifiant les preuves pour cette tâche, sans que le modèle n'impose nécessairement un composant physiquement séparé.

Le cas concret soulevé par l'article

Revenons au scénario de l'agent et du document contenant l'instruction cachée, car l'article le traite avec une rigueur qui mérite d'être rapportée fidèlement. Si le contexte d'autorité d'origine n'autorise que l'opération « résumer ce document », alors, sous Proof-of-Continuity, une opération comme « supprimer cette ressource » ou « exfiltrer ce secret » ne pourra jamais constituer une continuation valide, quoi que le document tente de suggérer. L'agent peut tenter physiquement l'action : le modèle ne prétend pas la rendre physiquement impossible, mais un système conforme ne peut pas l'accepter comme un résultat légitime de cette chaîne, car ce privilège ne figure pas dans l'ensemble hérité de l'origine.

L'article propose également un cas plus subtil, utile pour comprendre la précision de la contrainte : un exécuteur dispose légitimement de deux permissions distinctes, une en lecture et une en écriture, chacune valide pour une requête différente en cours au même moment. Si cet exécuteur combine les deux permissions en les attribuant à une seule des deux requêtes, chaque permission prise isolément reste authentique, mais la combinaison appartient à la mauvaise chaîne. C'est le même principe que l'exemple du document, appliqué à un cas encore plus insidieux car aucune des deux permissions, prise séparément, ne paraît suspecte.

Il ne s'agit pas d'un scénario de laboratoire isolé. L'injection d'instructions indirecte (indirect prompt injection), à savoir des instructions malveillantes dissimulées dans des contenus traités par l'agent, est aujourd'hui l'un des vecteurs d'attaque les plus débattus pour les systèmes agentiques. La spécification d'autorisation du Model Context Protocol, le standard par lequel les agents IA se connectent aujourd'hui aux outils externes, impose que chaque jeton soit lié à un destinataire précis et interdit explicitement le passage d'un jeton reçu pour un service vers un service différent en aval. C'est un remède réel, déjà en production, mais cela reste un contrôle ponctuel vérifié saut par saut : cela établit pour quel service un jeton a été émis, mais ne prouve pas à soi seul que l'action courante est la continuation causale de toute la chaîne ayant originé cette autorité. C'est à nouveau la différence entre possession liée et continuité démontrée.

Le problème des vocabulaires divergents

Un obstacle pratique est abordé explicitement dans l'étude : au sein d'un système réel, chaque saut parle souvent un langage différent. Un point de terminaison REST décrit les permissions d'une certaine façon, un périmètre (scope) OAuth d'une autre, et un rôle de base de données d'une troisième. L'article introduit donc une fonction de traduction entre vocabulaires, permettant de faire passer l'autorité d'un système de permissions à un autre sans jamais violer la contrainte de non-extension.

Une condition importante doit toutefois être gardée à l'esprit : le modèle considère cette traduction comme une donnée d'entrée, un choix de politique (policy), et non comme quelque chose qu'il démontre lui-même. Si la traduction s'avère trop généreuse et finit par accorder plus qu'elle ne le devrait, il s'agit d'une erreur de configuration de cette traduction spécifique, et non d'une faille dans la logique du modèle. C'est comme traduire un contrat d'une langue à une autre : si la traduction ajoute des droits que l'original ne prévoyait pas, l'erreur incombe à la traduction, et non au principe selon lequel un contrat doit être respecté.

Comment le construire réellement

L'article est explicitement un modèle et non un manuel d'implémentation : la construction concrète de la Proof-of-Relationship est déclarée hors périmètre et confiée à une architecture de contrôle compagne. En matière de scalabilité, il suggère qu'il n'est pas nécessaire de revalider tout l'historique à chaque saut ; des points de contrôle (checkpoints) ou des preuves synthétisées suffisent pour permettre à chaque étape de prouver sa place dans la chaîne sans transporter tout le passé.

Ce qui rend ce travail plus ambitieux qu'un simple exercice académique, c'est qu'une implémentation concrète est déjà en cours sous la même bannière. Le projet PIC-X part d'une autorité déjà existante, par exemple un jeton OAuth, en dérive un contexte d'autorité PIC initial, et produit des artefacts signés concrets, tels que des jetons JWT dédiés et des structures COSE, en maintenant la contrainte de non-extension tout au long du parcours. Sur le plan du code public, il existe déjà des paquets open source liés au projet, comme une bibliothèque Rust implémentant la logique de vérification des preuves de continuité, accompagnée d'une spécification technique publiée ouvertement. Ce n'est pas encore un standard, mais c'est la preuve que le passage de la théorie à la pratique a commencé.

Les limites reconnues par l'auteur

Il faut énoncer avec la même clarté ce que le modèle ne couvre pas encore, car l'article consacre une section honnête à ses propres limites. Le modèle formel publié dans l'article du 9 juillet, de son propre aveu, ne décrit que des chaînes linéaires : une étape après l'autre, sans ramification. Les scénarios dans lesquels un agent délègue une tâche à deux sous-agents en parallèle restent mentionnés comme des extensions futures dans ce texte. Depuis lors, le projet a commencé à traiter, dans des documents formels ultérieurs, le cas plus simple du fan-out—deux continuations « sœurs » issues du même point de la chaîne ; la composition, c'est-à-dire la convergence de chaînes indépendantes vers un résultat unique, demeure en revanche un problème distinct, avec des règles encore à définir.

Il est tentant d'évoquer ici Jorge Luis Borges et Le Jardin aux sentiers qui se bifurquent : la nouvelle imagine un roman, et au fond un destin, où chaque bifurcation n'élimine pas les alternatives mais les fait coexister dans des temps parallèles. Le modèle de Gallo sait pour l'instant marcher le long d'un seul sentier à la fois ; le rendre capable de gérer les bifurcations sans perdre la garantie qu'aucune branche n'acquière plus d'autorité que le tronc dont elle est issue reste un problème ouvert.

D'autres limites sont déclarées. La révocation n'est pas traitée comme une opération rétroactive sur une chaîne déjà lancée : il reste à préciser si révoquer bloque uniquement les transitions futures ou invalide aussi celles déjà émises. De plus, un risque de sécurité plus subtil est signalé par l'auteur : le modèle encadre l'autorité au sein d'une chaîne déjà initiée, mais ne décide pas à lui seul quand un exécuteur peut légitimement ouvrir une nouvelle chaîne propre. Distinguer une action véritablement autonome d'une action qui se déguise seulement comme telle—c'est-à-dire causée en réalité par une requête externe—reste, de l'aveu même de l'auteur, une responsabilité de l'architecture de contrôle, et non du modèle lui-même.

Ce que cela change pour les développeurs, concepteurs et décideurs

Pour ceux qui développent des agents et des outils, la question utile à se poser lors de chaque action devient simple à formuler, même si elle n'est pas triviale à résoudre : quelle est l'origine de cette autorité, cette opération est-elle vraiment une continuation directe de l'intention initiale, et si je mélange plusieurs sources d'autorité, suis-je en train de les séparer ou de les fusionner sans m'en rendre compte ?

Pour ceux qui conçoivent des plateformes et des infrastructures, l'article suggère d'introduire des métadonnées de provenance dans les appels inter-services, d'évaluer des composants de contrôle dédiés (sidecars, passerelles ou middlewares), et de considérer la continuité comme un critère d'évaluation des frameworks d'orchestration multi-agents avant de les adopter.

Pour ceux qui gèrent la sécurité et prennent des décisions stratégiques, le modèle offre un vocabulaire précis pour évaluer le risque d'escalade silencieuse dans les pipelines automatisés, ainsi qu'un argument solide pour inscrire la traçabilité de la chaîne causale parmi les exigences de sécurité minimales des systèmes autonomes, non pas comme une information utile uniquement pour un audit a posteriori, mais comme une propriété que la décision d'autorisation utilise activement.

Conclusions

La question la plus vaste reste ouverte, celle que l'article pose sans y répondre : quels standards existants, d'OIDC à OAuth en passant par les systèmes de capacités, finiront par intégrer un principe similaire à la continuité, et à quel coût en matière de complexité pour les développeurs ?

L'article est toutefois clair sur un point qu'il convient de garder à l'esprit comme enseignement final : possession, relation et continuité ne démontrent pas la même chose. La possession démontre le contrôle d'un objet à un instant donné. La relation démontre le lien causal entre deux étapes consécutives. La continuité démontre que l'autorité a traversé toute la chaîne sans jamais s'élargir. Cela ne rend pas les jetons, identifiants ou preuves de possession erronés : cela déplace simplement la question vers une autre dimension. Deux actions peuvent avoir le même sujet, le même jeton, voire la même permission, tout en aboutissant à des résultats d'autorisation différents parce qu'elles découlent de causes différentes.

C'est là le changement conceptuel majeur : l'autorité n'est plus seulement une possession détenue par un sujet à un instant donné. Lorsqu'elle est propagée à travers une exécution distribuée, elle doit demeurer une continuation vérifiable de l'autorité ayant causé cette exécution spécifique, et non être affirmée une fois au départ puis considérée comme acquise jusqu'à la fin.