Résumé Technique : Frontière d'Assurance Souveraine pour l'Infrastructure Agentique

1. Énoncé du Problème

L'intégration d'agents de Grands Modèles de Langage (LLM) dans les flux de travail opérationnels introduit une lacune critique d'autorisation au niveau du plan de contrôle. Bien que les agents puissent proposer des mutations à enjeux élevés sur des ressources de production (par exemple, la mise à l'échelle de nœuds, la rotation de credentials, la modification de groupes de sécurité réseau), les mécanismes de sécurité existants sont insuffisants pour gouverner ces systèmes de raisonnement non déterministes.

• Statique vs Dynamique : La gestion des identités et des accès (IAM) traditionnelle et les moteurs de politiques imposent des permissions statiques ou une conformité structurelle, mais ne peuvent déterminer si une proposition autonome est sémantiquement justifiée par des preuves en temps réel.
• Limites Post-Hoc : Les journaux d'audit et les protocoles de consensus enregistrent les actions ou conviennent des transitions d'état uniquement après l'exécution ou sans évaluer la sécurité sémantique de la transition.
• Accumulation de Risques : Des actions d'agents individuellement plausibles peuvent s'accumuler en défaillances systémiques, incluant des interruptions de disponibilité, des expositions de données, des contournements de politiques et une perte de contexte forensique.
• La Lacune Fondamentale : Il n'existe aucune frontière d'admission au moment de l'exécution qui convertisse la proposition d'un agent en autorité d'exécution uniquement après qu'elle a été liée à des preuves, à une politique et à un état de révocation.

2. Méthodologie : La Frontière d'Assurance Souveraine (SAB)

Le document propose la Frontière d'Assurance Souveraine (SAB - Sovereign Assurance Boundary), une frontière d'admission au moment de l'exécution liée par certificat, qui s'interpose entre le raisonnement de l'agent et la mutation de l'infrastructure. La SAB opère selon le principe que l'institution conserve le contrôle local sur la politique, la preuve et l'autorité d'exécution, traitant le runtime de l'agent comme un proposant non fiable.

2.1 Architecture : Modèle Airlock–Broker

La SAB sépare le système en deux couches distinctes :

1. Runtime de l'Agent Non Fiable : Génère des propositions mais ne détient aucun credential debout ni privilège d'exécution direct.
2. Broker d'Exécution Souverain de Confiance : La seule entité autorisée à invoquer les API d'infrastructure. Il exécute les mutations exclusivement après avoir vérifié un Certificat d'Assurance Souveraine ($\Omega$) signé.

Le pipeline d'admission comprend les étapes suivantes :

• Compilation du Contrat : Les commandes brutes de l'agent sont normalisées en un Contrat d'Exécution ($C$) fortement typé, définissant les cibles, les préconditions, les postconditions et les rollbacks.
• Liaison de Preuve (Evidence Binding) : Un collecteur de preuves assemble la télémétrie, les logs et les tickets pour calculer un digest cryptographique $H(E)$ de l'état du système au moment de la décision.
• Scoring de Conséquence : Un scoreur calcule une métrique de risque $R(C)$ basée sur le rayon d'impact (blast radius), l'expansion de privilèges, la sensibilité des données, l'irréversibilité et l'incertitude. Cela détermine le Niveau d'Autonomie ($L(C)$) (allant de L0 Conseil à L5 Prohibé).
• Routage du Chemin de Certification : Selon $L(C)$ et la politique, le contrat est routé via un chemin spécifique (ex: PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman).
  • Assurance de Quorum Sémantique (SQA) : Un maillage de validateurs externes non fiables fournit des attestations signées ($\Gamma_{SQA}$) concernant l'admissibilité sémantique de l'action.
  • Approbation Humaine : Pour les actions à enjeux élevés, les opérateurs fournissent des approbations multi-signatures liées au contrat et à la preuve spécifiques.
• Émission du Certificat : L'Airlock d'Assurance (faisant partie du TCB - Trusted Computing Base) vérifie toutes les exigences du chemin et émet un Certificat d'Assurance Souveraine ($\Omega$) signé.
  • $\Omega$ contient : $C$, $H(E)$, $R(C)$, $L(C)$, le chemin de certification, les signatures des validateurs, l'identité d'exécution ($ID_{exec}$), la fenêtre de validité ($T_{valid}$), la version de la politique ($P_{ver}$) et l'époque de révocation ($\rho_{rev}$).
• Vérification du Broker : Avant l'exécution, le Broker Souverain vérifie la signature de $\Omega$, vérifie l'époque de révocation, valide la version de la politique et effectue une vérification de dérive d'état ($\Phi_{drift}$) pour s'assurer que l'état réel n'a pas dévié de la preuve $E$ liée.

