Advanced AI Society Proof-of-Control apre un nuovo fronte nella sicurezza degli agenti

Advanced AI Society ha pubblicato Proof-of-Control per la revisione pubblica il 17 settembre, nonostante rimangano aperte questioni sulla versione, l'ambito e il livello di preparazione della bozza. Lo standard proposto chiede agli agenti AI di produrre evidenze a prova di manomissione che dimostrino che ogni azione controllata è rimasta entro i limiti autorizzati. Sposta inoltre la sicurezza degli agenti dalla fiducia nei log privati di un fornitore.

Questo cambiamento è importante perché gli agenti stanno andando oltre la generazione di testo. Possono chiamare strumenti, accedere a registri, modificare software, comunicare con servizi esterni e avviare transazioni. Un audit trimestrale non può osservare ogni decisione nel momento in cui avviene, mentre un log controllato dall'operatore dell'agente può offrire garanzie indipendenti limitate.

Advanced AI Society afferma che oltre 80 responsabili della sicurezza hanno contribuito a definire il suo approccio. Il gruppo sta collocando il lavoro all'interno di Linux Foundation Decentralized Trust, offrendo al progetto una sede neutrale per la governance tecnica. Tuttavia, una governance neutrale non rende completa una bozza, né le evidenze crittografiche garantiscono che un'organizzazione abbia scelto i controlli giusti.

Il Congresso sta affrontando lo stesso problema da un'altra prospettiva. Una proposta bipartisan della Camera indirizzerebbe NIST a sviluppare pratiche di sicurezza per gli agenti che comprendano verifica continua, valutazione della sicurezza, inventari e registri resistenti alla manomissione. Lo scontro tra standard aperti volontari e requisiti sostenuti dal governo costituisce la vera notizia.

Advanced AI Society Proof-of-Control è più di un annuncio di adesione

Il cambiamento importante è la pubblicazione di una proposta ispezionabile per la verifica degli agenti, non il titolo sull'adesione che la circonda.

Advanced AI Society ha descritto il suo annuncio di settembre come l'ingresso nella Linux Foundation e in LF Decentralized Trust. Tuttavia, i registri della Linux Foundation mostrano che l'organizzazione è diventata membro associato di LF Decentralized Trust il 21 aprile 2026. L'annuncio più recente combina quindi uno sviluppo precedente relativo all'adesione con la presentazione pubblica di Proof-of-Control e del laboratorio associato.

Questa distinzione è importante. L'adesione colloca un'organizzazione in una rete collaborativa, ma non convalida ogni affermazione o progetto tecnico che l'organizzazione pubblica. L'azione rilevante è portare uno standard di verifica proposto in un ambiente della fondazione dove contributori esterni possano ispezionarlo, metterlo in discussione ed estenderlo.

Il registro dell'adesione di aprile identifica Advanced AI Society come uno dei due nuovi membri associati. L'avviso di lancio di settembre introduce Proof-of-Control come laboratorio di LF Decentralized Trust e invita a inviare commenti pubblici.

Proof-of-Control è progettato attorno a una domanda diretta: una parte indipendente può verificare che un agente AI sia rimasto entro i controlli assegnati? Un controllo potrebbe impedire a un agente di spostare denaro senza approvazione, limitare i registri dei clienti a cui può accedere o restringere gli strumenti disponibili durante un'attività.

La proposta si concentra sul confine dell'azione, ovvero il punto in cui un agente tenta di chiamare uno strumento o creare un effetto esterno. La sua architettura colloca un gateway di intercettazione separato a quel confine. Il gateway valuta l'azione proposta, blocca quelle che escono dalla politica dichiarata ed emette evidenze sulla decisione.

Questo progetto è più specifico delle promesse convenzionali sull'AI responsabile. Descrive dove avviene l'applicazione dei controlli, quali evidenze dovrebbero essere prodotte e come un'altra parte potrebbe verificarle. Advanced AI Society individua inoltre sei domini di verifica: provenienza, privacy, portabilità, autorizzazione, identità e sicurezza.

L'idea centrale del framework è che il log di runtime di un agente resta un'affermazione quando lo stesso operatore controlla sia l'esecuzione sia la conservazione dei registri. Un sistema compromesso potrebbe omettere un'azione, riscrivere un record o aggirare la registrazione. Un meccanismo di verifica utile deve quindi rendere visibili le alterazioni e identificare le ipotesi da cui dipendono le sue evidenze.

