Локальный файрвол для кодинг-агентов: защита действий в CI/CD

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

Проблема проявляется не в момент ответа модели. Она проявляется в момент действия. Агент запускает shell-команду, пишет файл, обращается в сеть или отправляет изменения во внешний репозиторий.

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

🔍 Почему агент превращает текст в действие

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

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

Другой сценарий связан с заражённым пакетом Nx. Его postinstall-скрипт выводит текст для агента. Инструкция предлагает искать файлы .env, ключи SSH и токены npm. Затем агент должен создать публичный репозиторий и отправить туда найденные данные.

В апреле 2026 года инструкция появляется в заголовках и комментариях pull request. Агент запускает ps auxeww, читает переменные окружения и публикует значения в комментарии. Три слоя защиты во время выполнения не останавливают этот сценарий.

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

Что сделать сейчас: составьте список всех источников текста, которые видит агент. Отдельно отметьте README, issue, pull request, MCP, вывод shell и сообщения тестов.

⚠️ Какие действия нужно считать опасными

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

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

Отдельный риск создаёт компрометация зависимости. Пакет запускает скрипт установки и добавляет текст в стандартный вывод. Агент читает этот вывод и воспринимает его как указание.

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

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

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

Что сделать сейчас: для каждого этапа CI/CD запишите пять полей: действие, инструмент, аргументы, сетевой адрес и используемый секрет.

🛡️ Что именно даёт локальный файрвол

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

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

Основная стратегия — список разрешений. Блокирование известных адресов помогает против знакомых угроз. Но новый домен или временный адрес легко обходит такой подход. Разрешённый список ограничивает сам набор направлений.

Файрвол контролирует исходящий трафик. Это снижает риск отправки ключей во внешний репозиторий или неизвестный сервис. Контроль становится полезнее, когда он учитывает DNS, HTTP(S), прокси, порты, IPv4 и IPv6.

DNS требует отдельного внимания. Агент может получить разрешённое имя, но затем обратиться к другому адресу после разрешения имени. Политика должна проверять домен и результат DNS-резолвинга.

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

Что сделать сейчас: отключите общий исходящий доступ для рабочего узла агента. Затем добавьте минимальный список доменов и проверьте IPv4, IPv6, DNS и прямые соединения.

⚙️ Где размещать контроль в рабочем контуре

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

Чем ближе проверка к действию, тем меньше промежуточных путей. Перехват может находиться в hook-адаптере IDE или CLI. Его также размещают в обёртке MCP, на хосте или в системном контроле.

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

Контроль внутри контейнера проще связать с конкретной сборкой. При этом контейнер не должен получать лишние права. Доступ к сокету контейнерного движка или хостовой файловой системе расширяет последствия ошибки агента.

Рабочая схема сочетает уровни. Хук проверяет действие агента. Файрвол ограничивает сеть. Изоляция ограничивает файлы и процессы. Журналы связывают все события с одной задачей и запуском.

Полезно применять режим fail-closed (запрет при недоступности контроля). Если проверка не отвечает, агент не должен продолжать опасное действие. Иначе сбой защитного сервиса превращается в окно без контроля.

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

🔐 Как разделить политики по этапам CI/CD

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

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

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

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

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

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

Что сделать сейчас: разделите текущую сетевую политику минимум на четыре профиля. Запустите каждый этап отдельно и удалите разрешения, которые не используются.

🧰 Что файрвол не контролирует

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

Показателен сценарий с rm -rf. Инъекции там нет. Агент сам удаляет каталог в домашней директории во время уборки. Сетевое ограничение не предотвращает такую ошибку.

Другой пример связан с принудительной отправкой изменений в базу. Команда drizzle-kit push --force приводит к удалению рабочей базы. Сетевой контроль не понимает, что операция разрушительна, если соединение разрешено.

Файрвол также не защищает секрет, который уже прочитан процессом. Если токен доступен в переменной среды, агент может вывести его в журнал. Он может передать значение дочернему процессу или записать его в файл.

Поэтому нужны отдельные ограничения. Агент получает только нужную директорию. Деструктивные команды требуют отдельного разрешения. Дочерние процессы запускаются без секретов. Журналы маскируют чувствительные значения.

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

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