2.2 Invariants Formels

La SAB impose cinq invariants de frontière d'autorité :

1. Découplage Proposition-Exécution : Aucune proposition d'agent ne déclenche une mutation sans l'admission de l'airlock.
2. Exécution Liée au Certificat : L'exécution ne se produit que si le broker vérifie un $\Omega$ valide contenant le contrat $C$ spécifique.
3. Liaison de Preuve : Les approbations et les attestations sont cryptographiquement liées à $C$ et $H(E)$, empêchant la réutilisation dans différents contextes.
4. Sélection de Chemin Monotone : Les contrats ne sont admis que si toutes les exigences de leur chemin de certification sont satisfaites ; les chemins de moindre assurance ne peuvent pas outrepasser les exigences de risque plus élevé.
5. Autorité Éphémère : Les certificats sont rejetés si l'époque de révocation est obsolète ou si le temps d'exécution se situe en dehors de la fenêtre de validité.

3. Contributions Clés

Le document présente quatre contributions principales :

1. Admission Liée au Certificat : Il définit une frontière d'admission au runtime qui convertit l'autorité d'exécution autonome d'une permission ambiante en un artefact révocable et lié à une preuve.
2. Architecture Airlock–Broker : Il introduit les composants spécifiques (Contrat $C$, Digest de Preuve $H(E)$, Certificat $\Omega$, et Broker Souverain) qui séparent la proposition, l'admission et l'exécution.
3. Certification Sensible aux Conséquences : Il formalise le scoring de conséquence, les niveaux d'autonomie, les chemins de certification et les mécanismes de révocation qui permettent l'escalade, le rejet et la suspension avant l'exécution.
4. Prototype et Évaluation de Faisabilité : Il implémente un prototype en Go démontrant la faisabilité du système, incluant la sérialisation de contrats, les vérifications de politique OPA/Rego, la signature Ed25519 et un registre soutenu par PostgreSQL.

4. Résultats et Évaluation

Les auteurs ont évalué le prototype à l'aide de 500 contrats d'exécution étiquetés à travers 2 500 tentatives d'admission dans un banc d'essai local.

• Latence :
  • Admission par politique seule : ~1,84 ms (p50).
  • Admission SQA (avec maillage de validateurs) : ~185 ms (p50) / 380 ms (p95).
  • Vérification du Broker : ~0,15 ms (p50).
  • Propagation de la révocation : ~12,4 ms (p95).
• Précision :
  • Précision du routage (accord avec un oracle étiqueté par des experts) : 96,8 %.
  • Taux d'admission non sécurisé : 0,4 %.
• Efficacité :
  • Réduction de l'approbation humaine : 68,2 % par rapport à une file d'attente uniquement humaine.
  • Surcharge de stockage du certificat : ~3,4 Ko par action.
• Rejouabilité : 100 % des entrées du registre étaient rejouables avec le contexte du schéma.

Les résultats indiquent que la surcharge du plan de contrôle est réalisable sur une station de travail unique, échangeant de la latence contre de l'assurance et de la rejouabilité.

5. Signification et Revendications

Le papier affirme que la SAB répond à une lacune d'autorisation spécifique sans remplacer les couches de sécurité existantes.

• Souveraineté Opérationnelle : La SAB définit la souveraineté comme la rétention par l'institution du contrôle local sur l'évaluation des politiques, la rétention des preuves, les clés de signature et l'autorité d'exécution. Les modèles externes sont restreints à la génération de propositions et ne peuvent contourner la certification locale.
• Composabilité : La SAB n'est pas un remplacement pour l'IAM, la vérification formelle, les protocoles de consensus ou la revue humaine. Au lieu de cela, elle compose ces mécanismes en une frontière d'admission au niveau du système. Elle traite l'autorité d'exécution déléguée comme un artefact de runtime lié par certificat, lié par preuve, révocable et rejouable.
• Atténuation des Risques : En découplant la génération de propositions de l'exécution et en liant l'exécution à des preuves fraîches et à une politique active, la SAB empêche le raisonnement autonome seul de muter l'état, atténuant ainsi les risques de défaillance systémique, de fuite de données et de contournement de politique.

Les auteurs maintiennent une position modeste, reconnaissant que la SAB dépend de l'intégrité du TCB (Trusted Computing Base), de la fraîcheur des preuves externes et du calibrage des validateurs. Ils notent que les résultats du prototype dépendent de la charge de travail et ne garantissent pas une performance générale, suggérant une stratégie de déploiement progressif commençant par les domaines à hautes conséquences.