Due progetti di governance degli agenti usano la sigla ACS: l’Agent Control Standard di OWASP e l’Agent Control Specification usata dall’Agent Governance Toolkit (AGT) di Microsoft. Una revisione di integrazione dovrebbe partire dalle loro versioni esatte, dall’host che applica le decisioni e dalle prove che registrano ciò che è accaduto.
I nomi lasciano aperte domande concrete. Un’approvazione deve arrivare a un host in grado di gestirne la richiesta e l’esito. Un input trasformato di uno strumento deve essere applicato all’azione effettivamente eseguita. Un’interruzione del servizio decisionale richiede un esito definito. Questi dettagli determinano che cosa un’integrazione può affermare. Questo articolo fissa entrambi i contratti al 26 ottobre 2026, riporta un’esecuzione dei test di riferimento OWASP per l’adattatore host e rimanda a un confronto versionato. Questo articolo fa parte di una serie di ricerca in tre parti sull’autorità degli agenti, pubblicata il 26 ottobre 2026: prove di arresto, policy nella memoria degli agenti e standard di controllo degli agenti.
Fissate i contratti effettivi
Al 26 ottobre 2026, l’albero pubblicato da OWASP identifica la release 0.1.4, datata 16 ottobre. Il suo spazio dei nomi del protocollo e dello schema identifica ancora la 0.1.0. Il changelog registra requisiti di Trace modificati sotto quel namespace e chiede che le dichiarazioni di conformità indichino la release o il commit. La sola versione dell’handshake lascia quindi non specificata una parte del contratto. Cronologia delle release al commit fissato.
La documentazione attuale di Microsoft riflette una struttura cambiata. AGT usa un runtime upstream di decisione delle policy e un contratto di intercettazione separato, Agent Hooks. L’host fornisce uno snapshot completo, riceve la decisione del runtime ed è responsabile dell’applicazione. Guida ACS attuale di AGT.
Il bridge di riferimento OWASP fissa una revisione precedente di AGT e il Node SDK 0.3.1-beta.0, quindi la sua mappatura va letta rispetto a quella generazione. L’attuale guida di AGT descrive tre decisioni normalizzate, allow, deny e transform, con avvisi e informazioni di approvazione trasportati accanto a esse. Un bridge che ha dimostrato di funzionare con il contratto precedente richiede nuove prove di compatibilità prima di poter valere per quello attuale. Dipendenza fissata del bridge.
| Elemento | OWASP Agent Control Standard | AGT / Agent Control Specification |
|---|---|---|
| Release | 0.1.4 (16 ottobre 2026) | Dipendenza del motore 0.4.0-alpha.4 |
| Protocollo di comunicazione o manifest | Spazio dei nomi del protocollo, della specifica e dello schema 0.1.0 | Manifest esistente 0.4.0-alpha.1; contratto opt-in 0.5.0-alpha.1 |
| Bridge di riferimento | Fissa un commit precedente di AGT e il Node SDK 0.3.1-beta.0 | Non applicabile |
Seguite approvazione ed errori attraverso l’host
OWASP definisce i tipi di decisione e i comportamenti che dipendono dalle capacità, tra cui approvazione, rinvio e modifica. I requisiti Core obbligatori convivono con profili facoltativi. La specifica separa l’errore di consegna della decisione dagli altri esiti e definisce un comportamento negoziato in caso di errore. Contratto di conformità al commit fissato.
Nell’attuale contratto AGT, un rifiuto può includere informazioni che l’host usa per gestire una richiesta di approvazione, e una trasformazione richiede che l’host la convalidi e la applichi. La decisione del runtime è un passaggio di quel flusso. Agent Hooks dichiara il proprio confine di fiducia: l’host è considerato affidabile, i controlli girano nello stesso processo e i suoi otto punti di intercettazione non promettono una mediazione completa. Agent Hooks.
Un registro di integrazione dovrebbe collegare l’azione proposta alla decisione, all’eventuale approvazione umana, all’input infine inviato e al risultato. Se l’input cambia dopo l’approvazione, il registro deve mostrare come l’applicazione decide se l’approvazione vale ancora. Se un host non è in grado di presentare un controllo richiesto, il suo fallback documentato entra nella valutazione.
| Aspetto | OWASP 0.1.4 | AGT attuale |
|---|---|---|
| Decisioni | ALLOW, DENY, ASK e DEFER devono essere supportate; MODIFY dovrebbe esserlo, con una gestione definita per i client che non possono applicarla | allow, deny, transform; warn diventa allow con avvisi; escalate diventa un rifiuto (deny) che può essere rimosso, corredato di informazioni di approvazione |
| Approvazione umana | I dettagli di ASK, il timeout e la capacità dell’approvatore hanno un comportamento definito | L’host è responsabile della gestione delle richieste di approvazione e dei relativi esiti |
| Errore di consegna | on_decision_failure negoziato; per impostazione predefinita si procede con audit obbligatorio | Gli errori del runtime producono deny; il comportamento in esercizio dipende dall’host |
| Copertura | Core più profili facoltativi autodichiarati | Otto punti di intercettazione; host considerato affidabile; nessuna promessa di mediazione completa |
Cosa abbiamo eseguito
Abbiamo estratto l’implementazione di riferimento OWASP al commit 4cf23d4 ed eseguito senza modifiche le sue suite di convalida delle decisioni e di comportamento in caso di errore con Bun 1.3.14. Tutti i 94 test di quei due file sono stati superati (236 asserzioni). Coprono modifiche malformate, decisioni scadute, errori di consegna, rifiuti espliciti e mancata registrazione di un evento di audit.
I test fanno distinzioni utili. Una richiesta di approvazione scaduta può essere trattata diversamente da un servizio decisionale che non ha mai risposto. Un rifiuto esplicito è diverso da un errore di trasporto. Una configurazione che consente all’azione di procedere deve comunque soddisfare il proprio requisito di audit. Un’unica etichetta come «fail closed» non può descrivere tutti questi percorsi senza le relative condizioni.
Due file di test dipendenti dal runtime non sono riusciti a caricare la loro dipendenza nativa, che richiede glibc 2.39; il nostro host ha la 2.35. Abbiamo conservato il tentativo fallito accanto all’esecuzione riuscita. Da quei file non abbiamo ottenuto risultati live del motore di policy, e i 94 test superati non stabiliscono la piena conformità né l’interoperabilità.
I maintainer dell’implementazione di riferimento dichiarano anche lacune nella copertura degli hook, nella firma, nell’autenticazione e nella protezione dal replay. Queste lacune fanno parte dell’ambito documentato dell’implementazione, e qualsiasi riferimento che la usi come esempio dovrebbe mantenerle visibili. Ambito dell’implementazione di riferimento.
Registrate l’esito che le prove sostengono
Le modifiche a Trace in OWASP 0.1.4 aggiungono una regola utile: correlare gli identificatori di richiesta e di sessione e verificare se esiste un evento di errore della decisione corrispondente prima di considerare applicata una decisione. Questo separa ciò che il servizio di policy ha deciso da ciò che l’host ha completato.
Il confronto di ottobre (in inglese) separa i requisiti delle fonti, le osservazioni a livello di helper e gli scenari che non abbiamo eseguito. Usate questi scenari per un piano di test di integrazione:
| Scenario | Osservazione necessaria | Questa revisione |
|---|---|---|
| Chiamata a uno strumento negata | L’host impedisce l’invio | Comportamento dell’helper e sorgente esaminati; percorso nativo live non eseguito |
| Approvazione seguita da input modificato | L’approvazione è vincolata all’azione effettivamente inviata | Non eseguito |
| Servizio decisionale non disponibile | Postura scelta, azione risultante, evento di audit | Test degli helper host superati; percorso live non eseguito |
| Decisione scaduta | Limite temporale ed esito di fallback | Test degli helper host superati |
| Richiesta ripetuta (replay) | Rilevamento dei duplicati ed esito registrato | Protezione mancante dichiarata upstream; nessuna verifica live |
| Trasformazione non applicabile | Fallback sicuro e prove | Test degli helper host superati |
| Decisione registrata, l’host non la applica | Prove della decisione e dell’errore collegate | Contratto di Trace esaminato; scenario non eseguito |
Come KLA gestisce le stesse domande
KLA non è un’implementazione di nessuno dei due progetti ACS. A titolo di confronto: il KLA Policy Engine restituisce uno di quattro esiti, allow, warn, require_approval o block, per ogni azione governata. Quando la valutazione fallisce restituisce la sua decisione fail-closed, require_approval per impostazione predefinita, e il lint dei policy pack rifiuta una policy la cui decisione predefinita è fail-open. Sul percorso degli strumenti governati, una richiesta di approvazione per una chiamata a uno strumento registra un hash SHA-256 degli argomenti per cui è stata emessa, il che risponde allo scenario «approvazione seguita da input modificato» descritto sopra.
I test di questo articolo sono stati eseguiti solo sull’implementazione di riferimento OWASP e non contengono alcun risultato di KLA. La guida ai controlli agentici OWASP mette in relazione i controlli di runtime con le prove in modo più dettagliato.
Domande frequenti
Qual è la differenza tra OWASP ACS e l’Agent Control Specification di Microsoft?
Condividono la sigla e differiscono nel contratto. L’Agent Control Standard di OWASP (release 0.1.4, spazio dei nomi del protocollo di comunicazione 0.1.0) definisce ALLOW, DENY, ASK, DEFER e MODIFY con un comportamento negoziato in caso di errore. L’Agent Control Specification usata da Microsoft AGT normalizza le decisioni in allow, deny e transform e lascia la gestione delle approvazioni e l’applicazione delle decisioni a un host considerato affidabile.
Quale versione dovrebbe indicare una dichiarazione di conformità per il controllo degli agenti?
La release o il commit. OWASP 0.1.4 ha modificato i requisiti di Trace senza cambiare il spazio dei nomi del protocollo di comunicazione 0.1.0, e il suo changelog chiede che le dichiarazioni di conformità indichino la release o il commit. Per AGT, registrate separatamente le versioni del motore, del manifest e del contratto.
L’implementazione di riferimento OWASP supera i suoi test?
Il 26 ottobre 2026, al commit 4cf23d4, le due suite per l’adattatore host che abbiamo eseguito hanno superato 94 test su 94. Due file dipendenti dal runtime non hanno potuto caricare la loro dipendenza nativa su un host con glibc 2.35. Questi risultati coprono solo il comportamento degli helper e non stabiliscono la conformità.
Che cosa significa «fail closed» per un controllo degli agenti?
Dipende dall’errore. Un’approvazione scaduta, una richiesta di decisione senza risposta, un rifiuto esplicito e un errore di trasporto possono richiedere ciascuno un comportamento diverso. Per ciascuno indicate la classe di errore, l’azione risultante e l’evento di audit.
Punti chiave
I nomi dei progetti non stabiliscono l’interoperabilità. Fissate le versioni della release e del protocollo di comunicazione, seguite approvazione e trasformazione attraverso l’host, testate ogni classe di errore e controllate la traccia prima di dichiarare l’applicazione. Il confronto di ottobre offre un punto di partenza datato; aggiornatelo quando uno dei due progetti cambia.
Le versioni sono state fissate il 26 ottobre 2026. La nostra esecuzione ha coperto 94 test degli helper host; non è stato eseguito alcuno scenario live di host, approvazione o traccia.