Agentic AI Security Testing : Les preuves qui rendent les agents IA testables

Dans le Model Context Protocol (MCP), un hôte crée un client pour chaque serveur. L’hôte est censé faire respecter l’autorisation, le consentement et les frontières de sécurité. Les outils sont découverts et appelés via des opérations de protocole structurées. Leurs descriptions et annotations peuvent influencer le comportement du modèle et ne sont pas fiables en soi. Un incident s’étend donc sur l’ingestion de contenu, la planification, l’approbation, l’appel d’outil et l’effet distant. Il ne reste pas confiné à un seul appel de modèle.

De cette architecture découlent trois transitions observables : hôte→client, client→serveur et serveur→effet. Une trace qui se termine sur une réponse d’outil réussie peut néanmoins passer à côté de la question de savoir si une écriture externe a eu lieu, a été exécutée deux fois ou a atteint une autre cible. Les logs de composants ordinaires ou un identifiant de trace commun consignent rarement si l’approbation correspondait, à l’exécution, au principal, aux arguments, à la cible et à l’autorité déléguée.

Trois questions de recherche

• RQ1 : quels profils de preuves reconstruisent un effet sous des perturbations de télémétrie contrôlées et l’attribuent sans ambiguïté ?
• RQ2 : des liaisons sémantiques dérivées de menaces améliorent-elles la détection de sécurité au-delà de la simple corrélation ?
• RQ3 : que coûtent les preuves, et quels modes de défaillance subsistent ?

La contribution comporte trois volets : un Evidence Contract en quatre étapes qui fait correspondre les constats MAESTRO et STRIDE à des champs d’exécution ; un corpus déterministe d’injection de fautes avec six familles d’attaques, des variantes bénignes très proches et un ledger de ground truth que le reconstructeur ne voit jamais ; et une comparaison de profils fragmentés, corrélés, causaux et threat-guided sur 3024 cellules.

MAESTRO organise les menaces sur sept couches en interaction d’un système agentique et met l’accent sur les effets inter-couches. Les couches vont des Foundation Models aux opérations sur les données, aux frameworks d’agents, à l’infrastructure de déploiement, à l’évaluation et l’observabilité, puis à la sécurité et la conformité, jusqu’à l’écosystème d’agents. STRIDE ajoute six catégories de propriétés : Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service et Elevation of Privilege.

L’article utilise les deux frameworks pour sélectionner des scénarios pertinents aux frontières. Il ne revendique aucune validation empirique des frameworks. L’OWASP Top 10 for Agentic Applications 2026 sert de contre-vérification du vocabulaire, notamment ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory & Context Poisoning et ASI08 Cascading Failures ; ces risques y sont considérés comme des problèmes au niveau du système.

Chaque événement porte un identifiant d’événement immuable, un composant, une étape, une version de schéma et un horodatage. Des champs de corrélation y ajoutent les Trace-IDs, Span-IDs, Parent-IDs et Action-IDs. Les champs threat-guided lient des faits dont un oracle de test contrôle l’égalité ou l’ordre. Il est décisif que l’événement d’outil répète les valeurs exécutées au lieu de simplement pointer vers la décision. Seule la comparaison d’étapes voisines rend visibles des substitutions qui restent invisibles dans de simples traces de corrélation.

Ce que le contrat n’enregistre volontairement pas

Aucun profil n’enregistre de chain-of-thought masquée. Les preuves de décision se limitent à des résultats de policy explicites, des reason codes concis, des attributs approuvés et des hashes adaptés à des tests contrôlés. Il n’est pas nécessaire de stocker des contenus de prompt sensibles ni le raisonnement du modèle. Des labels de provenance, des identifiants stables et des keyed digests suffisent pour les tests et réduisent l’exposition.

Depuis septembre 2026, ACS est un projet de l’OWASP GenAI Security Project, au niveau 2 (Incubator) selon ses propres métadonnées ; la spécification v0.1.0 date du 5 juin 2026, le tag de release actuel est 0.1.2. ACS est issu de l’Agent Observability Standard (AOS). Selon ACS, un agent est digne de confiance lorsqu’il est inspectable, traceable et instrumentable. Les opérateurs doivent donc pouvoir établir après coup ce qu’un agent a fait et pourquoi, et pouvoir limiter à l’avance ce qu’il a le droit de faire.

