Résumé technique : Opérationnalisation de l'autorité reconstructive

Énoncé du problème

Les systèmes d'agents autonomes échouent fréquemment non pas en raison d'une logique de prise de décision incorrecte, mais parce qu'ils exécutent des décisions dont l'autorité n'est plus valable au moment de l'exécution. Dans des environnements dynamiques, les conditions dans lesquelles une décision est prise (moment de l'admission) divergent souvent des conditions au moment de l'exécution. Les approches de validation antérieures, qui traitent l'autorité comme une propriété statique héritée d'un état initial, ne peuvent pas empêcher l'exécution sous une « autorité périmée ».

Les modèles d'application de politiques existants (par exemple, XACML, OPA) fonctionnent généralement dans un espace de décision binaire : Admettre ou Refuser. Ces modèles traitent souvent les données manquantes ou incertaines comme un refus par défaut ou un risque acceptable, échouant à distinguer entre une autorité invalide (où les conditions sont connues pour être fausses) et une autorité non définie (où les conditions ne peuvent pas être déterminées en raison d'une observabilité incomplète). Cette lacune structurelle conduit des systèmes à exécuter des actions dans un contexte d'incomplétude épistémique, violant ainsi les garanties de sécurité.

Méthodologie

Ce document opérationnalise le Modèle d'autorité reconstructive (MAR), précédemment défini théoriquement dans l'article 5, en un protocole concret d'exécution au moment de l'exécution. La méthodologie centrale opère un changement de paradigme passant de la « validation de l'autorité héritée » à la « construction de l'autorité à partir de l'état actuel ».

1. Fondement théorique

Le système définit l'autorité $A(t)$ non pas comme un drapeau statique, mais comme une fonction $F$ de l'état observable actuel $O(t)$ :
$$A(t) = F(O(t))$$
Puisque l'état réel du système $S_r(t)$ n'est pas entièrement observable, le système doit déterminer si l'autorité est constructible. L'autorité n'est constructible que si :

1. Observabilité : Toutes les variables de dépendance requises sont observables avec une incertitude inférieure à un seuil $\theta_{auth}$.
2. Clôture : Le graphe de dépendance est entièrement résolu (aucune dépendance amont n'est manquante).
3. Cohérence : Aucune violation d'invariant n'est détectée sur les dépendances évaluées.

2. L'état d'exécution ternaire

L'article introduit une extension fondamentale de l'espace des états d'exécution, dépassant le binaire admettre/refuser pour adopter un modèle à trois états :

• Exécuter : L'autorité est constructible et évalue à Vrai.
• Refuser : L'autorité est constructible mais évalue à Faux (les conditions sont connues pour être violées).
• Arrêter : L'autorité est non évaluable ($A(t) = \bot$). Cela se produit lorsque les conditions de constructibilité échouent (par exemple, signaux manquants, incertitude élevée ou graphes de dépendance ouverts). Crucialement, Arrêter se distingue de Refuser ; il représente une suspension de l'exécution due à une incomplétude épistémique, et non un rejet basé sur des violations de politiques connues.

3. Protocole d'application au moment de l'exécution

L'opérationnalisation est mise en œuvre via une Boucle d'application au moment de l'exécution qui intègre trois couches :

• Acquisition d'état : Collecte $O(t)$ sans supposer de complétude.
• Moteur de construction d'autorité : Résout dynamiquement les dépendances $D(a)$ requises pour l'action $a$ en fonction de l'état actuel. Il évalue l'observabilité et l'incertitude pour chaque variable.
• Porte d'exécution : Applique la décision ternaire. Si $A(t) = \bot$, le système entre dans un état Arrêter.

4. La boucle de récupération

Pour traiter l'état Arrêter, l'article définit une Boucle de récupération. Plutôt que de considérer Arrêter comme un échec terminal, le système :

1. Identifie les variables non résolues spécifiques causant l'arrêt.
2. Déclenche la Couche de surveillance des invariants (IML) pour détecter une dérive ou acquérir des signaux manquants.
3. Augmente l'état (par exemple, en acquérant de nouvelles données ou en réduisant la portée de l'action).
4. Tente de reconstruire l'autorité.
   L'exécution ne reprend que lorsque l'autorité redevient constructible, assurant ainsi une vivacité conditionnelle.

Contributions clés

1. Opérationnalisation du MAR : Fournit le premier modèle d'exécution au moment de l'exécution qui impose la reconstruction de l'autorité au point d'action, plutôt que de s'appuyer sur une validation au moment de l'admission.
2. L'état Arrêter : Formalise un troisième état d'exécution pour gérer explicitement l'autorité non définie, empêchant le système d'exécuter dans l'incertitude ou de traiter les données manquantes comme un refus par défaut.
3. Algorithme de résolution de dépendances : Introduit un algorithme dynamique où les variables requises ne sont pas définies statiquement mais émergent de l'état d'exécution et de la fonction de construction $F$.
4. Intégration avec la pile de gouvernance : Démontre comment le MAR s'intègre dans le Protocole de contrôle des agents (ACP) et la Couche de surveillance des invariants (IML) plus larges, agissant comme critère d'autorisation à la porte d'exécution (Étape 3 de l'ACP) tout en restant orthogonal aux couches de gouvernance d'allocation et compositionnelle.
5. Garanties formelles :
   • Sécurité : Prouvé qu'aucune action n'est exécutée sauf si l'autorité est à la fois constructible et valide (Théorèmes 3 et 4).
   • Vivacité conditionnelle : Prouvé que l'exécution reprendra si les variables manquantes définissant l'autorité deviennent éventuellement observables (Théorème 2).

Résultats et affirmations

L'article ne présente pas de données expérimentales empiriques mais fournit un modèle opérationnel formel et des preuves logiques. Les principaux résultats sont :

• Garantie de sécurité : Le modèle empêche structurellement l'exécution sous une autorité périmée ou non définie, un mode de défaillance inhérent aux systèmes qui ne recomputent pas l'autorité au moment de l'exécution.
• Gestion de la dérive : En couplant le MAR avec l'IML, le système détecte la dérive comportementale et invalide l'autorité immédiatement, forçant un arrêt avant que l'exécution ne se produise.
• Traçabilité : Chaque tentative d'exécution génère un artefact d'audit détaillant le chemin de résolution des dépendances, les niveaux d'incertitude et la raison spécifique de Arrêter, Refuser ou Exécuter.

Importance

L'article prétend compléter la « Série sur la gouvernance des agents » en comblant le fossé entre les conditions de gouvernance théoriques et l'application au moment de l'exécution. Alors que les articles 0 à 4 définissent la validité structurelle de la gouvernance et que l'article 5 définit la nature théorique de l'autorité reconstructive, l'article 6 définit comment l'autorité est appliquée au moment de l'exécution.

L'importance réside dans le recadrage du contrôle d'exécution d'un problème d'estimation et de validation vers un problème de constructibilité et d'application. En refusant d'exécuter lorsque l'autorité ne peut pas être construite, le système privilégie la sécurité par rapport à la disponibilité, garantissant que les agents autonomes n'agissent que lorsque leur autorité est activement et vérifiablement dérivée de l'état actuel du monde. Cette approche fournit les sémantiques d'exécution nécessaires pour appliquer l'autorité reconstructive dans des systèmes dynamiques réels.