Il progetto propone più livelli di garanzia. I livelli inferiori dipendono dalle dichiarazioni dell'operatore o dall'accesso di un revisore. I livelli superiori puntano a registri verificabili in modo indipendente o a gate di esecuzione che impediscano un'azione controllata senza evidenze corrispondenti.

Ciò crea una distinzione significativa tra osservare un'azione e limitarla. Un record a prova di manomissione può aiutare gli investigatori a stabilire cosa sia stato registrato dopo un incidente. Un gate di esecuzione implementato correttamente può impedire un'azione coperta quando le sue condizioni di autorizzazione non sono soddisfatte.

Proof-of-Control non afferma di stabilire se il modello sottostante sia sicuro, accurato o allineato. Non decide nemmeno se un'azienda abbia concesso a un agente troppa autorità. Cerca di stabilire se i controlli dichiarati abbiano governato le azioni incluse in un ambito definito.

Questo obiettivo più ristretto è un punto di forza perché offre agli implementatori qualcosa di verificabile. È anche la fonte del limite più grande del progetto. L'evidenza che un agente abbia seguito una politica debole dimostra solo la conformità a quella politica debole.

Il Congresso sta trasformando la verifica degli agenti in una questione di appalti

La sicurezza degli agenti sta passando da preferenza tecnica a condizione per fare affari con acquirenti regolamentati e con il governo federale.

Il proposto Stop Rogue AI Act incaricherebbe il National Institute of Standards and Technology di pubblicare standard, linee guida e buone pratiche per l'implementazione sicura degli agenti. Secondo i dettagli riportati del disegno di legge, il lavoro riguarderebbe inventari continui degli agenti, valutazioni della sicurezza, log resistenti alla manomissione e verifica delle azioni degli agenti.

La proposta proviene dai rappresentanti Josh Gottheimer, democratico del New Jersey, e Mike Lawler, repubblicano di New York. La maggior parte delle organizzazioni utilizzerebbe volontariamente le pratiche NIST risultanti. Gli appaltatori federali in competizione per nuovi incarichi subirebbero una pressione maggiore per rispettarle.

Questo meccanismo conta più di un'ampia dichiarazione normativa. I requisiti di appalto possono influenzare i mercati tecnologici senza imporre un'unica architettura obbligatoria a ogni organizzazione privata. I fornitori spesso adottano controlli rivolti al governo nell'intera gamma dei loro prodotti, perché mantenere sistemi di sicurezza separati aumenta costi e complessità.

NIST stava già lavorando sul settore prima che emergesse la proposta della Camera. A febbraio, l'agenzia ha annunciato un'iniziativa sugli standard per gli agenti che copre interoperabilità, identità, autorizzazione e sicurezza. Ha inoltre richiesto contributi da parte di utilizzatori, sviluppatori, ricercatori e fornitori di infrastrutture.

La sovrapposizione con Proof-of-Control è chiara. Entrambi gli sforzi si concentrano su identità persistente, autorità definita, azioni osservabili ed evidenze che sopravvivano al di fuori della narrazione dell'agente stesso. Entrambi riconoscono inoltre che gli agenti interagiscono con sistemi esistenti attraverso strumenti, credenziali e interfacce di servizio.

I loro ruoli restano diversi. NIST sviluppa linee guida attraverso un processo federale di standardizzazione e può influenzare le aspettative in materia di appalti. Advanced AI Society sta proponendo uno standard orientato all'implementazione attraverso una comunità aperta e vuole che attorno a esso si sviluppino strumenti di verifica indipendente.

La proposta della Camera crea pressione su tre gruppi. I fornitori di agenti devono spiegare come i loro sistemi identifichino ciascun agente e ne limitino le autorizzazioni. Gli utilizzatori aziendali devono mantenere inventari e determinare quali sistemi possano compiere azioni rilevanti. I fornitori di sicurezza devono generare evidenze che valutatori esterni possano esaminare.

