🤖 AI

Certified Purity for Cognitive Workflow Executors: From Static Analysis to Cryptographic Attestation

Ce document présente une architecture de pureté certifiée qui renforce la gouvernance des flux de travail cognitifs en remplaçant les conventions d'exécution par des limites structurelles grâce à une compilation WebAssembly restreinte, des certificats de pureté cryptographiques et une attestation à distance, prouvant ainsi mathématiquement l'élimination des contournements adverses tout en maintenant une surcharge d'exécution négligeable.

Auteurs originaux : Alan L. McCann

Publié 2026-05-06

📖 6 min de lecture🧠 Analyse approfondie

CC0 1.0

Auteurs originaux : Alan L. McCann

Article original placé dans le domaine public sous CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.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 gérez une cuisine à haut risque où une équipe de chefs (agents IA) prépare des repas complexes (flux de travail cognitifs) pour des invités VIP. Les règles sont strictes : les chefs peuvent planifier le repas et noter les ingrédients dont ils ont besoin, mais ils ont strictement l'interdiction de toucher la cuisinière, d'ouvrir le réfrigérateur ou d'appeler le livreur. Seul le Chef de Cuisine (le « Pipeline de Gouvernance ») est autorisé à effectuer ces actions.

Pendant longtemps, la cuisine a reposé sur une règle simple : « Faites confiance aux chefs pour respecter les règles. » Les gestionnaires de cuisine examinaient les livres de recettes des chefs (analyse statique) pour vérifier s'ils avaient noté des instructions interdites. Si la recette semblait propre, le chef était autorisé à travailler.

Le Problème : L'Échappatoire du « Tour de Magie»
L'article explique que ce système de « confiance en la recette » présente un défaut fatal. Un chef déterminé et sournois pourrait utiliser des tours de magie pour contourner les règles sans les inscrire dans le livre de recettes. Sur la plateforme de cuisine spécifique qu'ils utilisent (appelée BEAM/Erlang), un chef pourrait :

Faire semblant d'être quelqu'un d'autre : Appeler une fonction par son nom au dernier moment, dissimulant le fait qu'ils appellent un outil dangereux.
Écrire de nouvelles règles à la volée : Saisir une nouvelle commande en cuisinant, réécrivant ainsi leur propre recette en plein repas.
Engager un garde du corps : Charger un outil secret et préécrit (un « NIF ») capable de tout faire, y compris d'ouvrir le réfrigérateur.
Envoyer un coureur : Faire apparaître une personne séparée à l'extérieur de la cuisine pour aller chercher des ingrédients.
Échanger le livre de recettes : Charger un livre de recettes complètement différent et dangereux pendant la cuisson.

Comme ces astuces se produisent pendant que le chef travaille, examiner le livre de recettes à l'avance (analyse statique) ne peut pas les déceler. C'est comme essayer d'arrêter un magicien en vérifiant ses poches avant le spectacle ; il pourrait avoir une carte cachée qu'il sortira plus tard.

La Solution : La Cuisine de « Pureté Certifiée»
Cet article propose une nouvelle conception de cuisine radicale qui rend ces tours de magie physiquement impossibles, et pas seulement interdits par les règles.

1. La Nouvelle Cuisine (Sandbox WebAssembly)
Au lieu de laisser les chefs travailler dans la cuisine ouverte, ils travaillent désormais à l'intérieur d'une boîte en verre transparente et scellée.

Pas de tours de magie : À l'intérieur de cette boîte, les outils pour « se cacher », « réécrire » ou « engager des garde du corps » n'existent tout simplement pas. La boîte est construite de telle sorte que la seule façon de sortir est par une seule porte verrouillée.
La Liste Blanche : La boîte ne dispose que d'une liste spécifique d'outils qu'elle peut utiliser (comme une calculatrice, un bloc-notes et un « formulaire de demande »). Elle ne peut pas toucher la cuisinière ni le réfrigérateur. Si un outil n'est pas sur la liste, la boîte n'a littéralement pas la poignée pour lui.

2. La Carte d'Identité (Certificat de Pureté)
Avant qu'un chef n'entre dans la cuisine, il doit obtenir une carte d'identité spéciale.

