Слепая зона шлюзов: сетевые экраны пропускают прямые команды ИИ-агентов в ядро
Способны ли корпоративные системы безопасности реально верифицировать каждое действие, которое автономный программный агент выполняет во внутренней инфраструктуре?
Существующие механизмы контроля среды исполнения, развернутые для мониторинга агентов на базе больших языковых моделей, оставляют непроверенные маршруты: зона их защитной видимости жестко привязана к физическому уровню размещения в программном стеке. Корпоративные команды штатно внедряют инструменты контроля для инспекции операций в реальном времени, однако инструмент способен оценивать только те действия, которые проходят непосредственно через точку его интеграции. Как выяснили исследователи Кентаро Тойода и Алекс Люн из Vulcan Research (AIFT, Сингапур) совместно с Бхуванесвари У. из Standard Chartered (Индия), агент может действовать по каналам за пределами стандартного вызова инструментов, и до сих пор не существовало методологии, сопоставляющей такое покрытие с объективной реальностью на уровне ядра ОС.
Пути выполнения и пределы размещения
Организации, использующие агентов в рабочей среде, обычно развертывают специализированные защитные программные слои. Агентские шлюзы, такие как agentgateway, Envoy AI Gateway и Microsoft Agent Governance Toolkit, перехватывают сетевой трафик между управляющей средой агента и серверами инструментов. Движки ограничений вроде NeMo Guardrails и LlamaFirewall фильтруют входящие и исходящие данные модели на соответствие политикам безопасности, а системы управления политиками, такие как Progent и ActPlane, принимают решение о допустимости конкретного действия. Одновременно средства мониторинга, включая AgentSight и Tetragon, отслеживают поведение агента извне хост-процесса.
Что происходит, когда агент инициирует операционную команду в обход сетевого шлюза?
Подобные действия выполняются без какой-либо проверки. Шлюз, расположенный перед обвязкой агента, фиксирует запросы к инструментам с полным семантическим контекстом, однако обвязка способна запускать локальные серверы инструментов как дочерние процессы или открывать прямые сетевые соединения. Напротив, мониторинг на уровне ядра с использованием eBPF фиксирует практически каждое действие в дереве процессов агента, но записям eBPF не хватает содержимого полезной нагрузки, а процессы агента в них смешиваются с несвязанными системными процессами.
"guardscope работает в два этапа: статический этап прогнозирует, какие из 15 путей действий агента система контроля способна проверить, исходя из ее исходного кода, а эмпирический этап запускает фиксированную нагрузку на развертывании с одной из восьми топологий и классифицирует каждое выполненное действие как проверенное, обойденное или заблокированное путем сверки решений системы контроля с эталонными данными на уровне ядра".
Этот разрыв между архитектурным размещением и фактическим охватом среды исполнения объясняет, почему проверка исключительно на сетевом периметре оставляет инфраструктуру уязвимой для скрытых путей выполнения.
Верификация покрытия в различных топологиях систем
Чтобы сделать этот охват измеримым, исследователи разработали фреймворк тестирования guardscope, работающий в две фазы. На первом этапе статический анализ изучает исходный код инструмента контроля и прогнозирует, какие из 15 путей действий агента программа способна оценить. На втором этапе эмпирическая нагрузка запускает 15 сценариев действий в тестовом контуре с одной из восьми архитектурных топологий, сопоставляя отчеты инструмента контроля с системными логами ядра ОС.
"guardscope делает заявления вендоров о защитном покрытии верифицируемыми: разработчик систем контроля среды исполнения теперь может публиковать перечень проверяемых путей в рамках протокола, подтвержденного ядром ОС".
Сопоставляя записи журналов безопасности с реальными событиями в операционной системе, guardscope категоризирует каждое действие как проверенное, пропущенное в обход или заблокированное. В серии эмпирических тестов на базе агентских сред Pi и OpenClaw авторы проверили реальные инструменты защиты, развернув Agent Governance Toolkit от Microsoft в роли сетевого шлюза, ActPlane в качестве контроля уровня ядра и eBPF-сенсор Tracee для фиксации эталонных данных операционной системы. Тесты подтвердили расчетные ограничения покрытия для исследованных классов действий.
Корпоративные стратегии безопасности, опирающиеся исключительно на шлюзы, формируют слепые зоны на маршрутах выполнения, лежащих ниже сетевого уровня. По мере того как автономные агенты получают прямой доступ к инфраструктуре, компаниям необходимо проектировать архитектуру мониторинга с опорой на активность ядра ОС, а не рассчитывать на то, что изолированные инструменты перехватят каждую команду. Будущие стандарты внедрения обяжут поставщиков защитных решений подтверждать фактическое покрытие путей выполнения телеметрией уровня хоста.
Что не сходится
Компании ставят защитные шлюзы вроде Agent Governance Toolkit от Microsoft ради полного контроля над автономными агентами, но эти инструменты вслепую пропускают прямые вызовы и локальные дочерние процессы. Архитектурный разрыв бьет по самой идее надзора: сетевой экран видит семантику запроса, но бессилен против скрытых маршрутов, пока сенсоры ядра операционной системы на базе eBPF фиксируют системные события в дереве процессов, но теряют полезную нагрузку действий. Фреймворк guardscope показал это на 15 сценариях действий: проверка на прикладном уровне оставляет инфраструктуру уязвимой, если агент решает действовать в обход стандартного периметра. Красивые дашборды сетевой безопасности исправно рапортуют об успешной фильтрации запросов, пока сам агент спокойно запускает команды прямо под ними в обход шлюза.
Источник: arXiv cs.AI