Linux Foundation lancia Agent Name Service per l’identità degli agenti IA

Linux Foundation ha annunciato il 10 novembre 2026 che Agent Name Service (ANS) è stato ufficialmente avviato come progetto della fondazione, portando agli agenti IA identità ancorate a domini, funzionalità di individuazione e autenticazione attraverso una specifica aperta e strumenti open source.

ANS è progettato per consentire a un sistema di stabilire con quale agente registrato sta interagendo prima di applicare le proprie politiche di sicurezza. Associa un nome versionato a un dominio controllato dall’operatore dell’agente, utilizza il Domain Name System (DNS) per pubblicare informazioni di individuazione e registra gli eventi del ciclo di vita firmati in un registro di trasparenza. Questo approccio riutilizza l’infrastruttura Internet esistente, senza richiedere un unico registro proprietario degli agenti.

Il lancio trasforma in un progetto sottoposto a governance l’annuncio d’intenti della fondazione del 23 giugno 2026. La fondazione afferma che da allora 11 organizzazioni hanno contribuito ad ANS o lo hanno adottato: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP e Trustmodel.ai.

Come funzionano la registrazione e l’autenticazione di ANS

La specifica a sette livelli copre identità, registrazione, denominazione versionata, pubblicazione DNS, trasparenza, monitoraggio dell’integrità e autenticazione degli agenti. Un nome ANS associa una versione a un dominio, come in ans://v1.0.0.payments.example.com; una nuova versione richiede una nuova registrazione.

Durante la registrazione, l’operatore invia all’Autorità di registrazione l’host dell’agente, la versione, gli endpoint e il materiale relativo ai certificati; l’autorità verifica il controllo del dominio e le prove richieste. L’operatore pubblica i record DNS restituiti e l’autorità li controlla prima dell’attivazione. Quindi firma l’evento del ciclo di vita e ne affida la sigillatura al registro di trasparenza, producendo artefatti pubblici che associano la registrazione ai certificati autorizzati.

I peer utilizzano un profilo di individuazione supportato per trovare gli endpoint e il _ans-badge record condiviso per reperire le prove di trasparenza. La sola individuazione non autentica il chiamante. L’autenticazione richiede tre verifiche: il certificato è associato all’identità registrata, la registrazione è ancora valida e il chiamante possiede la corrispondente chiave privata.

La bozza di autenticazione ANS-6 attribuisce pari importanza a TLS reciproco (mTLS) e alla dimostrazione applicativa del possesso (DPoP). mTLS è adatto a un percorso TLS end-to-end, mentre DPoP associa una prova monouso a una richiesta HTTP e può funzionare anche attraverso gateway che terminano TLS. Un verificatore di livello badge interroga il registro di trasparenza per ottenere prove aggiornate; il livello SCITT verifica localmente una ricevuta e un token di stato, senza effettuare chiamate di rete per ogni richiesta. DPoP richiede il binding SCITT.

Software e prime interoperabilità

Il software disponibile include un’implementazione di riferimento in Go dell’Autorità di registrazione, del registro di trasparenza e di un verificatore offline, oltre a SDK per Go, Rust e Java con API e copertura delle funzionalità differenti. Il ans-cli lo strumento supporta la registrazione, l’individuazione, la gestione dei certificati e le interrogazioni del registro di trasparenza su macOS, Linux e Windows. La guida rapida per l’uso locale utilizza chiavi di sviluppo e un noop verificatore DNS; ciò significa che il superamento del controllo della ricevuta non verifica il DNS pubblico, l’emissione di certificati di produzione né una distribuzione attiva.

Sul fronte dell’interoperabilità, Linux Foundation riferisce che Agent Directory Service di AGNTCY supporta la verifica delle identità ANS e che ANS Finder implementa Agentic Resource Discovery (ARD) e supera i test di conformità del relativo registro. La specifica di ARD riguarda l’individuazione prima dell’invocazione, non l’esecuzione, e consente la presenza di numerosi servizi di individuazione con politiche diverse in materia di fiducia, classificazione e accesso, anziché prescrivere un catalogo centrale. Questo lavoro collega le prove verificabili dell’identità all’individuazione senza creare un registro universale degli agenti.

Specifiche in bozza e limiti di sicurezza

Il comitato tecnico direttivo iniziale ha cinque membri con diritto di voto: Scott Courtney, Keith Perry e Connor Snitker di GoDaddy, Ken Huang di DistributedApps.AI e Michael Kantor di Hashgraph Online. Il comitato definisce l’indirizzo tecnico, mentre i responsabili dei repository esaminano le modifiche, gestiscono le release e si occupano delle segnalazioni di sicurezza. Sebbene il comunicato di lancio descriva la specifica come formalizzata, la documentazione del progetto classifica le specifiche pubblicate come bozze in fase di sviluppo attivo; ANS-6 è contrassegnata come DRAFT v1.0, versione 0.2.0, datata 3 novembre 2026.

Il modello di sicurezza stabilisce l’identità, non i permessi. L’autorizzazione, la delega lungo una catena di chiamate e il punteggio di fiducia non rientrano nell’ambito di ANS-6; spetta quindi a ciascuna applicazione decidere cosa può fare un agente autenticato. I digest dei metadati sigillati non attestano il codice in esecuzione su una macchina remota né garantiscono il comportamento dell’agente; i client devono comunque disporre di chiavi attendibili per i registri, verificare correttamente firme e prove, controllare l’attualità dei dati e definire una politica di gestione degli errori. Anche i badge pubblici, le ricevute e i token di stato possono essere riprodotti se il verificatore omette il controllo del possesso.

Una ricevuta dimostra la cronologia del registro, non la validità attuale, e può continuare a essere verificata anche dopo la revoca di un agente; deve quindi essere accompagnata da un controllo dello stato aggiornato. Anche il livello di maturità delle integrazioni varia. Il lavoro su NVIDIA OpenShell è presentato come un’anteprima di ricerca e i suoi controlli di registrazione della destinazione non implementano l’associazione prevista da ANS-6 al certificato TLS effettivo del peer.

ANS dispone ora di una governance affidata a una fondazione, bozze pubblicate e implementazioni di riferimento. Il valore pratico in termini di sicurezza dipende dal fatto che le implementazioni facciano rispettare congiuntamente l’identità, lo stato aggiornato e il possesso della chiave, lasciando al di fuori dell’attestazione d’identità l’autorizzazione e le valutazioni sul comportamento dell’agente.