💻 computer science

Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents

Ce document introduit la Preuve de Continuité (Proof-of-Continuity), un modèle de propagation d'autorité causale qui garantit que chaque étape d'exécution dans les systèmes distribués et les agents d'IA est strictement liée à son origine et limitée à un sous-ensemble non expansif de l'autorité d'origine, empêchant ainsi le problème du délégué confus en garantissant que les privilèges exercés étaient présents dans le contexte de la requête initiale.

Auteurs originaux : Nicola Gallo

Publié 2026-07-13

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Nicola Gallo

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous dirigez une course de relais à enjeux élevés, mais au lieu d'un témoin, les coureurs se passent une clé magique qui déverrouille des portes.

Dans l'ancienne façon de faire (appelée Preuve de Possession), la règle est simple : « Si vous tenez la clé, vous pouvez ouvrir la la porte. » Peu importe qui vous a donné la clé ou pourquoi vous l'avez. Si un coureur ramasse une clé dans une boîte d'objets trouvés, ou prend une clé de rechange dans sa propre poche, il est autorisé à l'utiliser.

L'article soutient que cela est dangereux. C'est comme un délégué confus : imaginez qu'un utilisateur demande à un programme informatique de « sauvegarder un fichier ». Le programme, détenant sa propre clé maîtresse, décide de sauvegarder ce fichier dans un coffre-fort gouvernemental secret parce qu'il possède la clé, même si l'utilisateur ne l'a jamais demandé et n'avait pas le droit d'ouvrir ce coffre-fort. Le programme est « confus » car il utilise une clé qu'il possède, plutôt que la permission spécifique que l'utilisateur lui a donnée pour cette tâche précise.

La Nouvelle Idée : Preuve de Continuité

L'auteur, Nicola Gallo, propose une nouvelle règle appelée Preuve de Continuité.

Au lieu de simplement vérifier si vous avez la clé, nous vérifions maintenant si votre clé est connectée au début de la course.

Considérez la chaîne d'exécution (la séquence d'étapes qu'un ordinateur suit) comme un fleuve.

