Deux projets de gouvernance des agents utilisent le sigle ACS : l'Agent Control Standard de l'OWASP et l'Agent Control Specification utilisée par l'Agent Governance Toolkit (AGT) de Microsoft. Une revue d'intégration doit partir de leurs versions exactes, de l'hôte qui applique les décisions et des preuves qui consignent ce qui s'est passé.
Les noms laissent de vraies questions ouvertes. Une approbation doit parvenir à un hôte capable d'en gérer la demande et le résultat. Une entrée d'outil transformée doit s'appliquer à l'action réellement exécutée. Une panne du service de décision exige une issue définie. Ces détails déterminent ce qu'une intégration peut affirmer. Nous fixons les versions des deux contrats au 26 octobre 2026, rendons compte d'une exécution des tests de l'adaptateur hôte de référence de l'OWASP, et renvoyons vers une comparaison versionnée. Cet article fait partie d'une série de recherche en trois volets sur l'autorité des agents, publiée le 26 octobre 2026 : preuves d'arrêt, politiques dans la mémoire des agents et standards de contrôle des agents.
Épingler les contrats réels
Le 26 octobre 2026, l'arborescence publiée par l'OWASP identifie la version 0.1.4, datée du 16 octobre. Son espace de noms de protocole et de schéma identifie toujours 0.1.0. Le journal des modifications consigne des exigences Trace modifiées sous cet espace de noms et demande que les déclarations de conformité nomment la version ou le commit. La seule version de handshake laisse donc une partie du contrat non spécifiée. Historique des versions épinglé.
La documentation actuelle de Microsoft reflète une structure modifiée. AGT utilise un runtime de décision de politique amont et un contrat d'interception distinct, Agent Hooks. L'hôte fournit un instantané complet, reçoit la décision du runtime et assume l'application. Guide ACS actuel d'AGT.
Le pont de référence de l'OWASP épingle une révision plus ancienne d'AGT et le SDK Node 0.3.1-beta.0 : sa correspondance doit donc être lue au regard de cette génération. Le guide AGT actuel décrit trois décisions normalisées, allow, deny et transform, accompagnées d'avertissements et d'informations d'approbation. Un pont dont le fonctionnement a été démontré avec l'ancien contrat a besoin de nouvelles preuves de compatibilité avant de pouvoir valoir pour le contrat actuel. Épinglage des dépendances du pont.
| Élément | OWASP Agent Control Standard | AGT / Agent Control Specification |
|---|---|---|
| Version | 0.1.4 (16 octobre 2026) | Dépendance du moteur 0.4.0-alpha.4 |
| Protocole ou manifeste | Espace de noms du protocole, de la spécification et du schéma 0.1.0 | Manifeste existant 0.4.0-alpha.1 ; contrat sur activation 0.5.0-alpha.1 |
| Pont de référence | Épingle un commit AGT plus ancien et le SDK Node 0.3.1-beta.0 | Sans objet |
Suivre l'approbation et la défaillance jusqu'à l'hôte
L'OWASP définit des types de décision et un comportement qui dépend des capacités, notamment l'approbation, le report et la modification. Les exigences Core obligatoires côtoient des profils optionnels. La spécification distingue l'échec de transmission d'une décision des autres issues et définit un comportement négocié en cas de défaillance. Contrat de conformité épinglé.
Dans le contrat AGT actuel, un refus peut inclure des informations permettant à l'hôte de traiter une demande d'approbation, et une transformation exige que l'hôte la valide et l'applique. La décision du runtime est une étape de ce flux. Agent Hooks énonce sa frontière de confiance : l'hôte est de confiance, les contrôles s'exécutent dans le processus, et ses huit points d'interception ne promettent pas une médiation complète. Agent Hooks.
Un enregistrement d'intégration doit relier l'action proposée à la décision, à toute approbation humaine, à l'entrée finalement envoyée et au résultat. Si l'entrée change après l'approbation, l'enregistrement doit montrer comment l'application décide si l'approbation s'applique encore. Si un hôte ne peut pas présenter un contrôle requis, son repli documenté entre dans l'évaluation.
| Sujet | OWASP 0.1.4 | AGT actuel |
|---|---|---|
| Décisions | ALLOW, DENY, ASK et DEFER doivent être pris en charge ; MODIFY devrait l'être, avec un traitement défini pour les clients qui ne peuvent pas l'appliquer | allow, deny, transform ; warn devient allow avec avertissements ; escalate devient un refus (deny) susceptible d'être levé, accompagné d'informations d'approbation |
| Approbation humaine | Les détails d'ASK, le délai d'expiration et la capacité de l'approbateur ont un comportement défini | L'hôte prend en charge le traitement des demandes d'approbation et de leurs résultats |
| Échec de transmission | on_decision_failure négocié ; par défaut, poursuite avec audit obligatoire | Les erreurs du runtime donnent deny ; le comportement en déploiement dépend de l'hôte |
| Couverture | Core et profils optionnels autodéclarés | Huit points d'interception ; hôte de confiance ; aucune promesse de médiation complète |
Ce que nous avons exécuté
Nous avons récupéré l'implémentation de référence de l'OWASP au commit 4cf23d4 et exécuté sans modification ses suites de tests sur la validation des décisions et le comportement en cas de défaillance avec Bun 1.3.14. Les 94 tests de ces deux fichiers ont réussi (236 assertions). Ils couvrent les modifications mal formées, les décisions expirées, les échecs de transmission, le refus explicite et l'échec d'enregistrement d'un événement d'audit.
Les tests font des distinctions utiles. Une demande d'approbation expirée peut être traitée autrement qu'un service de décision qui n'a jamais répondu. Un refus explicite diffère d'un échec de transport. Une configuration qui laisse l'action se poursuivre doit tout de même satisfaire son exigence d'audit. Une étiquette unique comme « fail closed » ne peut pas décrire tous ces chemins sans leurs conditions.
Deux fichiers de test dépendant du runtime n'ont pas pu charger leur dépendance native, qui exige glibc 2.39 ; notre machine dispose de la version 2.35. Nous avons conservé la tentative échouée avec l'exécution réussie. Ces fichiers ne nous ont fourni aucun résultat de moteur de politique en conditions réelles, et les 94 tests réussis n'établissent ni la conformité complète ni l'interopérabilité.
Les mainteneurs de la référence signalent aussi des lacunes dans la couverture des hooks, la signature, l'authentification et la protection contre le rejeu. Elles font partie du périmètre documenté de l'implémentation, et toute référence qui la prend comme exemple doit les laisser visibles. Périmètre de l'implémentation de référence.
Consigner l'issue que les preuves étayent
Les modifications Trace d'OWASP 0.1.4 ajoutent une règle utile : corréler les identifiants de requête et de session, et rechercher un événement d'échec de décision correspondant avant de considérer une décision comme appliquée. Cette règle sépare ce que le service de politique a décidé de ce que l'hôte a effectivement accompli.
La comparaison d'octobre (en anglais) distingue les exigences des sources, les observations au niveau des fonctions utilitaires et les scénarios que nous n'avons pas exécutés. Utilisez ces scénarios pour un plan de test d'intégration :
| Scénario | Observation nécessaire | Cette revue |
|---|---|---|
| Appel d'outil refusé | L'hôte empêche l'envoi | Comportement des fonctions utilitaires et sources examinés ; chemin natif réel non exécuté |
| Approbation suivie d'une entrée modifiée | L'approbation est liée à l'action réellement envoyée | Non exécuté |
| Service de décision indisponible | Posture choisie, action résultante, événement d'audit | Tests des utilitaires de l'hôte réussis ; chemin réel non exécuté |
| Décision expirée | Limite temporelle et issue de repli | Tests des utilitaires de l'hôte réussis |
| Requête rejouée | Détection des doublons et sort consigné | Absence de protection signalée en amont ; aucune sonde réelle |
| Transformation impossible à appliquer | Repli sûr et preuves | Tests des utilitaires de l'hôte réussis |
| Décision enregistrée, échec d'application par l'hôte | Preuves de décision et d'échec reliées | Contrat Trace examiné ; scénario non exécuté |
Comment KLA traite les mêmes questions
KLA n'implémente aucun des deux projets ACS. À titre de comparaison : le KLA Policy Engine renvoie l'un de quatre résultats, allow, warn, require_approval ou block, pour chaque action gouvernée. Lorsque l'évaluation échoue, il renvoie sa décision de repli restrictive (fail-closed), par défaut require_approval, et le lint des policy packs rejette toute politique dont la décision par défaut laisse passer l'action (fail-open). Sur le chemin des outils gouvernés, une demande d'approbation pour un appel d'outil enregistre une empreinte SHA-256 des arguments pour lesquels elle a été émise, ce qui répond au scénario « approbation suivie d'une entrée modifiée » ci-dessus.
Les tests de cet article ont porté uniquement sur l'implémentation de référence de l'OWASP et ne contiennent aucun résultat KLA. Le guide des contrôles agentiques OWASP relie plus en détail les contrôles d'exécution aux preuves.
Foire aux questions
Quelle différence entre l'ACS de l'OWASP et l'Agent Control Specification de Microsoft ?
Les deux partagent un sigle et diffèrent par leur contrat. L'Agent Control Standard de l'OWASP (version 0.1.4, espace de noms de protocole 0.1.0) définit ALLOW, DENY, ASK, DEFER et MODIFY avec un comportement négocié en cas de défaillance. L'Agent Control Specification utilisée par Microsoft AGT normalise les décisions en allow, deny et transform, et confie le traitement des demandes d'approbation et l'application des décisions à un hôte de confiance.
Quelle version une déclaration de conformité d'un contrôle d'agent doit-elle nommer ?
La version publiée ou le commit. OWASP 0.1.4 a modifié les exigences Trace sans changer l'espace de noms de protocole 0.1.0, et son journal des modifications demande que les déclarations de conformité nomment la version ou le commit. Pour AGT, consignez séparément les versions du moteur, du manifeste et du contrat.
L'implémentation de référence de l'OWASP réussit-elle ses tests ?
Le 26 octobre 2026, au commit 4cf23d4, les deux suites de l'adaptateur hôte que nous avons exécutées ont réussi 94 tests sur 94. Deux fichiers dépendant du runtime n'ont pas pu charger leur dépendance native sur une machine en glibc 2.35. Ces résultats ne couvrent que le comportement des fonctions utilitaires et n'établissent pas la conformité.
Que signifie « fail closed » pour un contrôle d'agent ?
Cela dépend de la défaillance. Une approbation expirée, une demande de décision restée sans réponse, un refus explicite et une erreur de transport peuvent chacun exiger un comportement différent. Pour chacun, nommez la classe de défaillance, l'action résultante et l'événement d'audit.
Points clés à retenir
Les noms de projets n'établissent pas l'interopérabilité. Épinglez les versions publiées et les versions de protocole, suivez l'approbation et la transformation jusqu'à l'hôte, testez chaque classe de défaillance et vérifiez la trace avant d'affirmer que l'application est effective. La comparaison d'octobre fournit un point de départ daté ; mettez-la à jour quand l'un des deux projets évolue.
Les versions ont été épinglées le 26 octobre 2026. Notre exécution a couvert 94 tests des utilitaires de l'hôte ; aucun scénario réel d'hôte, d'approbation ou de trace n'a été exécuté.