ИИ-агенты могут сбегать из «песочниц», даже не взламывая их

ии-агенты песочницы уязвимости безопасность Cursor Codex csoonline.com

ИИ-агенты в Cursor, Codex и Gemini CLI обходят песочницы без взлома. Узнайте, как конфигурации и скрипты становятся векторами атак, и внедрите новую модель безопасности для агентной разработки.

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

Компания Pillar Security раскрыла серию уязвимостей, демонстрирующих, как агенты в таких инструментах, как Cursor, Codex, Gemini CLI и Antigravity, могут косвенно пересекать границы безопасности, технически не покидая свои песочницы.

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

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

«CISO и специалистам по закупкам безопасности нужно осознать, что для агентной IDE или CLI недостаточно просто иметь песочницу, — отметили исследователи, добавив, — важно знать, где на самом деле проходит ее граница».

Побег из песочниц без их взлома

Pillar поставила под сомнение базовое понимание песочниц в ИИ-ассистированной разработке. Вместо побега через эксплуатацию ядра или контейнеров продемонстрированные атаки использовали косвенный механизм.

Во всех показанных векторах атак агент остается в изоляции, создавая файлы, которые затем потребляются доверенными приложениями на стороне хоста.

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

Разные побеги из песочниц для разных агентов

Pillar продемонстрировала эту закономерность на нескольких ИИ-инструментах для написания кода, используя разные техники. В Antigravity исследователи эксплуатировали слабости профиля macOS Seatbelt в стиле черного списка и злоупотребляли конфигурациями задач VS Code, которые позже выполнялись за пределами песочницы. В Cursor, в свою очередь, было показано доверие к созданным агентом виртуальным средам Python, альтернативным каталогам Git и конфигурациям хуков рабочей области, которые в итоге выполнялись с привилегиями хоста.

Исследователи также обнаружили общий путь побега, затрагивающий Cursor, Codex CLI и Gemini CLI через привилегированный демон Docker Desktop, позволяющий агентам в песочнице выполнять команды за пределами своих ограниченных сред.

В другом выводе по Codex CLI supposedly безопасный белый список Git мог быть манипулирован для изменения конфигурации репозитория и запуска выполнения кода на более позднем этапе.

Агентная разработка требует иной модели безопасности

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

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

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

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

Похожие новости: