5 min de lecture
~9 minutes
L’OWASP GenAI Security Project a publié l’Agent Control Standard : des hooks dans la plateforme d’agents, un Guardian qui autorise, refuse ou modifie chaque action, une trace et un inventaire vivant. L’idée est bonne, mais encore incomplète
Un agent qui agit sans que personne puisse l’arrêter
Un agent appelle un outil, lit une base, délègue à un sous-agent. Entre l’intention et l’exécution, il n’y a, dans la plupart des déploiements que je croise, ni point de contrôle commun ni langage partagé pour le décrire. Chaque framework a ses garde-fous maison, chaque éditeur son « guardrail » propriétaire, et personne ne peut dire de façon vérifiable ce qu’un agent a le droit de faire à l’instant T.
L’ACS part de ce constat, résumé en une phrase sur son site : « Enterprises cannot trust what they cannot govern ». Le standard ne vend pas un produit. Il décrit comment une plateforme d’agents expose des hooks, et comment une politique déclarative vient les piloter. C’est une spécification filaire, en version 0.1.0.
Je n’ai pas relu la spécification v0.1.0 ligne à ligne, donc les détails fins (liste exacte des hooks, schémas) sont à vérifier dans le dépôt avant de bâtir quoi que ce soit dessus.
Note du PandaRedacteur : le principe est excellent, la notice n’est pas finie. Ne montez rien dessus avant de l’avoir lue en entier.
Ce que l’ACS met sur la table
L’ACS repose sur trois piliers, qu’il nomme lui-même Instrument, Trace et Inspect.
Instrument : les hooks et le Guardian. La plateforme d’agents déclenche un hook à chaque point de décision : entrée, sortie, sélection d’un outil, appel d’un outil, passage de la planification à l’exécution, écriture en mémoire, exécution de code, invocation d’un sous-agent. Un Guardian Agent, séparé de l’agent observé, reçoit la requête et rend un verdict avant l’action.
Le Guardian a deux couches. Une couche déterministe, un moteur de politiques de type OPA/Rego ou Cedar, passe toujours en premier. Une couche agent optionnelle, un LLM, n’est sollicitée que par délégation et ne lit jamais le code de la politique.
Note du PandaRedacteur : On évite de faire arbitrer une injection de prompt par un autre modèle qui lirait les mêmes mots.
Trace : de la télémétrie, pas des logs maison. Chaque action émet des spans OpenTelemetry étendus avec des conventions propres aux agents, et les événements de sécurité sont mappés en OCSF pour atterrir dans un SIEM.
Inspect : l’AgBOM. Un inventaire vivant des modèles, outils, sources de connaissance et dépendances d’un agent, sérialisé en CycloneDX, SPDX ou SWID. C’est un SBOM qui bouge avec l’agent.
Le lien avec Zero Trust pour agents IA : l’inventaire d’abord saute aux yeux : l’AgBOM est précisément l’inventaire que cet article réclamait comme première étape, et le Guardian est la couche d’application qui n’a de sens qu’une fois l’inventaire fait. L’ACS propose les deux, dans le bon ordre.
Ce que l’ACS ne garantit pas encore
C’est la partie du texte qu’on lit moins vite en réunion de cadrage.L’implémentation de référence de la v0.1.0 a des limites que je ne peux pas passer sous silence :
- Pas d’authentification. ACS-Core exige une signature HMAC-SHA256 sur chaque enveloppe. Le Guardian de référence ne l’implémente pas. Tout ce qui atteint son port peut lire ou provoquer des décisions.
- Fail-open par défaut. Un Guardian en panne ou injoignable laisse l’hôte procéder. Il faut positionner
ACS_ON_DECISION_FAILURE=denypour obtenir un comportement fail-closed . - Couverture partielle. Sur dix-neuf hooks, deux sont évalués en direct :
steps/toolCallRequestetsteps/toolCallResult. - Conformité auto-déclarée. Un déploiement annonce ses profils (Trace, Inspect, Provenance, signature) au handshake, et personne ne vérifie.
- Export de traces partiel. Deux méthodes couvertes, pas d’OCSF, et un attribut requis peut manquer.
- Feuille de route lointaine. La v0.2.0 est visée pour mars 2027, aucune date pour la v1.0, et l’intégration MCP et A2A est seulement « planned ».
Note du PandaRedacteur : un portique d’aéroport qui laisse passer tout le monde dès que le courant saute, ça reste un contrôle de sécurité ?
Le point 2 mérite qu’on s’y attarde, parce que c’est le piège classique : l’agent le plus dangereux est aussi celui que la panne du contrôleur libère.
ACS or not ACS ?
Avant tout il faut considerer que. l’ACS ne se déploie pas en production aujourd’hui, mais il se lit, se teste et se mesure.
- La spécification v0.1.0 se lit en entier : je tranche moi-même le décompte des hooks et des verdicts, plutôt que de me fier à un résumé, le mien compris.
- Le Guardian se pose en laboratoire, avec
ACS_ON_DECISION_FAILURE=denyet un canal authentifié devant, pour mesurer la latence ajoutée à chaque appel d’outil. - Quelles actions échappent aux deux hooks évalués ? Mémoire, code, sous-agents. C’est là que se trouvent mes vrais risques, comme ceux que j’avais listés pour Excessive Agency dans le Top 10 LLM 2026.
- L’AgBOM, je le branche d’abord sur mon inventaire existant : c’est le morceau le moins risqué et le plus immédiatement utile, parce qu’il parle CycloneDX, un format que mes outils de supply chain lisent déjà.
- Pas question de citer l’ACS comme preuve de conformité. Le site relie le standard à l’EU AI Act (supervision humaine) et au NIST AI RMF ; c’est une intention de l’éditeur du standard, pas une équivalence juridique. Pour le cadre réglementaire, voir l’AI Act et les agents autonomes à haut risque, et pour le contrôle des identités qui complète le dispositif, les identités non humaines des agents IA.
Note du PandaRedacteur : le jour où l’ACS atteindra la v1.0, je ne demanderai pas « êtes-vous conforme ? » mais « qui l’a vérifié ? ». La conformité auto-déclarée, on la connaît : elle s’appelle un questionnaire.