Ce qu'un toolkit de gouvernance ne peut pas faire (d'après sa propre doc)

Une couche de gouvernance à l'exécution, comme l'Agent Governance Toolkit open source de Microsoft, est l'une des choses les plus utiles apparues dans la stack agentique. Elle intercepte chaque appel d'outil, décide face à une politique écrite si l'action peut se déclencher, et consigne le verdict dans un journal inviolable. À son crédit, le projet publie aussi une liste honnête de ce qu'il ne fait pas. Cette liste vaut plus que n'importe quelle revue, parce qu'elle définit le travail qui reste le vôtre.

Sauf qu'à l'instant où une couche de gouvernance est en place, elle invite une hypothèse dangereuse : le modèle de menace serait désormais couvert. Il ne l'est pas. Une couche de gouvernance est nécessaire et pas suffisante, et traiter « nécessaire » comme « suffisant » est la manière dont un système qui a l'air bien défendu laisse ses vraies brèches ouvertes.

L'erreur est d'acheter une serrure pour la porte d'entrée et d'arrêter de penser aux fenêtres.

Elle gouverne des actions, pas des intentions

Un gate sur l'appel d'outil voit l'action, pas le raisonnement derrière. Il n'attrapera donc pas un fait halluciné une fois ce fait passé dans une action que l'agent avait le droit de faire. Il n'arrêtera pas de façon fiable une instruction malveillante glissée à l'intérieur d'un contenu qu'on a demandé à l'agent de lire. Et il ne peut pas voir que dix actions individuellement inoffensives, chacune correctement autorisée, forment ensemble un plan nuisible.

Ce ne sont pas des bugs. C'est la limite de ce qu'un gate par appel peut faire. Les attraper demande d'autres couches : une frontière de contamination qui empêche une entrée non fiable de devenir une instruction privilégiée, un motif à deux modèles qui sépare le composant qui lit le contenu non fiable de celui qui a le droit d'agir, et une analyse au niveau du workflow qui regarde la séquence, pas seulement l'étape.

Elle tourne dans la même frontière de confiance que l'agent

Par conception, une couche de gouvernance applicative vit dans le même processus que l'agent qu'elle surveille. Ce qui signifie qu'un attaquant qui compromet complètement l'agent peut, en principe, passer devant le garde sans s'arrêter.

C'est le bon endroit pour appliquer la politique, et c'est aussi pourquoi appliquer une politique n'est pas la même chose qu'isoler. Un vrai confinement demande une frontière que l'agent ne peut pas contourner : des identités à moindre privilège par agent, des credentials à courte durée de vie sans rien de statique à voler, une exécution en bac à sable et une allow-list de sortie. Le gate décide de ce qui est permis. Le bac à sable décide de ce qui est possible même quand le gate est contourné.

L'autorisation par défaut est une falaise de configuration

Activée sans politique chargée, l'action par défaut est d'autoriser tout. Exécutez-la en mode permissif sans vous en rendre compte, et chaque agent est effectivement non gouverné pendant que le tableau de bord reste au vert.

C'est l'échec qui passe un comité de changement. La couche est présente, la case est cochée, et le règlement est vide. Une gouvernance qui autorise par défaut est une gouvernance qu'il faut mériter activement, à chaque fois, avec une politique écrite délibérément et des tests qui prouvent qu'elle est chargée.

Elle journalise ce qu'on lui a remis, brut

Le système d'audit consigne les paramètres d'appel d'outil tels qu'il les reçoit. Si un appel porte une donnée personnelle, un credential ou un jeton en argument, cette valeur peut atterrir mot pour mot dans le journal. Un enregistrement inviolable de vos secrets reste un enregistrement de vos secrets.

La rédaction, la classification et un chemin de données qui garde le matériel réglementé hors du journal ne sont pas le travail du toolkit. Ce sont les vôtres, et dans un environnement réglementé ils ne sont pas optionnels.

L'audit enregistre la tentative, pas le résultat

Le journal capte qu'une action a été autorisée et transmise au monde extérieur. Il ne vérifie pas que l'action a réussi, et il ne peut pas vous dire si l'autoriser était juste. C'est la preuve d'une décision, pas la preuve d'une bonne décision. Le jugement derrière la politique, et la responsabilité du résultat, se tiennent entièrement hors de l'enregistrement.

Nécessaire, et pas suffisante

Mettez les limites bout à bout et la forme du vrai système apparaît. Une couche de gouvernance est un contrôle parmi d'autres, et ceux qu'elle ne peut pas fournir sont exactement ceux qui séparent une démo d'un système qu'un régulateur acceptera.

La question à apporter à votre prochaine revue d'architecture n'est donc pas « avons-nous une couche de gouvernance à l'exécution ? ». Ayez-en une. C'est : lesquelles de ses limites annoncées couvrons-nous avec une autre couche, et lesquelles espérons-nous discrètement sans importance ? La réponse honnête à cette question, c'est votre posture de sécurité réelle. Le toolkit vous a dit où sont ses bords. Construire au-delà, c'est tout le métier.

Si vous voulez cartographier une couche de gouvernance sur les couches qui doivent l'entourer, prenez rendez-vous.