MICROSOFT: ИНФРАСТРУКТУРА ДОВЕРИЯ ДЛЯ АГЕНТОВ

Ключевые цифры — 50:1 — соотношение нечеловеческих идентичностей (NHI) к человеческим пользователям в корпоративных сетях (Silverfort). — 1,3 млрд — агентов будет работать к 2028 году по прогнозу IDC. — 68% — организаций не отличают активность агента от человека (CSA & Aembit). — 74% — агенты получают больше прав, чем необходимо для выполнения задачи. — 85% — организаций уже запускают ИИ-агентов в продакшене.

Введение: от сервисного аккаунта к «цифровому работнику»

Под, функция, сервисный аккаунт — а теперь ещё и ИИ-агент. Каждый из них способен стать точкой входа. Классическое управление учётными данными здесь не масштабируется: пароли не подходят для миллиардов агентов, секреты утекают, а сервисные аккаунты живут вечно.

Microsoft предлагает эволюцию подхода: вместо того чтобы адаптировать устаревшие механизмы под агентов, компания строит отдельный слой идентичности. IDC прогнозирует 1,3 миллиарда агентов к 2028 году. При этом 68% организаций пока не могут отличить активность агента от человека. Это не просто статистика — это сигнал к тому, что классическое управление учётными данными нуждается в переосмыслении.

Если раньше проблема нечеловеческих идентичностей (NHI) решалась через субъекты-службы (service principals) и управляемые идентичности, то с появлением агентов всё усложнилось. Агент — не просто «микросервис, который вызывает API». Агент принимает решения, действует от имени пользователя, коммуницирует с другими агентами и, в перспективе, будет самостоятельно выполнять цепочки задач. Для такой сущности нужен паспорт. Microsoft предлагает целую систему регистрации.

Продуктовая линейка: что уже в эксплуатации, а что ещё в превью

Microsoft Entra Workload ID — фундамент ($3/месяц за идентичность)

Не самый новый продукт, но без него ничего не работает. «Рабочие нагрузки» (workload identities) в терминологии Microsoft — это приложения, субъекты-службы и управляемые идентичности. То есть всё то, что мы привыкли называть NHI до эпохи агентов.

Ключевое нововведение последних лет — Workload Identity Federation (WIF). Это механизм обмена внешних токенов (например, от GitHub Actions, Kubernetes OIDC или AWS STS) на токены платформы Microsoft. Без секретов, без паролей, без вечных сервисных аккаунтов.

Принцип: внешняя рабочая нагрузка аутентифицируется у своего поставщика удостоверений (IdP), получает JWT, предъявляет его Entra — и получает токен доступа для Microsoft Graph или Azure Resource Manager. Entra доверяет внешнему IdP через явно настроенные отношения доверия: вы указываете URL издателя, аудиторию и идентификатор субъекта. Никакого обмена метаданными в реальном времени — доверие статично и требует ручного обновления при смене ключей.

Техническая деталь: при настройке федерации внешний OIDC-эндпоинт ограничен 100 ключами подписи. Если ваш рабочий процесс в GitHub Actions использует ротацию ключей чаще — готовьтесь к сюрпризам.

Workload ID также получил Conditional Access, Continuous Access Evaluation и ID Protection. Машинные аккаунты теперь подчиняются тем же политикам, что и люди — с той лишь разницей, что машина не может пройти MFA, но может быть заблокирована по геолокации или уровню риска.

Microsoft Entra Agent ID — агентский паспорт (в превью)

Вот где начинается интересное. Agent ID — это полноценный объект идентичности в тенанте Entra. У него есть object ID, app ID, он виден в Graph API и участвует в политиках доступа. Но архитектура отличается от классических рабочих нагрузок.

Agent Identity Blueprint — это многоразовый шаблон, который определяет «вид» агента: какие роли он может получить, какие разрешения Graph ему доступны, какие метаданные он несёт. Шаблон может быть мультитенантным (публикуется в каталоге и используется разными организациями), а сама идентичность агента — всегда однотенантная. Шаблон универсален, паспорт — уникален для каждого тенанта.

Создание происходит через Graph API: вы генерируете шаблон, затем на его основе разворачиваете идентичность внутри тенанта. Шаблон живёт в каталоге, идентичность — в тенанте. Это разделение позволяет независимым поставщикам ПО (ISV) публиковать агентов, а корпоративным клиентам — развертывать их с собственными политиками.

Ключевой архитектурный нюанс: идентичность агента не хранит учетные данные. Вообще. Никаких секретов, сертификатов или паролей. Единственный способ аутентификации — Federated Identity Credentials (FIC). Агент должен аутентифицироваться у внешнего доверенного источника, получить токен, и только тогда обменять его на токен Entra.

Ещё один подтип — Agent User. Это особый вид пользовательской идентичности (idtyp=user), который позволяет агенту аутентифицироваться в системах, категорически требующих человеческого участия. Создаётся явно, максимум один на идентичность агента. Агент может действовать от его имени. Удобно для интеграции с устаревшим ПО (legacy), но создаёт риск: в логах агент выглядит как человек.