Les trois piliers

Wire, provenance et chaîne d’audit

• Format de transmission JSON-RPC 2.0. Namespaces de méthodes : steps/* (hooks), protocols/* (MCP encapsulé ; A2A est réservé pour v0.2), agbom/*, system/* et handshake/*. En cas de conflit de version, le handshake se termine par UNSUPPORTED_VERSION. La prose de la spécification suppose encore des mécanismes MCP antérieurs à la révision 2026-07-28, et l’appartenance du wrapping MCP à ACS-Core est contradictoire dans le texte ; les appels d’outils MCP peuvent aussi passer par steps/toolCallRequest/-Result.
• La provenance est un label d’origine factuel posé sur les champs porteurs de données. Il est posé par du code de framework déterministe, jamais par le LLM : origin (user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external), source_id et derived_from comme arêtes de filiation.
• Dans le profil acs-provenance, la provenance au niveau du champ est obligatoire pour chaque champ porteur de données de la session, y compris chaque argument de steps/toolCallRequest. La classification de confiance est faite par le Guardian selon la policy locale ; ce n’est pas un champ du schéma v0.1.
• Chaque réponse pour une étape porteuse de contenu comporte un chain_hash : la tête SHA-256 glissante de la chaîne d’audit. policy_references (y compris la policy_version optionnelle) et cited_provenance_ids rendent la décision rejouable.
• Les signatures sont crypto-agiles et obligatoires dans ACS-Core : chaque requête et chaque réponse est signée sur l’enveloppe canonique ; HMAC-SHA256 avec une clé de session dérivée par HKDF est la base qui satisfait cette exigence. Elle rend détectable une altération sur le réseau, mais pas un Guardian compromis. La non-répudiation n’arrive qu’avec le profil acs-crypto : ML-DSA-65 (obligatoire) et SLH-DSA-128s (recommandé en secours).

Pourquoi la lacune d’effet est structurelle

Les hooks ACS se déclenchent dans le runtime de l’agent. steps/toolCallResult signale ce que l’outil renvoie à l’agent. Il ne signale pas ce qui s’est réellement passé sur le système cible. L’article montre pourquoi cette différence compte : une trace qui se termine sur la réponse d’outil réussie peut manquer des écritures en double ou des cibles redirigées. Les preuves d’effet doivent donc provenir d’une seconde source, indépendante de l’agent. Elle est liée à la trace ACS via les Action-IDs et Request-IDs.

Pourquoi le fail-open est le problème F1

Si le Guardian est injoignable avec la failure posture proceed, l’action se poursuit. ACS exige certes de consigner chaque proceed en fail-open comme événement d’audit, mais il ne se crée aucun Decision Receipt avec liaisons d’approbation. Sur le plan opérationnel, cela correspond à la perturbation F1 de l’expérience (interprétation VamiSec). Lorsque les événements de décision manquent, la reconstruction exacte et l’attribution tombent à 0 %, le rappel du profil threat-guided à 50 %. Un déploiement ACS qui prend les tests de sécurité au sérieux négocie donc on_decision_failure: deny (dans l’implémentation de référence : ACS_ON_DECISION_FAILURE=deny), règle la startup posture sur refuse côté Observed Agent et considère un receipt manquant comme un échec de test, et non comme une lacune dans le log.

Le corpus contient six familles de workflows avec chacune quatre variantes non sûres et deux variantes bénignes très proches : 36 templates, dont 24 non sûrs et 12 bénins. Trois répétitions déterministes donnent 108 instances de workflow. Les répétitions font varier les identifiants et le jitter des événements. Elles constituent un contrôle de reproductibilité, et non des échantillons statistiques indépendants.

Un générateur de confiance produit des événements JSON canoniques de type MCP. Séparément, un ledger de ground truth est créé avec les identités d’événements attendues, les arêtes parent, les labels unsafe, la règle violée et la première étape de violation. Avant la reconstruction, les IDs de cas privés sont retirés des événements observables. Les workflows de la même famille partagent une fenêtre temporelle volontairement chevauchante. C’est un cas difficile pour l’attribution au plus proche dans le temps.

Reconstruction et métriques

• P0 regroupe un effet avec l’outil le plus proche dans le temps, P1 par Trace-ID. P2 et P3 suivent les arêtes parent et se rabattent sur les Action-IDs lorsqu’un parent d’effet manque.
• La reconstruction exacte exige le prompt, la décision, l’outil, tous les effets et, dans P2/P3, les arêtes parent attendues.
• L’attribution sans ambiguïté exige que tous les effets attendus soient projetés exactement sur le bon prompt, la bonne décision et le bon outil, même lorsqu’une arête parent manque.
• Le rappel et la précision utilisent le label unsafe, le taux de faux positifs sur les cas bénins s’appuie sur les 12 templates bénins. Les taux Correct-Rule et First-Stage testent le diagnostic.

L’implémentation n’utilise que la bibliothèque standard Python. Deux exécutions propres ont produit des hashes de configuration, de cas, d’agrégats et de summary identiques à l’octet près. Trois tests unitaires vérifient la taille et l’équilibre de la matrice, les sorties déterministes ainsi que la comparaison de rappel P3 contre P2.

P0 n’a jamais atteint d’attribution sans ambiguïté, car les workflows qui se chevauchent dans le temps ont fusionné. Son rappel apparent de 84,5 % n’est pas une performance de sécurité exploitable : des chaînes fusionnées à tort ont déclenché une alerte sur 85,7 % des cas bénins. P1 n’a détecté que des effets en double. P2 a porté l’attribution sans ambiguïté à 85,7 %, le rappel de sécurité est resté à 16,7 %. P3 a conservé l’attribution de P2 et porté le rappel, le taux Correct-Rule et la localisation First-Stage à 92,9 %.

Sensibilité aux fautes

1. 1
   F0Preuves inchangées

   P1 à P3 reconstruisent et attribuent chaque workflow. P3 atteint 100 % de rappel et de précision sans faux positifs.

2. 2
   F2Scission de trace à la frontière de l’outil

   P1 perd entièrement la reconstruction et l’attribution. P2 et P3 restent à 100 %, car les identifiants de parent et d’action franchissent la frontière de trace modifiée.

3. 3
   F3Parents d’effet perdus

   La reconstruction exacte de P2/P3 tombe à 0 %, l’attribution sans ambiguïté reste à 100 % grâce au repli sur l’action.

4. 4
   F4–F6Décalage temporel, doublons, échange d’Action-ID

   Aucune perte pour P2/P3 : les preuves restantes fournissent un chemin sans ambiguïté, et les contrôles de corruption révèlent l’incohérence injectée.

5. 5
   F1Événements de décision manquants

   La faiblesse résiduelle dominante : la reconstruction et l’attribution tombent à 0 % dans P1 à P3, le rappel de P3 à 50 %. L’autorité de la source, la mémoire et les doublons restent détectables. La liaison d’approbation, de scope et de cible perd son point de comparaison.

Par rapport à P0, P3 ajoute 1682 octets (environ 1,64 Kio), par rapport à P2 1096 octets. Un collector avec la même représentation d’événements conserverait, pour un workflow de taille moyenne, environ 3,55 fois les octets canoniques de P0, ou 1,88 fois ceux de P2. Ces valeurs répondent à RQ3 comme comparaison du volume de sérialisation. Elles ne mesurent ni la latence, ni le CPU, ni le volume de transfert, ni la compression, ni l’indexation, ni les coûts monétaires.

Règles d’exploitation de l’article, transposées à ACS

• Des Decision Receipts, Invocation Receipts et Effect Receipts complets d’abord pour les opérations privilégiées : en termes ACS, pour des capabilities comme filesystem.delete, network.egress ou process.execute.
• Fixer des limites de conservation explicites. La déduplication, la compression et les keyed digests peuvent réduire le volume, mais doivent être mesurés séparément.
• Celui qui omet un champ pertinent pour les invariants ou échantillonne des Decision Receipts modifie l’Evidence Contract et doit réévaluer. F1 montre ce qui est alors perdu.
• Modéliser séparément l’intégrité, les horloges, la conservation et le contrôle d’accès. ACS propose pour cela la base HMAC (acs-core), des signatures asymétriques ou PQC (acs-crypto), request_hash (acs-audit) et le chain_hash de la chaîne d’audit.

1. 1
   Étape 1Traduire les menaces en hypothèses

   Passer en revue, pour chaque workflow d’agent, les couches MAESTRO et les propriétés STRIDE. Formuler pour chaque transition dangereuse un tuple H = (boundary, precondition, invariant, evidence, oracle).

2. 2
   Étape 2Définir les hooks et profils ACS

   ACS-Core comme base, plus les profils acs-trace et acs-provenance. En plus des six hooks obligatoires d’ACS-Core (sessionStart, userMessage ou agentTrigger, toolCallRequest, toolCallResult, agentResponse, sessionEnd), instrumenter steps/knowledgeRetrieval, steps/memoryContextRetrieval et steps/subagentStart — et vérifier que le Guardian les inscrit dans methods_evaluated (sinon ALLOW-by-default).

3. 3
   Étape 3Définir le Decision Receipt

   Principal, version de policy, reason code, opération, cible normalisée, digest d’arguments, capabilities, profondeur de délégation, expiration et idempotence dans policy_data. Persisté et lié à request_id ainsi qu’à chain_hash.

4. 4
   Étape 4Durcir la failure posture

   Régler la failure posture sur fail-closed : on_decision_failure: deny dans le ServerHello (implémentation de référence : ACS_ON_DECISION_FAILURE=deny) et, côté Observed Agent, la startup posture refuse au cas où le handshake lui-même échoue. Signer les enveloppes. Un receipt manquant est un échec de test.

5. 5
   Étape 5Raccorder un puits d’effets indépendant

   L’audit de gateway, de base de données ou de sink fournit la cible observée, le digest d’opération et la clé d’idempotence, corrélés via l’Action-ID.

6. 6
   Étape 6Tests négatifs avec jumeaux bénins

   Pour chaque famille, des cas non sûrs et des cas bénins très proches, par exemple une résolution d’alias autorisée ou des accès en lecture répétés. Figer les predicates avant de tester.

7. 7
   Étape 7Deux gates CI

   Gate 1 reconstruction : étapes obligatoires et arêtes parent complètes, sinon quarantaine. Gate 2 correction : invariants satisfaits, sinon arrêt avec la règle violée et la première étape.

8. 8
   Étape 8Injecter des fautes de télémétrie

   Exécuter régulièrement F1 à F6 contre votre propre pipeline. Un test qui reste vert sous F1 ne vérifie aucune approbation.

L’étude utilise des fixtures déterministes synthétiques, des invariants écrits à la main et des plannings d’événements fixes. Elle n’exécute ni LLM, ni implémentation MCP, ni OAuth, ni moteur de policy, ni service externe. Elle ne mesure pas le succès d’une prompt injection et ne montre pas non plus qu’un contrôle empêche un effet. La précision et le rappel ne valent que pour les six familles codées. Comme l’évaluateur a été conçu à partir des mêmes hypothèses de menace, l’expérience teste la force probante et la cohérence de l’implémentation, et non la découverte de nouvelles menaces.

• Le ledger de ground truth est logiquement séparé, mais provient de la même base de code. Des implémentations indépendantes, une mutation property-based et de vraies captures de protocole réduiraient les erreurs de mode commun.
• La télémétrie est supposée authentique. Les producteurs falsifiés, la troncature de logs au-delà des fautes injectées, les collectors compromis et la vérification cryptographique restent ouverts.
• Les nouvelles classes de menaces exigent leur propre hypothèse, leurs champs, leurs oracles et des tests écrits indépendamment. L’épuisement de ressources (Resource Exhaustion) exige par exemple des preuves de budget et de consommation, la télémétrie falsifiée exige l’identité du producteur et un contrôle d’intégrité.

Divulgation issue de l’article : OpenAI Codex a été utilisé pour l’organisation de la littérature, l’ossature d’implémentation et la revue du code d’évaluation synthétique, les premières ébauches et la révision linguistique ainsi que la mise en forme. La problématique, le modèle de menaces, l’exécution, la vérification des résultats et des sources ainsi que toutes les décisions finales relèvent de l’auteur.