Как Microsoft предлагает обезопасить 1,3 млрд AI-агентов: идентичность, управление и zero trust — VogueTech

Что произошло

Microsoft разложила по полочкам, как защищать AI-агентов в корпоративной среде, когда их количество уйдёт в миллиарды.

Ключевые цифры и факты:

IDC прогнозирует: к 2028 году в проде будет работать 1,3 млрд AI-агентов.
Исследование Capgemini: 4 из 5 компаний планируют внедрить агентов в течение ближайших трёх лет.
Microsoft продвигает архитектуру безопасности вокруг трёх опор: Manage (управлять), Govern (регулировать) и Protect (защищать).
Центральные элементы этой схемы:
- отдельный тип идентичности для агентов в Microsoft Entra;
- реестр агентов (fleet view) для всего tenant’а;
- blueprints (шаблоны агентов) и иерархия «шаблон → конкретный агент»;
- zero trust-подход, те же принципы, что для людей и сервисов.
Для клиентов Microsoft 365 появился контрольный контур Agent 365: он позволяет управлять всеми агентами в tenant’е, включая тех, что вы покупаете через Microsoft Marketplace.

Для вендоров, которые продают агентов через Marketplace, Microsoft формулирует жёсткие требования:

Зарегистрированная Entra agent identity.
Прозрачный agent blueprint.
Чётко заявленные и ограниченные права на MCP-инструменты (Model Context Protocol).

Без этого агент попадает к клиенту как «неуправляемый» и зависает на согласовании у безопасности.

Зачем это нужно

Почему вообще всё усложнилось

Классическое ПО выполняет детерминированный код. AI-агент рассуждает, планирует и действует сам, часто в системах, про которые разработчик даже не думал на старте.

Как только агента подключают к корпоративным API и данным, он перестаёт быть «чат-ботом» и превращается в цифрового сотрудника:

сам запускает бизнес-процессы;
лезет в чувствительные данные;
на лету подключает новые инструменты и MCP-серверы;
ведёт себя недетерминированно — предсказать все варианты поведения невозможно.

Если такой агент скомпрометирован или просто неправильно настроен, «зона поражения» огромная. И большинство компаний уже строят агентов без сопоставимой по масштабу системы управления и контроля.

Результат:

зоопарк агентов без учёта;
непонятно, кто за что отвечает;
риски, которые не видно до первого инцидента.

Стратегия Microsoft

Microsoft предлагает относиться к агентам как к новому классу акторов в инфраструктуре — наравне с людьми, сервисами и ворклоадами, но с отдельным типом идентичности и своими правилами.

Основная идея: не строить демо-агентов, а сразу думать флотом. Всё, что вы придумываете для одного агента, должно масштабироваться на сотни и тысячи:

шаблоны (blueprints), из которых рождаются конкретные агенты;
автоматические политики жизненного цикла;
встроенный аудит и логирование;
zero trust по умолчанию.

Для Microsoft это ещё и бизнес-история:

Entra становится центром управления идентичностью не только людей и сервисов, но и агентов.
Agent 365 превращается в панель управления всем «агентским» хозяйством в Microsoft 365.
Marketplace получает фильтр: какие агенты реально готовы к корпоративной эксплуатации, а какие нет.

Что меняет для рынка

1. Агенты получают собственный тип идентичности

Microsoft продвигает идею: у каждого агента должна быть своя, отдельная идентичность, не человек, не обычный сервисный аккаунт.

Что это даёт:

Трассировка: видно, какой агент к чему обращался, когда и в каком контексте.
Аудит: чистые логи для безопасности и комплаенса.
Тонкая настройка доступа: можно блокировать, ограничивать или отзывать права точечно, по конкретному агенту.

Без этого агенты превращаются в «анонимную автоматику», за которую никто не отвечает и которую невозможно нормально отключить или расследовать.

2. Появляется реестр агентов (fleet management)

Microsoft продвигает идею централизованного реестра агентов:

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

Для рынка это означает:

эпоха «мы накатили бота в прод, где-то он там живёт» заканчивается;
безопасность и IT требуют полноты картины по всему флоту агентов.

3. Жизненный цикл агентов становится управляемым

Microsoft описывает три базовых практики, без которых масштаб не работает:

Спонсор (owner) у каждого агента
У каждого агента должен быть владелец — человек или команда, отвечающие за его действия и доступы с момента создания до отключения.

