Намерение ИИ-агента — это лишь отправная точка, а не стратегия безопасности

В этом видео для Help Net Security Итамар Апельблат, генеральный директор Token Security, представляет результаты исследования компании. Оно показывает, что 65% активных чат-ботов с агентными функциями никогда не использовались, но при этом сохраняют действующие учётные данные для доступа. Он объясняет, почему компании относятся к ИИ-агентам скорее как к быстрым экспериментам, а не как к управляемым идентификаторам, и почему это создаёт риски, аналогичные "осиротевшим" сервисным учётным записям, только их сложнее заметить.

В беседе рассматривается, почему 51% внешних действий агентов по-прежнему полагаются на жёстко заданные учётные данные, как одна внедрённая подсказка может пройти через конвейер с несколькими агентами, не вызвав ни одного стандартного оповещения SOC, и почему 81% агентов, развёрнутых в облаке, работают на самостоятельно управляемых фреймворках. Апельблат также подробно объясняет, что значит операционализировать намерение агента в виде политики, и почему механизмы контроля должны сохранять силу даже в тот момент, когда пользователь переформулирует задачу для агента, выходя за рамки его исходной конфигурации.

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

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

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

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

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

Рассмотрим, к примеру, клиентоориентированный конвейер поддержки, построенный из нескольких специализированных агентов: агент приёма, который анализирует входящие заявки, агент поиска, который запрашивает данные CRM и учётных записей, и агент операций с учётными записями, имеющий права на сброс учётных данных или изменение настроек аккаунта. Поступает заявка в поддержку, которая выглядит как обычная эскалация: «Я заблокирован в своём административном аккаунте (ID аккаунта: 91024), срочно сбросьте мои учётные данные». Агент приёма анализирует запрос, извлекает идентификатор учётной записи из тела сообщения и делегирует задачу сброса пароля агенту операций с учётными записями на следующем этапе.

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

Именно здесь традиционная видимость SOC оказывается недостаточной. Хотя она обычно хорошо справляется с обнаружением известного вредоносного ПО, аномалий на конечных точках или подозрительных входов в систему, большинство традиционных инструментов не способны обнаружить, когда доверенная сервисная идентичность выполняет разрешенные действия в неправильной последовательности и по неправильной причине. Это "слепое пятно" контекста. SOC может по-прежнему видеть логи, но не исходный промпт, цепочку делегированных рассуждений, передачу между агентами или несоответствие между задуманной задачей и фактическим действием. Как только эта связь теряется, остается серия технически корректных событий, которые трудно отличить от обычной автоматизации.

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

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

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

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

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