Gli appaltatori federali affrontano il più chiaro potenziale fattore di imposizione. Un fornitore potrebbe considerare la verifica aperta facoltativa mentre vende nei normali mercati commerciali. Questa posizione diventa più difficile da sostenere quando un grande acquirente richiede inventari leggibili dalle macchine, registri continui e controlli verificabili in modo indipendente.

Assicuratori e revisori creano un'altra fonte di pressione. Un assicuratore che valuta un agente capace di avviare pagamenti ha bisogno di più di un documento di policy. Ha bisogno di evidenze che mostrino quale identità ha agito, quale autorità esisteva, quale controllo ha valutato la richiesta e se il record risultante è rimasto integro.

La stessa questione emerge nella sanità. Un agente può recuperare cartelle cliniche, riassumere un caso o preparare un ordine. Un ospedale deve distinguere tra confermare l'integrità del record e confermare che la decisione clinica fosse appropriata. Proof-of-Control affronta il primo aspetto, mentre governance e revisione professionale determinano ancora il secondo.

Gli sviluppatori avvertiranno il cambiamento nei punti di integrazione. La sicurezza non può più terminare con la protezione di un endpoint del modello. I team devono considerare credenziali, autorizzazioni degli strumenti, catene di delega, accesso ai dati ed effetti collaterali in ogni servizio che un agente può raggiungere.

Ecco perché la sicurezza degli agenti sta diventando una questione di appalti anziché un confronto tra funzionalità. Gli acquirenti hanno bisogno di evidenze che restino significative tra fornitori diversi. Le dashboard proprietarie aiutano gli operatori a gestire i propri sistemi, ma non creano automaticamente un linguaggio di garanzia condiviso per revisori, assicuratori, regolatori e clienti.

La verifica aperta sfida i log controllati dai fornitori

La competizione principale è tra evidenze portabili di terze parti e registri di sicurezza che restano controllati dal fornitore sottoposto a valutazione.

I tradizionali log aziendali non sono inutili. Supportano risposta agli incidenti, monitoraggio, debugging e conformità. Il problema è che il valore di un log dipende da chi lo ha generato, dal fatto che abbia catturato ogni percorso rilevante e dalla possibilità che qualcuno potesse modificarlo in seguito.

Gli agenti AI rendono queste domande più difficili. Le loro azioni possono dipendere da contesto in evoluzione, dati recuperati, output del modello, risposte degli strumenti e autorizzazioni delegate. Un sistema può registrare la chiamata finale allo strumento senza conservare contesto sufficiente per stabilire perché quella chiamata sia stata autorizzata.

Proof-of-Control propone evidenze generate durante l'esecuzione, non ricostruite dopo un incidente. Cerca inoltre record portabili che parti diverse possano interpretare senza ottenere accesso privilegiato all'intero ambiente dell'operatore.

La panoramica dello standard pubblicata dal progetto descrive le evidenze come binarie, contemporanee, a prova di manomissione e trasparenti riguardo alle ipotesi di fiducia residue. Binario significa che l'azione controllata è rimasta entro il confine dichiarato oppure no. Non significa che il risultato più ampio fosse corretto.

Si consideri un agente di acquisto autorizzato a effettuare ordini al di sotto di un limite definito dall'azienda. Il livello di verifica potrebbe registrare l'identità dell'agente, l'autorità delegata, l'importo valutato e il risultato della policy. Potrebbe inoltre rifiutare un ordine che superi tale limite.

Tuttavia, l'evidenza non stabilirebbe che l'acquisto fosse necessario, che il fornitore fosse affidabile o che il prezzo rappresentasse un buon valore. Si tratta di valutazioni aziendali separate. La verifica mostra se un controllo esplicito è stato rispettato, non se l'organizzazione abbia progettato un controllo sensato.

Questa separazione è essenziale perché il linguaggio della sicurezza spesso comprime diverse affermazioni distinte. Un fornitore può descrivere un agente come sicuro perché dispone di autorizzazioni, registri di audit e opzioni di approvazione umana. Queste funzionalità non dimostrano che non esista alcuna via di aggiramento o che ogni azione rilevante passi attraverso il punto di controllo.

Il gateway di intercettazione delle azioni proposto da Proof-of-Control tenta di risolvere questo problema. Si colloca al di fuori del processo dell'agente e media le chiamate agli strumenti controllate. Affinché l'architettura funzioni, l'agente non deve disporre di credenziali o percorsi di rete alternativi che aggirino il gateway.

