Моделі та платформи ШІ
Linux Foundation запускає службу імен агентів для ідентифікації ШІ-агентів
Додайте Unite.AI до бажаних джерел у Google
Linux Foundation оголосила 10 листопада 2026 року про офіційний запуск Agent Name Service (ANS) як проєкту фонду. Відкрита специфікація та інструменти з відкритим кодом забезпечують ШІ-агентам прив’язану до домену ідентичність, виявлення та автентифікацію.
ANS розроблено для того, щоб система могла встановити, з яким зареєстрованим агентом вона взаємодіє, перш ніж застосовувати власну політику безпеки. Служба прив’язує версійоване ім’я до домену, контрольованого оператором агента, використовує Domain Name System (DNS) для публікації інформації про виявлення та записує підписані події життєвого циклу в журнал прозорості. Такий підхід повторно використовує наявну інтернет-інфраструктуру, а не вимагає єдиного пропрієтарного реєстру агентів.
Цей запуск перетворює оголошений фондом 23 червня 2026 року намір на керований проєкт. За словами фонду, відтоді до ANS долучилися або впровадили його 11 організацій: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP і Trustmodel.ai.
Як працюють реєстрація та автентифікація в ANS
Специфікація з семи рівнів охоплює ідентичність, реєстрацію, версійоване найменування, публікацію DNS-записів, прозорість, моніторинг цілісності та автентифікацію агентів. Ім’я ANS прив’язує версію до домену, наприклад ans://v1.0.0.payments.example.com; для нової версії потрібна нова реєстрація.
Під час реєстрації оператор передає хост агента, версію, кінцеві точки та дані сертифіката Реєстраційному органу, який перевіряє контроль над доменом і необхідні докази. Оператор публікує отримані DNS-записи, а орган перевіряє їх перед активацією. Потім він підписує подію життєвого циклу та передає її до Журналу прозорості для опечатування, унаслідок чого створюються загальнодоступні артефакти, що пов’язують реєстрацію з авторизованими сертифікатами.
Вузли-партнери використовують підтримуваний профіль виявлення, щоб знаходити кінцеві точки та спільний _ans-badge запис для пошуку доказів у журналі прозорості. Самого виявлення недостатньо для автентифікації клієнта. Автентифікація передбачає три перевірки: сертифікат прив’язаний до зареєстрованої ідентичності, реєстрація залишається чинною, а клієнт має відповідний закритий ключ.
Проєкт специфікації автентифікації ANS-6 надає однаковий статус взаємному TLS (mTLS) і доказу володіння на рівні застосунку (DPoP). mTLS підходить для наскрізного з’єднання TLS, тоді як DPoP прив’язує одноразовий доказ до HTTP-запиту й може працювати через шлюзи, що завершують TLS-з’єднання. Верифікатор рівня бейджа запитує в Журналу прозорості актуальні докази; рівень SCITT перевіряє квитанцію й токен статусу локально, без мережевих запитів для кожного запиту. Для DPoP потрібна прив’язка SCITT.
Програмне забезпечення та початковий етап сумісності
Доступне програмне забезпечення охоплює еталонну реалізацію Реєстраційного органу, Журналу прозорості та автономного верифікатора мовою Go, а також SDK для Go, Rust і Java з різними API та обсягом підтримуваних функцій. Цей ans-cli інструмент підтримує реєстрацію, виявлення, керування сертифікатами та запити до Журналу прозорості в macOS, Linux і Windows. Локальна інструкція для швидкого запуску використовує ключі для розробки та noop верифікатор DNS, а це означає, що успішна перевірка квитанції не перевіряє загальнодоступний DNS, випуск сертифікатів для робочого середовища чи активне розгортання.
Щодо сумісності Linux Foundation повідомляє, що Agent Directory Service від AGNTCY підтримує перевірку ідентичностей ANS, а ANS Finder реалізує Agentic Resource Discovery (ARD) і проходить тести на відповідність вимогам реєстру. Власна специфікація ARD стосується виявлення до виклику, а не виконання, і допускає наявність багатьох служб виявлення з різними політиками довіри, ранжування та доступу, а не приписує використовувати центральний каталог. Ця робота поєднує перевірні докази ідентичності з виявленням, не створюючи універсального каталогу агентів.
Проєкти специфікацій і межі безпеки
Початковий технічний керівний комітет має п’ятьох членів із правом голосу: Scott Courtney, Keith Perry і Connor Snitker від GoDaddy, Ken Huang від DistributedApps.AI та Michael Kantor від Hashgraph Online. Комітет визначає технічний напрям, тоді як супровідники репозиторію перевіряють зміни, керують випусками та опрацьовують повідомлення про проблеми безпеки. Хоча в повідомленні про запуск специфікацію названо формалізованою, у документації проєкту опубліковані специфікації позначено як проєкти, що активно розробляються; ANS-6 має позначку DRAFT v1.0, версію 0.2.0 і дату 3 листопада 2026 року.
Модель безпеки встановлює ідентичність, а не дозволи. Авторизація, делегування в ланцюжку викликів і оцінювання довіри не входять до ANS-6, тож кожен застосунок сам вирішує, що може робити автентифікований агент. Опечатані дайджести метаданих не підтверджують, який код виконується на віддаленому комп’ютері, і не гарантують поведінки агента; клієнтам і далі потрібні довірені ключі журналу, належна перевірка підписів і доказів, перевірки актуальності та політика на випадок збоїв. Загальнодоступні бейджі, квитанції й токени статусу також можна відтворити повторно, якщо верифікатор не перевіряє володіння ключем.
Квитанція підтверджує історію журналу, а не поточну чинність, і може й надалі підтверджувати її після відкликання агента, тому її потрібно поєднувати з перевіркою поточного статусу. Зрілість інтеграцій також різниться. Розробку NVIDIA OpenShell позначено як попередню дослідницьку версію, а її перевірки реєстрації адрес призначення не реалізують прив’язування за ANS-6 до фактичного сертифіката TLS-вузла-співрозмовника.
ANS тепер має управління на рівні фонду, опубліковані проєкти специфікацій і довідкові реалізації. Практична цінність системи для безпеки залежить від того, чи забезпечують розгортання одночасну перевірку ідентичності, поточного статусу та володіння ключем, залишаючи авторизацію й оцінювання поведінки агента за межами твердження про його ідентичність.
