Open Research & Architecture Invariants

0. Le Teleological Bounding Protocol (TBP)

Un modèle de langage est un système probabiliste : il ne détermine pas à l'avance ce qu'il va produire, et rien dans son fonctionnement interne ne garantit qu'une sortie donnée respecte une contrainte de sécurité. Filtrer a posteriori le contenu généré — la démarche la plus répandue aujourd'hui — hérite donc de cette même incertitude : on demande à un système probabiliste de surveiller un autre système probabiliste.

Le TBP part d'un principe différent : la sécurité ne doit jamais dépendre de ce que le modèle produit, mais de la finalité déclarée de l'action qu'il s'apprête à entreprendre, vérifiée par un système déterministe avant toute exécution. Une action n'est jamais évaluée après coup — elle est bornée (bounded) à un périmètre de finalité (teleology) défini à l'avance, hors duquel elle ne peut simplement pas s'exécuter.

INVARIAN est une implémentation du TBP : chaque intention d'action est classifiée avant exécution (inoffensive, à arbitrer, hors périmètre), chaque classification est tranchée par un moteur de politiques déterministe (Open Policy Agent), et chaque décision laisse une preuve vérifiable. Le modèle propose ; le protocole dispose, l'agent est libre de penser, on contrôle son action.

Le protocole prévoit également un mode de repli pour le cas où aucun contrôleur humain n'est disponible pour arbitrer une action — cette démo, volontairement simplifiée, ne l'implémente pas.

1. Invariants du Broker

Un LLM est par nature probabiliste. L'infrastructure qui l'entoure doit être déterministe. Nous avons défini des invariants stricts, traduits en code, qui ne peuvent être outrepassés sous aucune condition. La démo technique en implémente quatre, chacun testable en direct — un déploiement d'entreprise peut en définir davantage, selon votre référentiel de risque.

2. Anonymisation Systématique

L'anonymisation n'est pas une option activée pour les cas sensibles : c'est une étape systématique, appliquée à chaque message avant qu'il ne quitte le périmètre INVARIAN, indépendamment du niveau de risque de l'action. Un coffre de session (Session Vault) détecte et masque les entités sensibles — noms, montants, identifiants, coordonnées — par une combinaison de règles déterministes et d'extraction sémantique multilingue, avant tout envoi vers un modèle cloud.

Ce principe s'applique même lorsque l'action est autorisée. Qu'elle soit exécutée automatiquement (inoffensive) ou validée par un opérateur humain en arbitrage, la donnée brute ne sort jamais du périmètre : seule sa version masquée transite vers le modèle. La reconstruction des valeurs réelles n'a lieu que localement, une fois la réponse validée revenue — jamais côté fournisseur cloud. Pour une entreprise ou un système critique, l'autorisation d'une action et la confidentialité de la donnée qu'elle manipule restent deux garanties strictement indépendantes.

3. Implémentation via Open Policy Agent

Plutôt que d'utiliser un autre modèle d'IA pour surveiller un modèle d'IA (ce qui crée une régression infinie de confiance), le plancher déterministe du TBP est exécuté par un parseur syntaxique et des règles OPA (Rego) au niveau du courtier IPC, garantissant une latence sub-milliseconde pour cette couche.

Chaque intention d'action est d'abord classifiée en trois niveaux : inoffensive (lecture seule, exécutée directement), à arbitrer (effet de bord, validation humaine requise) ou hors périmètre (refusée immédiatement, avec proposition de reformulation — jamais montrée à l'arbitrage). Cette classification est indépendante du jugement sémantique de l'Invariant Gamma : les deux couches se complètent, l'une déterministe et instantanée, l'autre sémantique et tolérante à la reformulation.

4. Auditabilité par Arbre de Merkle

Chaque décision du Broker est inscrite dans un registre Merkle. Cette structure garantit l'immuabilité de l'historique : toute altération d'une décision passée invalide la racine de l'arbre, rendant la fraude détectable instantanément.

Ce registre est complété par un journal d'audit signé au niveau applicatif (Invariant Delta) : chaque entrée porte l'identifiant de session, la nature de la décision, et une signature — la preuve cryptographique de l'arbre garantit l'intégrité de l'historique complet, le journal en donne une lecture humaine, action par action.

5. Démo Technique vs Produit d'Entreprise

Par honnêteté envers les équipes techniques qui évaluent l'architecture : la Sandbox Demo publique exécute le moteur réel, pas une maquette. Elle n'est cependant pas le produit d'entreprise complet. La distinction :

Ce qui est prouvé par la démo : l'architecture fonctionne, les invariants tiennent sous test, la latence ajoutée par le plancher OPA est négligeable. Ce qui reste à construire ensemble : l'intégration à votre environnement.

6. Prochaine phase du protocole — TBP-NETWORK (en construction)

La thèse ne change pas d'échelle : gouverner les capacités d'un agent, pas son modèle. Sur un poste, un contrôleur suffit à INVARIAN pour tenir la promesse démontrée dans les sections précédentes. Sur un réseau d'entreprise — plusieurs postes, plusieurs agents dont certains inconnus, des systèmes critiques partagés (GitLab, CRM, bases de données) — la même doctrine s'étend, mais change de nature : il ne s'agit plus seulement de censurer une intention avant exécution, il s'agit de garantir qu'aucune action sensible sur un système d'entreprise n'échappe à un point de contrôle, quel que soit l'agent qui l'a émise.

Ce que la démo prouve déjà, à l'échelle d'un seul poste : un plancher OPA fail-closed (toute panne du moteur de politiques refuse plutôt que d'autoriser), une double vérification de l'intention — sur le texte brut puis sur sa traduction canonique — pour empêcher un contournement par changement de langue, et un coupe-circuit automatique sur alerte critique. Ce sont les invariants des sections 1 à 4 ci-dessus ; le reste de cette section décrit ce qu'il faut ajouter pour les faire tenir à l'échelle d'un réseau.

Trois critères tranchent la campagne P2, repris tels quels du protocole de test :

Trois écarts restent ouverts, au-delà du code de la démo : une passerelle compatible OpenAI/Anthropic pour gouverner des agents déjà déployés sans les réécrire, une passerelle MCP déployable côté serveur plutôt qu'en process avec le broker, et une vérification de l'anonymisation par un tiers indépendant — le test interne (TBP_VAR_002) reste, par nature, auto-déclaré. Les briques existent déjà en open source pour construire autour (OPA/OPAL, LiteLLM ou envoy-ai-gateway comme socle de passerelle, Sigstore/Rekor comme modèle de registre ancré) : la valeur d'INVARIAN n'est pas dans ces briques, mais dans leur intégration et les invariants qui en résultent.

P1 et au-delà ne sont pas un chantier solo : le mode de repli du broker (arrêt total ou goulot ouvert en cas de panne) et la gouvernance des politiques par poste sont des décisions organisationnelles autant que techniques, qui engagent une équipe et une revue externe. Ce que cette démo établit, c'est que la doctrine tient sous test à l'échelle d'un poste — la base sur laquelle juger s'il vaut la peine d'investir dans la suite.

7. Contribuer au projet

Les politiques OPA par défaut et la vérification des preuves Merkle sont dans le dépôt TBP-NETWORK, ouvert aux auditeurs et chercheurs.

Dépôts publics du protocole (Apache 2.0) : TBP 4.2.1 · TBP-NETWORK