Questa condizione di assenza di aggiramenti è difficile da garantire. Gli ambienti software moderni contengono account di servizio, credenziali memorizzate nella cache, processi in background, plug-in e percorsi di rete diretti. Un verificatore deve testare il sistema circostante, non limitarsi a ispezionare l'output del gateway.

La proposta introduce anche compromessi sul fronte della privacy. Le evidenze di verifica devono comunicare abbastanza da sostenere una conclusione significativa senza esporre prompt, dati personali, pesi del modello o dati aziendali proprietari. Le affermazioni crittografiche possono ridurre la divulgazione, ma la loro utilità dipende dalla qualità della misurazione e dell'implementazione sottostanti.

La portabilità pone un'altra sfida. Due fornitori possono utilizzare linguaggi di policy, sistemi di identità, runtime e formati di logging diversi. Uno schema di evidenze condiviso può normalizzare parte di questa variabilità. Non può eliminare tutte le differenze nel modo in cui i controlli originali sono stati definiti o applicati.

Una governance aperta offre una risposta credibile a questa frammentazione. Specifiche pubbliche, vettori di test, codice di riferimento e modelli di minaccia documentati forniscono a clienti e ricercatori materiale che possono esaminare. Un programma di assurance controllato dal fornitore può divulgare meno informazioni e cambiare senza accordo esterno.

La Linux Foundation fornisce un'infrastruttura istituzionale per questo lavoro. Può sostenere la governance della comunità, le regole sulla proprietà intellettuale, i processi di contribuzione e la gestione a lungo termine. Non certifica che il progetto abbia risolto il contenimento degli agenti o l'adozione aziendale.

Questo confine dovrebbe rimanere visibile. L'hosting da parte di una fondazione dimostra che un progetto dispone di una sede per la collaborazione. Non dimostra che ogni distribuzione sia conforme, che ogni prova sia completa o che i clienti accetteranno i registri risultanti.

La bozza mostra già perché la revisione indipendente è importante

Le prime incoerenze di Proof-of-Control rivelano la differenza tra lanciare uno standard e affermarlo.

L'annuncio di settembre di Advanced AI Society definisce il rilascio una “bozza di lavoro v1.0” e afferma che i commenti pubblici resteranno aperti fino al 30 ottobre 2026. La sua pagina più dettagliata sullo standard identifica il documento come “Working Draft v0.1” e indica il 7 ottobre come scadenza per i commenti.

Anche la descrizione dell'evento della Linux Foundation lo definisce Proof-of-Control v0.1. Queste differenze potrebbero riflettere pubblicazioni non sincronizzate, un piano di rilascio modificato o etichette separate per artefatti correlati. Qualunque sia il motivo, l'ambiguità su versione e scadenza è rilevante per i contributori che decidono cosa esaminare.

Uno standard dipende da identificatori stabili. Gli implementatori devono sapere quali requisiti normativi si applicano, se un vettore di test corrisponde al testo corrente e quando si è verificata una modifica incompatibile. I revisori non possono valutare la conformità rispetto a un'etichetta in continuo cambiamento.

Questo non invalida l'obiettivo del progetto. Dimostra perché repository neutrali, tag di rilascio, registri delle modifiche e tracciamento pubblico delle issue sono importanti. Uno standard aperto deve rendere verificabile la propria provenienza prima di chiedere ai fornitori di agenti di fare lo stesso.

Il briefing pubblico previsto si terrà il 23 settembre. Riunisce leader della Linux Foundation, rappresentanti di Advanced AI Society, investitori nel settore della sicurezza, fornitori di identità, assicuratori e l'Agentic AI Foundation.

L'evento può chiarire la governance, ma la sola discussione pubblica non risolverà l'incertezza tecnica. I contributori hanno bisogno di una specifica normativa, di un modello di minaccia esplicito, di test di conformità e di implementazioni riproducibili. Hanno inoltre bisogno di un processo per decidere quali meccanismi soddisfano ciascun requisito.

Il progetto afferma che il suo repository include un'implementazione di riferimento, definizioni di affermazioni leggibili dalle macchine, scenari di attacco e vettori di test firmati. Descrive l'implementazione come riferimento anziché come prodotto destinato alla produzione. Questo avvertimento è importante perché il codice iniziale può dimostrare la fattibilità senza soddisfare i requisiti di sicurezza operativa.

