ИИ-агенты, прошедшие аутентификацию, все равно могут отклоняться от заданного поведения, раскрывать данные или подвергаться отравлению памяти

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

Первый уровень риска — вовсе не гипотетический. В июне Агентство кибербезопасности и защиты инфраструктуры США (CISA) внесло уязвимость в LiteLLM в свой каталог эксплуатируемых уязвимостей после того, как злоумышленники начали использовать ее «в дикой природе». Эта ошибка позволяла выполнять команды на хосте через сам шлюз, а в связке со второй уязвимостью для этого даже не требовались учетные данные. Это была лишь одна из семи распространенных уязвимостей (CVE), обнаруженных в этом единственном ИИ-шлюзе всего за месяц. И именно к этому уровню многие предприятия обращаются в первую очередь для защиты своих ИИ-агентов.

При проектировании безопасной архитектуры агентов средства управления на базе шлюзов не должны быть первыми. Они должны быть пятыми.

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

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

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

Неправильная отправная точка

Подумайте о маршрутизации трафика агента через новый шлюз среды выполнения. Финансовый агент-ресилер пытается изменить запись в продакшене. Шлюз аутентифицирует токен пользователя и проверяет вызов API. Чего он не может заметить, так это того, что запрос инициирован агентом, что агент выполняет более ограниченную функцию или что запрос является частью цепочки инструментов, вызванной ненадежным артефактом.

Учетные данные действительны. Вызов API разрешен. Действие противоречит цели делегирования. Шлюз на месте, но необходимая для него основа отсутствует, поэтому ресурсоемкий инструмент контроля применяется лишь к крошечной части общей картины.

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

Развертывание на основе зависимостей

Я называю этот процесс развертыванием, управляемым зависимостями (dependency-gated deployment). Прежде чем какой-либо нижестоящий элемент управления будет признан готовым к работе, должны быть успешно пройдены предварительные проверки на верхних уровнях. Параллельная разработка нижестоящих средств допускается.

Вот шесть шлюзов и доказательства того, что они работают:

Шесть шлюзов зависимости для средств контроля безопасности агентов. Каждый элемент управления контекстуализируется шлюзами, расположенными выше него. На основе анализа автором развертывания продакшн-агентов.

Начните с агентов, которых вы действительно можете назвать по имени

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

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

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

Агент не должен быть скрыт за разработческим токеном, общей служебной учетной записью или человеческой сессией. Простого знания о том, что вызывающий абонент является агентом, недостаточно. Плоскости управления требуется дополнительный контекст делегирования: кто делегировал работу, какую конкретную задачу было поручено выполнить агенту и к каким ресурсам агенту необходим доступ. Идентичность определяет, какой субъект совершил вызов. Делегирование же отвечает на вопрос, чьим авторитетом он действует и по какой причине.

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

Сократите объем полномочий перед проверкой поведения

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

Согласно исследованию Teleport за 2026 год, в котором приняли участие 205 руководителей службы безопасности, объем доступа превосходит прогностические возможности отрасли, уровень зрелости или уверенность в предотвращении инцидентов, связанных с ИИ. Например, организации с избыточными привилегиями у ИИ сообщили о частоте инцидентов в 76%, в то время как инциденты с ИИ происходили лишь у 17% организаций с минимальными привилегиями. Это указывает на то, что объем доступа в цепочке зависимостей важнее контекстно-зависимого обеспечения соблюдения политик во время выполнения.

Основной принцип — монотонное делегирование. Каждая передача ответственности должна сохранять или уменьшать полномочия; ни при каких обстоятельствах они не должны увеличиваться. Для агента-ресилера это означает предоставление доступа к одной бухгалтерской книге вместо наследования доступа сотрудника ко всем системам, к которым этот сотрудник может обращаться.

Наведите порядок с атрибуцией до автоматизации контроля

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

Теперь шлюз отрабатывает свою ценность

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

Обнаружение и путь прерывания — на последнем месте

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

Начните без замены вашей IAM

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

Пробелы в управлении поддаются количественной оценке. Согласно опросу Okta за 2026 год, только 34% руководителей заявили, что их организация всегда применяет тот же уровень строгости безопасности к своему агентскому персоналу, что и к человеческому. Последний элемент управления из цепочки нельзя применять первым, чтобы закрыть этот пробел.

Что делать в ближайшие 30 дней

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

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

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

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

Ник Кале (Nik Kale) — ведущий инженер, специализирующийся на корпоративных ИИ-платформах и безопасности.

Добро пожаловать в сообщество VentureBeat!

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

Читайте далее в рамках нашей программы гостевых постов и ознакомьтесь с нашими рекомендациями , если вы хотите опубликовать собственную статью!