Agent sprawl и governance: чек-лист из 8 правил

Почему agent sprawl опаснее shadow IT

Microsoft Digital Defense Report 2026 называет неконтролируемое размножение агентов одним из трёх системных рисков их внедрения — наряду с избыточным доступом и отсутствием человеческой ответственности. Оценка отчёта сильная: без централизованной видимости agent sprawl создаёт даже больший риск, чем shadow IT.

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

• идентичности: неизвестно, сколько агентов существует и какие учётные записи они используют;
• полномочия: доступ выдаётся «на всякий случай» и остаётся после завершения задачи;
• связи: агенты вызывают инструменты и других агентов вне поля зрения IAM и SOC.

Если управлять только реестром приложений, останутся неучтёнными креденшелы, запланированные задачи, webhook-подписки и downstream-вызовы. MDDR предлагает восемь риск-ориентированных правил governance. Ниже они развёрнуты в контроли, которые можно внедрять и проверять. Краткую выжимку остальных выводов отчёта мы публиковали в обзоре MDDR 2026.

Нулевой шаг: собрать реестр до выбора платформы

Governance невозможен без инвентаризации, но таблицы с названием агента и email владельца недостаточно. В реестре должна быть видна операционная модель: что агент делает, где исполняется, к каким данным и инструментам имеет доступ, кто отвечает за него и когда он должен прекратить работу.

Важно различать логического агента и его эфемерные экземпляры. Для сотен краткоживущих запусков не нужно вручную заводить сотни постоянных учётных записей: реестр описывает агента или его шаблон, а экземпляры получают недолговечные идентичности и автоматически исчезают вместе с задачей. При этом телеметрия экземпляра должна оставаться связанной с логическим agent ID.

1. Дайте каждому агенту отдельную аудируемую идентичность

Первое правило MDDR: у каждого агента должна быть собственная идентичность с метаданными о создателе, назначении и спонсоре. Общий service account на команду или личный API-ключ сотрудника нарушает это требование, даже если доступ формально документирован.

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

• отличить действия одного агента от действий другого;
• выдать самостоятельный набор разрешений и отозвать его без побочного ущерба;
• связать запуск с конкретной целью и ответственным человеком;
• расследовать цепочку «пользователь → агент → экземпляр → инструмент».

Контрольная точка: по произвольному вызову API можно установить не только человека, начавшего процесс, но и агента, экземпляр и использованную идентичность. Если в журнале виден лишь automation-service, атрибуции ещё нет.

2. Назначьте спонсора и автоматически передавайте ответственность

Спонсор — не обязательно разработчик агента. Это человек, который подтверждает необходимость его работы, принимает решение о рискованном доступе и участвует в реагировании на инцидент. Создатель может покинуть проект, а агент останется критичным для бизнеса — поэтому ответственность должна передаваться явно.

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

Контрольная точка: количество активных агентов без действующего спонсора равно нулю, а история передачи ответственности сохраняется. Ежегодная рассылка «подтвердите владение» не заменяет событийную автоматику.

3. Применяйте least privilege с первого дня

Доступ проектируется из задачи, а не из предположения, что может понадобиться в будущем. Практический формат — матрица «задача → инструмент → действие → класс данных → срок». Она заставляет различать чтение и запись, просмотр и экспорт, черновик и отправку, вызов тестового и производственного ресурса.

Для новых полномочий нужен approval, соразмерный риску. Подтверждение высокорисковых операций должно вызываться детерминированной политикой, а не решением самой модели о том, опасен ли её следующий шаг. Это особенно важно при prompt injection и отравлении памяти, о чём мы писали в разборе memory poisoning.

Least privilege включает и обратное движение: неиспользуемые scope отзываются, временный доступ истекает, смена назначения запускает пересмотр. Иначе агент накапливает standing privileges — постоянные полномочия, которые переживают исходную задачу.

Контрольная точка: по журналам использования можно показать, зачем нужен каждый привилегированный scope, а отсутствие использования приводит к отзыву, а не к очередной отметке «актуально».

4. Автоматизируйте жизненный цикл

Ручной пересмотр не масштабируется на динамичную агентную среду. Минимальный автоматизированный цикл выглядит так: предложен → активен → приостановлен → выведен из эксплуатации. У каждого активного агента есть срок следующего пересмотра; у временного — срок автоматического завершения.

Автоматика должна сверять реестр с реальностью: конфигурациями платформ, идентичностями в IAM, запусками и журналами вызовов. Обнаруженный вне реестра агент попадает на разбор, а исчезнувший из среды — в процедуру очистки.

Вывод из эксплуатации включает не только удаление записи из каталога. Нужно отозвать креденшелы, отменить расписания и подписки, разорвать downstream-связи и определить судьбу памяти агента. Для расследования её может понадобиться сначала изолировать и сохранить, а не безусловно удалить.

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

5. Применяйте единые политики на всех платформах

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

Единство не обязательно означает единый продукт или центральный прокси для всех вызовов. Разумная цель — общие инварианты и сопоставимые доказательства: обязательный agent ID, действующий спонсор, предельный срок креденшела, классификация рискованных действий, формат аудита и процедура отзыва. Локальные механизмы могут различаться, но высокорисковое действие не должно становиться разрешённым только потому, что агент создан на другой платформе.