Un gateway di riferimento può mostrare come valutare una policy e creare evidenze firmate. Un gateway di produzione deve anche resistere a furto di credenziali, condizioni di competizione, tentativi di replay, telemetria incompleta, compromissione delle chiavi, guasti dell'infrastruttura e operatori ostili.

La completezza crea un altro problema difficile. I registri a prova di manomissione possono dimostrare che le voci registrate non sono state alterate. Non possono, da soli, provare che ogni azione rilevante sia entrata nel registro. Un agente dotato di un percorso non monitorato potrebbe agire fuori registro mentre la catena di evidenze visibile resta internamente coerente.

Il livello più rigoroso proposto da Advanced AI Society affronta il problema attraverso il controllo dell'esecuzione. In questo modello, un'azione coperta non può verificarsi se non passa attraverso il controllo e non produce evidenze. Resta da stabilire se ogni azione rilevante sia davvero coperta.

Anche gli effetti esterni complicano il quadro. Un gateway può verificare che un agente abbia inviato una richiesta di pagamento autorizzata. Non può dimostrare automaticamente che una banca abbia regolato il pagamento esattamente come previsto. L'assurance deve collegare le evidenze dal lato dell'agente alle ricevute dei sistemi esterni.

Le catene di identità introducono rischi analoghi. Un agente può delegare il lavoro a un altro, che poi chiama un servizio di terze parti. Ogni passaggio può modificare autorità, contesto o esposizione dei dati. Uno standard credibile deve preservare l'attribuzione senza presumere che un singolo token di identità spieghi l'intera catena.

La qualità del controllo rimane il maggiore limite concettuale. Proof-of-Control evita esplicitamente di giudicare se una regola scelta fosse saggia. Questa separazione rende gestibile la conformità tecnica, ma le organizzazioni potrebbero commercializzare la conformità come una prova più ampia di sicurezza.

Gli acquirenti dovrebbero resistere a questa scorciatoia. Un agente verificato può seguire fedelmente una policy non sicura. Può anche produrre azioni autorizzate basate su un ragionamento errato del modello. La verifica in fase di esecuzione integra test, supervisione umana, analisi del rischio e risposta agli incidenti. Non li sostituisce.

L'affermazione più responsabile del progetto è quindi quella circoscritta. Mira a migliorare le evidenze sul fatto che i controlli dichiarati abbiano governato le azioni coperte. Le affermazioni sulla completa sicurezza degli agenti, sulla conformità normativa o sull'eliminazione della responsabilità andrebbero oltre ciò che tali evidenze dimostrano.

Lo standard deve dimostrare di funzionare su stack di agenti reali

L'adozione dipenderà dal fatto che Proof-of-Control possa operare su modelli ospitati, sistemi locali e flussi di lavoro multi-fornitore senza creare un ulteriore livello isolato di conformità.

Gli stack di agenti aziendali raramente provengono da un unico fornitore. Un'azienda può utilizzare un modello ospitato, un framework interno di orchestrazione, un fornitore di identità terzo, database cloud e strumenti specialistici di diversi vendor. Ogni livello espone controlli e telemetria differenti.

Proof-of-Control afferma che il suo modello di confine delle azioni può funzionare in configurazioni aperte e chiuse. Il fornitore del modello non deve necessariamente rivelare i propri pesi o dati di addestramento. Il livello di verifica osserva invece le azioni controllate quando il sistema di orchestrazione invoca capacità esterne.

Questo approccio favorisce le organizzazioni che controllano il proprio ciclo dell'agente. Possono inserire un gateway, limitare le credenziali e instradare le chiamate agli strumenti attraverso un confine definito. Un servizio di agenti gestito è più difficile da verificare perché il fornitore controlla l'ambiente di orchestrazione e decide quali evidenze esporre.

Questa differenza trasforma l'architettura in un criterio di acquisto. I clienti che valutano un agente gestito devono chiedersi se emetta evidenze verificabili in modo indipendente, se le evidenze coprano ogni chiamata agli strumenti rilevante e se un operatore possa aggirare il percorso dichiarato.

