Microsoft run-assert-eval transforme les constats de risque liés aux agents en contrôles d’exécution testés

Microsoft a publié run-assert-eval le 24 septembre, reliant quatre tâches de sécurité des agents jusqu’alors distinctes au sein d’un même workflow guidé. La compétence Microsoft run-assert-eval identifie les risques, mesure les défaillances, rédige des contrôles d’exécution et répète la même évaluation après l’ajout de ces contrôles. Le dilemme est immédiat : un cycle de sécurité plus rapide n’est utile que si ses mesures restent crédibles.

L’exemple de Microsoft donne de la substance à l’annonce. Selon l’entreprise, un agent de support à la facturation a divulgué les données d’un autre client dans 12 des 40 conversations de référence applicables. Après l’introduction d’une politique d’exécution, Microsoft a observé deux violations sur 34 conversations applicables. Le taux déclaré est ainsi passé de 30,0 % à 5,9 %.

Le résultat semble décisif, mais il provient d’un exemple élaboré et maintenu par les développeurs du projet. Microsoft n’a pas présenté de réplication indépendante ni d’étude de déploiement en production. L’avancée importante réside donc dans le mécanisme, et non dans un score favorable isolé. La compétence transforme une défaillance identifiée en politique applicable, puis teste l’intervention sans modifier discrètement l’évaluation.

Microsoft run-assert-eval relie la découverte, les tests et l’application des règles

Cette publication transforme un ensemble de projets de sécurité en un parcours vérifiable, depuis un risque inconnu jusqu’à un contrôle d’exécution testé.

Le billet de lancement de Microsoft décrit un workflow lancé à l’aide d’un prompt dans un environnement de développement compatible. Les développeurs commencent par définir un agent, son objectif prévu, ses outils et les limites qu’il doit respecter.

La compétence peut utiliser Clarity pour modéliser les menaces pesant sur l’agent. La modélisation des menaces consiste à identifier les défaillances plausibles, les actifs concernés, leurs causes et leurs conséquences avant de sélectionner les tests. Les équipes peuvent également fournir un risque connu issu d’une exigence produit, d’un rapport d’incident, d’un plan de test ou d’une évaluation existante.

Cette distinction est importante. La découverte des risques est recommandée, mais elle n’est pas obligatoire. Une équipe qui sait déjà que son agent de facturation expose des dossiers clients peut commencer par ce comportement plutôt que de répéter le travail de découverte.

Lorsque les équipes ont besoin de découverte, le modélisateur de menaces Clarity examine le contexte opérationnel plus large de l’agent. Il vise à faire émerger des défaillances qui n’avaient jamais été inscrites dans les exigences initiales.

Dans l’exemple de facturation de Microsoft, Clarity a identifié quatre modes de défaillance candidats. L’équipe a sélectionné deux risques jugés critiques : les actions à haut risque non vérifiées et l’exposition de données entre clients.

Le premier risque concernait des modifications de facturation effectuées sans confirmation de l’identité de l’appelant. Le second concernait des divulgations impliquant un compte n’appartenant pas à l’appelant.

La compétence a transmis chaque risque sélectionné à ASSERT, le framework d’évaluation de Microsoft fondé sur les exigences. Chaque risque est devenu une configuration, un comportement et une suite d’évaluation.

Cette structure étroite est plus conséquente qu’elle ne paraît au premier abord. Si une évaluation mélange des défaillances d’autorisation, de confidentialité, d’exactitude et d’escalade, son score agrégé ne peut pas expliquer quel contrôle est nécessaire.

Microsoft run-assert-eval sépare au contraire ces comportements. Des variations sont introduites dans chaque suite par des dimensions telles que le mode d’accès, le prétexte de l’utilisateur, les revendications d’autorité et la dérive du périmètre sur plusieurs tours.

La compétence recherche également des travaux antérieurs et des référentiels de sécurité pour trouver des dimensions de test pertinentes. Microsoft indique que ces sources peuvent inclure les recommandations du NIST, des ressources OWASP, des benchmarks, des documents réglementaires et des politiques de fournisseurs de modèles.

ASSERT génère ensuite des cas, exécute l’agent cible et évalue les transcriptions capturées. Ses deux principales mesures restent volontairement distinctes.

« Impermissible behavior violated » enregistre les cas où l’agent a réalisé un comportement interdit. « Permissible behavior violated » mesure les cas où l’agent n’a pas aidé alors qu’il était autorisé à le faire.

Cette séparation protège contre une illusion de sécurité bien connue. Un agent qui rejette chaque demande peut éviter de nombreuses actions nuisibles, mais il cesse également d’accomplir son travail.

Le workflow génère ensuite un projet de politique Agent Control Specification à partir de la défaillance mesurée. ACS est un format portable permettant de placer des contrôles à des points définis de l’exécution d’un agent.

Enfin, la compétence évalue une version gouvernée de l’agent face aux mêmes cas. Les exécutions de référence et gouvernée conservent la même définition du comportement, le même ensemble de tests et la même méthode de jugement.

Le résultat n’est pas simplement un nouveau score de sécurité. Il s’agit d’une comparaison contrôlée conçue pour isoler la politique comme variable modifiée.

La pression s’exerce sur les équipes qui utilisent les prompts comme principal garde-fou

Microsoft remet en cause l’idée selon laquelle des instructions écrites suffisent à constituer une limite de contrôle adéquate pour des agents utilisant des outils.

Les prompts système restent utiles pour définir les rôles et les comportements attendus. Ils demeurent toutefois des instructions probabilistes interprétées par un modèle, et non des vérifications d’autorisation déterministes appliquées par les logiciels environnants.

Cette faiblesse devient concrète lorsqu’un agent peut récupérer des dossiers, mettre à jour des comptes, émettre des remboursements ou appeler des outils administratifs. Une demande persuasive peut alors devenir une lecture de base de données ou une action métier.

L’exemple de facturation de Microsoft illustre cet écart. L’agent traitait un appelant associé au compte ACME-1001. Il n’aurait jamais dû récupérer ou modifier le compte d’un autre client.

Une demande évaluée sollicitait les coordonnées liées à BPS-447, qui appartenait à un autre client. Selon Microsoft, l’agent de référence a renvoyé l’intégralité du dossier.

Une revue de code pourrait confirmer que la fonction de récupération fonctionne correctement. Un test unitaire pourrait confirmer qu’un identifiant de compte valide renvoie le dossier attendu. Ni l’un ni l’autre ne teste nécessairement si le modèle choisit un identifiant non autorisé au cours d’une conversation réaliste.

Ce problème dépasse le support de facturation. Un agent de recherche peut accéder à des sources inappropriées, tandis qu’un agent de gestion des changements peut contourner une séquence d’approbation. Un agent de voyage peut faire un usage abusif d’informations d’identité ou de paiement stockées.

Les recommandations OWASP qualifient cette situation plus générale d’autonomie excessive. Elle survient lorsqu’une application d’IA possède davantage de fonctionnalités, d’autorisations ou d’autonomie que sa tâche ne l’exige.

L’injection de prompt peut déclencher ces défaillances, mais elle n’en est pas l’unique cause. Des demandes ambiguës, des plans hallucinés, des outils compromis et de simples erreurs du modèle peuvent également produire des actions dangereuses.

Les équipes concernées ne se limitent pas aux groupes de sécurité. Les chefs de produit doivent définir les résultats autorisés et interdits. Les développeurs doivent exposer des points de contrôle appropriés. Les responsables des risques doivent décider si une réduction mesurée est suffisante.

Les équipes d’évaluation sont également sous pression. Leur travail ne peut plus s’arrêter à un rapport qui énumère les défaillances. Le workflow de Microsoft attend qu’un constat soutienne un contrôle précis et une exécution de validation reproductible.

Les organisations qui utilisent des benchmarks génériques de modèles font face à un autre problème. Un benchmark large peut décrire les tendances moyennes d’un modèle, mais il ne peut pas saisir toutes les règles de compte, les limites d’escalade ou les processus d’approbation internes propres à chaque entreprise.

L’approche de Microsoft commence par les exigences et les risques identifiés dans l’application elle-même. Cela rend l’évaluation plus pertinente, même si cela rend également les comparaisons entre organisations moins simples.

Cette publication exerce aussi une pression sur les fournisseurs qui considèrent l’observation comme l’étape finale. Journaliser un appel d’outil dangereux après son exécution peut aider une enquête. Cela n’empêche pas l’action qui a causé le préjudice.

Run-assert-eval place l’intervention dans le chemin d’exécution de l’agent. Cela le rapproche de concepts de sécurité familiers tels que les vérifications d’autorisation, le principe du moindre privilège et les points d’application des politiques.