La Source : La course commence à une source (l'origine). La source libère une quantité spécifique d'eau (autorité/privilèges).
Le Flux : À mesure que l'eau s'écoule en aval, elle ne peut que diminuer ou rester la même. Elle ne peut jamais devenir soudainement plus grande. Si la source a libéré de l'eau pour « lire une carte », le fleuve en aval ne peut transporter que « la lecture d'une carte ». Il ne peut pas soudainement se transformer en une inondation capable de « démolir un bâtiment ».
Le Point de Contrôle : À chaque virage du fleuve (chaque étape du processus informatique), nous ne demandons pas seulement : « Avez-vous un seau ? » Nous demandons : « Ce seau d'eau provient-il directement de la source, et est-ce la même eau ? »

C'est le cœur de la découverte : L'autorité n'est pas seulement quelque chose que vous détenez ; c'est un fil continu qui vous relie au début. Si une étape du processus tente d'utiliser un privilège qui n'était pas présent dans le « seau » d'origine de la source, le fleuve se brise et l'action est bloquée.

Ce que cela exclut

L'article soutient explicitement que l'ancien modèle de « Preuve de Possession » est insuffisant pour les tâches complexes et multi-étapes (comme les agents d'IA ou les services distribués).

Il prouve que si vous vérifiez seulement qui détient la clé (possession) sans vérifier d'où cette clé provient dans la chaîne (lignage), vous ne pouvez pas arrêter le problème du délégué confus. L'article utilise une preuve mathématique pour montrer qu'un système ne peut pas posséder trois choses à la fois :

Laisser un assistant détenir ses propres clés et les clés de l'utilisateur.
Prendre des décisions basées uniquement sur qui détient les clés (en ignorant l'historique).
Être à l'abri du délégué confus.

L'article conclut que pour être sûr, vous devez abandonner l'idée d'ignorer l'historique. Vous devez rendre la décision « sensible au lignage ». Vous ne pouvez pas simplement regarder la clé ; vous devez regarder le fleuve.

À quel point sommes-nous certains ?

L'article ne se contente pas de suggérer que cela pourrait fonctionner ; il le prouve mathématiquement.

L'auteur définit un modèle formel (appelé modèle PIC) avec des règles strictes.
Ils fournissent le Théorème 1 et le Théorème 6, qui sont des preuves logiques montrant que si vous suivez les règles de la « Preuve de Continuité », il est impossible qu'un délégué confus se produise. Ce n'est pas un bug qui pourrait être corrigé plus tard ; c'est une règle du système qui rend l'erreur physiquement impossible à produire au sein du modèle.
L'article stipule que sous ce modèle, « la condition de délégué confus ne peut pas être satisfaite comme comportement de modèle valide ». Ce n'est pas un « peut-être » ; c'est un « jamais ».

Pourquoi cela importe pour l'IA et les Robots

L'article souligne que ceci est extrêmement important pour les agents d'IA. Imaginez un assistant IA à qui vous demandez de « résumer un document ».

Ancienne méthode : L'IA pourrait avoir une clé « supprimer un fichier » dans sa poche. Si vous tapez accidentellement une instruction qui la piège, elle pourrait utiliser sa propre clé « supprimer » pour supprimer vos fichiers, pensant : « J'ai la clé, donc je peux le faire. »
Nouvelle méthode (Preuve de Continuité) : L'IA vérifie le fleuve. Elle voit que la requête « résumer » n'a apporté qu'une clé de « lecture ». Même si l'IA possède une clé « supprimer » dans sa poche, elle ne peut pas l'utiliser pour cette tâche car le privilège « supprimer » n'était pas dans le flux d'eau d'origine provenant de la source. Le fleuve ne coule tout simplement pas de cette manière.

L'essentiel

L'article introduit une nouvelle façon de concevoir la permission. Il ne s'agit pas de savoir qui vous êtes ou ce que vous tenez en ce moment. Il s'agit de savoir d'où vous venez et ce que vous aviez le droit de faire au tout début.

En traitant l'autorité comme un fleuve continu et décroissant plutôt que comme un objet statique que l'on transporte, l'article prouve que vous pouvez garantir mathématiquement qu'aucune étape d'une chaîne ne pourra jamais faire ce que la requête originale n'autorisait pas. Cela transforme un problème de sécurité en une simple règle de flux : Vous ne pouvez pas créer de nouvelles permissions à partir de rien ; vous ne pouvez que transmettre ce qui vous a été donné.

Résumé Technique : Preuve de Continuité : Un Modèle Temporel pour la Propagation de l'Autorité dans les Systèmes Distribués et les Agents d'IA

1. Énoncé du Problème

Le document identifie une limitation fondamentale des modèles d'autorisation actuels, spécifiquement la Preuve de Possession (PoP - Proof-of-Possession) et les systèmes basés sur les capacités, lorsqu'ils sont appliqués à des chaînes d'exécution discrètes et multi-sauts (par exemple, les services distribués, les invocations d'outils par des agents d'IA).

Dans les modèles PoP, l'autorité est dérivée de la possession d'artefacts (jetons, identifiants, capacités). Bien que ces modèles parviennent à contraindre qui peut présenter un artefact, ils ne parviennent pas à garantir que l'autorité exercée à une étape ultérieure est une continuation causale du contexte d'autorité établi à l'origine de la requête.

Cette lacune mène au problème du « Député Confus » (Confused Deputy) dans les contextes distribués. Un député (exécuteur) peut détenir plusieurs sources d'autorité (privilèges ambiants, jetons délégués, identifiants porteurs). Si le député traite une requête et, en fonction des paramètres de cette requête, exerce un privilège qu'il détient mais qui ne faisait pas partie du contexte d'autorité d'origine de la requête, une violation de sécurité se produit. Le député est « confus » car il exécute une action déclenchée causalement par un utilisateur qui n'avait pas l'autorité pour provoquer cette action, bien que le député possède le privilège nécessaire de manière indépendante.

Le document soutient que les modèles basés sur la possession sont invariants à la lignée : ils traitent un événement $(o, r)$ (opération $o$ sur la ressource $r$ ) comme valide uniquement sur la base de la possession du privilège, ignorant la lignée temporelle $\ell$ qui a produit l'événement. Par conséquent, ils ne peuvent pas distinguer une continuation valide d'une lignée autorisée d'une exécution non autorisée qui possède simplement le même privilège.

2. Méthodologie et Définition du Modèle

Les auteurs introduisent le modèle d'Identité de Provenance de Continuité (PIC - Provenance Identity Continuity) et la discipline de Preuve de Continuité (PoC - Proof-of-Continuity) pour combler ce fossé temporel.

Formalisme Central

Chaîne d'Exécution : L'exécution est modélisée comme une chaîne causale d'étapes $\pi = \langle (s_0, C_0), (s_1, C_1), \dots, (s_n, C_n) \rangle$ , où $s_i$ est une étape et $C_i$ est le contexte d'autorité (un sous-ensemble de privilèges $O \times R$ ) transporté à cette étape.
Preuve de Relation (PoR - Proof of Relationship) : Un primitif causal à un seul saut. $PoR(s_i, s_{i+1})$ affirme que l'étape $s_{i+1}$ est une continuation causale valide de $s_i$ au sein de la même lignée.
Restriction d'Autorité Monotone : Une transition valide nécessite que le contexte d'autorité à l'étape suivante soit un sous-ensemble de l'étape actuelle : $C_{i+1} \subseteq C_i$ . L'autorité peut seulement être atténuée (restreinte), jamais étendue.
Preuve de Continuité (PoC) : Définie comme la composition transitive de la PoR et de la restriction monotone à travers toute la chaîne. $PoC(\pi)$ est vérifié si chaque transition adjacente est valide.

Cadre Théorique

Le document formalise la distinction entre Possession et Continuité en utilisant un argument de projection :

Les politiques basées sur la possession sont définies comme des fonctions invariantes par rapport à la lignée : $A(o, r, \ell) = \bar{A}(o, r)$ . Elles projettent l'espace des événements $E = O \times R \times L$ sur $O \times R$ , en ignorant la coordonnée de la lignée $L$ .
Théorème 3 : Les politiques invariantes à la lignée ne peuvent pas individualiser les occurrences. Deux événements avec des privilèges identiques mais des lignées différentes (l'un autorisé, l'autre un député confus) reçoivent le même verdict d'autorisation.
Théorème 5 (Compromis) : Un système ne peut pas satisfaire simultanément :
1. Une autorisation invariante à la lignée.
2. Une délégation capable de mélange d'autorité (exécuteurs détenant des sources d'autorité indépendantes).
3. La sécurité contre le député confus.
  Pour assurer la sécurité dans les systèmes nécessitant un mélange d'autorité, le modèle doit renoncer à l'invariance à la lignée, rendant l'autorisation sensible à la lignée.

3. Principales Contributions

Preuve de Continuité (PoC) : Une discipline minimale de propagation d'autorité où l'autorité est définie non pas comme une propriété statique d'une entité, mais comme une propriété temporelle d'une chaîne d'exécution. L'autorité n'existe que comme une continuation non expansive du contexte d'origine.
Formalisation du Député Confus comme un Mismatch de Lignée : Le document recadre le député confus non pas simplement comme une séparation de la désignation et de l'autorité (la vue spatiale des capacités), mais comme une collision de lignées distinctes sous une projection qui oublie le temps.
Résultats d'Impossibilité :
- Théorème 3 : Prouve que la possession invariante à la lignée ne peut pas distinguer les continuations valides des exécutions de type député confus.
- Théorème 6 : Prouve que sous le modèle PIC, la condition de député confus est impossible à satisfaire comme comportement valide. Si un privilège est absent du contexte d'origine $C_0$ , il ne peut pas apparaître dans un contexte ultérieur $C_n$ au sein d'une chaîne PoC valide.
Distinction des Primitives : Clarifie les rôles de :
- Preuve de Possession : Prouve le contrôle sur un artefact.
- Preuve de Relation : Prouve le lien causal entre des étapes adjacentes.
- Preuve de Continuité : Prouve la propagation de l'autorité sans expansion à travers toute la lignée.

4. Résultats et Garanties de Sécurité

Le résultat principal est la sécurité du modèle PIC. Sous la Preuve de Continuité :

Autorité Bornée à l'Origine : Tout privilège exercé à l'étape $n$ doit avoir été présent dans le contexte d'autorité d'origine $C_0$ .
Atténuation Irréversible : Si un privilège est abandonné à une étape $j$ (c'est-à-dire qu'il n'est pas inclus dans $C_j$ ), il est perdu définitivement et ne peut réapparaître à aucune étape ultérieure $k > j$ .
Élimination du Député Confus : Le modèle empêche structurellement la condition du député confus. Un exécuteur ne peut pas exercer un privilège déclenché par une requête si ce privilège n'était pas autorisé dans le contexte d'origine de la requête, quel que soient les autres privilèges que l'exécuteur détient.

Le document démontre que cette sécurité est obtenue en renonçant à l'invariance à la lignée. Les décisions d'autorisation doivent lire la coordonnée de la lignée (via la preuve PoR) pour déterminer si une action est une continuation valide de la requête causale.

5. Signification et Portée

Le document positionne la Preuve de Continuité comme un affinement de modélisation plutôt que comme un remplacement des mécanismes existants tels qu'OIDC, les portefeuilles (wallets) ou les jetons porteurs (bearer tokens).

Complémentarité : Les mécanismes d'identité et d'authentification restent essentiels pour établir l'origine. La PoC traite de la manière dont l'autorité se propage après que l'origine a été établie.
Pertinence pour les Agents d'IA : Le modèle est explicitement mis en avant comme crucial pour les agents d'IA, qui détiennent souvent des sources d'autorité multiples (identifiants de service, jetons d'utilisateurs, scopes d'outils) et exécutent des chaînes d'invocations d'outils. La PoC garantit qu'un agent ne peut pas utiliser un outil pour effectuer une action (ex: supprimer un fichier) si l'intention originale de l'utilisateur (ex: résumer un document) n'autorisait pas cette action, même si l'agent possède le privilège de suppression de manière indépendante.
Temporel vs Spatial : Le document soutient que si les modèles de capacités résolvent le problème spatial de la désignation, ils échouent souvent face au problème temporel de la propagation multi-sauts, à moins que la capacité ne soit traitée comme un artefact détenu (ce qui revient à la possession). La PoC étend la garantie « par construction » des capacités à travers les lignées multi-sauts en traitant l'autorité comme un flux continu et non expansif.

Le document conclut que le député confus n'est pas une vulnérabilité d'exécution à corriger, mais une impossibilité structurelle dans une exécution PIC valide. Le modèle déplace la charge de la vigilance au moment de l'exécution vers une discipline où l'autorité est définie strictement par son historique causal.