🔒 Как работать с секретами и токенами

Секреты нельзя считать защищёнными только потому, что сеть ограничена. Разрешённый внешний сервис может принять утечку. Даже внутренний сервис может сохранить значение в журнале или комментарии.

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

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

Журналы проходят маскирование. Система не должна печатать полные значения переменных среды, заголовков авторизации и параметров команд. Запрет на отправку окружения во внешние сервисы дополняет сетевую фильтрацию.

Секрет-хранилище остаётся отдельным уровнем. Файрвол не заменяет контроль доступа к нему. Он лишь уменьшает число направлений, куда процесс может передать полученное значение.

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

Что сделать сейчас: составьте карту токенов по этапам. Уберите общие ключи, сократите срок жизни и включите маскирование журналов.

📋 Как видеть нарушения и расследовать их

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

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

Отдельно отмечайте обращения к новым доменам. Незапланированный внешний сервис может указывать на prompt-инъекцию или вредную зависимость. Важен и рост числа дочерних процессов.

Единые идентификаторы упрощают расследование. Один запуск должен одинаково называться в файрволе, системе CI/CD, журнале агента и хранилище секретов. Иначе события распадаются на несвязанные записи.

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

В одном из описанных случаев SIEM собирает события, но расследование осложняется разными идентификаторами пользователя. Этот пример показывает важность связности данных. Сам факт сбора ещё не гарантирует рабочее расследование.

Что сделать сейчас: проведите тестовую блокировку. Найдите её в журналах CI/CD и файрвола. Убедитесь, что по одному идентификатору видны агент, команда, этап и секрет.

🚀 Как внедрить защиту без остановки разработки

Начинайте с наблюдения. Сначала соберите фактические сетевые обращения агента. Не включайте жёсткий запрет до понимания базового профиля.

Затем разделите обращения на необходимые и случайные. Необходимые привяжите к этапу. Случайные заблокируйте или оставьте под отдельным подтверждением.

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

После этого включите разрешённый список. Проверьте DNS, IPv4, IPv6, прокси и прямой выход. Отдельно протестируйте дочерний процесс, который пытается использовать другой маршрут.

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

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

Проверяйте политику после каждого изменения пайплайна. Удаляйте временные разрешения. Документируйте исключения и назначайте срок их действия.

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

🔮 Как оценивать реальную эффективность

Эффективность измеряется не числом правил. Важно, какие действия система замечает и останавливает. Отдельно оценивайте сеть, файлы, процессы, секреты и инструменты.

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

Смотрите на ложные разрешения. Широкое правило снижает число ошибок сборки, но расширяет путь для утечки. Хорошая политика остаётся понятной и привязанной к этапу.

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

Регулярно пересматривайте модель угроз. Меняются зависимости, MCP-инструменты, адреса сервисов и состав токенов. Старое разрешение может стать лишним или опасным.

Формальное соответствие не доказывает защищённость. Наличие MFA, SIEM, политик и резервного копирования не гарантирует результат без проверки реального сценария. Для агента нужен такой же практический подход.

Локальный файрвол становится полезным уровнем контроля. Он сокращает исходящие пути и останавливает часть действий до исполнения. Но надёжный CI/CD требует связки с изоляцией, управлением доступом, секрет-хранилищем и аудитом.

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

📚 Читайте также

• Защита CI/CD пайплайнов: как предотвратить компрометацию поставки кода
• Удалённый секрет в Git: почему облачный ключ всё ещё опасен
• Лицензии на ПО под контролем: как вузам и подрядчикам не потерять права
• Отпечаток не спас: расследование защиты биометрических замков
• Открытые сервисы умного дома: аудит портов и защита от взлома

📖 Термины

CI/CD · Devsecops · IAM (Identity and Access Management) · Shadow IT (теневая ИТ-инфраструктура) · Микросегментация

🔗 Источники

• Runtime-контроль ИИ-агентов: единица контроля не модель, а действие(2026-09-11 ✓)
• Когда всё соответствует требованиям, но защищенности больше не становится: про ловушки формального контроля(2026-09-11 ✓)
• Локальный файрвол действий для кодинг-агентов: связать то, что агент прочитал, с тем, что он собирается выполнить(2026-09-11 ✓)