OWASP Agent Control Standard (ACS) : contrôler les agents IA à l’exécution

Du générateur de réponses à l’acteur

Les applications LLM classiques produisent du texte qu’un humain lit avant que quoi que ce soit ne se produise. Les agents IA, eux, planifient de manière autonome, appellent des outils, écrivent dans une mémoire à long terme et lancent des sous-agents. Chacune de ces étapes peut modifier des données ou les faire sortir vers l’extérieur. La question de contrôle devient donc : « Cette action précise, avec ces arguments précis, est-elle autorisée maintenant, dans cette session ? » On ne peut y répondre qu’à l’exécution — entre la décision du modèle et son exécution par le framework.

Les prompts système ne sont pas des contrôles

De nombreux déploiements s’appuient sur des consignes du prompt système telles que « ne supprimer aucune donnée de production ». De telles phrases sont des demandes adressées à un système probabiliste, pas des règles effectivement appliquées. La page du projet ACS ouvre d’ailleurs son argumentaire sur ce constat : les prompts système ne sont pas des contrôles, de meilleurs modèles ne couvrent ni les cas limites ni les entrées adversariales, et les garde-fous propriétaires créent une dépendance vis-à-vis du fournisseur.

Éditeurs comme chercheurs le confirment. OpenAI écrit le 22 décembre 2025 que l’injection de prompt est « unlikely to ever be fully 'solved' ». Dans l’étude « The Attacker Moves Second » (arXiv, 10 octobre 2025), des attaques adaptatives ont contourné douze mécanismes de défense récents, le plus souvent avec des taux de réussite supérieurs à 90 % — alors que la plupart avaient initialement annoncé des valeurs proches de zéro. La robustesse du modèle réduit le risque, mais ne l’élimine pas. Il faut une instance de contrôle indépendante, extérieure au modèle.

Lethal trifecta et Agents Rule of Two

Le 16 juin 2025, Simon Willison a décrit la « lethal trifecta » : un agent qui a accès à des données privées, qui est exposé à des contenus non fiables et qui peut communiquer vers l’extérieur peut être amené, par injection de prompt, à exfiltrer des données. Le 31 octobre 2025, Meta a prolongé ce modèle avec sa règle « Agents Rule of Two » : au sein d’une session, un agent ne devrait combiner au plus que deux des trois propriétés suivantes : traiter des entrées non fiables ; accéder à des systèmes sensibles ou à des données privées ; modifier un état ou communiquer avec l’extérieur. S’il a besoin des trois, une supervision s’impose au minimum, par exemple via une approbation humaine. Meta souligne que la règle complète le principe du moindre privilège sans le remplacer.

Appréciation de VamiSec : les deux modèles décrivent des propriétés d’une session, et non d’un modèle. On ne peut les faire respecter que si une instance voit chaque action ainsi que l’historique de la session. C’est précisément ce point de contrôle que standardise l’OWASP Agent Control Standard (ACS). Pour reconnaître les entrées non fiables, il faut le profil optionnel acs-provenance ; ACS-Core seul ne fournit aucune information de provenance.

Incidents documentés — et ce qu’un contrôle à l’exécution aurait limité

Pourquoi le contrôle doit intervenir à l’exécution

Le choix du modèle, le durcissement des prompts et le red teaming avant la mise en production restent nécessaires, mais ne disent rien de ce que fait un agent dans une session concrète. Le contrôle à l’exécution les complète : il intervient avant l’action, évalue le contexte de toute la session et laisse une piste d’audit reconstituable. Pour ASI02 (Tool Misuse and Exploitation), l’OWASP Top 10 for Agentic Applications 2026 recommande un middleware d’application des politiques placé en amont, un « Intent Gate » qui vérifie l’intention et les arguments avant l’exécution. ACS n’y est pas cité, mais fournit (appréciation de VamiSec) un contrat d’interface ouvert (wire contract) précisément pour ce point de contrôle. Les politiques restent de votre ressort.

Plus précisément : l’Agent Control Standard (ACS) est une spécification de l’OWASP GenAI Security Project qui définit à quels points de contrôle (hooks) un agent IA soumet ses étapes à une instance de politique externe, et comment celle-ci répond par une décision (disposition). Le format est JSON-RPC 2.0 avec un champ propre, acs_version, transporté via HTTP(S) ou stdio. L’état actuel est la spécification v0.1.0, publiée sous la release 0.1.2 (tag du 21 septembre 2026). ACS définit le contrat entre l’agent et le Guardian, pas les politiques : ce qui est autorisé reste du ressort de votre organisation.

Les parties

Un principe de conception porte l’architecture : le modèle de langage ne doit rien savoir des hooks. C’est le framework qui les déclenche, et les informations de provenance sont renseignées en dehors du chemin de sortie du modèle. Selon notre lecture, un modèle manipulé ne doit ainsi pouvoir ni voir ni influencer le point de contrôle.

Trois piliers : Instrument, Trace, Inspect

ACS-Core et sept profils

La conformité est modulaire. ACS-Core constitue le socle obligatoire, sur lequel s’appuient six profils optionnels qu’un déploiement déclare lors du handshake. Il n’existe pas de niveaux numérotés — seulement des noms de profils combinables indépendamment les uns des autres. Seule dépendance : acs-inspect-dynamic étend acs-inspect.

Ce que garantit ACS-Core, la spécification le formule sobrement : le canal est authentifié et l’Observed Agent respecte les décisions. Rien ne garantit en revanche que les politiques soient strictes — un Guardian permissif est conforme, simplement permissif. La détectabilité des manipulations de la chaîne d’audit, y compris face à un Guardian compromis, n’est assurée que par acs-crypto et acs-audit, car la base HMAC repose sur un procédé symétrique. Les combinaisons données en exemple par la spécification vont d’une intégration IDE minimale avec acs-core seul jusqu’à un déploiement à haut niveau d’assurance avec les sept profils.

Le modèle en tiers de la page du projet : des couches d’architecture, pas des niveaux

1. 1
   Tier 1 · Platform layer

   Les frameworks d’agents fournissent des hooks middleware standardisés — c’est là que naît le point de contrôle.

2. 2
   Tier 2 · Enforcement layer

   Un composant open source lit des politiques déclaratives et renvoie des décisions via ces hooks.

