Исследователи безопасности продемонстрировали, что из «песочниц», защищающих четыре широко используемых агента кодирования искусственного интеллекта — Cursor, OpenAI’s Codex, Google’s Gemini CLI и Antigradity, — можно выйти, даже не атакуя «песочницу» в лоб. Результаты, опубликованные 20 июля 2026 года исследовательской группой Pillar Security и опубликованные BleepingComputer, раскрывают структурную слабость того, как инструменты кодирования ИИ изолируют код, генерируемый их агентами, от машин разработчиков, на которых они работают.

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

Как работают побеги

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

Но они не инертны. Инструменты, работающие за пределами «песочницы», постоянно читают эти файлы и обрабатывают их. Интегрированные среды разработки поддерживают интерпретаторы Python, интеграции Git сканируют репозитории, VS Code запускает файлы задач, запускает команды перехватчиков, а Docker Desktop предоставляет локальный сокет. Агент в песочнице может подчиняться каждому заданному ему правилу и при этом записывать файл, который позже выполняет, загружает или сканирует один из этих внешних инструментов.

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

Триггер: быстрая инъекция

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

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

«Неделя побегов из песочницы»

Исследовательская группа Pillar Security — Эйлон Коэн, Дэн Лисичкин и Ариэль Фогель — воспроизводила обходные пути в течение нескольких месяцев и публиковала их в виде серии, которую они называют «Неделя побегов из песочницы», выпуская по одной рецензии в день. Исследователи рассортировали свои семь выводов по четырем различным режимам отказа.

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

Четыре затронутых инструмента — Cursor, OpenAI’s Codex, Google Gemini CLI и Antigradity — представляют собой широкий срез рынка агентов кодирования AI, от потребительских плагинов IDE до корпоративных инструментов командной строки. Такая широта предполагает, что проблема не в ошибке в каком-то отдельном продукте, а в общем архитектурном предположении, которое исследование опровергает.

Почему это важно для агентской экономики

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

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

Сложная проблема доверенных файлов

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

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

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

Будьте впереди ИИ

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

Читать больше новостей об искусственном интеллекте