Дружественный огонь и агент-отступник: Новая граница безопасности для ИИ-агентов программирования

Введение

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

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

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

Ключевой вывод

Общий сигнал, стоящий за Дружественным огнем и Агентом-отступником, прост: непроверенный контекст может стать опасным, когда агент воспринимает его как источник полномочий.

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

Для использования в продакшене агент не должен быть окончательным авторитетом в вопросе разрешения вызова инструментов. Он может предложить действие. Уровень разрешений, песочница, политика безопасности и человек-контролер должны решать, разрешено ли действие на самом деле.

Почему важен Дружественный огонь

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

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

Важный урок — не паниковать по поводу инструментов ИИ-безопасности. Нужно отделять доказательства от авторизации.

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

Рискованный шаблон выглядит так:

./security.sh

Сама команда может выглядеть безобидной, но важный вопрос — откуда она взялась. Была ли она явно запрошена пользователем? Была ли предложена моделью? Была ли скопирована из стороннего README? Была ли встроена в комментарий к проблеме или скрипт зависимости? Эти источники не должны иметь одинаковый уровень доверия.

Урок для платформы от Агента-отступника

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

Платформа, где разговорные агенты могут выполнять блоки кода внутри управляемой среды выполнения.

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

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

Общий тип отказа

«Дружественный огонь» и «Непослушный агент» — это разные инциденты, но они указывают на один и тот же тип отказа: недоверенный контекст получает операционные полномочия.

В сценарии «Дружественный огонь» недоверенное содержимое репозитория может влиять на агента, заставляя его выполнять команды. В сценарии «Непослушный агент» выполнение кода на платформе агента может влиять на общее поведение среды выполнения и чувствительные данные диалогов. Исследования, связанные с MCP, также подняли аналогичную проблему: пользовательский интерфейс одобрения и метаданные, которые модель фактически получает, не всегда могут отражать одну и ту же картину доверия.

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

Более безопасная архитектура разделяет три уровня:

1. Рассуждение модели: агент читает файлы, предлагает действия и объясняет риски.
2. Применение политик: внешний уровень решает, какие действия разрешены.
3. Изоляция выполнения: песочница ограничивает ущерб, даже если было одобрено неверное действие.

Рекомендуемая архитектура

1. Изолируйте рабочее пространство

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

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

Хорошие настройки по умолчанию включают:

• отсутствие монтирования личного домашнего каталога
• отсутствие долгоживущих облачных учётных данных
• отсутствие токена менеджера пакетов по умолчанию
• отсутствие неограниченного исходящего сетевого доступа
• временные кеши пакетов
• строгие ограничения по времени и ресурсам
• полное ведение журнала команд

2. Разделите рабочий процесс агента на этапы

Не позволяйте чтению, редактированию и выполнению сливаться в один автоматический поток. Разделите их.

Этап чтения: агент может просматривать файлы, выявлять риски и составлять план.

Этап внесения изменений: агент может генерировать diff или патч, в идеале без выполнения недоверенных скриптов.

Этап выполнения: агент может выполнять только одобренные команды из узкого списка разрешений, с тайм-аутами и ограничениями ресурсов.

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

ясно. Команда, предложенная репозиторием, не равна команде, явно запрошенной пользователем.

3. Выполняйте детерминированное сканирование до оценки модели

AI-агенты полезны для объяснения и сортировки, но детерминированные инструменты, где возможно, должны запускаться в первую очередь.

Например:

• сканирование на наличие секретов перед выполнением любой команды
• проверка уязвимостей зависимостей перед скриптами установки
• обнаружение бинарных файлов перед запуском инструментов репозитория
• статический анализ перед интерпретацией модели
• проверка diff-файла блокировки перед обновлением пакетов
• проверка жизненного цикла скриптов перед установкой зависимостей

Агент может обобщать и ранжировать результаты. Он не должен заменять базовые сканеры.

Процедура работы со сторонним кодом

Для ненадежных репозиториев самое безопасное правило — сначала проверять, а не выполнять.

1. Клонируйте репозиторий в чистую одноразовую среду.
2. Отключите помощники для учетных данных и избегайте монтирования секретов хоста.
3. Используйте временные кеши пакетов.
4. Ограничьте доступ к родительским каталогам.
5. Позвольте агенту читать файлы и составить план рисков.
6. Просмотрите скрипты жизненного цикла перед установкой зависимостей.
7. Попросите агента объяснить источник и назначение каждой команды, которую он хочет выполнить.
8. Выполняйте только одобренные команды с ограничениями по времени, сети и файловой системе.
9. Возвращайте только проверенные артефакты: исправления, отчеты и примечания для воспроизведения.
10. Не забирайте из «песочницы» кеши пакетов, сгенерированные бинарные файлы, историю команд или состояние выполнения.

Полезное правило просто: чем меньше вы доверяете входным данным, тем меньше полномочий должно быть у агента.

Как продуктовые команды должны проектировать разрешения для AI-агентов

Одного переключателя «безопасный режим» недостаточно. Реальным продуктам нужны разрешения на уровне возможностей.

Лучшая модель разрешений рассматривает каждую возможность отдельно:

Возможность	Рекомендуемый режим по умолчанию	Почему это важно
Чтение файлов	Разрешено в ограниченном рабочем пространстве	Агентам нужен контекст, но не вся машина.
Запись исправлений	Разрешено после проверки плана	Написание кода безопаснее, чем его выполнение.
Запуск тестов	Только из разрешенного списка	Тестовые команды могут вызывать произвольные скрипты.
Установка зависимостей	Требуется одобрение	Скрипты жизненного цикла пакетов — это серьезная поверхность риска.
Доступ к сети	По умолчанию запрещен для ненадежной работы	Предотвращает утечку данных и загрузку удаленных полезных нагрузок.
Доступ к секретам	По умолчанию запрещен	Секреты не должны быть видны ненадежным задачам.
Создание pull request'ов	Требуется одобрение	PR могут повлиять на доверенные репозитории и CI-системы.
Развертывание	Требуется ручное одобрение	Развертывание — это действие, влияющее на производственную среду.

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

Что это значит для рабочих процессов NxCode

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

Практический подход — классифицировать задачи на три группы:

1. Низкорисковая работа в доверенной среде

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

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

3. Операции, влияющие на продуктивную среду
   Примеры: развёртывание, миграции баз данных, ротация секретов, изменения инфраструктуры и обновления разрешений CI/CD. Такие задачи требуют одобрения человека и надёжных журналов доказательств.

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

Примечания к источнику

• Исходный язык: китайский.
• Язык вывода: английский.
• Работа с изображениями: исходная страница содержит общее изображение для карточки блога и логотип NxCode, но не содержит уникальных скриншотов тела статьи, диаграммы рабочего процесса или результирующих изображений, которые критически необходимы для тела статьи. Эти общие/навигационные изображения не были вставлены в тело Markdown.
• Обработка рекламы/навигации: навигация по продуктам, ссылки в нижнем колонтитуле, рекламные блоки CTA и несвязанные модули сайта были исключены.
• Примечание об авторских правах: итоговая статья представляет собой англоязычную переработанную и реорганизованную версию для публикации, а не дословную копию исходной страницы.

Часто задаваемые вопросы

Что такое «дружественный огонь» в безопасности ИИ-агентов кодирования?

«Дружественный огонь» относится к шаблону риска, при котором ИИ-агент, используемый для защитной работы, подвергается влиянию недоверенного содержимого кодовой базы. Агент может прочитать сторонний репозиторий и воспринять инструкции из документации или скриптов как безопасные операционные указания.

Что такое Rogue Agent?

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

Почему ИИ-агенты кодирования уязвимы для инъекций подсказок?

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

Достаточно ли изоляции для защиты ИИ-агентов кодирования?

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

Должны ли ИИ-агенты запускать команды из файлов README?

Не автоматически. Команды из README могут быть полезной документацией, но они исходят из проверяемого репозитория. Для недоверенных проектов агент должен объяснить источник команды и риск, прежде чем выполнение будет одобрено.

Как командам следует обрабатывать сторонние репозитории с помощью ИИ-агентов?

Используйте одноразовую среду, избегайте монтирования секретов, ограничьте сетевой доступ, сначала выполняйте статические проверки и извлекайте только проверенные патчи или отчёты. Не считайте состояние изолированной среды или сгенерированные артефакты доверенными по умолчанию.

какие разрешения должны предоставлять ИИ-продукты для написания кода?

Продукты должны предоставлять детализированные элементы управления для чтения файлов, записи патчей, запуска тестов, установки зависимостей, использования сети, доступа к секретам, создания pull request'ов и развертывания. Каждая возможность должна иметь свою собственную область действия, бюджет, журналы и правила утверждения.

Связанные инструменты

• Claude Code: Инструмент агентного программирования от Anthropic для чтения, редактирования и работы с кодом.
• OpenAI Codex: Платформа агентного программирования от OpenAI с концепциями изоляции и утверждения.
• Google Dialogflow CX: Платформа диалоговых агентов от Google Cloud, включающая плейбуки и возможности работы с блоками кода.
• Docker: Распространенный способ создания одноразовых сред разработки и тестирования.
• Semgrep: Инструмент статического анализа, который может сканировать исходный код перед выполнением агентом.
• GitHub CodeQL: Движок семантического анализа кода, полезный для рабочих процессов проверки безопасности.

Связанные ссылки

• AI Now Friendly Fire Research: Краткий обзор исследования оборонительных ИИ-агентов и риска удаленного выполнения кода.
• Varonis Rogue Agent Disclosure: Техническая статья об уязвимости Rogue Agent в Dialogflow CX.
• Claude Code Security Documentation: Официальное руководство по безопасности для Claude Code от Anthropic.
• Claude Code Auto Mode: Объяснение Anthropic режима Auto Mode и решений о разрешениях в Claude Code.
• OpenAI Codex Sandbox Documentation: Официальное объяснение того, как Codex использует границы изоляции.
• OpenAI Codex Auto-review: Официальная документация по поведению авторевью в Codex.
• Dialogflow CX Code Blocks: Документация Google Cloud по блокам кода Python в плейбуках Dialogflow CX.

Резюме

Friendly Fire и Rogue Agent показывают, что безопасность ИИ-агентов — это не только проблема выравнивания моделей. Практическая граница — это среда выполнения: файлы, команды, сетевой доступ, секреты, среды выполнения и возможность аудита.

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

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