3. 3
   Tier 3 · Enterprise layer

   Des classificateurs propres et une logique métier spécifique se raccordent derrière la même interface.

Ce schéma décrit qui apporte quelle partie, et non le degré de conformité d’un déploiement. Pour toute déclaration de conformité, seuls les profils comptent. Il reste utile pour votre planification d’architecture : il sépare la question de la plateforme qui fournit les hooks de celle de savoir qui exploite et maintient les politiques.

De l’observation au contrôle

Les travaux ont débuté le 11 mai 2025 sous le nom « Agent Observability Standard » (AOS) dans l’écosystème GitHub de Zenity, puis ont rejoint en juin 2025 l’organisation OWASP, où AOS figurait comme « OWASP other project ». En mai et juin 2025, la couche protocole s’est provisoirement appelée « ASOP » (Agent Security & Observability Protocol), avant de reprendre le nom AOS. Après une phase de commits seulement sporadiques à partir de mi-2025, le projet a été rebaptisé Agent Control Standard le 10 avril 2026. Le nouveau nom marque le pas franchi sur le fond : de la simple observation à l’application effective des règles. ACS a ensuite brièvement fonctionné comme projet indépendant hors de l’OWASP, avant d’y revenir en septembre 2026 — cette fois au sein de l’OWASP GenAI Security Project.

Statut : Incubator et public preview

ACS est un projet de l’OWASP GenAI Security Project, rattaché à l’Agentic Security Initiative. Dans ses propres métadonnées OWASP Nest, il déclare le niveau 2, soit le stade « Incubator » dans le schéma Nest ; un classement par une instance de l’OWASP n’est donc pas attesté. Le Project Lead qualifie publiquement l’état du projet de « public preview » et invite expressément les implémenteurs à la prudence. ACS n’est pas une norme ISO, IETF ou W3C, ni une norme harmonisée. Le stade précoce se voit aussi sur la forme : il n’existe aucune release GitHub, seulement des tags ; le texte de la spécification et les schémas ont changé entre v0.1.1 et v0.1.2 sans que la version de spécification v0.1.0 soit incrémentée.

Qui pilote le projet ?

Selon GOVERNANCE.md, Michael Bargury et Ory Segal ont créé ACS ; tous deux restent responsables du projet. Le Project Lead est Rock Lambros. Par souci de transparence : Bargury est CTO et cofondateur de Zenity, Lambros est présenté par Zenity comme « Director of AI Standards and Governance », et les premiers commits AOS proviennent majoritairement de l’écosystème Zenity. Les workstreams — Coding Agents, Development (SDK), Identity, Outreach et Spec — sont dirigés par des personnes issues de plusieurs organisations. La page du projet décrit ACS comme neutre vis-à-vis des fournisseurs et piloté collectivement ; il s’agit d’une autodescription. Notre lecture : un projet OWASP fortement marqué par Zenity dans sa création et sa direction.

Les décisions passent par un processus d’acceptation (acceptance gate). Seules les issues portant le label status:accepted entrent dans le backlog ; toute modification du comportement, du texte normatif ou du code nécessite une issue acceptée, les modifications de la spécification commencent par une GitHub Discussion, et les commits exigent un sign-off DCO. Le développement se fait sur la branche integration. Ce n’est que lorsque le Project Lead promeut les changements vers main que le site et les URI des schémas sont republiés. Au 3 octobre 2026, aucune promotion vers main n’a eu lieu depuis le 10 septembre 2026 — les modifications sur integration ne sont donc pas encore publiées.

Licence : ce que vous pouvez reprendre

Feuille de route : ce qui est attesté

La prochaine release de la spécification, v0.2.0, vise mars 2027 ; aucune date n’est fixée pour la v1.0. Sont notamment prévus pour la v0.2 : streaming et interruption, ASK récursif et quorum, isolation multi-tenant, le binding Cedar, la fédération de l’AgBOM via des pairs A2A et l’encapsulation A2A. L’objectif en cours depuis le kick-off du 10 septembre 2026 : en 90 jours, mettre entre les mains d’évaluateurs externes une implémentation de référence du Guardian opérationnelle, dont l’interopérabilité avec l’Agent Governance Toolkit de Microsoft a été mesurée par benchmark. Reste à savoir si cet objectif sera atteint d’ici début décembre 2026. La PR #21, qui vise à redéfinir le périmètre obligatoire d’ACS-Core, est elle aussi toujours ouverte. Les esquisses de versions divergentes publiées dans des billets de blog ne constituent pas une feuille de route officielle.