Un team finanziario offre un test concreto. Si supponga che un agente prepari fatture, aggiorni i registri contabili e avvii bonifici bancari. Il sistema di verifica deve distinguere tra la lettura di un libro mastro, la proposta di un pagamento, l'ottenimento dell'approvazione e l'invio dell'istruzione finale.

Ogni azione necessita di un'identità, una fonte di autorità, una policy applicabile, un riferimento temporale e un risultato. Il sistema deve preservare questa catena tra gli strumenti senza far trapelare dati contabili in un registro pubblico di verifica. Deve inoltre gestire un'approvazione revocata o una modifica della policy durante l'esecuzione.

Un agente di ingegneria del software crea un test diverso. Può ispezionare codice privato, modificare file, eseguire test e richiedere una distribuzione. Proof-of-Control potrebbe verificare a quale repository l'agente abbia avuto accesso e se la distribuzione abbia richiesto un'approvazione nominativa.

Lo standard dovrebbe comunque considerare gli effetti indiretti. Il codice che supera un controllo di autorizzazione può in seguito esporre dati o modificare il comportamento in produzione. Le evidenze in fase di esecuzione mostrano come l'agente abbia attraversato un confine, mentre la revisione del software e i test di sicurezza valutano l'artefatto prodotto.

L'assistenza sanitaria mette alla prova privacy e autorità professionale. Un agente potrebbe recuperare la cartella di un paziente sotto la delega di un medico e inviare un ordine in bozza per l'approvazione. Le evidenze devono dimostrare che l'accesso è rimasto entro l'autorizzazione senza divulgare le informazioni mediche sottostanti.

Questi scenari richiedono più di un generico registro firmato. Richiedono semantiche comuni per identità, autorizzazioni, valutazione delle policy, conservazione delle evidenze e comportamento in caso di errore. Un record che un verificatore interpreta diversamente da un altro non crea interoperabilità.

I test di conformità determineranno quindi la credibilità del progetto. Team indipendenti dovrebbero poter eseguire la stessa suite di test su implementazioni separate e ottenere risultati coerenti. I test negativi dovrebbero mostrare come i sistemi falliscono quando i record vengono alterati, le azioni aggirano il gateway o l'autorità scade.

Anche le prestazioni conteranno. Gli agenti spesso effettuano diverse chiamate agli strumenti durante un singolo compito. La generazione continua di evidenze aggiunge lavoro di firma, archiviazione, verifica e valutazione delle policy. Le imprese avranno bisogno di dati su latenza e operatività provenienti da distribuzioni rappresentative.

I materiali pubblici di Proof-of-Control sottolineano la verifica alla velocità delle macchine perché la revisione umana non può eguagliare l'esecuzione degli agenti. Questa premessa è ragionevole, ma l'automazione può anche ripetere una regola difettosa alla velocità delle macchine. Le modifiche ai controlli devono quindi essere governate con la stessa cura delle modifiche al codice.

La proprietà operativa è un'altra questione aperta. I team di sicurezza possono definire policy di base, i team applicativi possono integrare gateway, i team di identità possono gestire le deleghe e i team di conformità possono conservare le evidenze. Uno standard che presuppone un unico proprietario unificato incontrerà difficoltà nelle grandi organizzazioni.

Il progetto può comunque riuscire senza diventare l'unico standard di sicurezza per gli agenti. Il suo modello di evidenze potrebbe informare le linee guida NIST, le API dei fornitori, i questionari assicurativi o i modelli di approvvigionamento. Concetti condivisi possono influenzare il mercato anche quando le implementazioni variano.

Il rischio maggiore è l'adozione cerimoniale. I fornitori potrebbero dichiarare l'allineamento coprendo solo azioni selezionate oppure usare il linguaggio della verifica aperta senza fornire test indipendenti. Livelli di conformità chiari e requisiti verificabili dalle macchine possono ridurre questo comportamento.

Tre segnali decideranno se la verifica aperta diventerà infrastruttura

I prossimi tre test sono la coerenza della specifica, l'implementazione indipendente e l'adozione normativa.

Il primo segnale sarà se Advanced AI Society risolverà i conflitti nella bozza relativi alle scadenze per versioni e commenti. Un tag di rilascio pubblico dovrebbe collegare il testo normativo, gli schemi, i vettori di test, l’implementazione di riferimento e la cronologia delle modifiche.