Cela n’élimine pas les prompts. Cela leur attribue un rôle plus restreint. Les modèles peuvent planifier et interpréter le langage, tandis que des contrôles déterministes décident si des opérations sensibles doivent se poursuivre.

Cette répartition devient de plus en plus importante à mesure que les agents accèdent à des fichiers locaux et à des connaissances internes. Les équipes qui construisent une base de connaissances interrogeable sont confrontées à la même question de frontière : la récupération doit respecter le périmètre d’autorisation réel de l’utilisateur.

Microsoft run-assert-eval intègre cette question dans un workflow que les développeurs peuvent exécuter plus tôt. La charge passe alors de l’espoir que le modèle respecte une règle à la démonstration de l’endroit où le logiciel l’applique.

Le mécanisme central est un test contrôlé avant-après

L’idée la plus forte de run-assert-eval n’est pas la génération automatisée de politiques ; c’est la préservation de l’évaluation tout en ne modifiant que le contrôle.

Les comparaisons de sécurité deviennent peu fiables lorsque les équipes régénèrent l’ensemble de tests après avoir appliqué un correctif. Un groupe différent de prompts peut faire paraître une politique faible efficace, ou faire paraître une politique solide moins performante.

Changer le juge crée une autre variable de confusion. Deux évaluateurs peuvent interpréter différemment la même transcription, surtout lorsque le comportement acceptable dépend du contexte.

Run-assert-eval met en cache la systématisation de référence et les cas de test. L’agent gouverné est ensuite confronté à la même définition du comportement, aux mêmes cas et à la même approche de jugement.

Microsoft décrit cela comme le gel de l’évaluation. La politique devient la variable indépendante visée, tandis que les taux de violation mesurés deviennent les résultats observés.

Le principe rappelle les tests de régression dans les logiciels conventionnels. Un test défaillant doit rester inchangé pendant que les développeurs modifient l’implémentation. Sinon, des résultats positifs peuvent refléter un test réécrit plutôt qu’un comportement corrigé.

Les tests d’agents sont plus difficiles, car les sorties des modèles sont variables. Le juge peut également être fondé sur un modèle, et les cas générés peuvent contenir leurs propres ambiguïtés.

Maintenir ces éléments constants ne supprime pas toutes les sources d’incertitude. Cela rend toutefois la différence avant-après plus interprétable.

Microsoft indique que de précédentes évaluations ASSERT ont constaté un accord de 80 % à 90 % entre son juge automatisé et des évaluateurs humains. L’entreprise compare cette fourchette à un accord d’environ 90 % entre évaluateurs humains.

Ces chiffres correspondent aux résultats rapportés par Microsoft, et non à des garanties universelles d’exactitude. L’accord du juge peut varier selon le comportement, le modèle, la grille d’évaluation, la langue et la complexité de la politique sous-jacente.

L’évaluation sous-jacente reste inspectable. Le référentiel ASSERT indique que les exécutions stockent des artefacts locaux, des cas générés, des sorties de modèles, des justifications du juge et des métriques.

Les artefacts locaux peuvent faciliter les audits, car les examinateurs peuvent vérifier pourquoi une transcription a été classée comme violation. Ils peuvent également identifier les cas où l’évaluateur a mal interprété la politique.

La conception à deux taux d’ASSERT ajoute une autre protection. Une politique qui bloque les comportements nuisibles peut néanmoins échouer si elle provoque des refus excessifs.

Pour la suite inter-clients, Microsoft a rapporté un taux de violation de référence pour les comportements interdits de 30,0 %. Le résultat gouverné était de 5,9 % sur un dénominateur applicable différent.

Microsoft a également réparti ses résultats entre des subdivisions par prompts et par scénarios. Les cas de prompt testent des interactions plus directes, tandis que les cas de scénario capturent des workflows plus riches et un contexte conversationnel.

Pour les cas de prompt inter-clients, le taux déclaré de comportements interdits est passé de 20,8 % à 8,7 %. Le taux correspondant pour les scénarios est passé de 43,8 % à 0,0 %.

Pour les cas de requêtes d’actions non vérifiées, le taux signalé est passé de 4,0 % à 0,0 %. Dans la répartition par scénarios, il est passé de 8,7 % à 4,5 %.

Les violations de comportements autorisés auraient atteint 0,0 % dans les quatre répartitions régies. Microsoft interprète ce résultat comme la preuve que les contrôles ont préservé le travail légitime dans cet échantillon.