MDDR также рекомендует объединять владельцев приложений, хранителей данных, проектировщиков бизнес-процессов, compliance и спонсоров агентов. Задача такой группы — не утверждать каждый запуск вручную, а определять правила, которые технические контроли исполняют автоматически.

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

6. Требуйте аутентификацию между агентами

Доверие к исходной человеческой сессии не доказывает идентичность каждого downstream-агента. В мультиагентном графе вызываемая сторона должна проверить, какой именно агент обратился к ней, разрешено ли ему это взаимодействие и в контексте какой задачи он действует.

Для этого применяются взаимная TLS, подписанные workload-креденшелы и токены с ограниченной аудиторией. Конкретный выбор зависит от среды: SPIFFE и SPIRE помогают выдать проверяемую идентичность нагрузке, а механизмы делегирования и ослабления токенов сохраняют контекст по цепочке. Аутентификация сама по себе не даёт права на вызов — после неё всё равно требуется авторизация.

Оригинальный access-токен пользователя не следует бездумно пробрасывать через всю цепочку. Иначе каждый следующий агент получает полномочия исходного принципала, а граница между участниками исчезает. Точки аутентификации в протоколах взаимодействия мы разбирали в статье про A2A и MCP.

Контрольная точка: неаутентифицированный вызов между агентами отклоняется, а журнал позволяет восстановить цепочку «человек → оркестратор → субагент → инструмент», включая проверку прав на каждом переходе.

7. Выдавайте отдельные креденшелы для каждого инструмента

Седьмое правило MDDR — per-tool scoped credentials: короткоживущие секреты, привязанные к одному вызову инструмента, вместо долгоживущего токена со всеми потенциально нужными правами. Это сужает и набор возможных действий, и время, в течение которого украденный креденшел приносит пользу.

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

Там, где немедленная выдача на каждый вызов пока невозможна, переходным этапом может стать креденшел на узкую задачу с коротким TTL. Но это компромисс, а не эквивалент целевой модели. Дополнительная привязка токена к ключу клиента, например DPoP, ограничивает replay, однако не заменяет узкие scope и аудиторию. Практические ошибки выдачи таких креденшелов разобраны в руководстве по аутентификации MCP.

Контрольная точка: перехват креденшела для одного инструмента не открывает доступ к остальным, а после короткого TTL или завершения вызова его ценность для атакующего исчезает.

8. Измеряйте revocation latency

Отзыв доступа часто считается завершённым, когда администратор нажал «disable». Для агентной среды правильнее измерять интервал от решения об отключении до момента, когда ресурсы фактически перестали принимать действия агента. Между этими событиями могут оставаться выпущенные access-токены, активные сессии, кеши авторизации и креденшелы downstream-инструментов.

Поэтому revocation latency измеряется сквозным тестом: остановить агента, отозвать идентичность и креденшелы, затем повторить реальные вызовы ко всем критичным ресурсам и убедиться в отказе. Короткие TTL уменьшают окно риска, а introspection, отзыв сессий и ресурсные политики помогают не ждать естественного истечения каждого токена.

Метрику полезно разлагать по платформам и типам доступа. Среднее время скрывает проблемные хвосты; для реагирования важны p95 и худший наблюдаемый результат. Норматив зависит от риска: отключение агента с правом платежа и чтения публичного справочника вряд ли должно иметь одинаковый целевой срок.

Контрольная точка: учения по компрометации регулярно подтверждают фактическое время остановки, включая ранее выпущенные токены и вызовы через субагентов.

Метрики, которые показывают состояние программы

Количество зарегистрированных агентов само по себе не говорит о качестве governance. Полезнее сочетать покрытие, остаточный риск и способность сдерживать инцидент.

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

Ориентир внедрения на 90 дней

Дни 1–30 — видимость. Собрать реестр, обнаружить фактические идентичности и креденшелы, назначить спонсоров, прекратить выдачу общих аккаунтов новым агентам. В первую очередь разобрать агентов с записью в критичные системы.

Дни 31–60 — жизненный цикл и доступ. Включить сроки пересмотра, карантин без спонсора и автоматическую очистку. Ввести матрицу полномочий и короткоживущие креденшелы для самых рискованных инструментов.

Дни 61–90 — связи и реагирование. Выровнять политики между платформами, закрыть неаутентифицированные agent-to-agent вызовы, провести учения по компрометации и опубликовать revocation latency по критичным ресурсам.

За этот срок не обязательно переводить все сценарии на идеальную модель. Важно получить управляемый контур и измеримый backlog, а не ещё один каталог, который устарел сразу после заполнения.

Вывод

Agent sprawl нельзя решить одним запретом на создание агентов или покупкой ещё одной платформы. Восемь правил MDDR образуют связанную систему: идентичность делает действия различимыми, спонсор закрепляет ответственность, least privilege ограничивает возможный ущерб, автоматический жизненный цикл не даёт доступу застаиваться, а измеренный отзыв превращает реагирование в проверяемую операционную способность.

Главный критерий зрелости прост: организация может не только перечислить своих агентов, но и доказать, почему каждый из них сейчас имеет именно такой доступ и как этот доступ будет прекращён. Тогда рост числа агентов становится масштабированием бизнес-процессов, а не неконтролируемым ростом поверхности атаки.

Основной источник: Microsoft Digital Defense Report 2026, раздел «The agentic defense stack», стр. 22–24.