Justifier la confiance dans le travail d’un agent : son résultat, son parcours d’exécution et les preuves qui fondent l’évaluation.
Architecture et protocole de validation spécifiés Prochaine étape · Expérimentation MCP contrôlée
Les équipes d’ingénierie souhaitent confier aux agents des capacités utiles : modifier un logiciel, appeler des services et mener des processus à leur terme. Agent Assurance étudie ce qui permettrait de justifier cette autonomie, en reliant les exigences de la tâche au travail réalisé et aux limites respectées.
Le produit s’adresse aux équipes plateforme et plateforme IA, en lien avec les responsables de la sécurité et des risques opérationnels.
Cadrage produit, architecture logique, modèles de tâches et d’événements, sémantique des décisions, structure des preuves, scénarios de référence et protocole de validation.
Le premier axe expérimental utilise les appels d’outils du Model Context Protocol (MCP) pour tester si une évaluation de la séquence apporte une décision utile au-delà des contrôles d’autorisation individuels.
Vérifier le changement livré au regard des exigences fonctionnelles, des tests de non-régression, des propriétés de sécurité, des critères de performance et des attentes métier.
Le vérificateur adapté dépend de la tâche : une modification de code, un livrable généré et une opération métier achevée nécessitent des preuves différentes.
Évaluer les opérations, identités, délégations, flux de données et ressources partagées au fil de l’exécution. Leur enchaînement peut créer une capacité que chaque contrôle d’autorisation local permet isolément.
La détection de ces capacités composées constitue la priorité de recherche actuelle. MCP est la première surface expérimentale.
L’architecture spécifiée suit le travail depuis un contrat de tâche défini à l’extérieur de l’agent jusqu’à une évaluation précédant l’effet d’une action critique.
Le modèle de preuve relie une affirmation aux événements qui l’étayent, à la version des règles, aux identités et aux contrôles d’intégrité. Chaque évaluation déclare son périmètre, les surfaces couvertes et les informations disponibles.
L’exécution A peut écrire un livrable dans un stockage. L’exécution B peut lire dans ce stockage. Leurs autorisations individuelles permettent ces opérations, tandis que les règles de la tâche imposent l’isolation des deux exécutions.
L’expérience placerait les deux opérations sous contrôle et conserverait l’identité et la provenance de la ressource entre les exécutions.
L’opération est autorisée localement. L’événement identifie l’exécution à l’origine de l’écriture et la ressource persistante.
Le contrôle d’autorisation local permet la demande. La provenance de la ressource la relie à l’exécution A.
Le contrôle proposé évalue si cette lecture compléterait un canal entre exécutions interdit par les règles de la tâche.
Décision attendue : refuser la lecture avant son appel lorsque le chemin interdit est établi.
Le chemin à l’appui est : exécution A → ressource persistante → demande de lecture par l’exécution B. L’évaluation doit identifier la règle pertinente, la provenance de la ressource, les événements observés et le point où l’action a été arrêtée.
Un processus de partage autorisé constitue un cas de comparaison : les mêmes opérations peuvent être permises lorsque le contrat de tâche autorise cet échange.
Une provenance insuffisante produit une évaluation indéterminée. Pour une action critique, les règles peuvent exiger qu’un responsable autorisé examine les preuves disponibles et décide de poursuivre ou non.
Une violation vérifiée des règles conduit à DENY. Une action critique dont l’évaluation est indéterminée peut conduire à REQUIRE_APPROVAL. La décision dépend à la fois des preuves, des règles et de la criticité.
Le catalogue de scénarios couvre les canaux entre exécutions, la persistance, la délégation, l’intégrité des preuves et les résultats corrects obtenus par des chemins interdits.
Le protocole compare les décisions d’autorisation individuelles à l’évaluation contextuelle proposée. Il mesure ensuite les fausses alertes, les violations manquées, la latence, la qualité des explications et le comportement lorsque les observations sont incomplètes.
Ces expériences permettront d’établir la faisabilité technique, l’apport à la décision et les conditions d’une adoption utile.
QA Hub et d’autres vérificateurs pourraient fournir des preuves pour vérifier le résultat. Agent Assurance relierait ces preuves au parcours d’exécution pour justifier une autonomie accrue dans un périmètre explicite.