Questo passaggio rafforzerebbe l’argomento centrale del progetto. La provenienza verificabile dovrebbe iniziare dallo standard stesso. Se gli artefatti resteranno etichettati in modo incoerente, le imprese esiteranno a costruire controlli o contratti attorno a essi.

Il secondo segnale è l’implementazione indipendente. Il codice di riferimento dell’organizzazione fondatrice può dimostrare che i suoi autori hanno costruito ciò che hanno descritto. Un team separato deve dimostrare che la specifica comunica dettagli sufficienti per produrre evidenze e risultati di verifica compatibili.

I report di implementazione utili dovrebbero documentare i fallimenti oltre ai successi. Dovrebbero identificare latenza, onere di integrazione, framework per agenti non supportati, vincoli di privacy e qualsiasi percorso di aggiramento scoperto durante i test. Le affermazioni sulla produzione richiedono evidenze provenienti da ambienti esterni al controllo diretto degli autori.

Il terzo segnale è il modo in cui NIST e il Congresso definiranno i requisiti di verifica degli agenti. Se le linee guida federali richiederanno inventari continui, registri resistenti alle manomissioni, identità attribuibili e controlli testabili in modo indipendente, Proof-of-Control risponderà a un’esigenza di approvvigionamento riconoscibile.

Il progetto acquisirebbe ulteriore slancio se i contraenti federali o gli acquirenti regolamentati richiedessero evidenze portabili anziché screenshot dei fornitori. Tale requisito premierebbe l’interoperabilità e creerebbe spazio per più fornitori di verifica.

L’esito opposto indebolirebbe l’argomento a favore di un ecosistema condiviso. Le agenzie potrebbero accettare log convenzionali e audit periodici, oppure il Congresso potrebbe non far avanzare la legislazione sottostante. Le imprese potrebbero quindi trattare la verifica aperta come un esperimento di sicurezza facoltativo.

Il più ampio dibattito di Washington sull’AI resta irrisolto. I leader del Congresso hanno discusso di misure di protezione, sottolineando al contempo un approccio normativo leggero e la competizione con la Cina. Questa tensione rende gli standard tecnici mirati più plausibili di un’unica legge organica sull’AI.

La distinzione tra legislazione e promulgazione deve restare chiara. La proposta della Camera sulla sicurezza degli agenti non è una politica federale consolidata. L’iniziativa esistente del NIST è attiva, ma le sue linee guida finali e gli effetti sul mercato sono ancora in evoluzione.

Advanced AI Society dispone quindi di una finestra ristretta per influenzare il vocabolario emergente. Se riuscirà a dimostrare controlli implementabili prima che le regole di approvvigionamento si irrigidiscano, le sue definizioni potrebbero plasmare il modo in cui gli acquirenti descrivono l’affidabilità a runtime.

Gli sviluppatori dovrebbero osservare se i framework comuni per agenti aggiungeranno supporto nativo per evidenze portabili. Gli acquirenti aziendali dovrebbero chiedere ai fornitori di identificare ogni azione controllata e qualsiasi percorso che aggiri l’applicazione delle regole. I team di sicurezza dovrebbero confrontare l’integrità delle evidenze con la loro completezza.

Anche i lavoratori della conoscenza hanno un interesse in gioco. Un agente che agisce sulle email, sui documenti, sul calendario o sui conti finanziari di una persona può generare conseguenze prima che l’utente le esamini. Gli utenti necessitano di una registrazione comprensibile dell’autorità concessa e di ciò che l’agente ha fatto con essa.

L’iniziativa Proof-of-Control di Advanced AI Society offre una risposta seria a questa necessità, ma resta una bozza preliminare. Il suo valore deriverà da interoperabilità testata, ambito preciso ed evidenze che resistano all’esame di soggetti diversi dai suoi creatori.

Il prossimo passo corretto non è presumere che lo standard risolva la sicurezza degli agenti. Acquirenti e sviluppatori dovrebbero esaminare la bozza, testare il requisito di assenza di aggiramenti e presentare fallimenti concreti di implementazione durante la revisione pubblica. La verifica aperta diventa infrastruttura solo quando partecipanti indipendenti possono riprodurne le affermazioni e identificarne i limiti.