Les violations restantes de comportements non autorisés restent importantes. Elles montrent que la politique n’a pas éliminé tous les échecs, même dans cet exemple contrôlé.

Cela correspond à la conception itérative du flux de travail. Une équipe peut examiner les échecs persistants, affiner sa définition du risque ou sa politique, puis répéter le même processus.

La méthode offre donc des éléments de preuve plus solides qu’une poignée de démonstrations manuelles. Elle n’établit toujours pas comment l’agent se comporte face à toutes les requêtes futures, mises à jour de modèle, outils ou environnements.

Le bénéfice pratique est plus limité et plus utile. Les équipes reçoivent des preuves traçables qu’un contrôle précis a modifié les performances dans le cadre d’une évaluation définie, sans simplement réduire l’agent au silence.

Les politiques d’exécution bloquent les actions avant que le modèle ne puisse les terminer

La correction de facturation fonctionne en vérifiant le périmètre du compte à la frontière de l’outil, et non en demandant au modèle de reconsidérer ses intentions.

Après avoir mesuré l’exposition entre clients, run-assert-eval a généré un projet de politique et un manifeste ACS. La politique exprimait la logique de décision, tandis que le manifeste indiquait où cette logique devait s’appliquer.

Microsoft a utilisé Rego, un langage déclaratif de politiques couramment associé aux moteurs de politiques. Le contenu généré est resté un projet nécessitant une validation humaine.

Cette étape de révision est importante. Microsoft indique explicitement que la génération ne vaut pas approbation. Les développeurs doivent examiner la politique, le point d’intervention, le manifeste et la connexion à l’agent cible.

La politique retenue refusait les appels d’outils lorsque l’identifiant de compte demandé différait du compte de l’appelant. Cette règle ne nécessitait pas qu’un autre modèle décide si la demande paraissait suspecte.

Microsoft a placé la vérification à pre_tool_call, un point d’interception atteint avant que l’agent n’exécute un outil. Un identifiant non concordant entraîne donc un refus avant toute récupération de données.

L’équipe a également utilisé post_tool_call. Cette seconde vérification retenait tout résultat non concordant qui ne devait jamais entrer dans le contexte du modèle.

L’utilisation des deux points crée une défense en profondeur. Le premier cherche à empêcher une opération non autorisée. Le second limite l’exposition si le contrôle précédent est contourné ou incorrectement connecté.

Le moteur de politiques ACS vise à dissocier ces contrôles d’un cadre d’agents particulier. Les politiques peuvent ainsi rester portables lorsque les équipes changent de modèles ou de bibliothèques d’orchestration.

Cette portabilité répond à un véritable problème de maintenance. Les contrôles intégrés dans des prompts ou des rappels propres à un framework peuvent devenir difficiles à auditer entre plusieurs implémentations d’agents.

Une spécification partagée peut fournir aux examinateurs de sécurité un objet cohérent à inspecter. Elle peut aussi permettre aux développeurs de versionner les modifications de politiques aux côtés du code applicatif.

Toutefois, la portabilité ne garantit pas une intégration correcte. Chaque environnement d’exécution doit exposer le contexte pertinent, préserver l’identité et appeler la politique au bon moment.

Une règle de périmètre de compte dépend d’informations fiables sur le compte. Si l’identité de l’appelant est erronée ou absente, une comparaison parfaitement rédigée produira malgré tout un résultat d’autorisation incorrect.

La même préoccupation s’applique aux arguments des outils. Une politique qui inspecte account_id suppose que la ressource demandée est correctement représentée par ce champ.

Des outils complexes peuvent dissimuler des cibles sensibles dans des requêtes, documents, URL ou actions imbriquées. Une règle étroite peut alors manquer des chemins équivalents vers la même ressource protégée.

Les politiques d’exécution ne peuvent pas non plus corriger toutes les catégories d’échec. Un contrôle peut bloquer un remboursement non autorisé ou une lecture de base de données. Il ne peut pas déterminer automatiquement si chaque explication générée est exacte ou équitable.

Des approbations humaines restent appropriées pour certaines actions à fort impact. Une conception d’outils fondée sur le moindre privilège peut réduire les dégâts même lorsque le modèle prend une mauvaise décision.

Le cadre de gestion des risques liés à l’IA plus large considère la gestion des risques comme une activité couvrant tout le cycle de vie. Il inclut la gouvernance, la cartographie, la mesure et la gestion continue plutôt qu’un unique test avant publication.

