Suite de tests des capacités de gouvernance à l’exécution des agents IA

Procédure

1. 01Appelez l’outil à conséquences par le parcours gouverné prévu, avec une politique qui le bloque ; confirmez que le système métier n’a pas changé d’état.
2. 02Tentez la même action par chaque parcours alternatif admis par l’architecture : appels API directs, intégrations secondaires, consoles opérateur.
3. 03Demandez au fournisseur de nommer le composant exact qui applique la règle sur chaque parcours et l’équipe qui en détient la configuration.

Attendu de toute plateforme gouvernée

Un résultat block ou require_approval empêche l’effet de bord sur le parcours gouverné, et le fournisseur peut recenser les parcours gouvernés ainsi que ceux qui restent sans protection.

Comportement observé de KLA

Sur le parcours de la passerelle, la passerelle de gouvernance scelle un reçu de décision dans le registre des preuves avant l’exécution de l’outil ; block et require_approval terminent l’appel et l’exécuteur d’outil n’est jamais appelé. La politique de l’outil est aussi vérifiée dans le hub d’outils à chaque appel MCP. L’admission d’une exécution par l’API d’exécution est authentifiée et contrôlée par rôle sans décision de politique ; l’application de la politique par action intervient à la frontière de l’outil pendant l’exécution.

Preuves

• services/governance-pep/src/gateway.ts: decision sealed before the side effect; block and require_approval short-circuit
• governance-gateway.test.ts: 15 cases on the gateway decision path
• cmb-aml-governance-gateway.test.ts: 16 end-to-end cases on a banking workflow
• scripts/check-production-governance-gateway.mjs: deployment guard that the gateway is enabled in production

Réserves

• La passerelle est activée par la configuration du déploiement ; les overlays de production et de développement livrés l’activent, et un opérateur auto-hébergé doit faire de même.
• Le point de terminaison interne d’exécution des connecteurs suppose que la barrière de l’outil a déjà été franchie ; il autorise l’appelant sur la connexion liée et n’effectue pas de seconde évaluation de politique.

Procédure

1. 01Mettez le service de décision de politique hors ligne ou injectez une défaillance de transport pendant que l’agent propose une action à conséquences.
2. 02Répétez avec une défaillance interne du moteur de politiques : aucune politique résolue, un pack de politiques dont la signature échoue, une dépendance de garde-fous indisponible.
3. 03Enregistrez le résultat, le code de motif et la possibilité qu’une configuration transforme la défaillance en allow.

Attendu de toute plateforme gouvernée

Chaque mode de défaillance produit block ou require_approval avec un motif lisible par machine. Aucune valeur de configuration ne peut transformer une défaillance d’évaluation en allow.

Comportement observé de KLA

Le comportement fail-closed, c’est-à-dire le refus par défaut en cas de défaillance, s’applique à chaque couche examinée : panne de transport au point d’application, absence de politique résolue, échec de signature du pack, environnement d’exécution des garde-fous indisponible, panne du fournisseur de droits, panne du juge IA et panne du stockage des preuves entraînent tous un refus. La surcharge d’environnement accepte block ou require_approval et refuse allow. La production utilise block par défaut ; les autres environnements utilisent require_approval. La publication d’un pack de politiques dont la décision par défaut est allow ou warn échoue à la compilation.

Preuves

• services/governance-pep/src/decisions.ts + environment.ts: fail-closed decision builder; override cannot be allow
• policy-evaluation-service.test.ts: 12+ fail-closed cases including pack-verification failure and “must not fail open” regression
• services/policy-engine/src/policy-pack/lint.ts: allow/warn default decision is a publish-time error
• transition-gate-decision.test.ts: errored policy outcome blocks and is excluded from human-recoverable reasons

Réserves

• Les environnements hors production refusent par défaut avec require_approval ; une panne y remplit donc la file d’approbation tandis que les actions restent en pause.
• Le refus fail-closed par défaut vient de la variable d’environnement d’exécution ; un service de production lancé avec un NODE_ENV incorrect se dégrade en require_approval.

Procédure

