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

Эти случаи объединяет не дефект модели и не неудачный ответ. Агент ни разу не вышел из своей песочницы и не нарушил ни одного правила. Произошло следующее: агент прочитал или записал файл внутри проекта, а затем доверенный инструмент, работающий вне песочницы, выполнил содержимое этого файла. Песочница выстояла. Компрометация обошла её.

Механизм: настройка производительности Git, которой уже много лет

Самый наглядный пример опубликовала компания Manifold Security 2 сентября 2026 года под названием GitSpawn. Он основан на настройке Git уровня проекта под названием core.fsmonitor — легитимной и документированной опции производительности, значением которой является команда, запускаемая Git для быстрого определения изменённых файлов вместо сканирования всего каталога.

Теперь соединим две половины:

  • ИИ-агент для программирования, начиная работу над проектом, автоматически запускает команды Git, такие как git status и git diff, чтобы понять состояние репозитория. Это нормальное и необходимое поведение.
  • Если в репозитории задано вредоносное значение core.fsmonitor, простой запуск этих команд выполняет команду злоумышленника.

В результате открытие репозитория кода перестаёт быть событием чтения и становится событием выполнения. Ни клика, ни одобрения, ни запроса, показанного разработчику. Согласно отчёту, уязвимыми оказались восемь агентов командной строки, и для нескольких из них вышли исправления: goose в 1.44.0, Claude Code в 2.1.196 для пути core.fsmonitor, Codex CLI в 0.131.0, а также Cursor. В отчёте отмечено, что четыре пути на момент публикации всё ещё не были исправлены. Этот класс отслеживался под идентификаторами, включая CVE-2026-72718, CVE-2026-19592 и CVE-2026-55607.

Не один инцидент, а целый класс

За шесть недель до GitSpawn исследователи Pillar Security опубликовали 20 июля 2026 года серию, которую назвали неделей побегов из песочницы, задокументировав семь уязвимостей в четырёх агентах для программирования от трёх поставщиков: Cursor, Codex, Gemini CLI и Antigravity. Их описание механизма стоит прочитать дважды. Агент остаётся внутри коробки и соблюдает все правила. Он лишь записывает файл, который доверенный инструмент за пределами коробки позже запускает, загружает или сканирует.

  • В Cursor файл конфигурации хуков, управляемый рабочим пространством, позволял выполнение за пределами песочницы; уязвимость отслеживается как CVE-2026-48124 и исправлена в версии 3.0.0.
  • В Codex CLI список разрешённых команд доверял git show только по имени, хотя переданные ему параметры могут сделать его не только читающим. Исправлено в версии 0.95.0.
  • Проблема с сокетом Docker одновременно затронула Codex, Cursor и Gemini CLI.
  • В Antigravity — обход списка запретов macOS Seatbelt и проблема с конфигурацией задач редактора; Google классифицировала обе как трудные для эксплуатации.

Затем 10 сентября 2026 года Upstarts Media сообщило о третьем раскрытии — от стартапа Accomplish — о протекающих песочницах в Claude Code, Codex и Cursor. Интересная цифра здесь не уязвимость, а время исправления: проблема Cursor была решена примерно за неделю, две проблемы OpenAI — в августе, тогда как проблема Anthropic заняла около пятидесяти дней и десятки релизов. Три исследовательские группы, три отчёта, два месяца, одна закономерность.

Почему это важно, даже если вы никогда не пишете код

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

На саудовском рынке этот сценарий не теоретический. Сверьте эти случаи со своей компанией:

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

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

Что сделать на этой неделе

Пять шагов, и первый не требует бюджета:

  1. Обновите инструменты агентов во всей команде сегодня. Исправления существуют для большинства этих инструментов, и ценность в том, чтобы на исправленной версии были все, а не один человек. Начните с того, чтобы знать, кто что запускает и в какой версии, потому что самого такого перечня обычно нет.
  2. Относитесь к входящему коду как к недоверенному содержимому. Код от подрядчика или из открытого источника — это не документ, который вы читаете, а то, что выполняется. Открывайте его в первый раз на машине или в контейнере, отделённом от рабочей сети.
  3. Отделите машину разработки от продакшн-ключей. Не храните токены рабочих серверов на машине, где открываются проекты из внешних источников. Тогда ущерб останется в пределах этого устройства.
  4. Проводите развёртывание через центральный конвейер, а не с личного ноутбука. Когда развёртывание проходит через один конвейер сборки с ограниченными правами, компрометация одной машины перестаёт быть путём в продакшн.
  5. Добавьте пункт в договоры на аутсорсинговую разработку. Вы вправе указать, как и из какого репозитория передаётся код, и потребовать от поставщика поддерживать его инструменты в актуальном состоянии. Это условие договора, а не технический спор.

На местном уровне ничто из этого не является необязательной хорошей практикой. Основные средства контроля кибербезопасности, выпущенные Национальным управлением кибербезопасности (NCA), включают отдельные домены для безопасности конечных устройств, безопасности управления изменениями и разработкой и безопасности третьих сторон, а ответственность за защиту персональных данных остаётся на организации в соответствии с Законом о защите персональных данных (PDPL). Если дверь открылась через машину разработчика, открывшую проект поставщика, это не уменьшает ответственности.

Взгляд Origami

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

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

Итог

Три независимых раскрытия за два месяца говорят об одном: ИИ-агент для программирования превращает открытие проекта из чтения в выполнение, и для этого достаточно, чтобы посторонний поместил одну строку в файл конфигурации. Для большинства инструментов вышли исправления, некоторые пути остались открытыми, но урок переживёт любой релиз. Любой инструмент, который вы запускаете на машине с высокими привилегиями, является частью вашей поверхности атаки, независимо от того, указан ли он в ваших политиках. Начните с одного вопроса: кто в вашей команде прямо сейчас запускает ИИ-агента, на какой машине и в какой версии?

Источники