Linux Foundation 9 июня объявил о намерении запустить Agent Name Service, или ANS, открытый стандарт, который должен дать каждому агенту в сети проверяемое имя и упростить идентичность AI-агентов. Идея звучит почти старомодно: если интернет десятилетиями держится на DNS, почему бы не использовать ту же логику для идентификации AI-агентов. Для разработчиков и ИТ-команд это важный сигнал: рынок уже уперся не только в качество моделей, но и в банальный вопрос, как вообще понять, с каким агентом вы разговариваете и можно ли ему доверять.
Об этом сообщает The New Stack: Linux Foundation хочет превратить ANS в открытый слой именования и проверки для агентных систем. Судя по описанию, речь не о еще одном каталоге ботов и не о маркетинговом бейдже в духе «проверено кем-то где-то», а о попытке собрать инфраструктурный стандарт вокруг уже привычных интернет-механизмов. В центре конструкции DNS-подобные имена и криптографическая проверка через PKI-сертификаты. Если план сработает, агент сможет не просто назваться «умным помощником по закупкам», а доказать, что он действительно принадлежит конкретной компании, работает по заявленному адресу и поддерживает нужные сценарии взаимодействия.
Технически замысел понятен и потому интересен. У обычного веб-сервиса есть домен, DNS-запись, TLS-сертификат и более-менее ясная цепочка доверия. У AI-агентов пока чаще всего есть только красивое имя в интерфейсе и набор обещаний в документации. В реальной агентной среде этого мало: агент должен быть обнаружим, однозначно идентифицируем, а его возможности должны быть описаны в машиночитаемом виде. В исследовательском описании ANS, которое появилось еще в 2025 году, система строится как протокол-агностичный реестр: она поддерживает регистрацию и продление записей, DNS-подобное именование, разрешение по возможностям и слой адаптеров для разных агентных протоколов, включая A2A, MCP и ACP. На человеческом языке это означает простую вещь: агент можно не только найти, но и проверить, кто он, чем умеет заниматься и по какому каналу с ним безопасно разговаривать.
Почему тема всплыла именно сейчас, тоже несложно понять. Агентный рынок быстро переходит из стадии демо-роликов в стадию интеграций, где ошибки стоят денег. Если один агент инициирует платеж, второй получает доступ к CRM, а третий читает внутреннюю документацию через MCP, вопрос идентичности AI-агентов перестает быть академическим. Это уже не про «будущее интернета», а про банальную эксплуатацию: кого пускать в контур, кому доверять секреты, как ограничивать права и что логировать для аудита. Собственно, в самой логике cloud-native мира это давно известная боль. У сервисов есть service discovery, certificates, service mesh и политики доступа. У агентов все это только складывается, причем на ходу и без общего словаря.
Интересно, что ANS не возник на пустом месте. В мае 2025 года авторы одноименного препринта описали Agent Name Service как универсальный каталог для безопасного поиска и совместимости AI-агентов. А в апреле 2026-го появилась proof-of-concept реализация для Kubernetes: в демонстрационной среде на кластере из трех узлов и симуляции 50 агентов авторы показали задержку ниже 10 мс на демонстрируемых сервисных маршрутах и полную успешность сценариев развертывания. Это не production-grade сертификат качества, и сами исследователи аккуратно оговаривают ограничения, но для инфраструктурной идеи важен сам факт: концепция уже вышла за пределы слайдов и пробует приземлиться в инженерную практику.
При этом ждать магии от DNS-подхода точно не стоит. DNS хорошо решает задачу именования и маршрутизации, но плохо заменяет полноценную модель доверия сам по себе. Если агент получил красивое имя и сертификат, это еще не делает его безопасным, полезным или честным в описании своих возможностей. Нужны политики, аттестация, ограничение прав, аудит действий и нормальная интеграция с существующим IAM-стеком. Иначе рынок получит старую проблему в новой упаковке: вместо фишинговых сайтов появятся фишинговые агенты с правдоподобными именами, а вместо поддельных API — поддельные «автономные помощники». Поэтому ценность ANS не в том, что он закрывает тему, а в том, что он предлагает общий базовый слой, поверх которого уже можно строить нормальную безопасность.
Для русскоязычных команд, которые экспериментируют с агентами внутри продуктов, саппорта, продаж или внутренней автоматизации, отсюда следует вполне практичный вывод. Если ваш стек движется к multi-agent-сценариям, вопрос «как агенты находят друг друга» нельзя отделять от вопроса «как они подтверждают личность и полномочия». Идентичность AI-агентов быстро становится таким же базовым инфраструктурным элементом, как DNS для сервисов или SSO для сотрудников. Это касается не только больших платформ. Стартапам нужен способ не утонуть в хаосе интеграций, а крупным компаниям — не открыть внутренние системы без внятной модели доверия. И если Linux Foundation действительно дожмет ANS до статуса рабочего открытого стандарта, у рынка появится шанс не собирать агентную экосистему из десятка несовместимых костылей.
Главный вопрос теперь не в том, можно ли натянуть DNS-логику на AI-агентов, а в том, согласятся ли на общий слой именования сами участники рынка. С технологической стороны идея выглядит слишком рациональной, чтобы ее игнорировать. Но у индустрии плохая привычка плодить несовместимые стандарты ровно там, где всем нужен один.