1. 01Déclenchez un résultat require_approval, approuvez-le, puis modifiez un paramètre important (montant, bénéficiaire, enregistrement cible) avant la reprise de l’exécution.
2. 02Soumettez à nouveau la charge utile de reprise avec l’approbation d’origine et les arguments modifiés.
3. 03Vérifiez quel côté recalcule la liaison : la charge utile de l’appelant ou l’enregistrement scellé par le serveur.

Attendu de toute plateforme gouvernée

L’approbation est liée à un condensat canonique des arguments exacts, la liaison est revérifiée côté serveur à la reprise depuis un enregistrement que l’appelant ne peut pas fournir, et une divergence bloque l’action.

Comportement observé de KLA

Au moment de l’approbation, la passerelle scelle dans le registre durable un hash SHA-256 canonique des arguments de l’outil. À la reprise, elle recalcule le hash à partir des arguments soumis et le compare à la copie du registre ; le hash porté par la charge utile de reprise est volontairement ignoré. Une divergence, comme l’absence d’un hash scellé, bloque avec le motif tool_args_mismatch.

Preuves

• services/governance-pep/src/gateway.ts: TOCTOU re-verification against the ledger-sealed hash only
• governance-gateway.test.ts: “TOCTOU: Phase-2 resume with mutated arguments fails closed and never executes”
• cmb-aml-governance-gateway.test.ts: “fails closed when the decision input changes after approval”

Réserves

• La revérification cryptographique s’exécute sur le parcours de la passerelle. Les outils de connecteur gouvernés reprennent via l’objet d’état de l’agent-runtime, qui fixe structurellement les arguments sans seconde comparaison de hash.

Procédure

1. 01Créez une approbation avec une échéance, laissez-la expirer, puis tentez de l’approuver par chaque surface de décision exposée par la plateforme.
2. 02Confirmez l’autorité conservée par une approbation expirée et les surfaces qui appliquent son expiration.

Attendu de toute plateforme gouvernée

Une approbation échue refuse l’approbation et le rejet sur chaque surface de décision ; l’escalade reste la seule voie.

Comportement observé de KLA

Les approbations portent une échéance (une heure par défaut). Les deux surfaces de décision refusent une décision échue : la surface du plan de contrôle, utilisée par Decision Desk, calcule l’état échu et n’autorise que l’escalade, tandis que la mise à jour de décision de l’API d’exécution exige que l’échéance soit encore dans le futur et renvoie un conflit après la date limite. La séparation maker-checker est appliquée côté serveur sur les deux parcours.

Preuves

• services/api/src/routers/approvals.ts: overdue approvals accept escalate only; maker cannot check
• services/execution-api/src/routes/approvals.ts: decision update requires due_at in the future
• approval-decision-self-approval.test.ts: post-deadline decision returns 409 without signaling the workflow
• approvals.maker-checker.test.ts: 10 cases

Réserves

• Les approbations de la barrière d’outil attendent indéfiniment par conception ; le délai configurable concerne les nœuds de workflow d’approbation humaine explicites.

Procédure

1. 01Capturez une décision approuvée, puis rejouez-la sur une autre exécution, un autre appel d’outil, un autre locataire et le même appel avec une sortie différente.
2. 02Confirmez la clé de portée de la décision conservée.

Attendu de toute plateforme gouvernée

Les décisions et les approbations sont limitées au locataire, à l’exécution et à l’appel d’outil ; aucun rejeu ne franchit ces périmètres.

Comportement observé de KLA

La clé d’idempotence est tenant:execution:gate ; la barrière d’entrée contient l’identifiant de l’appel d’outil et la barrière de sortie ajoute le hash de la sortie. Un appel validé rejoué renvoie la décision conservée ; une clé n’autorise jamais un travail sous un autre locataire ou une autre exécution. Les approbations fail-closed dérivent un identifiant déterministe de l’exécution et de la barrière, de sorte que les nouvelles tentatives font référence à une seule approbation.

Preuves

• services/governance-pep/src/idempotency.ts: key structure
• cmb-aml-governance-gateway.test.ts: “does not replay an approval across execution or tenant ledger keys”

Procédure

1. 01Livrez deux fois le même appel d’outil gouverné en parallèle ; livrez-le à nouveau après la fin d’une exécution ; arrêtez le worker entre la décision et la fin, puis laissez l’orchestrateur effectuer une nouvelle tentative.
2. 02Comptez les effets de bord et examinez le lien entre décisions, exécutions et enregistrements de preuves.

