OpenKedge: Governing Agentic Mutation with Execution-Bound Safety and Evidence Chains

L'article présente OpenKedge, un protocole qui sécurise les mutations agentic en remplaçant l'exécution directe par des contrats d'exécution vérifiables et une chaîne de preuves cryptographiques reliant l'intention aux résultats.

L'essentiel

Imaginez que vous dirigez une ville très moderne où des robots intelligents (les agents IA) gèrent tout : l'électricité, le trafic, les banques et les hôpitaux. Jusqu'à présent, ces robots avaient un pouvoir dangereux : ils pouvaient ouvrir n'importe quelle porte, couper le courant ou déplacer des objets en appuyant simplement sur un bouton, sans que personne ne vérifie si c'était une bonne idée à ce moment précis.

C'est là que OpenKedge entre en jeu. C'est un nouveau système de sécurité qui change radicalement la façon dont ces robots agissent.

Voici comment cela fonctionne, expliqué simplement avec des métaphores :

1. Le Problème : Le Robot qui Appuie sur le Bouton "Tout Effacer"

Dans l'ancien système (les architectures centrées sur les API), si un robot disait "Je veux éteindre ce serveur", le système obéissait immédiatement.

• Le risque : Imaginez un robot qui a un peu "halluciné" (il a fait une erreur de logique). Il pense qu'un serveur est inutile, alors qu'il gère en réalité les urgences d'un hôpital. Comme le système est aveugle, il coupe le courant. Catastrophe !
• L'analogie : C'est comme donner un trousseau de toutes les clés de la ville à un robot qui a un peu de fièvre. Il peut ouvrir la bonne porte, mais il risque aussi d'ouvrir celle du coffre-fort ou de couper l'eau de la ville.

2. La Solution OpenKedge : Le "Bureau des Permis"

OpenKedge dit : "Attendez ! Avant d'agir, il faut demander la permission."

Au lieu de donner un bouton d'action directe, OpenKedge oblige le robot à soumettre une demande d'intention.

• L'analogie : Au lieu de laisser le robot ouvrir la porte lui-même, il doit d'abord aller au bureau de la mairie (le système OpenKedge) et dire : "Bonjour, je veux fermer cette porte parce qu'il y a un incendie."

3. Les Trois Piliers de la Sécurité

A. La Vérification (Le Gardien du Contexte)

Avant d'accepter la demande, le système OpenKedge ne regarde pas seulement ce que le robot dit. Il regarde la réalité du moment.

• Comment ? Il vérifie : "Est-ce qu'il y a vraiment un incendie ? Est-ce que quelqu'un d'autre (un humain ou un autre robot) a déjà dit de garder la porte ouverte ? Est-ce que c'est l'heure de fermer cette porte ?"
• L'analogie : C'est comme un gardien de sécurité très attentif qui vérifie l'heure, l'identité du visiteur et la météo avant de laisser quelqu'un entrer dans un bâtiment sensible. Si le robot se trompe de contexte, le gardien dit : "Non, pas maintenant."

B. Le Contrat d'Exécution (La Cage de Sécurité)

Si la demande est acceptée, le robot ne reçoit pas ses clés habituelles. Il reçoit un contrat temporaire et limité.

