Linux Foundation lancerer Agent Name Service til identifikation af AI-agenter

Linux Foundation meddelte den 10. november 2026, at Agent Name Service (ANS) officielt er lanceret som et projekt under fonden. Tjenesten giver AI-agenter identitet, der er knyttet til domæner, samt mulighed for opdagelse og godkendelse gennem en åben specifikation og open source-værktøjer.

ANS er udviklet til at lade et system fastslå, hvilken registreret agent det kommunikerer med, før det anvender sin egen sikkerhedspolitik. Tjenesten knytter et versionsnummereret navn til et domæne, som agentens operatør kontrollerer, bruger Domain Name System (DNS) til at offentliggøre oplysninger, der gør det muligt at finde agenten, og registrerer underskrevne hændelser i agentens livscyklus i en gennemsigtighedslog. Tilgangen genbruger eksisterende internetinfrastruktur i stedet for at kræve ét proprietært agentregister.

Lanceringen fører fondens hensigtserklæring af 23. juni 2026 videre som et projekt med en formel styringsstruktur. Fonden oplyser, at 11 organisationer har bidraget til eller taget ANS i brug siden da: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP og Trustmodel.ai.

Sådan fungerer registrering og godkendelse med ANS

Specifikationen med syv lag omfatter identitet, registrering, versionsnummererede navne, offentliggørelse via DNS, gennemsigtighed, integritetsovervågning og godkendelse af agenter. Et ANS-navn knytter en version til et domæne, som i ans://v1.0.0.payments.example.com; en ny version kræver en ny registrering.

Ved registrering indsender operatøren agentens vært, version, endepunkter og certifikatoplysninger til en registreringsmyndighed, som kontrollerer domænekontrollen og de påkrævede beviser. Operatøren offentliggør de returnerede DNS-poster, og myndigheden kontrollerer dem, før registreringen aktiveres. Derefter underskriver myndigheden hændelsen i agentens livscyklus og får gennemsigtighedsloggen til at forsegle den. Det skaber offentligt tilgængelige artefakter, der knytter registreringen til godkendte certifikater.

Modparter bruger en understøttet profil til tjenesteopdagelse til at finde endepunkter og den fælles _ans-badge post for at finde dokumentation i gennemsigtighedsloggen. Opdagelse alene godkender ikke den, der foretager opkaldet. Godkendelse kræver tre kontroller: Certifikatet er knyttet til den registrerede identitet, registreringen stadig er gyldig, og den, der foretager opkaldet, har den tilhørende private nøgle.

Udkastet til ANS-6 om godkendelse sidestiller gensidig TLS (mTLS) og Demonstrating Proof of Possession (DPoP) på applikationslaget. mTLS egner sig til en TLS-forbindelse fra ende til ende, mens DPoP knytter et engangsbevis til en HTTP-anmodning og kan fungere via gateways, der afslutter TLS-forbindelsen. En kontrollør på badgeniveau henter aktuelle beviser fra gennemsigtighedsloggen, mens SCITT-niveauet lokalt kontrollerer en kvittering og et statustoken uden netværkskald for hver anmodning. DPoP kræver SCITT-tilknytningen.

Software og tidlig interoperabilitet

Den tilgængelige software omfatter en referencemimplementering af registreringsmyndigheden, gennemsigtighedsloggen og en offlinekontrollør i Go samt SDK’er i Go, Rust og Java med forskellige API’er og forskellig funktionsdækning. Det ans-cli værktøj understøtter registrering, opdagelse, certifikathåndtering og forespørgsler til gennemsigtighedsloggen på macOS, Linux og Windows. Den lokale hurtigstartguide bruger udviklingsnøgler og en noop DNS-kontrollør, hvilket betyder, at en godkendt kvitteringskontrol ikke tester offentlig DNS, udstedelse af produktionscertifikater eller en aktiv implementering.

Hvad angår interoperabilitet, oplyser Linux Foundation, at AGNTCYs Agent Directory Service understøtter kontrol af ANS-identiteter, og at ANS Finder implementerer Agentic Resource Discovery (ARD) og består ARD’s overensstemmelsestest for registre. ARD’s egen specifikation omhandler opdagelse før igangsættelse, ikke udførelse, og tillader mange opdagelsestjenester med forskellige politikker for tillid, rangering og adgang i stedet for at foreskrive et centralt katalog. Arbejdet forbinder verificerbare identitetsbeviser med opdagelse uden at oprette et universelt agentregister.

Specifikationsudkast og sikkerhedsgrænser

Den første tekniske styrekomité har fem stemmeberettigede medlemmer: Scott Courtney, Keith Perry og Connor Snitker fra GoDaddy, Ken Huang fra DistributedApps.AI samt Michael Kantor fra Hashgraph Online. Komitéen fastlægger den tekniske retning, mens vedligeholderne af kodearkivet gennemgår ændringer, håndterer udgivelser og behandler sikkerhedsrapporter. Selvom udgivelsesmeddelelsen beskriver specifikationen som formaliseret, betegner projektets dokumentation de offentliggjorte specifikationer som udkast under aktiv udvikling. ANS-6 er markeret DRAFT v1.0, version 0.2.0, dateret 3. november 2026.

Sikkerhedsmodellen fastslår identitet, ikke tilladelser. Autorisation, delegering gennem en kæde af opkald og tillidsscore er uden for ANS-6’s rammer, så det er op til den enkelte applikation at afgøre, hvad en godkendt agent må gøre. Forseglede metadataaftryk attesterer ikke kode, der kører på en fjernmaskine, og garanterer ikke agentens adfærd. Klienter har desuden stadig brug for betroede lognøgler, korrekt kontrol af underskrifter og beviser, kontrol af aktualitet og en politik for håndtering af fejl. Offentlige badgemarkeringer, kvitteringer og statustokens kan også genafspilles, hvis kontrolløren undlader at kontrollere, at beviset er i brugerens besiddelse.

En kvittering dokumenterer loghistorikken, ikke den aktuelle gyldighed, og kan fortsat verificeres, efter at en agent er blevet tilbagekaldt. Derfor skal den suppleres med et aktuelt statustjek. Integrationsmodenheden varierer også. NVIDIA OpenShell-arbejdet betegnes som en forskningsforhåndsvisning, og dets kontroller af destinationsregistrering implementerer ikke ANS-6-binding til TLS-modpartens faktiske certifikat.

ANS har nu en fondbaseret styringsmodel, offentliggjorte udkast og referenceimplementeringer. Den praktiske sikkerhedsværdi afhænger af, at implementeringer håndhæver identitet, aktuel status og besiddelse af nøglen samlet, samtidig med at autorisation og vurderinger af agentens adfærd holdes uden for identitetserklæringen.