Au niveau du protocole, les hooks portent le préfixe steps/, par exemple steps/toolCallRequest. Il existe en outre des méthodes qui ne sont pas des hooks natifs steps/* : agbom/snapshot et agbom/changed pour l’inventaire, la sonde de vivacité (liveness probe) system/ping, le handshake handshake/hello et l’espace de noms protocols/MCP/* pour les messages MCP encapsulés. La page Hooks de la spécification compte 19 hooks plus deux méthodes AgBOM plus le ping, soit 22 méthodes ; le paquet de schémas comprend au total 44 schémas JSON. Certains textes du projet (README, docs/acs.md) mentionnent encore 16 hooks de cycle de vie — c’est le décompte sans les trois hooks de skills.

Le minimum Core : six hooks

ACS-Core exige au moins six hooks : sessionStart, userMessage ou agentTrigger, toolCallRequest, toolCallResult, agentResponse et sessionEnd. Un framework devrait implémenter tous les autres dès lors qu’il peut observer l’événement concerné ; ils sont négociés lors du handshake. Pour votre évaluation produit, cela signifie que l’affirmation « prend en charge ACS » ne dit pas encore si les écritures en mémoire, les sous-agents ou les skills parviennent tout simplement jusqu’au Guardian.

Le piège methods_evaluated

Lors du handshake, l’Observed Agent indique les méthodes qu’il implémente (methods_implemented). Le Guardian répond avec la liste des méthodes qu’il évalue réellement (methods_evaluated). Si l’agent envoie un hook absent de cette liste, il doit le traiter comme ALLOW-by-default — l’étape est au mieux journalisée, mais pas contrôlée. La seule implémentation de référence n’évalue par exemple que steps/toolCallRequest et steps/toolCallResult, soit deux hooks sur 19.

toolCallRequest : le point d’application central

steps/toolCallRequest est le seul hook pour lequel la spécification prévoit expressément les cinq dispositions ; c’est aussi là que s’appliquent les paradigmes de contrôle. Une règle MUST est centrale : les frameworks doivent déclencher toolCallRequest pour toute action qui quitte le contexte de raisonnement de l’agent — même si le framework ne la gère pas en interne comme un outil. Cela couvre les accès en lecture et en écriture au système de fichiers, les requêtes réseau, les lancements de processus et les commandes shell. Ce qui contourne ce hook échappe à toute politique.

Sont obligatoires dans le payload tool.name et arguments, chaque valeur d’argument pouvant porter sa propre provenance. En option s’ajoutent une capability abstraite comme filesystem.delete ou network.egress, le champ raw_command et un intent. Les politiques peuvent ainsi évaluer ce que produit une action, plutôt que le programme qui l’exécute.

Hooks à effet protecteur particulier

• memoryStore est la destination standard (sink) de toute influence qui se propage d’une session à l’autre et, selon la spécification, le point d’appui contre l’empoisonnement de la mémoire (memory poisoning, cf. ASI06 : Memory & Context Poisoning).
• preCompact et postCompact sécurisent le compactage : le résumé doit porter l’origin agent_generated et hériter de la provenance de toutes les entrées compactées, afin que des contenus non fiables ne soient pas blanchis.
• subagentStart permet au Guardian de refuser le lancement d’un sous-agent ; chaque sous-agent reçoit son propre session_id et sa propre chaîne d’audit.
• skillRegister et skillLoad lient les skills à un digest : seul peut être chargé ce qui a été approuvé auparavant avec un skill_id et un digest identiques ; les chargements impossibles à rattacher devraient être refusés.

Au niveau du protocole, les dispositions figurent en minuscules dans le champ decision ; le texte de la spécification les écrit en majuscules (ALLOW, DENY…). Dans la v0.1, chaque réponse est de type final — les états intermédiaires (progress) et les interruptions (interruption) ne sont prévus que pour la v0.2. Chaque réponse doit contenir type, acs_version, request_id et decision ; le request_id reprend celui de la requête.

MODIFY : deux formes qui s’excluent mutuellement

L’objet modifications connaît deux formes. Soit modified_content remplace l’intégralité du payload — aucun autre edit n’est alors autorisé. Soit le Guardian envoie des edits structurés : redactions (chemin JSON Pointer plus texte de remplacement, par défaut « [REDACTED] ») et/ou parameter_overrides (nom d’argument plus nouvelle valeur). Les deux peuvent coexister, mais leurs cibles doivent être disjointes : aucun chemin de caviardage ne doit toucher le même champ qu’un override, ni un champ parent ou enfant de celui-ci. La spécification le justifie ainsi : un ordre d’application fixe résoudrait les conflits en silence et, selon l’ordre retenu, exposerait à nouveau des valeurs caviardées ou écraserait des valeurs assainies. Si un Guardian enfreint ces règles, l’Observed Agent doit traiter la réponse comme un deny.

Un exemple : un agent veut interroger intégralement une table clients. Le Guardian répond par modify avec une entrée dans parameter_overrides qui limite la requête à 500 lignes — comme dans le scénario du simulateur « Requête de base de données sans limite ». Les valeurs d’override figurent alors comme valeur brute dans l’objet, et non dans une enveloppe value.

ASK : une approbation aux règles claires

• ask_details exige un approver avec type (human, agent ou service) et id, une question et timeout_seconds (au minimum 1).
• À l’expiration du délai, timeout_disposition s’applique ; la valeur par défaut est deny.
• Le Guardian doit vérifier l’identité de l’approbateur au regard de la politique — l’authentification de l’approbateur est obligatoire.
• Un seul niveau : les approbateurs ne peuvent pas eux-mêmes renvoyer un ask. Le quorum et les approbations récursives sont reportés à la v0.2.
• Si un client ne peut pas résoudre un ASK, le Guardian ne doit pas envoyer de ask. Il se rabat sur defer avec timeout_decision deny ou sur deny avec le reason code approver_unavailable — un allow silencieux est exclu.
• Via intent_extension, une approbation peut étendre les capabilities autorisées pour this_request ou pour toute la session. Selon la spécification, c’est la seule manière conforme de modifier a posteriori l’intent défini.

Point important pour la réglementation : ASK n’équivaut pas automatiquement à un contrôle humain. L’approbateur peut être un agent ou un service, et timeout_disposition peut être réglé sur allow. Le contrôle humain prévu à l’article 14 du règlement européen sur l’IA (AI Act) est applicable aux systèmes à haut risque à partir du 2 décembre 2027 (annexe III) ou du 2 août 2028 (annexe I) ; les agents IA ne sont pas à haut risque par nature. Pour utiliser ASK comme brique à cet effet, il faut, selon l’appréciation de VamiSec, une politique avec approver.type human et timeout_disposition deny, ainsi qu’un processus d’approbation qui évite la fatigue décisionnelle. ASK contribue alors à la constitution des preuves, mais ne satisfait pas à lui seul à l’article 14 : la v0.1 ne connaît pas de bouton d’arrêt, seulement le deny étape par étape.

DEFER : différer la décision, mais dans certaines limites

defer_details exige un reason (insufficient_context, conflicting_policies, low_confidence ou pending_dependency), une resolution_method (additional_context, human_approval ou timeout) et resolution_timeout_ms. Pour l’expiration du délai, timeout_decision ne connaît que deny ou ask — jamais allow — et vaut deny par défaut. Le texte de la spécification exige ce champ, mais le schéma ne le déclare pas obligatoire ; renseignez-le donc toujours explicitement. Les reports (deferrals) en cascade doivent être limités par session. Attention aux unités : ASK compte en secondes (timeout_seconds), DEFER en millisecondes (resolution_timeout_ms).

Chaque session commence par handshake/hello. Le ClientHello se trouve dans le payload d’une enveloppe de requête ordinaire, le ServerHello revient sous forme de result — sans decision. La version négociée doit correspondre à celle du client pour la version majeure ; les champs inconnus doivent être ignorés.

Failure posture : fail-open par défaut

Pour chaque étape signalée, l’Observed Agent doit attendre la décision — jusqu’au timeout négocié — puis l’appliquer. Un framework qui envoie des hooks mais ignore le verdict n’est pas conforme. Si aucune décision exploitable n’arrive, la spécification parle de decision failure : le Guardian reste muet, le transport s’interrompt (connexion refusée, erreur TLS, réponse malformée) ou le Guardian renvoie une erreur au lieu d’une décision. Dans les trois cas, on_decision_failure s’applique, et sa valeur par défaut est proceed : l’action se poursuit sans contrôle. Le fail-closed (deny) doit être configuré explicitement par le déploiement.

La spécification nomme ouvertement le prix à payer : quiconque peut perturber le canal réduit le contrôle à une simple journalisation. En contrepartie s’applique une obligation stricte — chaque étape qui se poursuit sans décision doit être consignée comme événement d’audit. Si une décision arrive malgré tout dans le délai, l’agent doit la respecter, quelle que soit la posture.

Startup posture : quand le handshake lui-même échoue

Si le Guardian est injoignable au démarrage de la session ou répond sans ServerHello, c’est une startup posture configurée hors protocole qui s’applique : proceed (la session démarre sans protection) ou refuse. Là encore, proceed est la valeur par défaut, afin qu’une panne du Guardian ne bloque pas les nouvelles sessions. Une session démarrée sans protection doit figurer dans le journal d’audit propre au déploiement. Un refus explicite du Guardian, par exemple SESSION_REFUSED, constitue en revanche une décision et non une panne.

Timeouts : aucune valeur par défaut dans la spécification

La spécification ne fixe aucun timeout standard chiffré. timeout_config.default_ms est obligatoire dans le ServerHello, mais sa valeur relève du déploiement ; per_method_ms autorise des valeurs différentes par méthode. Le schéma du handshake rappelle que chaque milliseconde de timeout représente, dans le pire des cas, autant de latence pour l’étape, et recommande d’aligner les délais par méthode sur la tolérance à la latence plutôt que sur une valeur forfaitaire généreuse. L’implémentation de référence utilise 5000 ms — une valeur d’implémentation, pas une exigence. Un modèle de timeout fondé sur la sensibilité est prévu pour la v0.2. Précision terminologique : ACS_ON_DECISION_FAILURE est une variable d’environnement du Guardian de référence qui fixe la valeur de on_decision_failure — pas un champ de la spécification.

Un ping ne prouve pas l’application des décisions

system/ping est une pure sonde de vivacité : le Guardian doit toujours répondre allow, le ping ne nécessite pas de signature et n’est pas inscrit dans la chaîne d’audit. Un Guardian peut donc répondre aux pings tout en refusant chaque hook signé. La spécification recommande par conséquent de surveiller directement les decision failures sur le chemin des hooks.

Deux couches, un ordre fixe

La couche déterministe évalue chaque hook en premier. Elle décide elle-même ou délègue à la couche agent — selon la spécification, sous le pilotage d’une configuration de chaîne avec les modes « * », on_ask ou basé sur des motifs. La v0.1 ne définit toutefois aucun format pour cette configuration. La couche agent reçoit les mêmes entrées plus le résultat intermédiaire de la couche déterministe, mais jamais le code de politique. Sa réponse doit repasser par la couche déterministe au retour.

1. 1
   Arrivée du hook

   L’enveloppe de requête, le SessionContext, l’intent et, le cas échéant, la provenance sont transmis au moteur de politiques.

2. 2
   Évaluation déterministe

   La Policy-as-Code — dans la v0.1 avec OPA/Rego comme référence de départ — renvoie allow, deny, modify, ask ou defer, ou délègue.

3. 3
   Couche LLM optionnelle

   Évalue les cas qui ne peuvent pas être tranchés de manière déterministe ; traite les champs non fiables comme des données et ne voit aucun code de politique.

4. 4
   Contre-vérification et réponse

   Le résultat repasse par la couche déterministe ; metadata.evaluator indique deterministic, agent ou composite.

5. 5
   Journalisation

   Chaque décision est journalisée avec sa justification, l’identifiant du modèle et, si disponible, le niveau de confiance.

Moteur de politiques : une interface plutôt qu’un produit

ACS définit l’interface vers le moteur déterministe, pas le moteur lui-même. L’entrée se compose de l’enveloppe de requête, du SessionContext, de l’intent et de la provenance ; la sortie, d’une enveloppe de décision, éventuellement assortie d’une délégation à la couche agent (delegate_to). ACS fixe en outre des conventions, dont celle-ci : pas d’appels HTTP externes dans les politiques canoniques. Cela favorise le déterminisme et la maîtrise de la latence.

Obligations de la couche LLM

• Les données non fiables sont des données, pas des instructions ; les champs concernés doivent être encapsulés ou mis entre guillemets dans le prompt.
• Aucun accès au code de politique de la couche déterministe.
• Journaliser chaque décision avec sa justification, l’identifiant du modèle et le niveau de confiance (si disponible) ; avec evaluator agent ou composite, model_id doit être renseigné.
• Les délais suivent le timeout_config négocié lors du handshake.
• L’ensemble de la couche est optionnel dans la v0.1.0 : des déploiements purement déterministes sont pleinement conformes.

Paradigmes de contrôle sans extension propre du protocole

La spécification cite quatre paradigmes comme objectifs pour la v0.1. Un Guardian les exprime via les mêmes champs — reason_codes, policy_references, policy_data et cited_provenance_ids. Si un déploiement combine plusieurs paradigmes, une seule décision peut tous les citer.

Les règles FIDES, CaMeL et de type AARM nécessitent des informations de provenance et supposent donc le profil acs-provenance ; ce n’est pas le cas de l’IBAC pur. ACS n’implémente lui-même aucun de ces procédés : il fournit les champs par lesquels un Guardian les applique et les justifie. ACS n’empêche donc pas l’injection de prompt — il crée le point de contrôle où les politiques agissent contre ses conséquences.

Exploitation : latence et disponibilité (appréciation de VamiSec)

• Latence : chaque contrôle se situe sur le chemin critique de l’agent. Gardez la couche déterministe locale et sans appels externes, réservez la couche LLM à quelques cas ambigus et mesurez evaluation_duration_ms par méthode.
• Disponibilité : en fail-closed, le Guardian devient critique pour l’exploitation. Exploitez-le au plus près de l’agent et de manière redondante. L’implémentation de référence documente elle-même le risque : elle écrit ses journaux de façon synchrone sur le chemin de décision, si bien qu’un disque lent bloque toute décision en cours.
• Cycle de vie des politiques : versionnez vos politiques et renvoyez policy_version dans chaque décision ; la spécification le prévoit pour reconstituer les états historiques des politiques.
• Délimitation : le Guardian ne remplace ni la sandbox, ni l’IAM, ni la gestion des secrets, ni le pare-feu de sortie (egress). Les actions qui contournent toolCallRequest lui restent invisibles.

La seule implémentation de référence fait tourner l’Agent Governance Toolkit de Microsoft sans modification derrière l’interface ACS. Il s’agit explicitement d’une preuve de concept : deux hooks sur 19 actifs, pas de signature HMAC, fail-open par défaut. Elle démontre le schéma pour deux clients (Claude Code et OpenCode), mais n’est pas destinée à la production.

Entre l’Observed Agent et le Guardian Agent transitent des décisions qui autorisent ou bloquent des actions. Quiconque peut manipuler ce canal transforme un deny en allow ou rejoue une ancienne autorisation. L’OWASP Agent Control Standard (ACS) traite donc la sécurité du canal comme un élément du socle obligatoire ACS-Core, et non comme un profil optionnel.

Signature de base : HMAC-SHA256 avec clé de session

ACS-Core exige sur chaque requête et chaque réponse une signature portant sur l’enveloppe canonique. Le mécanisme de base qui satisfait cette obligation est HMAC-SHA256. La clé est dérivée par session via HKDF — à partir du matériel cryptographique du déploiement (un secret pré-partagé ou une liaison de canal telle qu’un exporteur TLS) combiné au session_id. La v0.1 ne définit pas d’échange de clés dans le protocole. C’est la canonicalisation RFC 8785 (JCS) de l’enveloppe, sans le champ signature, qui est signée ; le destinataire recalcule cette forme et rejette toute signature non concordante. TLS seul ne suffit explicitement pas, car il ne lie aucun message individuel pour l’audit. Seule la méthode de liveness system/ping est exemptée de l’obligation de signature.

Deux détails comptent pour l’architecture. Dans le schéma JSON, le champ signature est optionnel, alors qu’il est obligatoire au niveau normatif dans ACS-Core — une simple validation de schéma ne détecte donc pas les signatures manquantes. Par ailleurs, la spécification ne fixe ni le sel, ni la chaîne info, ni la fonction de hachage, ni la longueur de clé pour HKDF ; deux implémentations peuvent donc dériver des clés différentes. Selon notre appréciation, ces paramètres ont leur place dans l’accord d’interface entre l’exploitation de la plateforme et celle du Guardian.

Protection contre le rejeu

Chaque requête porte un request_id (UUID), un timestamp et, en option, un nonce. Le Guardian doit rejeter les requêtes dont l’horodatage se situe hors de la fenêtre négociée skew_window_ms (valeur par défaut recommandée : 300 000 ms, soit cinq minutes) et refuser les valeurs request_id en double au sein d’une session ; il devrait rejeter les nonces en double. Il en découle une exigence d’exploitation souvent négligée : des horloges synchronisées des deux côtés.

Chaîne d’audit : chaîne de hachage avec tête publiée

Le Guardian tient pour chaque session un SessionContext, une chaîne append-only de ContextEntries. Chaque entrée reçoit un entry_hash : SHA-256 sur l’entrée canonicalisée JCS sans les champs de hachage, chaîné avec le hachage de l’entrée précédente ; la première entrée a un previous_hash null. D’autres canonicalisations ne sont pas admises en v0.1. Le point décisif est la publication : pour chaque étape porteuse de contenu (content-bearing step), le Guardian doit joindre le chain_hash courant à sa réponse, couvert par la signature de la réponse. La spécification en donne ouvertement la raison : si le Guardian gardait la tête de chaîne privée, il pourrait par exemple supprimer un deny, recalculer la chaîne à partir de ce point et présenter plus tard un historique expurgé. Quiconque enregistre le trafic détecte une chaîne réécrite a posteriori.

Ce que la chaîne prouve — et ce qu’elle ne prouve pas

• Les champs obligatoires d’une ContextEntry sont uniquement entry_id, step_id, step_type et entry_hash. Le request_hash portant sur le contenu de la requête n’est que recommandé (SHOULD) dans ACS-Core et ne devient obligatoire qu’avec le profil acs-audit. Sans lui, la chaîne prouve qu’une étape a eu lieu, mais pas ce qui a été demandé.
• Le schéma ContextEntry ne prévoit aucun champ pour la disposition, la justification ou l’approbateur. ACS consigne normativement les décisions sous forme d’événements de trace (profil acs-trace, chapitre 9) ; seule une extension d’intent écrit sa propre entrée avec l’identité de l’approbateur (chapitre 11).
• HMAC est symétrique : le Guardian détient la clé et pourrait signer à nouveau une tête de chaîne réécrite. Le canal est protégé contre la manipulation sur le réseau, pas contre un Guardian compromis.
• La non-répudiation vis-à-vis de tiers n’apparaît qu’avec acs-crypto : au minimum ML-DSA-65 (MUST), SLH-DSA-128s (SHOULD), procédés hybrides optionnels.
• La v0.1 ne prévoit aucun rapprochement entre plusieurs Guardians (issue #18, reportée).

L’apport normatif de Trace est le vocabulaire : noms de spans, clés d’attributs, classes d’événements et correspondance entre dispositions et niveaux de sévérité. La transmission se fait via OTLP (gRPC ou HTTP) vers les backends existants ; l’espace de noms wire trace/* n’est que réservé en v0.1.0. L’objectif affiché est que les événements ACS s’intègrent aux pipelines SIEM sans parseur spécifique. Les extensions OTel et OCSF portent dans le dépôt le statut « Working draft ». Trace est le profil optionnel acs-trace. Quiconque le revendique doit, pour chaque étape prise en charge, émettre au moins l’un des deux formats avec ses attributs obligatoires, consigner chaque décision avec sa disposition, l’évaluateur et — le cas échéant — la justification, et reporter sur l’événement les faits de provenance issus du hook.

OpenTelemetry : des spans par hook, les décisions comme événements de span

La hiérarchie des spans est déterministe : un span racine acs.session par session, en dessous un acs.turn par tour et un span d’étape par hook. Les décisions ne sont pas des spans à part entière, mais un événement de span acs.decision rattaché au span d’étape ; le verdict et l’action contrôlée partagent ainsi le même contexte parent. Les attributs obligatoires de l’événement sont acs.decision et acs.evaluator (deterministic, agent ou composite). Pour les appels d’outils, ACS utilise les noms de spans gen_ai.tool.call et gen_ai.tool.result. Attention : dans les conventions GenAI d’OpenTelemetry (au statut « Development » en octobre 2026), gen_ai.tool.call n’est qu’un préfixe d’attribut ; le nom de span recommandé y est execute_tool {gen_ai.tool.name}. Les tableaux de bord et requêtes alignés sur ces conventions ne correspondent donc pas sans adaptation aux spans d’outils ACS.

Cas d’usage SIEM pour les agents

Les limites à anticiper

• Best effort : Trace ne doit jamais bloquer l’application des décisions. Si la destination (sink) tombe en panne, la décision parvient malgré tout à l’Observed Agent — la télémétrie peut donc être lacunaire.
• Données autodéclarées : les événements Trace naissent dans l’environnement observé et ne deviennent des preuves qu’après attestation par une partie externe.
• Lacune côté skills : les mappings couvrent 16 des 19 hooks natifs, plus les deux méthodes agbom. skillRegister, skillLoad et skillUnload n’ont ni mapping OTel ni mapping OCSF.
• Dérive documentaire : l’emplacement de la provenance dans OCSF est contradictoire (enrichments dans le mapping normatif, unmapped.acs.provenance dans le guide). La page d’exemples avec des requêtes Splunk et Elastic utilise encore l’ancien nom ASOP et OCSF 1.0.
• Protection des données : les spans peuvent contenir des prompts et des arguments d’outils. La spécification recommande un caviardage (redaction) dès l’émission ; selon notre appréciation, cela doit figurer de manière contraignante dans le concept de journalisation.

Selon la spécification, l’AgBOM est un inventaire dynamique et interrogeable des composants qu’utilise un Observed Agent. La justification est précise : toute politique qui dépend de ce qu’est un agent — quel modèle, quels outils — devient invérifiable sans inventaire. Si une politique du Guardian dépend de l’inventaire, par exemple pour bannir un modèle ou un outil, le déploiement doit implémenter le profil acs-inspect. L’AgBOM canonique est un graphe de composants, stocké sous forme de liste plate avec des références par ID, afin que les états successifs puissent être comparés par diff.

Huit types de composants

snapshot et changed : deux méthodes wire

L’Observed Agent envoie agbom/snapshot une fois par session, après sessionStart et avant le premier hook porteur de contenu ; le message contient l’AgBOM complète. agbom/changed signale les mutations — composants ajoutés, supprimés ou modifiés, sous forme de diff ou d’instantané complet — et peut indiquer une cause, par exemple component_upgraded, discovery ou user_action. Les deux événements entrent dans la chaîne d’audit. Le Guardian peut, par un deny, refuser une session comportant un composant banni ou bloquer un remplacement à chaud (hot swap).

Important pour le choix des profils : qui ne revendique qu’acs-inspect fournit exactement un snapshot par session et ne suit pas les modifications. Les changements à l’exécution ne deviennent visibles qu’avec acs-inspect-dynamic. Les déclencheurs de snapshot renegotiation et policy_request renvoient à des mécanismes qui ne doivent être spécifiés qu’avec la v0.2 — en v0.1, seul session_start est en pratique fiable. Chaque composant devrait en outre porter une registration_provenance (obligatoire sous acs-provenance). On peut ainsi distinguer si un composant provient de la configuration ou s’il a été ajouté à l’exécution.

Sérialisations : CycloneDX, SPDX, SWID

Sur le wire circule toujours la forme canonique ; le Guardian produit les sérialisations à la demande pour les outils en aval. Un déploiement acs-inspect doit en proposer au moins une : CycloneDX 1.6, SPDX 3.0 ou SWID (ISO/IEC 19770-2). Les trois mappings ont le statut « Working draft » ; les correspondances vers CycloneDX et SPDX ne sont en partie pas valides au regard des schémas. Le mapping CycloneDX utilise comme type de composant des noms tels que ai-model ou service, que CycloneDX 1.6 ne connaît pas sous cette forme ; le mapping SPDX emploie des classes et des relations qui n’existent pas dans SPDX 3.0.1. Prévoyez donc vos exports avec une validation propre. CycloneDX lui-même est disponible en version 1.7 depuis octobre 2025.

Délimitation : AgBOM, AI-SBOM, SBOM CRA

Provenance par champ : des faits plutôt que des étiquettes de confiance

La provenance indique d’où vient un élément de données et comment il est arrivé à sa place. Un objet de provenance porte un provenance_id, un origin avec l’une des sept valeurs — user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external — ainsi qu’en option source_id (p. ex. nom d’outil, URL ou chemin) et derived_from comme liste des antécédents. Ces informations sont attachées aux champs porteurs de données, et même à chaque argument individuel pour toolCallRequest. Une politique peut ainsi cibler un flux de données précis plutôt que l’appel entier.

• Fixée par le framework : origin, source_id et derived_from sont attribués par du code déterministe en dehors du chemin de sortie du LLM. Demander au LLM de produire la provenance n’est pas conforme.
• Lignage transitif : les données dérivées héritent de l’origine de leurs entrées, y compris à travers la synthèse et le compactage. Un résumé de sorties d’outils tierces reste ainsi identifiable comme tel.
• Pas de champ trust : une valeur trust n’est que réservée en v0.1, sans schéma. Le Guardian déduit la confiance d’origin et de source_id au regard de sa politique ; un traitement par le LLM ne rend jamais fiable un contenu non fiable (règle de monotonie).
• Tout ou rien : avec provenance_producer: deterministic, chaque champ porteur de données doit porter une provenance ; un remplissage partiel n’est pas conforme. Si le client annonce provenance_producer: none alors que la politique exige la provenance, le Guardian refuse la session dès le handshake avec PROVENANCE_REQUIRED.

La provenance ne relève pas d’ACS-Core, mais du profil acs-provenance. Elle est un prérequis pour des paradigmes d’application tels que FIDES, CaMeL et AARM, mais pas pour une simple autorisation fondée sur l’intention (IBAC). ACS n’empêche pas l’injection de prompt. Il crée le point de contrôle où une politique peut en limiter les conséquences — par exemple en bloquant un e-mail dont le destinataire et le contenu proviennent d’un résultat de récupération (retrieval) non fiable. Les étiquettes de sensibilité ou IFC ne font pas partie du standard ; elles relèvent du Guardian ou du déploiement.

Session Intent : la finalité verrouillée

Dans ACS, l’intent n’est pas un format wire, mais un concept de gouvernance : il lie les actions à une finalité autorisée, et ce avant que des données non fiables ne puissent exercer une influence. Intent.parsed, l’ensemble des capabilities autorisées pour la session, est fixé lors de sessionStart ou du premier agentTrigger. Ensuite, ni le LLM, ni les sorties d’outils, ni les données issues de canaux non fiables ne peuvent le modifier ; si l’intent est défini dès sessionStart, un agentTrigger ultérieur portant un intent divergent doit être rejeté.

La seule voie conforme pour l’étendre est une intent_extension qu’un approbateur renvoie via le flux ask — avec des indications obligatoires sur les capabilities et la portée (scope). Avec scope this_request, l’extension ne vaut que pour la requête en cours. Avec scope session, le Guardian ajoute les capabilities, écrit une ContextEntry de type intent_extension avec l’identité de l’approbateur et gère la provenance de l’extension séparément de celle de l’intent initial. En scope_mode strict, il ne doit honorer aucune extension que la politique interdit en mode strict. Pour les RSSI, c’est, selon notre appréciation, le levier contre l’extension rampante des droits : toute extension requiert une approbation authentifiée.

Identity : un socle normatif mince, beaucoup de chantiers

La signature d’ACS-Core authentifie de manière symétrique le canal entre l’Observed Agent et le Guardian. Elle n’est ni une authentification du principal ni une non-répudiation — ne confondez pas ces notions dans votre architecture et vos preuves.

Wrapping MCP : spécifié, avec une question d’obligation ouverte

L’espace de noms protocols/MCP/* est la voie canonique pour transporter les messages MCP jusqu’au Guardian, par exemple protocols/MCP/tools/call. Le message MCP reste inchangé ; ACS y superpose l’enveloppe, le contrat de décision et les règles de la chaîne d’audit. Le déroulement se fait en deux temps : l’agent soumet la requête encapsulée au Guardian, applique sa décision, transmet le message au serveur MCP après un allow, conformément à la description du flux, et fait également contrôler la réponse de ce dernier avant de la traiter.

Un déploiement peut regrouper les appels d’outils MCP (tools/call) dans les hooks génériques steps/toolCallRequest et steps/toolCallResult lorsque des politiques au niveau des outils suffisent. Le wrapping devrait être utilisé lorsque la politique a besoin de distinctions propres à MCP : négociation des capacités lors d’initialize, modèles de prompts côté serveur (prompts/get), accès aux ressources (resources/read) et notifications (notifications/*). Indépendamment de cela, les frameworks doivent déclencher toolCallRequest pour toute action qui quitte le contexte de raisonnement — y compris pour les opérations intégrées sur fichiers, réseau ou shell.

MCP 2026-07-28 : le texte de la spécification est en retard

Depuis le 28 juillet 2026, la révision MCP 2026-07-28 est la version actuelle (état : octobre 2026). Elle rend le cœur du protocole sans état, supprime le handshake initialize et déclare notamment obsolètes le sampling et les roots. L’espace de noms ACS protocols/MCP/* est neutre vis-à-vis des versions ; la révision 2025-06-18 n’apparaît dans la spécification qu’à titre d’exemple. La prose suppose cependant encore l’ancienne sémantique et cite explicitement la négociation initialize comme point à contrôler. La spécification ne dit pas si cela affecte les wrappers en pratique ; nous ne disposons d’aucune analyse solide. Selon notre appréciation, les architectures fortement axées sur MCP devraient prévoir les hooks d’outils génériques comme point de contrôle principal.

A2A : réservé pour la v0.2

L’espace de noms protocols/A2A/* n’est que réservé en v0.1 ; une sémantique normative de wrapping est prévue pour la v0.2 (échéance visée pour la v0.2.0 : mars 2027). Les pages A2A du dépôt datent de l’époque AOS de 2025 et ne sont pas compatibles avec les schémas. Les relations A2A ne sont aujourd’hui visibles qu’indirectement : via agentTrigger avec trigger_type a2a_inbound et via les composants a2a_peer de l’AgBOM. Les sous-agents in-process, en revanche, sont couverts par ACS avec subagentStart et subagentStop ; chaque sous-agent reçoit sa propre session avec sa propre chaîne d’audit, que le parent référence via le final_chain_hash, sans fusionner les chaînes.

Cycle de vie des skills : register, load, unload

Le digest couvre l’artefact chargeable complet, y compris les poids de modèle ou adaptateurs embarqués ; seuls la référence et le digest sont persistés dans l’AgBOM, pas le contenu. Le Guardian ne devrait pas se fier à un digest_verified signalé par le framework, mais effectuer lui-même la comparaison avec son approbation. La proposition de conception (design proposal) relative au cycle de vie des skills, publiée dans le dépôt, nomme ouvertement la limite : le digest lie l’artefact enregistré, pas le code qu’un skill charge ultérieurement — un tel chargement passe par les hooks d’outils ordinaires en tant que network.egress ou process.execute. L’analyse des marketplaces avant publication ne fait pas partie d’ACS, et un mapping Trace fait encore défaut pour les trois hooks de skills (chapitre 9).

ACS est un projet de l’OWASP GenAI Security Project et, selon les propres métadonnées OWASP Nest du projet, classé au niveau 2 (Incubator) ; le Project Lead qualifie l’état actuel de « public preview ». ACS n’est ni une norme ISO, ni un standard IETF ou W3C, ni une norme harmonisée.

Ce que la v0.1 apporte déjà

Malgré ce stade précoce, la v0.1 apporte de la substance : un vocabulaire commun de 19 hooks et cinq dispositions, 44 schémas JSON publiés, une failure posture clairement décrite avec obligation d’audit pour chaque contournement, et une spécification qui nomme ouvertement ses propres lacunes. Selon notre appréciation, cela suffit pour évaluer les fournisseurs à l’aune d’un référentiel ouvert et commun et pour concevoir vos propres points de contrôle de façon qu’ils restent compatibles avec les versions ultérieures — mais pas pour vous fier à des étiquettes de conformité.

La conformité est une autodéclaration

Lors du handshake, l’Observed Agent déclare les profils qu’il prend en charge (profiles_supported) et le Guardian ceux qu’il accepte (profiles_accepted). Il existe exactement sept profils : acs-core, obligatoire, ainsi qu’acs-trace, acs-inspect, acs-inspect-dynamic, acs-provenance, acs-crypto et acs-audit. Il n’existe ni paliers ni niveaux. Qui vérifie les revendications de conformité ? La spécification y répond elle-même : en v0.1.0, personne. Il n’y a ni suite de tests, ni registre des implémentations conformes, ni instance chargée de trancher les revendications litigieuses (issue #19, ouverte, priorité P1). ACS-Core ne garantit en outre que deux choses — un canal authentifié et le fait que l’Observed Agent respecte les décisions du Guardian. Il ne garantit pas des politiques strictes : même un Guardian permissif est conforme.

Implémentation de référence : l’état réel, en toute franchise

La seule implémentation de référence est explicitement une preuve de concept. Elle exploite l’Agent Governance Toolkit (AGT) de Microsoft, sans modification, comme moteur de politiques derrière le wire ACS, avec des intégrations hôtes pour Claude Code et OpenCode. Elle ne revendique acs-core que de manière restreinte (« qualified ») et aucun des six profils optionnels. Il n’existe pas de benchmark d’interopérabilité avec AGT ; c’est l’objectif de la fenêtre de 90 jours ouverte depuis le kick-off du 10 septembre 2026. On ne peut pas en déduire un soutien de Microsoft à ACS. Attention à l’homonymie : dans la documentation d’AGT, « ACS » désigne la propre « Agent Control Specification » de Microsoft (2 juin 2026), le langage de politiques d’AGT — et non le standard OWASP.

Lacunes ouvertes de la spécification ayant une portée pratique

• Fail-open par défaut : on_decision_failure et la startup posture sont réglés sur proceed ; vous devez configurer délibérément le fail-closed (deny ou refuse).
• Pas de mécanisme d’arrêt : la v0.1 ne connaît pas de kill switch ; l’interruption et le streaming sont prévus pour la v0.2. En v0.1, on n’arrête un agent qu’étape par étape, par deny.
• Périmètre obligatoire en mouvement : une proposition ouverte (PR #21) ferait passer modify et system/ping au niveau SHOULD.
• Lacunes d’interopérabilité (analyse propre) : les paramètres HKDF, la signature du handshake et l’entrée du request_hash sont sous-spécifiés.
• Dérive documentaire : certaines pages citent encore 16 hooks au lieu de 19, ou seulement trois dispositions. Seuls la spécification et les schémas font foi sur le plan normatif.

Trois remarques préalables. Premièrement, ACS ne crée aucune présomption de conformité ; le texte de la spécification ne contient aucune correspondance avec l’AI Act, NIS2, DORA, le CRA ou ISO/IEC 42001 — toutes les correspondances ci-dessous sont des déductions de VamiSec. Deuxièmement, les agents IA ne sont pas en soi des systèmes à haut risque. Les obligations relatives au haut risque prévues au chapitre III, sections 1 à 3, du règlement (UE) 2024/1689 s’appliquent, selon le Digital Omnibus (règlement (UE) 2026/1744), à partir du 2 décembre 2027 pour l’annexe III et à partir du 2 août 2028 pour l’annexe I ; l’article 50 s’applique depuis le 2 août 2026. Troisièmement, toute argumentation dépend des profils : ACS-Core seul ne comprend ni Trace, ni AgBOM, ni request_hash.

Démarrer en cinq étapes

1. 1
   InventaireRecenser et classifier les agents

   Recensez les agents, modèles, outils, serveurs MCP et skills, et clarifiez pour chaque usage la classification au titre de l’AI Act. Résultat : un registre des agents avec classe de risque, responsables et accès aux données.

2. 2
   ArchitectureDéfinir les points de contrôle et les profils

   Vérifiez quels hooks votre plateforme déclenche réellement et lesquels le Guardian confirme dans le handshake sous methods_evaluated : tout le reste est traité en allow-by-default et n’est pas protégé. Choisissez les profils selon vos besoins de preuve, par exemple acs-core plus acs-trace et acs-audit pour les obligations de journalisation.

3. 3
   PolitiquesFormuler les politiques sous forme de code

   La couche déterministe s’exécute en premier (référence v0.1 : OPA/Rego). Formulez des règles pour les commandes destructrices, l’egress et les paiements, exigez pour les actions lourdes de conséquences un ask avec approbateur humain et timeout_disposition deny, et référencez les versions de politiques dans policy_references.

4. 4
   ExploitationDécider et tester la failure posture

   Pour les agents à fort potentiel de dommages, définissez on_decision_failure sur deny et la startup posture sur refuse. Testez une panne du Guardian, le rejeu et les erreurs de signature, et surveillez directement les échecs de décision (decision failures), car un ping réussi ne prouve pas que l’application des décisions fonctionne correctement.

5. 5
   PreuvesRaccorder Trace et constituer les preuves

   Exportez OCSF ou OpenTelemetry vers le SIEM, mettez en œuvre les cas d’usage du chapitre 9 et fixez des durées de conservation. Sécurisez la tête de chaîne à l’extérieur et vérifiez les déclarations de conformité des fournisseurs par vos propres tests.

Un approfondissement avec un programme de 100 jours, un modèle de rôles, des indicateurs et des questions d’évaluation à poser aux plateformes d’agents vous attend dans le livre blanc « Agent Control für CISOs » destiné aux RSSI (en allemand), que vous pouvez demander plus bas sur cette page. VamiSec accompagne l’évaluation, l’architecture, la conception des politiques et les tests en tant que cabinet de conseil indépendant ; VamiSec ne fait pas partie du projet ACS.