La plupart des équipes traitent la gouvernance de l'IA comme quelque chose que l'on observe : un tableau de bord, un score de qualité, un audit mené en fin de trimestre. L'observation compte, mais elle intervient après que l'action s'est déjà exécutée. À ce stade, l'argent a bougé et l'enregistrement a été écrit. La véritable gouvernance doit intervenir avant — sur le chemin d'exécution, sous la forme d'un verrou que l'action doit franchir pour continuer.
Dans Cortex, chaque action d'agent parcourt le même pipeline de huit verrous fail-closed. Fail-closed signifie que le refus est le comportement par défaut : si un verrou ne peut pas laisser passer une action de façon affirmative, l'action s'arrête. Rien n'atteint le modèle ni l'outil tant que toute la séquence n'est pas franchie. Voici le pipeline, dans l'ordre.
Le pipeline
- 1 — Identité. S'agit-il d'une identité d'agent gouvernée, active et non expirée ? Une identité expirée ou suspendue est refusée avec 403 IDENTITY_EXPIRED avant que quoi que ce soit d'autre ne s'exécute.
- 2 — Budget. Reste-t-il de la dépense disponible sous les plafonds du tenant et de l'agent ? Un plafond dépassé renvoie 402 — l'exécution ne démarre jamais.
- 3 — Garde-fous. Filtrage DLP et de sécurité sur le prompt et les entrées avant que le modèle ou un outil ne les voie. Une entrée bloquée n'atteint jamais le modèle.
- 4 — Registre. La compétence, l'outil ou le modèle est-il enregistré, autorisé et — pour une publication — au-dessus du seuil de fiabilité ? Une publication sous le seuil est refusée avec 409 RELIABILITY_TOO_LOW.
- 5 — Control Tower. L'agent ou l'outil est-il en pause, confiné ou sous kill switch ? Un sujet en pause est arrêté ici.
- 6 — Exécution. L'appel gouverné au modèle et aux outils s'exécute réellement — le seul verrou dont le chemin nominal est un 200.
- 7 — Contrôle de sortie. Filtrage DLP et de sécurité sur l'artefact généré avant sa remise à un humain ou à un système en aval.
- 8 — Audit. L'issue est scellée dans le Trust Ledger à altération détectable avec un reçu signé — l'exécution est ainsi prouvable, et pas seulement affirmée.
Chaque case du pipeline est un verrou de gouvernance que vous pouvez voir et contrôler. Si un seul verrou refuse, l'exécution n'atteint jamais le modèle ni l'outil. Le refus est le comportement par défaut.
La politique et la supervision se superposent par-dessus
Les huit verrous constituent le socle structurel. Deux couches configurables se posent par-dessus et ne peuvent rendre une décision que plus stricte, jamais plus permissive. Policy-as-Code évalue vos règles par ordre de priorité et se résout vers l'effet le plus restrictif — deny l'emporte sur require_approval, qui l'emporte sur allow. Une action à forte valeur déclenche une règle require_approval et reste en attente au lieu de s'exécuter :
Les Oversight Modes déterminent le degré d'autonomie d'un agent — de suggest_only, où chaque action reste en attente, en passant par execute_low_risk, jusqu'à autonomous, où seul le plancher de risque propre à l'action met en attente. Point essentiel, la supervision est une couche de resserrement : le plancher « risque élevé » de l'action est toujours respecté, et la supervision ne peut qu'ajouter de la friction, jamais en retirer.
Pourquoi un refus est une fonctionnalité, pas un échec
Un vrai code de statut sur une action refusée est ce qu'un runtime gouverné produit de plus utile. Un 402, un 403, un 409 ou un 451 est un verdict honnête et lisible par une machine : cette action a été arrêtée, voici exactement pourquoi, et voici l'enregistrement qui le prouve. Ce sont les passages silencieux qui mettent les entreprises en difficulté — l'action qui s'est exécutée alors qu'elle n'aurait pas dû, sans rien pour en rendre compte.
Lorsque chaque exécution franchit les mêmes huit verrous et que chaque verdict atterrit dans le registre, la gouvernance cesse d'être un audit trimestriel pour devenir une propriété du système. Vous n'espérez pas qu'un agent s'est bien comporté. Vous pouvez montrer, verrou par verrou, qu'il ne pouvait pas faire autrement.