• Comment ? Le système crée une identité éphémère (comme un badge d'accès valable 5 minutes) qui ne permet de faire que ce qui a été approuvé, et rien d'autre.
• L'analogie : Imaginez que le robot veut peindre un mur. Au lieu de lui donner un seau de peinture et un pinceau pour toute la maison, on lui donne un petit pinceau, une seule couleur, et on lui dit : "Tu as 10 minutes pour peindre uniquement ce carré précis. Si tu touches au plafond ou si tu dépasse le temps, ton pinceau se transforme en pierre."
• Même si le robot devient fou (hallucination) et essaie de peindre le sol, le système l'en empêche physiquement.

C. La Chaîne de Preuve (Le Journal de Bord Indélébile)

C'est peut-être l'aspect le plus important. OpenKedge enregistre tout dans une chaîne de preuves inaltérable (la IEEC).

• Comment ? À chaque étape, le système écrit : "Qui a demandé ? Pourquoi ? Quelle était la situation ? Quelle décision a été prise ? Qu'est-ce qui s'est passé ?" Tout est lié cryptographiquement (comme un sceau de cire numérique).
• L'analogie : C'est comme un journal de bord de navire écrit par un notaire. Si un accident arrive, on ne se contente pas de regarder les dégâts. On peut relire le journal pour voir exactement pourquoi le capitaine a tourné le gouvernail à gauche, quelles informations il avait, et si c'était une bonne décision. On ne peut pas effacer les pages.

Pourquoi est-ce révolutionnaire ?

1. On passe de la réaction à la prévention : Au lieu d'essayer de réparer les dégâts après que le robot a fait une bêtise, on l'empêche de la faire avant même qu'il ne commence.
2. On gère les conflits : Si deux robots veulent faire des choses opposées en même temps (l'un veut fermer, l'autre ouvrir), OpenKedge triche le débat de manière logique et mathématique pour choisir la meilleure option, au lieu de laisser le chaos régner.
3. On peut tout expliquer : Grâce à la chaîne de preuves, on peut toujours dire pourquoi une décision a été prise. C'est crucial pour la confiance dans les systèmes automatisés.

En résumé

OpenKedge transforme les robots intelligents de conducteurs imprévisibles en passagers responsables. Ils peuvent toujours proposer des idées, mais le système (le chauffeur et le contrôleur) vérifie la route, limite la vitesse et garde les mains sur le volant.

C'est une façon de dire : "L'intelligence artificielle est puissante, mais elle doit être encadrée par des règles de sécurité aussi solides que celles d'un avion, pas juste par des boutons."

Résumé technique

1. Problématique : Les failles des architectures centrées sur les API

L'essor des agents IA autonomes introduit une faille fondamentale dans les architectures logicielles modernes basées sur les API. Le problème central réside dans le décalage entre la nature probabiliste des agents (qui peuvent halluciner, manquer de contexte ou agir de manière conflictuelle) et la nature passive et immédiate des API traditionnelles.

Les architectures actuelles souffrent de quatre défaillances majeures :

• Manque de validation contextuelle : Les requêtes API sont exécutées de manière isolée, ignorant les mises à jour récentes, les contraintes temporelles et les invariants du système global.
• Conflits multi-agents : Plusieurs acteurs (humains et IA) peuvent émettre des mises à jour mutuellement exclusives sans mécanisme de résolution déterministe.
• Mutations dangereuses : Les agents probabilistes peuvent générer des actions incorrectes ou hallucinées, entraînant des changements d'état nuisibles ou irréversibles (ex: suppression de bases de données critiques).
• Absence de traçabilité de bout en bout : Les architectures traditionnelles manquent de logs complets permettant de reconstruire le raisonnement derrière une mutation initiée par une IA, rendant l'audit et le débogage impossibles.

Le papier souligne que l'amélioration du raisonnement des LLM (Large Language Models) seule est insuffisante ; le système sous-jacent doit activement évaluer, coordonner et contraindre les mutations avant leur exécution.

2. Méthodologie : Le protocole OpenKedge

OpenKedge propose un changement de paradigme architectural : passer de l'exécution directe d'API à une gouvernance basée sur l'intention. Le protocole transforme la mutation d'état en un processus gouverné plutôt qu'une conséquence immédiate d'un appel.

L'architecture repose sur quatre piliers principaux :

A. Proposition d'Intention (Intent Proposals)

Au lieu d'appeler directement une API, les agents (ou opérateurs) doivent soumettre une proposition d'intention déclarative. Cette proposition décrit le résultat souhaité, séparant le "quoi" (l'objectif) du "comment" (l'exécution).

B. Évaluation Contextuelle et Politiques

Le système évalue rigoureusement chaque proposition contre :

• L'état global du système en temps réel (dépendances, trafic, historique).
• Des contraintes temporelles.
• Des politiques de sécurité strictes (définies en "Policy-as-Code", par exemple avec le langage Cedar).
  Seules les intentions validées sont autorisées à passer à l'étape suivante.

C. Contrats d'Exécution et Identités Éphémères

Les intentions approuvées sont compilées en contrats d'exécution explicites : $C = (a, r, t)$, où :

• $a$ : Action permise.
• $r$ : Périmètre de ressources (scope).
• $t$ : Validité temporelle (TTL).
  Ces contrats sont appliqués via des identités orientées tâche éphémères. Contrairement aux comptes de service persistants, ces identités sont générées dynamiquement pour une seule séquence d'exécution, limitant strictement les privilèges et empêchant l'escalade de privilèges ou les effets de bord non autorisés.

D. Chaîne de Preuve Intent-to-Execution (IEEC)

Le cœur de la traçabilité est l'IEEC (Intent-to-Execution Evidence Chain). C'est une chaîne cryptographique immuable qui lie :

1. L'intention initiale.
2. Le contexte récupéré.
3. La décision de politique (Approve/Reject).
4. Les bornes du contrat d'exécution.
5. Le résultat final.
   Cette chaîne permet de reconstruire de manière déterministe n'importe quel changement d'état, répondant non seulement au "quoi" s'est produit, mais aussi au "pourquoi" et au "comment" cela a été autorisé.

3. Contributions Clés

Le papier présente trois contributions majeures :

1. Protocole de Mutation Gouverné par l'Intention : OpenKedge redéfinit la mutation d'état en la découplant de l'exécution. Le système n'accepte que les mutations sémantiquement valides et sans conflit, évaluées par rapport au contexte global et aux politiques.
2. Sécurité Liée à l'Exécution via Contrats : L'introduction de contrats d'exécution appliqués par des identités éphémères garantit que même en cas d'hallucination ou de comportement malveillant de l'agent, l'exécution physique reste strictement bornée (scope, temps, action).
3. Chaîne de Preuve IEEC : Une lignée cryptographique unifiée qui rend chaque mutation bornée dans l'exécution et explicable dans sa lignée. Cela établit une nouvelle invariante pour les systèmes agents : toute mutation doit être vérifiable et reconstituable.

4. Résultats et Évaluation

Les auteurs ont évalué OpenKedge via une implémentation de référence nommée Riftront et une simulation d'infrastructure cloud (AWS).

• Arbitrage de Conflits : Dans des scénarios à haute concurrence (humains vs agents, agents non vérifiés), le protocole a démontré sa capacité à arbitrer de manière déterministe les intentions conflictuelles en utilisant des scores de confiance, l'autorité statique et la récence temporelle, sans verrouillage distribué.
• Sécurité des Infrastructures :
  • Scénario 1 : Un agent tentant de supprimer une instance de calcul "inutilisée" (mais en réalité critique) a été bloqué car l'évaluation contextuelle a détecté des dépendances actives.
  • Scénario 2 : Une réduction de capacité de cluster en période de pic de trafic a été interceptée car elle violait les contraintes de disponibilité.
  • Dans tous les cas, les mutations dangereuses ont été contenues avant l'exécution API.
• Performance et Déterminisme :
  • Le système a maintenu un taux de mutation de 3 200 par seconde sans dégradation du débit.
  • La latence d'évaluation des politiques était d'environ 11 ms, et la déduction d'état à moins de 30 ms (99e percentile).
  • Des tests de rejeu ont confirmé que des charges de travail identiques produisaient des logs d'événements et des états dérivés strictement identiques, prouvant l'absence de conditions de course observables.

5. Signification et Impact

OpenKedge représente un changement fondamental dans la conception des systèmes autonomes :

• Du filtrage réactif à la prévention proactive : La sécurité n'est plus une couche de filtrage après coup, mais une propriété intrinsèque de l'exécution.
• Confiance structurelle : En remplaçant la confiance implicite dans l'appelant (l'agent) par une gouvernance explicite et une vérification cryptographique, OpenKedge permet le déploiement d'agents IA à grande échelle dans des environnements critiques (DevOps, cloud, IoT).
• Auditabilité absolue : L'IEEC transforme les opérations opaques en artefacts décisionnels reproductibles, essentiels pour la conformité réglementaire et le débogage des systèmes complexes.

En conclusion, OpenKedge fournit les fondations nécessaires pour opérer des systèmes agents de manière sûre, en garantissant que l'évolution de l'état du système provient exclusivement de transitions valides, bornées et sans conflit, dérivées d'intentions approuvées.