Attendu de toute plateforme gouvernée

Une seule occurrence de l’effet de bord par action approuvée lors de nouvelles tentatives parallèles et séquentielles, avec un comportement précis pour la fenêtre de plantage.

Comportement observé de KLA

Un registre durable à écriture anticipée enregistre l’intention avant l’exécution et valide le résultat ensuite ; un appel validé rejoué renvoie le résultat mis en cache sans nouvelle exécution, et l’écriture perdante d’un doublon concurrent renvoie le résultat de l’écriture gagnante. Chaque branche terminale, y compris block et cancel, valide la clé afin qu’une nouvelle tentative renvoie la décision. Après un plantage entre l’intention et la validation, la passerelle relance une fois l’opération et transmet la clé d’idempotence au connecteur aval.

Preuves

• services/governance-pep/src/gateway.ts: write-ahead intent, committed short-circuit, one-shot output release
• governance-gateway.test.ts: “exactly-once: a replayed committed call returns the cached result without re-executing”; concurrent-loser case
• cmb-aml-governance-gateway.test.ts: re-drive across an orchestrator retry without a second side effect

Réserves

• Dans la fenêtre de plantage, exactly-once dépend du respect de la clé d’idempotence transmise par le système aval ; un système qui l’ignore se dégrade en au-moins-une-fois. Le code source le précise.
• La table du registre durable utilise des clés préfixées par le locataire pour l’isolation ; elle ne possède pas encore de politique de sécurité au niveau des lignes.

Procédure

1. 01Suivez la résolution des identifiants de connecteur et la mémoire de processus dans laquelle ils entrent pendant un appel d’outil gouverné.
2. 02Tentez une falsification de requête côté serveur via une URL de connecteur qui se résout vers des adresses internes ou de métadonnées.
3. 03Soumettez des instructions d’écriture via un connecteur de base de données en lecture seule.

Attendu de toute plateforme gouvernée

Les identifiants sont résolus uniquement dans le plan de contrôle ; la sortie est liée à des adresses validées ; les connecteurs en lecture seule refusent les écritures à plusieurs niveaux.

Comportement observé de KLA

Les identifiants de connecteur sont résolus dans le plan de contrôle et matérialisés uniquement dans des en-têtes de requête sortante ou un client de base de données ; le worker d’exécution envoie l’entrée de l’outil et reçoit le résultat. La sortie du connecteur valide chaque adresse résolue à la connexion, lie la connexion à l’adresse IP validée, conserve les noms TLS de l’hôte d’origine et refuse les redirections. Les lectures de base de données passent un filtre de mots-clés avec masquage littéral, puis s’exécutent dans une transaction en lecture seule imposée par la base, avec le rôle disposant du moindre privilège. Les valeurs ressemblant à des secrets sont refusées dans les enregistrements d’installation durables à la frontière de l’API.

Preuves

• services/api/src/services/connector-execution.ts: control-plane custody; DNS-pinned egress; BEGIN READ ONLY
• connector-network-safety.ts: metadata, link-local, multicast, and documentation ranges blocked; private ranges gated by explicit configuration
• mcp-installation-secret-safety.ts: secret-pattern rejection at the API boundary

Réserves

• Les serveurs d’outils MCP lancés localement héritent de l’environnement du processus worker ; un binaire MCP hostile pourrait lire les variables présentes sur ce pod.
• La conservation des identifiants relève de l’architecture ; aucun test négatif automatisé n’affirme qu’un prompt de modèle ne peut jamais contenir d’identifiant.
• Un connecteur peut être configuré pour ignorer la vérification TLS ; un évaluateur doit contrôler ce réglage dans l’enregistrement de connexion.

Procédure

1. 01Modifiez un octet d’un enregistrement de décision conservé, d’un audit d’approbation et d’un reçu de preuve, en utilisant tout accès privilégié admis par le stockage de la plateforme.
2. 02Lisez chaque enregistrement modifié dans le produit et exportez-le ; consignez le point où la détection intervient.

Attendu de toute plateforme gouvernée

