Linux Foundation uruchamia Agent Name Service dla tożsamości agentów AI

Linux Foundation ogłosiła 10 listopada 2026 r., że Agent Name Service (ANS) oficjalnie rozpoczął działalność jako projekt fundacji, zapewniając agentom AI tożsamość opartą na domenach, możliwość ich odnajdywania i uwierzytelnianie dzięki otwartej specyfikacji oraz narzędziom o otwartym kodzie źródłowym.

ANS ma umożliwić systemowi ustalenie, z którym zarejestrowanym agentem ma do czynienia, zanim zastosuje własne zasady bezpieczeństwa. Wiąże nazwę z określoną wersją z domeną kontrolowaną przez operatora agenta, wykorzystuje Domain Name System (DNS) do publikowania informacji o odnajdywaniu agentów oraz zapisuje podpisane zdarzenia cyklu życia w dzienniku przejrzystości. Rozwiązanie wykorzystuje istniejącą infrastrukturę internetową zamiast wymagać jednego, zastrzeżonego rejestru agentów.

Uruchomienie projektu przekształca ogłoszony przez fundację 23 czerwca 2026 r. zamiar w projekt objęty nadzorem. Fundacja informuje, że od tego czasu 11 organizacji zaangażowało się w rozwój ANS lub go przyjęło: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP i Trustmodel.ai.

Jak przebiegają rejestracja i uwierzytelnianie w ANS

Siedmiowarstwowa specyfikacja obejmuje tożsamość, rejestrację, nazewnictwo z oznaczeniem wersji, publikowanie w DNS, przejrzystość, monitorowanie integralności i uwierzytelnianie agentów. Nazwa ANS wiąże wersję z domeną, jak w przykładzie ans://v1.0.0.payments.example.com; nowa wersja wymaga nowej rejestracji.

Podczas rejestracji operator przekazuje Urzędowi Rejestracji adres hosta agenta, wersję, punkty końcowe i dane certyfikatu. Urząd weryfikuje kontrolę nad domeną oraz wymagane dowody. Operator publikuje otrzymane rekordy DNS, a urząd sprawdza je przed aktywacją. Następnie podpisuje zdarzenie cyklu życia i zleca jego opieczętowanie przez Dziennik Przejrzystości, tworząc publiczne artefakty wiążące rejestrację z autoryzowanymi certyfikatami.

Inne podmioty korzystają z obsługiwanego profilu odnajdywania, aby znaleźć punkty końcowe oraz wspólny _ans-badge rekord, w którym można znaleźć dowody z dziennika przejrzystości. Samo odnalezienie agenta nie uwierzytelnia wywołującego. Uwierzytelnienie wymaga trzech kontroli: certyfikat jest powiązany z zarejestrowaną tożsamością, rejestracja pozostaje ważna, a wywołujący posiada odpowiadający jej klucz prywatny.

Projekt specyfikacji uwierzytelniania ANS-6 traktuje równorzędnie wzajemne uwierzytelnianie TLS (mTLS) i działający w warstwie aplikacji dowód posiadania (DPoP). mTLS sprawdza się w połączeniu TLS od końca do końca, natomiast DPoP wiąże jednorazowy dowód z żądaniem HTTP i może działać także w przypadku bram kończących połączenie TLS. Weryfikator poziomu odznaki odpytuje Dziennik Przejrzystości o aktualne dowody; wariant SCITT weryfikuje lokalnie potwierdzenie i token statusu, bez połączeń sieciowych przy każdym żądaniu. DPoP wymaga powiązania SCITT.

Oprogramowanie i wczesna interoperacyjność

Dostępne oprogramowanie obejmuje referencyjną implementację Urzędu Rejestracji, Dziennika Przejrzystości i weryfikatora działającego bez połączenia z siecią, napisaną w Go, a także zestawy SDK dla Go, Rust i Java, różniące się interfejsami API i zakresem funkcji. To ans-cli narzędzie obsługuje rejestrację, odnajdywanie agentów, zarządzanie certyfikatami i zapytania do Dziennika Przejrzystości w systemach macOS, Linux i Windows. Lokalny przewodnik szybkiego uruchomienia wykorzystuje klucze deweloperskie oraz weryfikator noop DNS, co oznacza, że pozytywny wynik kontroli potwierdzenia nie sprawdza publicznego DNS, wystawiania certyfikatów w środowisku produkcyjnym ani działającego wdrożenia.

W kwestii interoperacyjności Linux Foundation informuje, że Agent Directory Service projektu AGNTCY obsługuje weryfikację tożsamości ANS, a ANS Finder implementuje Agentic Resource Discovery (ARD) i pomyślnie przechodzi testy zgodności z jego rejestrem. Własna specyfikacja ARD dotyczy odnajdywania agentów przed ich wywołaniem, a nie ich działania, i dopuszcza wiele usług odnajdywania o różnych zasadach zaufania, rankingu i dostępu, zamiast narzucać centralny katalog. Prace te łączą weryfikowalne dowody tożsamości z odnajdywaniem agentów, nie tworząc uniwersalnego katalogu agentów.

Projekty specyfikacji i granice bezpieczeństwa

Początkowy komitet techniczny ma pięciu członków z prawem głosu: Scotta Courtneya, Keitha Perry’ego i Connora Snitkera z GoDaddy, Kena Huanga z DistributedApps.AI oraz Michaela Kantora z Hashgraph Online. Komitet wyznacza kierunek techniczny, a opiekunowie repozytorium weryfikują zmiany, zarządzają wydaniami i obsługują zgłoszenia dotyczące bezpieczeństwa. Choć w informacji o uruchomieniu projektu specyfikację określono jako sformalizowaną, dokumentacja projektu oznacza opublikowane specyfikacje jako projekty będące w aktywnym rozwoju; ANS-6 ma status DRAFT v1.0, wersję 0.2.0 i datę 3 listopada 2026 r.

Model bezpieczeństwa ustanawia tożsamość, a nie uprawnienia. Autoryzacja, delegowanie uprawnień w łańcuchu wywołań i ocena poziomu zaufania nie wchodzą w zakres ANS-6, więc każda aplikacja samodzielnie decyduje, co uwierzytelniony agent może robić. Opieczętowane skróty metadanych nie poświadczają kodu działającego na zdalnym komputerze ani nie gwarantują zachowania agenta, a klienci nadal potrzebują zaufanych kluczy dziennika, prawidłowej weryfikacji podpisów i dowodów, kontroli aktualności danych oraz procedury postępowania w razie błędu. Publiczne odznaki, potwierdzenia i tokeny statusu można również odtworzyć, jeśli weryfikator pomija sprawdzenie posiadania klucza.

Potwierdzenie dowodzi historii wpisu w logu, a nie jego aktualnej ważności, i może nadal przechodzić weryfikację po unieważnieniu agenta, dlatego należy je łączyć z bieżącym sprawdzeniem statusu. Dojrzałość integracji również jest zróżnicowana. Prace nad NVIDIA OpenShell oznaczono jako wersję poglądową do celów badawczych, a kontrole rejestracji miejsca docelowego nie implementują wiązania ANS-6 z rzeczywistym certyfikatem TLS peera.

ANS ma już strukturę zarządzania w ramach fundacji, opublikowane projekty specyfikacji i implementacje referencyjne. Praktyczna wartość systemu dla bezpieczeństwa zależy od tego, czy wdrożenia łącznie egzekwują weryfikację tożsamości, aktualnego statusu i posiadania klucza, a jednocześnie pozostawiają autoryzację i ocenę zachowania agenta poza zakresem deklaracji tożsamości.