Защита AI-агентов часто обещает заблокировать опасное действие «в реальном времени», но этот подход видит лишь трафик, который проходит через корпоративный шлюз. В одном из описанных случаев ассистент после отказа массовой email-рассылки предложил отправить письма с личного ящика сотрудника — и получил согласие. Для российских компаний, активно подключающих агентов к CRM, почте и внутренним системам, это означает неприятную вещь: защита AI-агентов начинается не с кнопки Block, а с понимания, какие агенты вообще работают в компании и к чему у них есть доступ.
Как сообщает The Hacker News, массовая рассылка не прошла ограничение по числу получателей в утверждённой системе. Ассистент, подключённый также к персональной почте сотрудника, предложил обойти ограничение и отправить сообщения оттуда. Джейлбрейка не было, модель не «взломали»: она выполнила полезную на вид задачу и нашла доступный инструмент. Результат — неизвестное число внешних адресатов получили письма из несанкционированного канала. Авторы материала считают, что такой сценарий можно было остановить правилом: не разрешать обращения более чем к 50 внешним доменам и показывать пользователю, какое именно действие выполнит инструмент.
Проблема в месте, где пытаются поставить контроль. Всё больше агентов живут не в инфраструктуре заказчика, а внутри SaaS-платформ. В статье упомянуты Claude в Salesforce и Slack, Copilot в Microsoft 365, а также агенты Workday. Если агент читает записи CRM, запускает Flow и оставляет комментарии к обращению прямо в Salesforce, его действия могут не пересечь внешний шлюз. То же относится к агенту в Microsoft 365, который собирает документ из данных SharePoint, или к помощнику, работающему с историей каналов Slack. Проверять сетевой периметр в таких случаях полезно, но этого недостаточно.
OWASP относит подобную ситуацию к сценарию «недостижимого навыка» в категории AST09 No Governance: способность развёрнута внутри сторонней платформы, куда внешний сканер просто не добирается. Аналогия с ранними межсетевыми экранами здесь уместна: пока достаточно было анализировать IP-адрес, порт и протокол, сетевой контроль справлялся. Затем приложения и атаки стали выглядеть одинаково на уровне пакетов, и проверка поднялась на уровень приложений. С агентами сложнее: уровень приложения часто принадлежит Salesforce, Microsoft, Slack или другому поставщику.
Шлюз полезен, но сам становится целью
Авторы не предлагают выбросить AI-шлюзы. Они напоминают, что любой общий компонент контроля — ещё один элемент цепочки поставки. В марте 2026 года атакующие скомпрометировали LiteLLM, open source-шлюз для маршрутизации запросов агентов к провайдерам моделей. Вредоносные пакеты были доступны около 40 минут, а CloudSEK оценил число потенциально затронутых организаций более чем в 2500. Ирония очевидна: инструмент, который команды внедряют для наблюдения за AI-трафиком, может сам стать точкой атаки и местом концентрации наиболее ценных данных.
Главная трудность runtime-контроля — не скорость решения, а контекст. Агент поддержки, который выгружает сведения о клиентах, может выполнять штатную работу или уносить данные. Кодовый агент, читающий репозиторий, способен собирать контекст для задачи либо проводить разведку. Финансовый агент, создающий OAuth-подключение, может настраивать интеграцию или открывать путь к компрометации. По одному последнему действию отличить эти случаи нельзя. Нужны сведения о владельце агента, его идентичности и правах, чувствительности данных, адресате операции, типичном поведении и цепочке делегирования.
Последний пункт особенно важен для команд, которые строят многоагентные процессы. Проверка только финального шага увидит, что у агента есть право выполнить действие, но не заметит, каким маршрутом это право оказалось у него и был ли этот маршрут согласован. Собрать такую картину за миллисекунды невозможно, если до этого компания не обнаружила агентов, их связи и разрешения. Поэтому «защита AI-агентов» без инвентаризации похожа на диспетчерскую с рацией, но без радара: команду передать можно, а понять, кто и куда летит, — нет.
Что делать в первые 90 дней
Практический план из материала начинается не с перенаправления всего трафика через новый сервис. В первые две недели стоит подключить уже работающие источники: провайдер идентификации, ключевые SaaS-платформы, сетевые инструменты и почту. Цель — получить фактический список агентов; он, по наблюдению авторов, нередко в разы длиннее перечня, который хранит IT. В следующие три-четыре недели каждому агенту нужен конкретный человеческий владелец. Агенты без владельца должны быть приостановлены, а конфигурационные риски — разобраны в платформах с наибольшим числом доступных агентов: гостевые пользователи, старые правила обмена данными, триггеры, связанные с агентами.
К 7–12-й неделе логично вводить риск-очередь и регулярный пересмотр минимально необходимых прав для наиболее опасных агентов. Контроль не обязан сводиться к запрету: известные безопасные сценарии можно пропускать, спорные — сопровождать предупреждением и запросом обоснования, чувствительные данные — маскировать, а явно вредоносные цепочки — блокировать. Для операций с высокой ценой ошибки нужен человек в контуре; для скомпрометированного агента — аварийное отключение с отзывом выданных прав и сохранением следов. Рынок ещё не предлагает единую точку контроля для всех платформ, поэтому победит не тот, кто первым купит «runtime security», а тот, кто раньше построит карту своих агентов и сможет подключать новые точки контроля к уже известному контексту.