La modification de tout enregistrement de gouvernance est détectée à la lecture ou à l’export, au moyen de mécanismes d’intégrité indépendants du stockage modifié.

Comportement observé de KLA

Les enregistrements de gouvernance sont ajoutés à un registre immuable par des écritures vérifiées qui lient la clé et la valeur à la preuve de transaction. Les lectures de la piste d’audit et des barrières de politique passent par des lectures vérifiées qui recalculent le hash du contenu de l’enregistrement et sa preuve d’inclusion ; une divergence empêche de servir l’enregistrement. Les reçus de décision sont signés avec Ed25519 sur une sérialisation canonique et chaînés : chaque reçu inclut le hash de son prédécesseur dans le corps signé, si bien qu’une modification, une suppression ou une réorganisation rompt la chaîne à un index déterminé. Le journal relationnel des transitions est ajouté uniquement par un déclencheur de base de données et porte le même hash de chaîne.

Preuves

• services/api/src/services/immudb-multi-tenant.ts: hash recomputation and trusted-read verification on audit and policy-gate reads
• services/governance-pep/src/receipt-chain.ts + signing.ts: signed hash chain; 28 test cases including tamper, reorder, truncation
• export-api.receipt-ledger-bundle.test.ts: tampered receipt and tampered ledger record turn the export red

Réserves

• Certaines lectures de décisions de politique vérifient un hash de contenu stocké à côté de l’enregistrement sans recalculer de preuve d’inclusion côté serveur, et les modèles de lecture utilisés pour l’affichage, comme la table des décisions de contrôle, sont des lignes modifiables ; l’altération sur ces parcours est établie par comparaison avec le registre scellé et lors de l’export.
• La détection intervient lorsqu’un enregistrement est lu ou exporté ; aucun travail de revérification continue en arrière-plan n’existe.
• La troncature à la fin d’une chaîne de reçus n’est détectée que si le vérificateur reçoit un hash terminal conservé indépendamment.

Procédure

1. 01Exportez un Sealed Evidence Bundle pour une exécution gouvernée, transférez-le sur une machine hors ligne, isolée du réseau, et lancez le vérificateur publié.
2. 02Modifiez un octet dans chaque classe d’artefact et recommencez ; chaque modification doit faire passer l’exécution au rouge avec un contrôle nommé.

Attendu de toute plateforme gouvernée

Un vérificateur autonome prouve les signatures, les chaînes de hash et les preuves d’inclusion à partir du seul bundle, indique clairement ce qu’il ne peut pas prouver hors ligne et applique le refus fail-closed en cas d’altération.

Comportement observé de KLA

Le vérificateur des preuves exécute cinq contrôles sans accès réseau, en utilisant le jeu de clés contenu dans le bundle : signature du manifeste avec les clés du service et du locataire, chaînes de signatures des reçus au moyen du vérificateur d’exécution, recalcul de la chaîne de hash du registre, inclusion Merkle par rapport à la preuve de transaction conservée et cohérence de l’ancre temporelle. Une altération d’un octet dans toute classe d’artefact fait passer le contrôle correspondant au rouge dans la suite automatisée, y compris pour la malléabilité des signatures et les algorithmes incorrects. Le code de sortie constitue le verdict.

Preuves

• packages/evidence-verifier: five checks, command-line verifier, ~55 automated cases
• verifier.test.ts: one-byte tamper per artifact class; revoked key; path escape; malformed key set

Réserves

• Le jeu de clés du vérificateur voyage dans le bundle ; une exécution réussie prouve donc la cohérence interne du bundle tel qu’il a été exporté. Détecter un bundle resigné par un exportateur non fiable exige de comparer ses clés à un matériel de clés reçu indépendamment, et l’épinglage intégré des clés figure dans la feuille de route.
• L’inclusion Merkle est vérifiée par rapport à la preuve de transaction conservée dans le bundle ; la vérification par rapport à l’état du registre signé indépendamment figure dans la feuille de route, et la confirmation de l’ancre temporelle sur la chaîne publique exige une étape réseau.
• Un bundle qui ne déclare que des reçus non signés passe le contrôle des reçus avec zéro chaîne vérifiée ; le vérificateur indique le nombre de reçus non signés et l’auditeur doit en tenir compte.