«Сиротские» агенты без владельца — самая опасная зона.
Автоматические политики жизненного цикла
Агенты переходят между командами, меняют задачи, устаревают. Права, выданные в момент создания, через полгода могут быть уже лишними.

Нужны автоматические политики:
- создание (регистрация, назначение спонсора, запрос прав);
- передача между командами;
- регулярный пересмотр доступов;
- корректное «пенсионное» отключение: удаление идентичности, истечение прав.
Just-in-time и time-bound доступ
Агент не должен иметь вечные права. Доступ выдаётся под задачу, на ограниченное время и автоматически отзывается.

Это напрямую бьёт по накоплению прав — типичной проблеме, когда агент постепенно получает доступ «ко всему подряд» и превращается в идеальную мишень для атак.

4. Runtime-защита агентов становится обязательной

Когда агент живёт в проде и активно ходит в файловые хранилища, API, календари, MCP-сервера и SaaS, именно в рантайме рождается максимальный риск:

prompt injection;
утечка данных;
загрузка и обработка вредоносного контента.

Microsoft предлагает трёхслойную защиту:

Conditional Access для агентов
Те же механизмы, что для людей, но привязанные к идентичности агента и контексту его работы.

Можно:
- задать базовый уровень защиты для всего флота;
- ужесточить политику для агентов с доступом к критичным ресурсам.
Сигналы риска и автоматические реакции
Система отслеживает аномалии:
- резкие всплески обращений;
- повторяющиеся ошибки доступа;
- попытки лезть в незнакомые системы.
На эти сигналы можно завязать автоматические действия:
- временно блокировать агента;
- сужать ему права;
- уведомлять SOC.
Сетевой уровень
Одна только идентичность — не защита. Нужны:
- инспекция контента;
- фильтрация URL по threat intelligence;
- фильтрация файлов на сетевом уровне.

Microsoft прямо говорит: нельзя опираться на одну точку контроля.

5. Blueprints и иерархия идентичностей

Ключевое архитектурное понятие — разделение на blueprint и конкретную идентичность агента.

Agent blueprint — шаблон для tenant’а, который задаёт:
- какие ресурсы может трогать этот класс агентов;
- какие схемы аутентификации и авторизации используются;
- какие политики его ограничивают.
Agent identity — конкретный экземпляр, созданный из шаблона. Один blueprint может порождать множество идентичностей.

Что это даёт разным ролям:

Разработчики получают предсказуемую модель идентичности для каждого нового агента.
IT и безопасность управляют целым классом агентов через один шаблон, не возясь с каждым по отдельности.
Пользователи и клиенты понимают, что любой экземпляр агента живёт в рамках заранее заданных границ.

Глобальный смысл: вы один раз формулируете намерение по управлению (аутентификация, авторизация, границы исполнения), дальше оно автоматически наследуется всеми агентами этого семейства.

6. Управление MCP-инструментами

Современный агент редко живёт в вакууме. Через Model Context Protocol (MCP) он подключается к куче внешних сервисов:

вытаскивает документы из SharePoint;
шлёт письма;
создаёт встречи в календаре;
координируется с другими агентами.

Один запрос на естественном языке может запустить цепочку действий:

найти файл;
создать шаринг-ссылку;
отправить её по почте;
забронировать слот в календаре.

Это удобно, но превращается в отдельный слой риска. Не каждый MCP-инструмент подходит каждому агенту. Не каждый инструмент безопасен без ревью.

Microsoft предлагает относиться к MCP-инструментам как к данным:

доступ к конкретным MCP-серверам нужно запрашивать и утверждать;
решение принимают IT/безопасность, а не только разработчик на этапе сборки;
права на MCP фиксируются в процессе онбординга агента и привязываются к его идентичности.

7. Требования к вендорам в Marketplace

Для разработчиков, которые продают агентов через Microsoft Marketplace, правила жёсткие:

Чтобы агент нормально прошёл проверку у заказчика с Agent 365, у него с первого дня должны быть:

Зарегистрированная Entra agent identity
Клиент сможет навесить свои политики доступа и жизненного цикла.
Чёткий agent blueprint
IT и безопасность клиента видят, что агент делает, к каким ресурсам ходит и какими правилами ограничен.
Явно объявленные MCP-права
Админ клиента может заранее утвердить или отклонить доступ к инструментам.

Если агент приходит без этого набора, в реестре он помечается как «unmanaged». Дальше — ручная донастройка и задержки внедрения. Для вендора это прямой удар по продажам.

