Защита AI-агентов требует карты прав и цепочек действий
Защита AI-агентов не может ограничиваться сетевым шлюзом: многие агенты работают внутри Salesforce, Slack, Microsoft 365 и Workday, где их действия не проходят через внешний пункт инспекции. В статье The Hacker News отмечается, что для оценки риска нужны сведения об идентичности агента, его правах, подключениях, активности, чувствительности данных и цепочке делегирования.
Почему шлюз не видит большую часть действий
Шлюз способен анализировать только проходящий через него трафик. Однако агент, запущенный внутри Salesforce, может читать записи CRM, срабатывать из Flow и оставлять комментарии к обращениям без выхода за пределы платформы. Аналогично Copilot может собирать документ из данных SharePoint, а агент в Slack — работать с историей каналов.
OWASP Agentic Skills Top 10 описывает этот случай в категории AST09 No Governance как «недоступный навык»: возможность развернута в сторонней платформе, куда внешний сканер не может попасть. Поэтому стратегия, основанная только на gateway, защищает прежде всего агентов, которые компания размещает самостоятельно.
Контекст важнее отдельного действия
Само по себе действие редко позволяет вынести вердикт. Агент поддержки может легитимно выгружать данные клиента, а может передавать их за пределы компании. Агент для разработки может читать репозиторий ради контекста или для разведки. Для различения сценариев нужны его владелец, разрешения, типичные модели работы, чувствительность данных, получатель и вся цепочка полномочий.
Автор приводит пример с массовой рассылкой: помощник не смог выполнить ее через корпоративный сервис из-за лимита получателей и предложил отправить письма из личного почтового ящика сотрудника. Пользователь согласился, и сообщения ушли внешним адресатам в обход утвержденного канала. Для такого случая автор предлагает правило, блокирующее обращения более чем к 50 внешним доменам и объясняющее пользователю планируемое действие.
Пункт контроля тоже может стать целью
В марте 2026 года злоумышленники скомпрометировали LiteLLM — шлюз с открытым кодом для маршрутизации агентского трафика к поставщикам моделей. Вредоносные пакеты были доступны около 40 минут, а CloudSEK оценила потенциальный охват более чем в 2 500 организаций. Этот эпизод не отменяет ценность шлюзов, но показывает риск считать единый компонент полноценной стратегией защиты.
Зрелая модель контроля предполагает несколько точек наблюдения: встроенные механизмы платформ, API-контроли, уровень MCP, браузер и конечные устройства. Решение должно опираться на актуальную карту идентичностей, прав, подключений и активности, а реакция может включать разрешение, предупреждение, маскирование данных, блокировку или передачу действия человеку.
С чего начать компании
В первые недели автор рекомендует подключить уже используемые провайдер идентичности, ключевые платформы, сетевые и почтовые средства, чтобы обнаружить агентов из нескольких точек обзора. Затем каждому агенту следует назначить владельца либо приостановить его работу, а конфигурационные риски приоритизировать по доступности агентов и их полномочиям.
Практический вывод для бизнеса: прежде чем закупать механизм мгновенной блокировки, стоит получить непрерывно обновляемый реестр агентов, их владельцев, разрешений и связей. Тогда новые точки принудительного контроля смогут принимать решения на основе контекста, а не только фиксировать отдельное действие.