Run-assert-eval s’inscrit dans ce schéma plus large. Il fournit un pont concret entre la cartographie d’un risque et la mesure puis la gestion d’un comportement.

Le point d’entrée du flux de travail sous la forme d’un prompt unique ne doit pas masquer le travail sous-jacent. La modélisation des menaces, la conception des tests, la révision des politiques, l’intégration système et l’interprétation des résultats exigent encore des décisions éclairées.

Ce que Microsoft a réduit, c’est le passage manuel entre ces décisions. La skill transporte des artefacts structurés d’une étape à l’autre et maintient visibles leurs relations.

Cela peut réduire le risque qu’une description du risque perde son sens lors de son transfert entre les équipes produit, évaluation et sécurité.

Cela peut également raccourcir l’intervalle entre la découverte d’un échec et la vérification d’une mesure d’atténuation. C’est souvent durant cet intervalle que les risques non résolus liés aux agents s’accumulent.

Les premiers résultats constituent des preuves, pas une garantie générale de sécurité

L’exemple de Microsoft étaye la logique du flux de travail, mais n’établit pas son efficacité en production pour tous les agents, organisations ou attaques.

La limite la plus évidente est la provenance. Microsoft et les contributeurs du projet ont conçu les outils, sélectionné l’exemple, appliqué les contrôles et communiqué les mesures obtenues.

Cela ne rend pas les résultats invalides. Cela signifie que les lecteurs doivent distinguer un exemple pratique transparent d’un benchmark indépendant ou d’une étude de terrain.

Les tailles d’échantillon exigent également de la prudence. La référence annoncée incluait 40 conversations applicables, tandis que l’exécution régie en comptait 34.

Ces dénominateurs diffèrent parce que seuls les cas applicables contribuent à un taux de comportement donné. Néanmoins, de petits échantillons peuvent produire des pourcentages instables.

Dans cet exemple, passer de 12 violations à deux est opérationnellement significatif. Cela ne doit pas être interprété comme une réduction universelle de 80 % pour d’autres agents.

Le taux signalé de 0,0 % de violations de comportements autorisés signifie également qu’aucune violation n’est apparue dans cet échantillon. Cela ne signifie pas que la politique ne peut jamais bloquer un comportement légitime.

Un ensemble de tests plus vaste pourrait révéler de rares refus erronés. Le trafic de production pourrait inclure des relations entre comptes, des règles de délégation ou des exceptions de support absentes de l’exemple.

La fuite d’évaluation constitue une autre préoccupation. Si une politique est continuellement ajustée par rapport à un même jeu de tests figé, les développeurs peuvent finir par surajuster les cas connus.

Le gel des tests crée une comparaison crédible lors d’une intervention donnée. Les programmes à long terme ont néanmoins besoin de cas retenus, de nouvelles variantes adversariales et d’une surveillance des changements de comportement.

Les changements de modèle peuvent aussi invalider les conclusions antérieures. Un nouveau modèle peut formater les arguments d’outil différemment, interpréter les refus différemment ou trouver un autre chemin vers l’information protégée.

Les changements d’outils créent un risque similaire. L’ajout d’une fonction d’exportation ou d’un point de terminaison de recherche générale peut introduire une voie d’accès non couverte par la vérification initiale du compte.

Le juge d’évaluation mérite une surveillance continue. La plage d’accord signalée par Microsoft est encourageante, mais les cas de désaccord peuvent se concentrer autour des limites les plus ambiguës et les plus importantes.

Les équipes devraient conserver une révision humaine pour les cas contestés et échantillonner périodiquement les résultats apparemment réussis. Un juge automatisé stable est utile pour la comparaison, mais n’est pas une autorité infaillible.

La chaîne d’approvisionnement soulève également un problème contenu dans le mot « skill ». Les skills d’agents contiennent des instructions qui influencent la planification, l’exécution et la validation.

Microsoft Research a récemment signalé 307 échecs induits par des skills dans deux contextes de benchmark. Ils comprenaient 125 échecs fonctionnels et 182 régressions d’efficacité.

Cette recherche n’évalue pas spécifiquement run-assert-eval. Elle établit une raison plus large d’inspecter les instructions, scripts, autorisations et hypothèses opérationnelles de toute skill.