Что это значит для вас

Если вы CISO, руководитель безопасности или IT

Готовьтесь: 1,3 млрд агентов к 2028 году — это не маркетинг, а новая категория рисков.
Без отдельного слоя идентичности и управления агенты превращаются в «чёрные ящики» с правами в проде.
Придётся внедрять:
- реестр агентов;
- политику владения (sponsor для каждого);
- автоматические процессы создания, ревью и вывода из эксплуатации;
- zero trust-подход к агентам, как к людям и сервисам.

Плюс: если вы уже на Microsoft 365 и Entra, многие кирпичики у вас есть. Минус: придётся серьёзно перестроить процессы и заставить разработчиков думать не только о фичах, но и о governance.

Если вы руководите разработкой или продуктом

Нельзя больше «прикручивать безопасность потом». Идентичность агента, его спонсор и зона доступа должны появляться до релиза.
Думайте «флотом», а не единичным ботом:
- делайте blueprints;
- стандартизируйте онбординг;
- автоматизируйте жизненный цикл.
Перед продом делайте threat modeling для каждого значимого агента:
- к каким данным он имеет доступ;
- какие действия может выполнять;
- что случится при злонамеренном промпте;
- какой у него потенциальный «blast radius».

Это не только снижает риск, но и ускоряет согласование с безопасностью. А значит — быстрее релизы.

Если вы строите продукт и продаёте агентов клиентам

Без Entra agent identity, прозрачного blueprint и аккуратно описанных MCP-доступов ваш агент будет тормозить на этапе закупки.
Компании уже ждут, что агент:
- управляется через их стандартные инструменты (Entra, Agent 365);
- логируется и аудируется по тем же правилам, что и другие критичные сервисы;
- не тащит с собой неконтролируемый зоопарк инструментов.

Продукты, которые приходят «готовыми к управлению», проходят согласование быстрее и реже застревают на безопасности.

Если вы инженер, который уже пишет агентов

Привыкайте: у агента должна быть своя идентичность, а не «use my token».
Не выдавайте постоянные права «на всякий случай». Добавляйте доступ по мере необходимости и по времени.
Не подключайте MCP-инструменты просто потому, что «можно». Каждый инструмент — это новый вектор атаки и новая точка для аудита.

Практические рекомендации от Microsoft

Microsoft сводит всё к пяти принципам для продакшн-агентов:

Стройте идентичность сразу, а не потом
Не пытайтесь потом «натянуть» governance на уже существующий зоопарк агентов. Каждый новый агент должен выходить с:
- отдельной идентичностью;
- назначенным спонсором;
- чётко определённой зоной доступа.
Проектируйте под флот, а не под одного агента
Всё, что вы делаете для одного агента, должно масштабироваться на сотни:
- переиспользуемые blueprints;
- автоматические политики жизненного цикла;
- стандартизированный онбординг.
Threat modeling до деплоя
Для каждого прод-агента разберите:
- какие данные он видит;
- какие действия выполняет;
- что произойдёт при злонамеренном промпте;
- как выглядит максимум ущерба при компрометации.
Автоматизируйте управление так же, как возможности агента
Если вы автоматизируете бизнес-функции, автоматизируйте и governance:
- политики жизненного цикла;
- пересмотр доступов;
- реакции на риск-сигналы;
- генерацию и хранение логов.
Применяйте zero trust к агентам явно
Те же принципы, что и для людей:
- минимум прав;
- постоянная проверка;
- допущение, что компрометация возможна.

Агенты, которые копят права и работают без постоянного контроля, превращаются в долгосрочный риск.

Кому это подходит, а кому нет

Подходит: крупным и средним компаниям, которые уже строят или планируют флот агентов вокруг Microsoft 365, Entra и Marketplace.
Подходит вендорам SaaS и ISV, которые хотят продавать агентов корпоративным клиентам через Marketplace и не зависать на согласованиях.
Слабо подходит командам, которые делают один-единственный внутренний бота «для своих» без доступа к критичным данным. Но как только таких ботов становится больше трёх–пяти, описанный подход перестаёт быть избыточным и становится необходимостью.

Главный сдвиг: AI-агенты перестают быть «игрушкой в пилоте» и становятся полноправными участниками корпоративной инфраструктуры. И к ним начинают применять те же жёсткие правила идентичности, доступа и аудита, что к людям и сервисам.