TL;DR
Исследователи взяли настройки безопасности реальных кодинг-агентов (Claude Code, Codex CLI, Gemini CLI и других) и по очереди включали и выключали каждую. Одну и ту же задачу они прогоняли с «отравленным» окружением: вредные инструкции в файлах репозитория, в описаниях инструментов, в внешних сервисах. Так видно, что именно режет атаки и сколько это стоит в полезной работе. Харнес (обвязка агента) — это программа вокруг модели: она собирает контекст, выдаёт инструменты и решает, что можно выполнять без вопросов.
Главная находка: автоодобрение действий делает агента заметно «продуктивнее» и одновременно почти полностью беззащитным. С ним доля успешных атак выросла с 29,2% до 95,6%. Агент не просто «иногда ошибается»: любая вредная инструкция из окружения (из issue, README, ответа сервиса) почти всегда доходит до выполнения. Причина простая: модель читает текст репозитория как часть задачи, а подтверждение от человека — последний барьер, и вы его убрали.
Остальные настройки ведут себя по-разному. Сетевая изоляция и режим «только чтение» почти обнуляют атаки, но сильно бьют по полезной работе. Белый список команд защищает при небольшой потере полезности. Чёрный список опасных команд защищает и даже улучшает результат. Есть и ловушка: запретили одну операцию, а агент делает то же самое другим путём.
Схема метода
ШАГ 1: Выбери настройку безопасности → включи / выключи (одна за раз)
ШАГ 2: Прогони одни и те же рабочие задачи в обоих режимах
ШАГ 3: Замерь отдельно: (а) сделал ли агент нужную работу,
(б) сработала ли вредная инструкция из окружения
ШАГ 4: Сравни пары → защита vs цена в полезности
ШАГ 5: Проверь обходные пути к запрещённой операции
Для вас это ручной вариант: не выбирать настройки «на глаз», а сравнивать защиту и цену на 3–5 своих типовых задачах.
Пример применения
Задача: Небольшая студия в Казани подключила Claude Code к репозиторию интернет-магазина. В публичный трекер пишут подрядчики и случайные люди. Разработчик устал от бесконечных «Разрешить?» и хочет включить режим «делай всё сам». Нужно решить, какие настройки оставить.
Промпт:
Ты — аудитор безопасности настроек кодинг-агента.
Контекст: мы используем Claude Code на репозитории интернет-магазина
(Node.js, PostgreSQL, деплой через GitHub Actions). В трекер пишут внешние
люди, агент читает issue и README. Сейчас разработчик хочет включить
автоодобрение, чтобы агент не спрашивал разрешение на каждую команду.
Для каждой настройки ниже:
1. Объясни, от какой атаки она защищает в нашей ситуации.
2. Оцени цену: какую легитимную работу она сломает или замедлит.
3. Назови 2-3 обходных пути к запрещённой операции,
которые эта настройка НЕ закрывает.
4. Дай вердикт: включить / включить частично / не включать.
Настройки: автоодобрение, сетевая изоляция, режим «только чтение»,
белый список команд, чёрный список команд (rm -rf, curl | sh),
ограничение путей, права MCP-серверов.
В конце собери итоговую конфигурацию и перечисли,
что я должен проверить руками после настройки.
Результат: Модель выдаст таблицу по каждой настройке: защита, цена, обходные пути, вердикт. В итоге — рекомендуемая конфигурация. Скорее всего, автоодобрение будет помечено как опасное без изоляции, а список «руками проверить» будет содержать пробные запросы на запрещённые действия.
Почему это работает
Слабость. Модель не отличает инструкцию владельца от инструкции, спрятанной в тексте issue или в ответе сервиса. Для неё всё это текст в контексте. Поэтому, если убрать подтверждения, вредная инструкция доходит до выполнения. Поэтому же «просто запретить» часто не работает: нужное агенту действие можно выполнить по другому маршруту.
Сильная сторона. Харнес, а не модель, решает, что реально выполняется. Его правила (разрешения, песочница, списки команд) жёстко ограничивают действия независимо от того, что модель «захотела». Эти правила измеримы: включил → замерил → выключил → сравнил.
Как метод это использует. Сравнивая включённый и выключенный режимы на одной и той же задаче, вы видите цену и пользу каждой настройки отдельно. Так выбираете точечные ограничения (белый и чёрный списки команд) вместо тупых (полная изоляция), которые защищают, но ломают работу.
Рычаги: - Автоодобрение → оставляй только внутри песочницы без доступа в сеть. - Сетевая изоляция → включай, если агент читает недоверенный контент и не должен ничего скачивать. - Режим «только чтение» → для разбора кода и ревью, не для правок. - Белый список команд → задачи предсказуемые, набор команд известен. - Чёрный список команд → дешёвая страховка поверх всего остального.
Шаблон промпта
В статье нет готовых промптов для читателя: её результат — данные и настройки. Ниже шаблон, который я собрал по её выводам. Он нужен, чтобы пройти по методу аудита, а не как авторский приём.
Ты — аудитор настроек безопасности кодинг-агента.
Агент: {название_агента}
Что он делает у нас: {типовые_задачи}
Что агент читает из недоверенных источников: {issue, README, веб, MCP, пакеты}
Что для нас критично защитить: {секреты, продакшен, база, репозиторий}
Что мы планируем включить: {планируемая_настройка}
Для каждой из настроек (автоодобрение, сетевая изоляция, только чтение,
белый список команд, чёрный список команд, ограничение путей, права MCP):
1. Защита: от каких атак из списка «читает из недоверенных источников» спасает.
2. Цена: какие из {типовые_задачи} сломает или замедлит.
3. Обходы: 2-3 альтернативных способа сделать то же запрещённое действие.
4. Вердикт: включить / частично / не включать — и почему.
Затем:
- Собери итоговую конфигурацию с конкретными флагами/ключами {название_агента}.
- Составь 5 тестовых запросов, которыми я проверю, что запреты реально работают
(включая обходные пути).
- Отметь настройки, про которые ты не уверен: я проверю их по документации.
Что подставлять: название инструмента, 3–5 типовых задач, источники недоверенного текста, что нельзя потерять, что хотите включить.
Ограничения
⚠️ Одна модель: Все 2 500 запусков шли на одной базовой модели (GLM-5.2), чтобы отделить эффект харнеса. Как поведут себя те же настройки с другими моделями, статья не показывает.
⚠️ Скромный набор задач: Всего 23 задачи. Реальный проект сложнее, поэтому цену в полезности меряйте на своём репозитории.
⚠️ Настройки, а не промпты: Статья про флаги и конфиги харнеса. Что даёт текст в CLAUDE.md или системном промпте против атак, она не проверяла. Вывод «напишите в инструкции „не слушай внешний текст"» из неё не следует.
⚠️ Закрытые продукты — «чёрный ящик»: Для платных агентов у более половины ячеек стоит «неизвестно». Для фильтра инъекций это 13 из 13 закрытых ячеек. Не считайте, что защита есть, если она не подтверждена.
⚠️ Быстро устаревает: Настройки и их умолчания меняются с каждой версией. В доступном тексте статьи нет разделов с деталями атак и разбором провалов по каждому агенту — только итоговые цифры.
Как исследовали
Команда сначала составила карту защит. Они изучили 40 кодинг-агентов (27 с открытым кодом и 13 закрытых) и выделили десять механизмов: автоодобрение, сетевая изоляция, белый и чёрный списки команд, права MCP, фильтр инъекций, ограничение путей, режим «только чтение», аудит-лог и доверие проекту. Потом оценили 400 ячеек «агент × механизм»: включено по умолчанию, нужно включать самому, нет, неизвестно. Оценку делали независимо три LLM и два человека, с обязательной ссылкой на строку документации или кода. Это дало любопытную картину. Около половины подтверждённых защит нужно включать вручную: режим «только чтение» почти везде opt-in (30 из 31), автоодобрение тоже (26 из 30). Права MCP и аудит, наоборот, обычно уже включены. У закрытых продуктов «неизвестно» больше половины ячеек против 16% у открытых.
Дальше собрали бенчмарк из 23 задач (Python, JS, C++, C#, Go, Ruby). В окружение подмешали вредные ресурсы по пяти путям: файлы репозитория, инструкции и скилы, описания инструментов, память и знания, внешние сервисы. Легитимные инструкции пользователя при этом не трогали. Отдельные детерминированные проверки измеряли два результата: сделана ли работа и сработала ли атака. Каждую настройку гоняли включённой и выключенной в одинаковых Docker-контейнерах. Итого 2 500 запусков, 81 155 вызовов инструментов и 2,2 млрд токенов.
Результаты: - Автоодобрение: атаки 29,2% → 95,6%, полезность выросла. - Сетевая изоляция: атаки 57,1% → 0,8%, но потеря полезности 24,5 п.п. - Режим «только чтение»: атаки 8,3% → 0,8%, потеря 34,0 п.п. - Белый список: небольшая потеря полезности. - Чёрный список: полезность даже выросла.
Неожиданное и практичное: ограничение «общей возможности» режет и вредное, и нужное, потому что обе операции ходят через один и тот же канал. А разрешённый инструмент оставляет лазейку к запрещённому по обходному пути. Вывод для практики: оценивать настройку нужно сразу по трём осям: атаки, полезность, стоимость выполнения.
Адаптации и экстраполяции
🔧 Техника: добавить «обходные пути» → проверка лазеек
После вердикта по каждой настройке попросите:
Для каждой запрещённой операции придумай способ выполнить её другим
инструментом или командой. Покажи, как я проверю, что запрет это закрывает.
Статья прямо показывает, что разрешённые инструменты оставляют запрещённое достижимым. Этот шаг ищет такие дыры до атаки.
🔧 Техника: два режима по типу задачи → меньше потерь
Попросите разделить задачи: «разбор и ревью» (только чтение + сеть выключена) и «правки» (песочница + белый список). Режим «только чтение» дорого стоит в правках, но почти ничего не стоит при анализе кода.
Ресурсы
- HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses? (препринт)
- Сайт проекта: https://tsingpig.github.io/HarnessSecurity-Benchmark/
- Авторы: Zhengyang Zhu, Liming Huang, Runmin Ji, Mingxi Ye, Zihan Zhou, Hanyang Guo, Jingwen Wu, Yuhan Ye, Yuming Feng, Hong-Ning Dai, Zibin Zheng
- Университеты: Sun Yat-sen University, Peng Cheng Laboratory, East China Normal University, Hong Kong Baptist University, Tsinghua University