La Preuve : Une autorité de confiance examine le code du chef (le « binaire ») et vérifie qu'il n'utilise que les outils autorisés.
Le Sceau : Ils signent la carte avec un sceau cryptographique (comme un cachet de cire). Ce sceau prouve que cette version spécifique du code du chef est propre.
L'Anti-Tamper : Si le chef tente de modifier son code ne serait-ce que légèrement (pour ajouter un outil secret), le sceau se brise. La carte devient invalide. Vous ne pouvez pas prendre une carte propre du Chef A et la donner à un Chef B modifié.

3. Le Garde de Sécurité (Portail d'Exécution)
Lorsqu'un chef arrive à la porte de la cuisine, un garde de sécurité vérifie la carte.

La Vérification : Le garde vérifie le sceau, confirme que le code correspond à la carte et s'assure que les outils listés sont toujours sur la liste « autorisée ».
Le Résultat : Si la carte est valide, le chef entre. Sinon, il est immédiatement refoulé. Cela se produit chaque fois avant que le chef ne commence à cuisiner.

4. Le Passeport Inter-Cuisines (Attestation à Distance)
Que se passe-t-il si le Chef A travaille dans la Cuisine A, mais doit engager le Chef B de la Cuisine B ?

Le Chef B apporte un « Passeport » (un enregistrement d'attestation) prouvant qu'il a été vérifié par le garde de sécurité de sa propre cuisine et que sa cuisine suit les mêmes règles strictes.
La Cuisine A peut lire ce passeport et faire confiance au Chef B sans avoir besoin de voir le code source du Chef B ou de signer un contrat. C'est une preuve de confiance lisible par machine.

Pourquoi Cela Compte (Les Résultats)
L'article prouve que ce système fonctionne mathématiquement :

Pas d'échappatoire : Parce que les « tours de magie » (classes de contournement) sont structurellement absents de la nouvelle cuisine, un chef sournois ne peut littéralement pas les exécuter. Ce n'est pas qu'ils sont attrapés ; c'est qu'ils ne peuvent pas se produire.
Rapide : Vérifier la carte prend moins d'un clignement d'œil (environ 40 microsecondes). Le temps supplémentaire ajouté à la préparation d'un repas est inférieur à 0,4 % du temps nécessaire pour attendre un camion de livraison.
Sans confiance requise : Vous n'avez pas à faire confiance au chef, au gestionnaire de cuisine ou à l'autre cuisine. Vous devez seulement faire confiance aux mathématiques derrière le sceau et à la conception de la boîte en verre.

En Résumé
L'article fait passer la gouvernance d'un panneau « S'il vous plaît, ne volez pas » (qui repose sur le respect des règles par les gens) à un mur « Vous ne pouvez physiquement pas voler » (qui repose sur la structure du bâtiment). Il transforme une promesse en garantie mathématique, assurant que les agents IA peuvent planifier et réfléchir, mais qu'ils ne peuvent jamais agir secrètement en dehors des règles.

Résumé Technique : Pureté Certifiée pour les Exécuteurs de Flux de Travail Cognitifs

1. Le Problème : Le Fossé de Pureté dans les Flux de Travail Cognitifs

Les systèmes de flux de travail cognitifs (orchestrant l'inférence IA, l'utilisation d'outils et le raisonnement) opèrent de plus en plus dans des domaines à haut risque. Les travaux antérieurs (McCann [2026e]) ont établi une architecture de gouvernance à trois couches garantissant la Complétude de la Gouvernance, la Complétude de la Provenance et l'Impossibilité d'Effets Non Gouvernés. Cependant, ces théorèmes de sécurité reposaient sur une prémisse critique : la Contrainte de Module Pur, qui exige que les modules exécuteurs ne puissent pas effectuer d'effets d'E/S et ne puissent que retourner des directives déclaratives.

Dans l'implémentation précédente, cette contrainte était appliquée via une analyse statique du graphe d'importation des modules sur la machine virtuelle BEAM (Erlang/OTP). Bien que supérieure à une gouvernance basée sur des conventions, ce mécanisme est insuffisant face à une contournement malveillant. Les fonctionnalités dynamiques du BEAM permettent cinq classes distinctes de contournement que l'analyse statique ne peut pas prévenir de manière fiable :

Dispatch Dynamique : Utilisation de :erlang.apply/3 pour invoquer des fonctions arbitraires sans imports statiques.
Évaluation de Code : Utilisation de Code.eval_string/1 pour exécuter du code arbitraire à l'exécution.
Fonctions Implémentées Nativement (NIFs) : Chargement de bibliothèques partagées avec un accès système illimité.
Ports : Création de processus externes via :erlang.open_port/2.
Chargement Dynamique de Modules : Chargement de bytecode arbitraire à l'exécution via :code.load_binary/3.

En raison du théorème de Rice, aucune analyse statique ne peut décider de la propriété sémantique non triviale de « aucun effet d'E/S » pour tous les programmes possibles. Une sur-approximation correcte rejetterait la plupart des codes Elixir idiomatiques légitimes. Cela crée un fossé de pureté : le modèle formel suppose la pureté, mais le mécanisme d'application (analyse statique) ne peut pas la garantir structurellement face à un adversaire déterminé.

2. Méthodologie : De la Détection à la Prévention Structurelle

Cet article propose une Architecture de Pureté Certifiée qui convertit la contrainte de module pur d'une convention appliquée par analyse en une frontière de capacité structurelle appliquée par l'environnement d'exécution. La méthodologie repose sur quatre mécanismes fondamentaux :

A. Cible de Compilation Restreinte (WebAssembly)

Les exécuteurs sont compilés vers une cible WebAssembly (WASM) restreinte. Le modèle de capacités de WASM est exploité pour éliminer structurellement les cinq classes de contournement du BEAM :

Pas de Dispatch Dynamique : WASM manque d'instructions pour résoudre les appels de fonctions par des noms de chaînes/atoms à l'exécution ; les appels sont restreints à des indices statiques dans une table de fonctions.
Pas d'Évaluation de Code : WASM exécute du bytecode pré-compilé ; il n'existe aucun mécanisme pour générer ou charger du nouveau code à l'exécution.
Pas de NIFs/Ports : Les modules WASM s'exécutent dans une machine virtuelle isolée (sandbox) sans accès aux systèmes de fichiers hôtes, aux bibliothèques partagées ou à la création de processus.
Pas de Chargement Dynamique : L'instanciation des modules est entièrement contrôlée par l'hôte ; les modules ne peuvent pas charger d'autres modules.

B. La Liste Blanche de Fonctions Hôte ( $W$ )

Le module WASM ne peut invoquer que des fonctions explicitement déclarées dans sa section d'importation. Ces imports sont restreints à une Liste Blanche ( $W$ ) finie et énumérée :

$W_{data}$ : Opérations de données pures (gestion de la mémoire, manipulation de chaînes, arithmétique, sérialisation JSON, lectures de contexte).
$W_{dir}$ : Constructeurs de directives (fonctions qui construisent des structures de données représentant des effets intentionnels, par exemple directive_http_request, mais ne les exécutent pas).
Exclusion : Les imports WASI (WebAssembly System Interface), qui accordent des capacités d'effets, sont explicitement exclus.

C. Certificats de Pureté

Un Certificat de Pureté est un artefact de preuve cryptographique liant un binaire d'exécuteur à sa classification de pureté.

Structure : Contient le hachage SHA-256 du binaire de l'exécuteur, le hachage de la preuve de pureté (liste d'imports + classification), et une signature Ed25519 sur ces hachages.
Intégrité : En raison de la résistance aux collisions de SHA-256 et de l'inaltérabilité d'Ed25519, un certificat ne peut pas être transféré vers un artefact modifié.

D. Portail de Vérification à l'Exécution

Avant qu'un exécuteur n'entre dans le pipeline de gouvernance, un Portail de Vérification effectue :

Vérification de Signature : Valide la signature Ed25519.
Liaison d'Artefact : Confirme que le hachage du binaire correspond au certificat.
Dérivation Indépendante de la Preuve : Analyse de novo la section d'importation du binaire WASM et vérifie qu'elle correspond à la preuve de pureté revendiquée par rapport à la liste blanche actuelle.
Validation de Classification : S'assure que tous les imports sont classés comme purs.

Seuls les exécuteurs passant ce portail sont instanciés. Ce portail agit comme une précondition structurelle, garantissant qu'aucun exécuteur sans certificat de pureté valide ne peut s'exécuter.

3. Contributions Clés

Modèle de Menace Formel : Une caractérisation rigoureuse des cinq classes de contournement du BEAM et des limites théoriques de l'analyse statique (Théorème de Rice) dans ce contexte.
Pureté Structurelle par Construction : Une preuve (Théorème 4.5) montrant que la compilation vers la cible WASM restreinte satisfait la contrainte de module pur par construction, indépendamment du contenu du code de l'exécuteur.
Élimination des Contournements : Preuves formelles (Théorème 5.5) que chacune des cinq classes de contournement du BEAM est structurellement impossible dans l'environnement WASM restreint.
Attestation Cryptographique : Un schéma pour les Certificats de Pureté et les Enregistrements d'Attestation à Distance permettant une vérification portable et inter-organisationnelle de la pureté des exécuteurs sans accès au code source.
Définition de la Base de Calcul de Confiance (TCB) : Une définition explicite des cinq composants requis pour la garantie (runtime WASM, fonctions hôte, liste blanche, portail de vérification, interpréteur de directives), réduisant la surface de confiance du code d'exécuteur illimité à un ensemble borné et auditable.
Niveaux de Confiance Gradués : Une architecture d'implémentation supportant trois niveaux (Pureté Vérifiée, Analyse Statique, Expérimental) pour permettre une adoption progressive.

4. Résultats et Évaluation

L'architecture a été évaluée sur quatre exécuteurs implémentés (basés sur Rust, compilés vers WASM) s'exécutant sur un processeur Apple série M avec le backend JIT Wasmtime.

Latence de Vérification : Le portail de vérification prend 39–42 µs (médiane) pour les exécuteurs de production. Avec la mise en cache basée sur le hachage, le coût amorti tend vers zéro pour les invocations répétées.
Surcharge à l'Exécution : Le cycle complet de plan (instanciation, exécution, désérialisation) s'achève en 256–398 µs. Cela représente une surcharge <0,4 % sur une requête HTTP de 100 ms et <0,05 % sur un appel LLM typique de 800 ms.
Déterminisme : Aucune divergence n'a été observée sur 40 invocations répétées avec des entrées identiques, confirmant la nature déterministe de l'environnement d'exécution WASM.
Taille des Certificats : Les certificats sont compacts (~1,3 Ko), bien dans les budgets de bande passante.
Correction : Tous les exécuteurs ont produit les formes de directives attendues, et le système a maintenu des sorties identiques au niveau des octets entre les exécutions.

5. Signification et Revendications

L'article revendique un changement fondamental dans le statut épistémologique des garanties de gouvernance :

De la Détection à la Prévention : Les approches précédentes reposaient sur la détection de motifs de contournement connus via l'analyse statique. Cette architecture prévient le contournement en rendant les capacités productrices d'effets structurellement absentes.
Renforcement des Théorèmes Existants : Les théorèmes de sécurité de McCann [2026e] (Complétude de la Gouvernance, Complétude de la Provenance, Absence d'Effets Non Gouvernés) restent formellement identiques. Cependant, leur prémisse fondamentale est acquise mécaniquement plutôt que supposée. La garantie repose désormais sur les propriétés mathématiques du modèle de capacités WASM et des primitives cryptographiques (SHA-256, Ed25519) plutôt que sur les limites d'un analyseur statique.
Confiance Portable : En convertissant les preuves de pureté locales en enregistrements d'attestation portables, l'architecture permet la composition de gouvernance inter-organisationnelle, permettant à l'Organisation A de vérifier cryptographiquement la pureté des exécuteurs de l'Organisation B sans examen du code source.

L'article note explicitement qu'il ne s'agit pas d'une preuve mécanisée au sens de Rocq ou Lean (réservée à la logique de gouvernance sous-jacente dans des articles compagnons), mais d'une garantie structurelle vérifiée à l'exécution. La contribution est la réduction de la surface de confiance de « tout le code de l'exécuteur » vers une petite Base de Calcul de Confiance explicitement définie.