Agent Registry — централизованный каталог для обнаружения. Агенты регистрируются здесь, чтобы другие агенты могли их находить через MCP или A2A. Microsoft описывает это как «телефонную книгу для агентов».

На заметку архитектору Agent ID пока в превью. Microsoft не раскрывает жестких лимитов, но по аналогии с Workload ID стоит ожидать ограничений на количество FIC и частоту обмена токенами. Для боевой среды (production) — пока только оценка.

Microsoft Agent 365 — плоскость управления (GA: 1 мая 2026)

Центральный продукт для управления жизненным циклом агентов в экосистеме M365. Цена: $15 на пользователя в месяц. Входит в состав M365 E7 ($99/пользователь). Для Conditional Access нужен Entra ID P1, для ID Protection — P2. Полный стек требует лицензий премиум-уровня, что стоит учитывать при планировании бюджета.

Agent 365 интегрируется с тремя китами Microsoft: Entra (идентичность), Defender (мониторинг безопасности) и Purview (комплаенс). Обещается единая панель управления для контроля жизненного цикла агентов, аудита их действий и применения политик.

Copilot Studio + Azure AI Foundry — фабрика агентов

Каждый агент, созданный в Copilot Studio, автоматически получает идентичность в тенанте Entra. Создатель записывается как куратор (sponsor) — человек, ответственный за агента.

Это создаёт интересную юридическую ситуацию: если агент совершит ошибку, ответственность формально лежит на кураторе.

Azure AI Foundry предоставляет Agent Service с управляемой идентичностью, A2A-коннекторами и поддержкой MCP. До публикации все агенты в проекте делят общую идентичность, после публикации — каждый получает уникальную управляемую идентичность. В среде разработки разработчики работают с «общим паспортом», а в боевой среде — уже с индивидуальными.

Стандарты: A2A, MCP и федерация рабочих нагрузок

A2A (Agent2Agent)

Протокол, инициированный Google, но с активным участием Microsoft. HTTP/JSON-RPC 2.0, Server-Sent Events для потоковой передачи. Microsoft выпустил A2A .NET SDK (в превью), интегрирует протокол в Semantic Kernel и Azure AI Foundry.

Аутентификация в A2A гибкая: от API-ключей до OAuth 2.0, OpenID Connect и токенов Entra ID. Обнаружение реализовано через Agent Cards — JSON-дескрипторы, которые агенты публикуют о себе.

Архитектурный паттерн, который продвигает Microsoft: MCP для инструментов, A2A для межагентской коммуникации. Агенту нужно вызвать функцию — MCP, договориться с другим агентом — A2A.

MCP (Model Context Protocol)

Интегрирован в Copilot Studio как коннекторы. Microsoft Graph MCP Server for Enterprise позволяет агентам обращаться к корпоративным данным через единый протокол. Для аутентификации MCP-серверов Microsoft предлагает сайдкар-аутентификацию (sidecar) через Entra Agent ID.

Workload Identity Federation

Федерация на базе OIDC для Kubernetes, GitHub Actions, AWS STS, GCP. Избавляет от долгоживущих секретов в пользу краткосрочных токенов с явным временем жизни и аудитом.

Технические детали: под капотом

Обмен токенами в WIF:

Сайдкар-паттерн (sidecar) для сторонних агентов:

Entra Auth SDK запускается как сопутствующий контейнер. Код агента никогда не касается учетных данных — он делает HTTP-запросы к сайдкару, который управляет всей аутентификацией. Цена за «работу без секретов» — эксплуатационная сложность второго контейнера, его мониторинг, обновления и сценарии отказа.

Паттерн федерации:

Для агентов в AWS/GCP, где сайдкар невозможен, используется прямая федерация: агент получает токен у облачного провайдера, обменивает его в Entra.

Жизненный цикл идентичности в Foundry:

• До публикации: общая идентичность для всех агентов проекта.
• После публикации: уникальная управляемая идентичность для каждого агента.
• Права доступа в среде разработки и боевой среде могут кардинально отличаться.

Итоги и открытые вопросы

Agent 365 решает задачу управления жизненным циклом агентов, которую Copilot Studio делает доступной широкому кругу пользователей. Вместе эти продукты формируют естественную экосистемную привязку: чем больше агентов работает внутри Microsoft-стека, тем выше ценность единой плоскости управления. Это не уникальная для отрасли динамика, но команде стоит заранее оценивать долгосрочные последствия такой привязки.

Уже работающие агенты с идентичностью: Entra Conditional Access Optimization Agent (сам Microsoft использует свой продукт для оптимизации собственных политик) и агенты Copilot Studio.

Вопрос, который остаётся открытым: если 68% организаций не отличают агента от человека, то насколько эффективны все эти плоскости управления, когда агент с профилем Agent User может проходить в устаревших системах как обычный сотрудник?

Microsoft обещает «бесшовный опыт работы с агентами». На практике агентная аутентификация — это сайдкар-контейнеры, метаданные федерации, развертывание шаблонов, ротация FIC и несколько моделей биллинга. Инфраструктура агентных паспортов уже выходит из превью в продукты, но путь к её массовому внедрению лежит через решение интеграционных, лицензионных и организационных вопросов.