Nik Kale, специалист по корпоративным платформам искусственного интеллекта и безопасности, считает, что многие организации начинают с операционного шлюза агентов, рассматривая его как главную точку контроля, хотя такие шлюзы зависят от уровней идентификации и атрибуции, которые могут отсутствовать или быть недостаточно зрелыми. В результате шлюз может проверять действительность токена и запрос API, но не всегда знает, какой агент выполнил запрос, кто его уполномочил, какую задачу он выполнял или являлся ли запрос частью цепочки инструментов, запущенной ненадёжным компонентом.
Эта проблема приобретает практическое значение по мере расширения внедрения агентов. В июне Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) добавило уязвимость в LiteLLM в каталог известных эксплуатируемых уязвимостей после обнаружения её фактического использования. Уязвимость позволяла выполнять команды на хосте через сам шлюз; кроме того, при объединении со второй уязвимостью её можно было эксплуатировать без учётных данных. Источник указывает, что за один месяц в шлюзе были выявлены семь распространённых уязвимостей (CVE).
Безопасность — это цепочка доверия, а не единственная точка контроля
Kale предлагает то, что он называет «развёртыванием, управляемым доверием»: ни один последующий уровень не следует считать операционно завершённым до прохождения необходимых проверок предыдущих уровней. Средства контроля можно разрабатывать параллельно, но их активация в рабочей среде должна следовать чёткой последовательности:
- Инвентаризация агентов и ответственное владение: у каждого рабочего агента должны быть известны владелец, конкретное назначение, одобренные инструменты и статус в жизненном цикле.
- Независимая идентичность и контекст делегирования: система должна знать агента, его владельца, а также пользователя или организацию, от имени которых агент выполняет работу.
- Краткосрочные учётные данные, ограниченные задачей: скомпрометированный агент не должен получать доступ к ресурсам, не связанным с порученной ему задачей.
- Атрибуция и измеримость: задачу должно быть возможно восстановить от момента её запуска до конечного воздействия на другие системы.
- Применение процедур во время выполнения: решения о применении политик должны основываться на идентичности агента, уполномочивающей стороне, задаче и действии, а не только на действительности токена.
- Поведенческая базовая линия и межсистемный механизм остановки: команды безопасности должны иметь возможность отключить фактические полномочия агента во всех местах, к которым он получает доступ.
Начинайте с того, что можно определить и атрибутировать
Согласно предложенной системе, первым шагом является инвентаризация рабочих агентов, находящихся в средах с открытым исходным кодом, облачных сервисах, продуктах «программное обеспечение как услуга» и инструментах разработчиков. Реестр должен включать владельца агента, его ответственность, этап жизненного цикла, разрешённые инструменты, области данных и источники учётных данных. Отсутствие такой инвентаризации является не только проблемой документации: часть времени реагирования на инцидент может уйти на попытки определить источник, который организация должна была знать заранее.
Автор подчёркивает, что идентичность агента не следует прятать внутри кода разработчика, общей сервисной учётной записи или пользовательской сессии. Недостаточно знать, что вызывающая сторона является «агентом». Необходимо также регистрировать, кто поручил работу, какова конкретная задача и какие ресурсы агенту требуется использовать. Идентичность определяет действующее лицо, тогда как делегирование показывает, от чьего имени действует агент и по какой причине ему были предоставлены эти полномочия.
Сократите полномочия до анализа поведения
После определения идентичности агента следует ограничить его возможности по времени, задаче, инструментам и необходимым для неё ресурсам. Источник указывает на возможность использовать существующие функции систем управления идентификацией и доступом (IAM), такие как идентичность рабочей нагрузки, обмен токенами, условный доступ и полномочия с ограниченным сроком действия.
Kale ссылается на исследование Teleport за 2026 год, охватившее 205 руководителей по безопасности: организации, использующие искусственный интеллект с чрезмерными полномочиями, сообщили о частоте инцидентов в 76%, тогда как среди организаций, применяющих принцип наименьших привилегий, этот показатель составил 17%. Согласно его анализу, это указывает на то, что масштаб доступа может быть более ранним фактором в цепочке доверия, чем применение контекстно-зависимых политик во время выполнения.
Предлагаемый автором принцип — «монотонное делегирование»: каждый переход ответственности должен сохранять полномочия или уменьшать их; увеличивать их нельзя. На примере агента финансовых расчётов это означает предоставление ему права просматривать конкретный реестр, а не наследование всех систем, к которым имеет доступ сотрудник, подавший запрос.
Когда шлюз действительно становится полезным?
Операционный шлюз приобретает полную ценность только после появления зарегистрированной идентичности агента, явного контекста делегирования, конкретных учётных данных и журналов с возможностью атрибуции. Тогда он может оценить, уполномочен ли агент выполнить определённое действие, в интересах конкретной стороны, в рамках конкретной задачи и над конкретным ресурсом. Пользовательский токен может быть действителен для предоставления агенту финансовых расчётов права записи, но полный контекст может показать, что действие выходит за пределы задачи.
Наиболее строгие средства контроля следует направлять на границы, последствия которых трудно обратить: платежи, изменения политик доступа, удаление, изменения рабочей среды и экспорт данных. Поведенческие базовые линии появляются позже, после того как действия агента становятся различимыми и поддающимися атрибуции; тогда можно выявлять необычное использование инструментов, неожиданный доступ между областями данных или отклонение от задачи.
Механизм остановки не ограничивается отключением одного объекта в каталоге идентичностей. Полная остановка, как описывает источник, требует отключения идентичности агента, отзыва активных и производных учётных данных, блокирования запуска инструментов, завершения текущих задач и изоляции рабочей нагрузки, содержащей агента.
План проверки за 30 дней
Автор не предлагает заменять существующую программу управления идентичностями. Если поставщик идентичностей не рассматривает агентов как нативные типы объектов, можно начать с надёжного реестра, связанного с существующими идентичностями рабочих нагрузок, затем добавить идентификаторы агента и задачи как надёжные контексты выполнения, использовать краткосрочные учётные данные и включить эти идентификаторы в журналы вызовов инструментов.
На практике он предлагает начать с десяти рабочих агентов и задокументировать владельца, назначение, инструменты и учётные данные каждого из них. Затем следует проверить, различают ли системы управления идентичностями и журналирования агента, человека или сервис, поручивший задачу, а потом восстановить полностью выполненную задачу от начала до конца, включая её последующие последствия. Место разрыва цепочки покажет пробел, который следует устранить до добавления нового средства операционного применения политик.
Редакционное примечание: ценность этой системы заключается не в предложении нового шлюза, а в изменении порядка, с которого следует начинать. Упомянутые факты о LiteLLM, а также показатели Teleport и Okta подтверждают важность сокращения полномочий и атрибуции, но сами по себе не доказывают, что предложенный порядок уровней является единственным решением или подходит для каждой корпоративной архитектуры. Кроме того, материал представляет собой анализ автора, а не официальный стандарт; поэтому его применение требует проверки особенностей существующих в каждой организации систем идентификации, журналирования и механизмов остановки.