Publié le 8 octobre 2026 à 07:00 · Publication originale
24 septembre 2026.
Un agent de support facturation doit travailler uniquement sur le compte du client authentifié.
Microsoft le teste pourtant sur des demandes visant d'autres comptes.
Résultat: 12 violations sur 40 conversations applicables.
30%.
L'agent restitue parfois les données d'un autre client.
L'équipe Responsible AI applique alors run-assert-eval.
Le workflow ne se contente pas d'ajouter une règle. Il conserve la définition du comportement, le jeu de tests et la méthode de jugement, puis modifie le contrôle d'exécution.
Pour la fuite inter-clients, l'Agent Control Specification intervient avant l'appel d'outil.
Si l'account_id demandé ne correspond pas au compte authentifié, l'appel est refusé.
La décision est déterministe.
Aucun LLM supplémentaire ne décide si la requête "semble" suspecte.
Le même contrôle agit aussi après l'appel d'outil afin qu'un résultat interdit ne remonte pas dans le contexte du modèle.
Puis Microsoft rejoue l'évaluation.
Les violations inter-clients passent de 30% à 5,9%: 2 cas sur 34 conversations applicables.
Sur le sous-ensemble de scénarios, elles passent de 43,8% à 0%.
Mais Microsoft mesure aussi l'autre échec possible: bloquer des demandes légitimes.
Les violations de comportement permis tombent à 0% sur les quatre sous-ensembles publiés.
Une règle de sécurité ne devient donc crédible qu'après avoir montré deux choses: le comportement interdit recule et l'agent continue à accomplir le travail autorisé.
ULTRA®
Le détail méthodologique est probablement le plus important.
run-assert-eval réutilise le même comportement cible, le même jeu de tests et la même approche de jugement avant et après le contrôle.
La politique devient l'intervention.
Microsoft précise que les évaluateurs automatisés d'ASSERT avaient auparavant atteint 80 à 90% d'accord avec des évaluateurs humains, eux-mêmes autour de 90% entre eux.
Cela ne transforme pas l'expérience en essai scientifique parfait: les dénominateurs applicables passent ici de 40 à 34 et les échantillons restent petits.
Mais la logique change profondément la gouvernance.
Un contrôle n'est plus défendu parce qu'il paraît raisonnable.
Il produit une trace avant/après sur une épreuve conservée.
Pour un comité de risque, cela rapproche la gouvernance des agents de l'assurance technique: identifier un défaut, intervenir au point d'échec, mesurer le coût du contrôle et rejouer exactement l'épreuve.
ARGOS
Une politique devient beaucoup plus sérieuse lorsqu'elle peut échouer devant le même test qui avait révélé le risque.
Sources
Microsoft Responsible AI, "Introducing run-assert-eval", 24 septembre 2026
Microsoft, ASSERT, 2 juin 2026
Microsoft, Agent Control Specification, 2 juin 2026
#VOCEASSOCIATION #AIGovernance #AgenticAI #AIAssurance