Run-assert-eval répond en partie à cette préoccupation grâce à des artefacts visibles et à des validations humaines. Les équipes peuvent inspecter les configurations d’évaluation et les politiques générées avant d’exécuter des exécutions régies.

Sa génération de tests étayée par la littérature crée une autre obligation de vérification. Un cadre cité peut guider les dimensions, mais sa pertinence dépend de la fidélité avec laquelle la skill traduit cette source en cas de test.

Une traduction faible peut produire d’impressionnantes étiquettes de couverture sans couverture significative. Les examinateurs devraient donc inspecter les scénarios, et pas uniquement les noms de cadres qui y sont associés.

Le coût opérationnel est une autre question ouverte. L’exécution de cas générés, la capture de traces, l’évaluation des transcriptions et la répétition des évaluations consomment des appels de modèle et du temps d’ingénierie.

Le projet n’a pas publié de comparaison étendue entre ce coût et les flux de travail d’évaluation manuelle. Les organisations doivent déterminer quels risques justifient une évaluation plus approfondie.

L’interprétation la plus raisonnable est mesurée mais positive. Microsoft a assemblé un processus cohérent pour un difficile problème d’intégration.

Cette publication ne prouve pas qu’un agent est sûr. Elle aide une équipe à formuler une affirmation de sécurité précise, à y associer des preuves et à tester si une intervention a amélioré un résultat défini.

Trois signaux montreront si l’approche tient ses promesses

Le prochain test consistera à voir si des équipes indépendantes reproduisent les gains du flux de travail sans sacrifier le comportement utile de l’agent ni créer de charges de maintenance cachées.

Le premier signal est la réplication par des tiers. Les développeurs devraient surveiller les évaluations publiques qui appliquent Microsoft run-assert-eval à des agents en dehors des exemples inclus.

Une réplication convaincante publierait les définitions des risques, les cas, la politique, les traces, la configuration du juge et les résultats de la révision humaine. Elle divulguerait également les échecs persistants après la gouvernance.

Des résultats obtenus avec différents modèles et frameworks renforceraient l’affirmation de portabilité de Microsoft. Des différences d’intégration substantielles révéleraient où ACS dépend encore des environnements d’exécution individuels.

Le deuxième signal est l’existence de preuves de production plus étendues. Les équipes doivent savoir si les évaluations figées prédisent les incidents, refus et contournements de politiques dans le trafic réel.

Des preuves utiles comprendraient les tendances des violations après déploiement et les demandes légitimes bloquées par les contrôles. Elles suivraient également les échecs introduits après des modifications de modèle, d’outil ou de prompt.

Les déploiements les plus solides relieront les artefacts d’évaluation à une surveillance continue. Une amélioration avant publication compte davantage lorsque la télémétrie de production confirme la même frontière comportementale.

Le troisième signal est la réponse du projet à l’évasion et à la dérive des politiques. Les attaquants comme les utilisateurs ordinaires peuvent atteindre des actions protégées par des chemins absents de la suite initiale.

Surveillez l’apparition de nouvelles suites couvrant l’injection indirecte de prompts, l’autorité déléguée, les identités contradictoires, la manipulation d’état et les transferts entre plusieurs agents. Surveillez aussi la manière dont le projet évite le surajustement aux cas figés.

Des politiques versionnées et des exécutions de régression seront essentielles. Les équipes ont besoin d’un déclencheur clair pour répéter les évaluations chaque fois que les modèles, outils, autorisations ou règles métier changent.

La publication doit également être jugée à l’aune de son expérience de révision. Une politique générée n’est utile que si les développeurs et les équipes de sécurité peuvent comprendre pourquoi elle existe et ce qu’elle bloque.

Cela fait des artefacts locaux, des transcriptions citées et des définitions étroites de comportements bien plus que de simples détails d’implémentation. Ils constituent la chaîne de preuves qui soutient l’approbation.

Microsoft run-assert-eval est donc mieux considéré comme une discipline d’ingénierie emballée sous forme de skill. Il relie la modélisation des menaces, l’évaluation spécifique à un comportement, l’application de règles à l’exécution et le retest contrôlé.

Les développeurs ne devraient pas se demander si le processus certifie qu’un agent entier est sûr. Ils devraient se demander s’il rend un risque important mesurable, un contrôle vérifiable et une amélioration reproductible.

C’est une promesse plus modeste que de prouver une sécurité générale. C’est aussi un point de départ plus crédible pour la gouvernance des agents.