OpenAI щойно випустила codex-security на GitHub — сканер, який можна встановити через npm, що проводить триетапний аналіз репозиторію та намагається автоматично виправляти помилки.
Те, що замовчується під час цього запуску, — це глибша вада, яку нещодавно виявили демонстрації обходу пісочниці (sandbox bypass). Дослідники показали, що агенти, які працюють у «заблокованих» середовищах для таких інструментів, як Cursor, Codex CLI, Gemini CLI та Google Antigravity, все ще можуть вийти за межі передбаченого захисту, експлуатуючи ті самі інтерфейси, що з'єднують пісочницю з хост-системою. Новий сканер OpenAI не зачіпає цю поверхню атаки.
Як працюють ці обходи
Агенти залишаються всередині своїх контейнерів, але все, що вони записують на диск, одразу вважається надійним зовнішніми помічниками — git hooks, розширеннями Python, демонами Docker та подібними сервісами. Ці помічники зчитують файли, сприймають їх як легітимні та виконують на хості без запиту користувача.
- Cursor дозволив агенту зареєструвати git hook, який запускався поза межами пісочниці.
- Codex CLI не зміг перевірити параметри в командах git, що відкрило шлях для довільного виконання коду.
- Кілька агентів отримали прямий доступ до Docker socket — привілейованої точки входу, яка дозволяє коду запускати контейнери на хост-машині.
- Уразливості DuneSlide дозволяють зловмиснику перезаписати компонент, який забезпечує роботу пісочниці, фактично повністю прибираючи цей бар'єр.
У кожному випадку експлойт спрацьовував непомітно — через результат пошуку в інтернеті або відповідь від інструмента multi-choice-prompt (MCP), яку споживав агент. Шкідливе навантаження виконувалося, зникало і ніколи не з'являлося під час статичного сканування коду.
Чому інструмент OpenAI не вирішує проблему
Codex-security зосереджується на статичному аналізі: він перевіряє вихідні файли, які ви комітите, позначає небезпечні патерни та може автоматично їх переписувати. Такий підхід дозволяє виявити недбалий або небезпечний код перед релізом, але він сканує код, який ви відправляєте, тоді як атаки відбуваються в середовищі виконання (runtime) самого агента.
Обходи пісочниці показують, що справжня небезпека полягає в runtime-мості між ШІ-пісочницею та рештою інструментарію розробника. Зловмиснику не потрібно впроваджувати шкідливий код у репозиторій; йому достатньо переконати агента в пісочниці записати файл, який згодом виконає зовнішній процес.
Хто виграє, а хто програє
- Розробники
- Постачальники інструментів
- OpenAI
- Зловмисники
Що спільнота може зробити зараз
Важливі виправлення стосуються операційної діяльності, а не лише рівня коду. Ось практичні кроки, яких варто дотримуватися кожному, хто інтегрує ШІ-агента для програмування:
- Фіксуйте версії агентів (pin versions) і читайте списки змін перед оновленням. Нові релізи можуть ненавмисно відкрити новий hook або socket.
- Ставтеся до «clone and explore» як до запуску невідомого коду. Ніколи не спрямовуйте агента на репозиторій, який ви не контролюєте, без додаткової ізоляції.
- Аудитуйте кожен допоміжний інструмент (git hooks, розширення Python, доступ до Docker). Якщо інструмент може змінювати директорію або symlink на основі виводу агента, вважайте, що його можна використати як зброю.
- Видаліть доступ до Docker socket із пісочниці.
- Запитуйте, що і що зчитує. Складіть карту потоків даних від пісочниці до хоста; будь-який процес, який споживає файли, записані агентом, має бути ретельно перевірений.
Контраргумент: чому codex-security все ще важливий
Сканер покращує одну сторону проблеми, але він не замінює необхідності зміцнення runtime-мосту.
За чим стежити далі
- Посібники зі зміцнення безпеки від спільноти, які каталогізують безпечні конфігурації для поширених інструментаріїв розробників у поєднанні з ШІ-агентами.
Заголовок може святкувати появу нового сканера безпеки, але справжня історія полягає в тому, що пісочниця ШІ-агента для програмування — це лише фасад, якщо навколишня екосистема продовжує довіряти всьому, що він записує. Наступна хвиля захисту має вийти за межі коду і зосередитися на конвеєрах (pipelines), які його виконують.