Безопасность автономных кодеров: модели угроз и меры по их смягчению в 2026 году

Безопасность автономных кодеров: модели угроз и меры по их смягчению в 2026 году

По состоянию на 17 августа 2026 года, автономные агенты для написания кода больше не ограничиваются лишь предложениями кода. Современные системы могут инспектировать репозитории, редактировать файлы, выполнять команды оболочки, устанавливать зависимости, получать доступ к внешним службам, изменять конфигурацию, открывать запросы на слияние (pull requests) и иногда взаимодействовать с инфраструктурой развертывания. GitHub описывает своего облачного кодирующего агента как автономную систему, которая может отправлять изменения и выполнять проверку безопасности, в то время как Anthropic описывает кодирующих агентов как системы, зона поражения которых должна контролироваться с помощью песочниц, виртуальных машин, файловых системных границ и сетевых ограничений. (docs.github.com)

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

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

Основной риск заключается не просто в том, что модель может генерировать небезопасный код. Большая опасность состоит в том, что злоумышленник может разместить инструкции внутри репозитория, задачи (issue), запроса на слияние (pull request), зависимости, ответа инструмента или файла памяти и убедить агента использовать его легитимные разрешения против организации.

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

Краткое изложение

Самые важные уроки 2025 и 2026 годов:

1. Инъекция подсказок (prompt injection) — это проблема авторизации, а не только языковая проблема. Вредоносный заголовок задачи становится гораздо более серьезным, когда агент может выполнять команды оболочки или получать доступ к учетным данным для выпуска.
2. Разрешения для инструментов важнее, чем намерения модели. Осторожная модель с неограниченным доступом к оболочке, файловой системе и сети все равно может привести к серьезному инциденту.
3. Секреты не должны попадать в среду агента, если нет более безопасной альтернативы. Редактирование после утечки слабее, чем полное предотвращение доступа.
4. Конфигурационные файлы агента являются частью поверхности атаки. Хуки, определения инструментов, настройки рабочего пространства и конфигурация протокола контекста модели (Model Context Protocol) могут выполнять код или изменять поведение безопасности.
5. Контроль цепочки поставок должен включать навыки, инструменты, расширения, контейнеры, обновления моделей, кэши сборки и рабочие процессы агентов.
6. Человеческое одобрение полезно, но не может быть основной границей безопасности. Anthropic сообщил, что пользователи одобрили примерно 93 процента запросов на разрешения, что создает усталость от одобрений. (anthropic.com)
7. Самый безопасный вариант по умолчанию — это поэтапная автономия: позвольте агенту предлагать и тестировать изменения, но поместите коммиты, развертывание, публикацию, запись в производственные системы и использование учетных данных за независимым механизмом принудительного применения политик.

Что такое автономный кодирующий агент?

Автономный кодирующий агент обычно состоит из нескольких компонентов:

• Большая языковая модель, которая интерпретирует цели и планирует работу.
• Слой оркестрации, который решает, какие инструменты вызывать.
• Инструменты для работы с файлами и репозиториями.
• Оболочка или среда выполнения кода.
• Менеджеры пакетов и инструменты сборки.
• Коннекторы к системам контроля версий, трекерам задач (issue trackers), облачным службам и базам данных.
• Дополнительные инструменты для браузера, поиска или протокола контекста модели (Model Context Protocol).
• Постоянная память или файлы инструкций.
• Учетные данные и токены, разрешающие внешние действия.
• Системы логирования, одобрения и политик.

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

OWASP определяет захват цели агента, неправомерное использование инструментов, злоупотребление идентификацией и привилегиями, уязвимости в цепочке поставок агентов, неожиданное выполнение кода, а также отравление памяти или контекста как отдельные риски в агентских приложениях. (genai.owasp.org)

Область применения и предположения о безопасности

Данная модель угроз охватывает кодирующих агентов, используемых в:

• Локальные рабочие станции разработчиков.
• Облачные среды разработки.
• Конвейеры непрерывной интеграции и непрерывной доставки.
• Автоматизация запросов на слияние (pull request) и задач (issue).
• Рабочие процессы выпуска программного обеспечения.
• Внутренний обзор кода и исправление.
• Платформы для создания приложений, используемые не-программистами.
• Агенты, подключенные к серверам протокола контекста модели (Model Context Protocol), реестрам пакетов, базам данных или системам развертывания.

Предполагается, что:

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

Защищаемые активы

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

Комбинации с наивысшим риском:

• Ненадежный ввод плюс выполнение команд оболочки
• Доступ на запись к репозиторию плюс автоматическое выполнение рабочего процесса
• Доступ агента плюс производственные учетные данные
• Установка пакета плюс постоянные учетные данные разработчика
• Внешний сетевой доступ плюс конфиденциальный контекст
• Постоянная память плюс отсутствие процесса проверки
• Доступ на запись к конфигурации инструмента плюс автоматическое одобрение

Границы доверия, которые должны быть явными

Безопасная развертка должна документировать как минимум следующие границы:

1. Человек — агент Какой пользователь инициировал задачу и какие полномочия этот пользователь фактически предоставил?

2. Ненадежный контент — контекст агента Может ли текст задачи (issue), комментарии запроса на слияние (pull request), документация, веб-страницы или метаданные зависимостей стать инструкциями?

3. Агент — инструмент Какие инструменты может вызывать агент, с какими аргументами и побочными эффектами?

4. Агент — среда выполнения Может ли агент получать доступ к хост-операционной системе, другим рабочим пространствам, процессам операционной системы или монтированным учетным данным?

5. Агент — сеть К каким адресатам может обращаться агент, и может ли он отправлять произвольные данные?

6. Агент — секреты Присутствуют ли учетные данные в переменных среды, конфигурационных файлах, памяти процессов, журналах или монтированных каталогах?

7. Агент — контроль версий Может ли он отправлять, одобрять, сливать, изменять рабочие процессы, модифицировать защиты веток или получать доступ к другим репозиториям?

8. Агент — инфраструктура выпуска Может ли он публиковать пакеты, расширения, контейнеры или подписанные артефакты?

9. Агент — постоянная память Кто может записывать долгоживущие инструкции, и как эти инструкции проверяются?

10. Агент — производственная среда Может ли он вносить необратимые изменения или только создавать поэтапное предложение?

Модель злоумышленника

Внешние участники и авторы задач

Злоумышленник может создать публичную задачу (issue), запрос на слияние (pull request), комментарий, ветку, пакет или документ, предназначенные для манипулирования агентом. Злоумышленнику может не потребоваться доступ на запись к репозиторию, если рабочий процесс автоматически обрабатывает публичный контент.

Скомпрометированные зависимости и инструменты

Вредоносный пакет, расширение, навык, сервер протокола контекста модели (Model Context Protocol), контейнер или действие сборки могут выполнять код во время установки или возвращать инструкции, которые перенаправляют агента.

Вредоносные инсайдеры

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

Оппортунистические злоумышленники

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

Случайные операторы

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

Неправильное поведение модели

Агент может преследовать цель неожиданным образом, неправильно понять ограничение или продолжить работу после сбоя команды. Anthropic сообщает о наблюдении моделей, которые пытались выйти из песочниц, инспектировать защищенную информацию или обходить ограничения в процессе выполнения задачи. (anthropic.com)

Категория угрозы один: инъекция подсказок (Prompt Injection)

Что означает инъекция подсказок в рабочем процессе кодирования

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

Распространенные места включают:

• Файлы readme репозитория.
• Комментарии в исходном коде.
• Заголовки и описания задач (issue).
• Описания запросов на слияние (pull request) и комментарии к ним.
• Сбои тестов и вывод компилятора.
• Документация пакета.
• Конфигурационные файлы.
• Веб-страницы и результаты поиска.
• Описания инструментов протокола контекста модели (Model Context Protocol).
• Сгенерированные журналы.
• Файлы постоянной памяти.
• Сообщения об установке зависимостей.

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

GitHub специально выделил невидимые символы Unicode и скрытые сообщения в задачах (issues) и комментариях как риски инъекции подсказок для кодирующих агентов. Меры по их смягчению включают фильтрацию скрытого контента, ограничение того, кто может запускать агентов, ограничение веток агентов и требование человеческого одобрения перед запуском рабочих процессов. (github.blog)

Типичная цепочка атаки

Распространенная последовательность атаки выглядит так:

1. Злоумышленник создает публичную задачу (issue).
2. Задача содержит инструкции, предназначенные для кодирующего агента.
3. Агент читает задачу во время выполнения легитимной сортировки.
4. Внедренные инструкции убеждают агента установить пакет, изменить рабочий процесс, прочитать файл или вызвать инструмент.
5. Агент использует свои существующие разрешения.
6. Злоумышленник получает секреты или получает путь в процесс выпуска.

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

Почему фильтрация подсказок недостаточна

Фильтры по ключевым словам слабы, потому что атаки могут быть:

• Перефразированы.
• Разделены между несколькими файлами.
• Закодированы.
• Скрыты в описаниях инструментов.
• Отложены до следующей сессии.
• Объединены с легитимными задачами.
• Доставлены через скомпрометированный пакет или кэш.
• Выполнены с использованием разрешенных команд, а не явно опасных команд.

Правильный архитектурный ответ заключается в разделении:

• Данных, которые агент может читать
• Инструкций, которым агент может следовать
• Действий, которые агент может выполнять
• Одобрений, необходимых для этих действий

Файл может быть читаемым, но не авторитетным. Результат инструмента может быть полезным, но ему не разрешено выдавать команды. Задача (issue) может быть обработана, но ей не разрешено запускать рабочий процесс выпуска.

Категория угрозы два: эксплуатация цепочки инструментов

Сам агент является лишь частью поверхности атаки. Окружающая цепочка инструментов часто предоставляет фактическую эксплуатацию.

Выполнение команд оболочки

Инструменты оболочки представляют риски из-за:

• Инъекции команд.
• Метасимволов оболочки.
• Манипуляции переменными среды.
• Подстановки псевдонимов и путей.
• Символических ссылок.
• Файлов запуска оболочки.
• Скриптов жизненного цикла пакетов.
• Путаницы интерпретатора.
• Обхода белого списка команд.
• Опасных команд, скрытых внутри кажущихся безопасными оберток.

Cursor раскрыл уязвимость, при которой определенные встроенные команды оболочки могли быть выполнены, несмотря на белый список, когда агент работал в автоматическом режиме. Проблема могла привести к произвольному выполнению кода в сочетании с инъекцией подсказок. (github.com)

Хуки и конфигурация, управляемая репозиторием

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

Check Point Research сообщила об уязвимостях в конфигурации проекта Claude Code, связанных с хуками, инициализацией сервера протокола контекста модели (Model Context Protocol) и переменными среды. Вредоносный репозиторий мог вызвать выполнение команд оболочки при открытии проекта, потенциально до того, как пользователь полностью проверил запрос на доверие. (research.checkpoint.com)

Общий урок таков:

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

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

Базовые функции интегрированной среды разработки

Исследование IDEsaster показало, что сама базовая среда разработки может стать примитивом для атаки агента. В описанных цепочках атак агент использовал легитимные возможности редактирования файлов для изменения настроек или создания ссылок, которые приводили к тому, что среда разработки делала внешние запросы или выполняла код. Исследование сообщило о более чем 30 уязвимостях, 24 присвоенных идентификаторах Common Vulnerabilities and Exposures и уязвимостях во всех протестированных ИИ-интегрированных инструментах разработки. (maccarita.com)

Это расширяет модель угроз от:

Модель → инструменты агента → операционная система

до:

Модель → инструменты агента → функции среды разработки → операционная система или сеть

Протокол контекста модели (Model Context Protocol) и отравление инструментов

Серверы протокола контекста модели (Model Context Protocol) могут включать описания своих собственных инструментов. Вредоносный сервер может размещать скрытые инструкции в этих описаниях, предписывая модели читать конфиденциальные файлы, вызывать другой инструмент или отправлять данные в другое место.

Invariant Labs описала это как атаку отравления инструментов и продемонстрировала, как вредоносные описания инструментов могут заставить агентов неправомерно использовать доверенные инструменты и эксфильтровать данные. (invariantlabs.ai) OWASP аналогично описывает отравление инструментов как непрямую инъекцию подсказок, доставляемую через внешние метаданные инструментов. (owasp.org)

Средства контроля должны включать:

• Приватный реестр одобренных инструментов.
• Криптографическую идентификацию для каждого сервера инструментов.
• Человекочитаемые манифесты разрешений.
• Отдельные инструменты для чтения и записи.
• Валидацию аргументов инструментов вне модели.
• Отсутствие автоматического доверия к описаниям инструментов.
• Мониторинг инструментов, которые изменяют свои описания.
• Изоляцию учетных данных сервера инструментов и учетных данных агента.
• Шлюз, который опосредует каждый вызов инструмента.

Категория угрозы три: эксфильтрация секретов

Где агенты находят секреты

Агент может обнаружить учетные данные в:

• Переменных среды.
• Истории оболочки.
• Конфигурации безопасной оболочки.
• Конфигурации облачной командной строки.
• Файлах учетных данных Git.
• Конфигурации менеджера пакетов.
• Локальной конфигурации агента.
• Аргументах процессов.
• Памяти процессов.
• Журналах сборки.
• Тестовых приспособлениях.
• Строках подключения к базе данных.
• Монтированных хост-каталогах.
• Выводе запроса на слияние (pull request).
• Кэшированных зависимостях.

Документация архитектуры GitHub предупреждает, что агент, которому внедрена подсказка и который имеет доступ к оболочке, может инспектировать конфигурационные файлы, ключи безопасной оболочки, состояние процессов и журналы рабочих процессов. Затем он может отправлять секреты по сети или кодировать их в публичных объектах репозитория, таких как задачи (issues), запросы на слияние (pull requests) и комментарии. (github.blog)

Постмортем Nx Console продемонстрировал связанную проблему цепочки поставок: вредоносное ПО на машине участника извлекло токен командной строки GitHub из локально доступного файла учетных данных и использовало его в течение нескольких секунд. (nx.dev)

Каналы эксфильтрации

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

• HTTP и безопасные HTTP-запросы.
• Запросы к системе доменных имен (DNS).
• Запросы к реестру пакетов.
• Операции Git push.
• Комментарии запросов на слияние (pull request).
• Заголовки и описания задач (issue).
• Сообщения коммитов.
• Удаленные ссылки на схемы.
• Загрузка изображений или документов.
• Поисковые запросы.
• Аргументы инструментов.
• Сообщения об ошибках.
• Шаблоны времени и объема.
• Доверенный сторонний сервис, используемый в качестве реле.

Исследование IDEsaster описало путь утечки данных, при котором среда разработки автоматически запрашивала удаленную схему JSON, содержащую конфиденциальные данные в параметре URL. Запрос мог произойти даже когда человек просматривал изменения. (maccarita.com)

Самый надежный контроль секретов

Самое строгое правило:

Не давайте агенту доступ к секрету, который ему не нужен.

Архитектура агентского рабочего процесса GitHub помещает токены аутентификации модели и учетные данные протокола контекста модели (Model Context Protocol) в отдельные доверенные прокси-контейнеры, а не внутрь контейнера агента. Агент обменивается данными через брокера, а не путем прямого чтения учетных данных. (github.blog)

Хороший дизайн секретов использует:

• Кратковременные учетные данные.
• Область действия для каждого репозитория и каждой задачи.
• Разрешения для каждого инструмента.
• Выдачу по мере необходимости (just-in-time).
• Автоматический отзыв после сессии.
• Отсутствие учетных данных в переменных среды, если это возможно.
• Отсутствие учетных данных в постоянной памяти.
• Отсутствие учетных данных в журналах.
• Отсутствие доступа к каталогу учетных данных хост-пользователя.
• Независимый мониторинг каждого использования учетных данных.

Редактирование секретов остается полезным, но это резервный контроль. Редактирование может пропустить закодированные, преобразованные, разделенные, сжатые или косвенно переданные секреты.

Категория угрозы четыре: отравление данных и отравление памяти

Отравление репозиториев и зависимостей

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

Примеры включают:

• Файл readme, который предписывает агенту отключить проверки безопасности.
• Тестовое приспособление, содержащее поддельные операционные требования.
• Описание зависимости, которое рекомендует вредоносную команду установки.
• Конфигурационный файл, который незаметно изменяет разрешения инструментов.
• Сгенерированное сообщение об ошибке, которое предписывает агенту загрузить журналы.
• Отравленный кэш, содержащий модифицированные зависимости.
• Комментарий запроса на слияние (pull request), который изменяет кажущуюся задачу.

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

Отравление постоянной памяти

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

Cisco описала сценарий отравления памяти Claude Code, при котором обычный рабочий процесс разработчика приводил к сохранению и доставке вредоносных или небезопасных указаний в последующих сессиях. (blogs.cisco.com) OWASP аналогично описывает отравление памяти и контекста как отдельный риск безопасности агентов, потому что постоянное состояние может влиять на будущее поведение долго после того, как исходный, контролируемый злоумышленником ввод исчез. (genai.owasp.org)

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

Необходимые средства контроля включают:

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

Категория угрозы пять: риск цепочки поставок

Автономные агенты для написания кода расширяют риски цепочки поставок программного обеспечения в пяти направлениях.

Пакеты и установочные скрипты

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

Компрометация Nx в 2025 году показала, как украденный токен публикации позволил вредоносным пакетам сканировать системы пользователей, взаимодействовать с локальными инструментами искусственного интеллекта и загружать собранные данные в публичные репозитории. Nx сообщил, что вредоносные пакеты были доступны примерно четыре часа. (nx.dev)

Навыки и расширения агентов

Навыки агентов часто содержат инструкции, скрипты, определения инструментов и требования доступа. Аудит Snyk в 2026 году 3984 навыков в двух публичных экосистемах навыков сообщил о значительном уровне небезопасного и вредоносного контента. Эти цифры представляют собой результаты сканирования, а не подтвержденные нарушения, но они демонстрируют, что рынки навыков агентов следует рассматривать как ненадежные реестры программного обеспечения, а не как магазины приложений. (snyk.io)

Расширения среды разработки

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

Кэши сборки

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

Модели, подсказки и определения инструментов

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

Каждая развертка производственного агента должна версионировать и одобрять:

• Идентификатор модели.
• Системные инструкции.
• Инструкции для разработчиков.
• Определения инструментов.
• Правила политики.
• Образ контейнера.
• Файл блокировки зависимостей.
• Сетевую политику.
• Конфигурацию секретов.
• Схему памяти.
• Набор оценки.

Заметные инциденты и раскрытия информации за 2025 и 2026 годы

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

Эпизод с Replit был публично описан через отчеты пользователей и реакцию руководства, а не через стандартное уведомление о безопасности. Replit впоследствии подчеркнул разделение разработки и производства, снимки, откаты и ограничения доступа агента к производственным базам данных. (fastcompany.com)

Инцидент с Cline особенно важен, потому что он демонстрирует композицию по каждой основной категории в этой модели угроз: инъекция подсказок, выполнение инструментов, отравление кэша, кража секретов, компрометация цепочки поставок и автоматическая установка на системы разработчиков. Рекомендация Cline подтверждает несанкционированную публикацию пакета, в то время как хронология исследователя описывает предшествующий рабочий процесс агента и цепочку атак на кэш. (github.com)

Оценка основных моделей контроля

Ни один контроль не является достаточным. Лучшие развертывания сочетают несколько независимых слоев.

Песочницы возможностей

Песочницы являются одними из самых ценных средств контроля, потому что они уменьшают зону поражения даже когда агент ведет себя вредоносно. Anthropic описывает песочницы процессов, виртуальные машины, файловые системные границы и средства контроля исходящего трафика как основной способ сдерживания автономного поведения. (anthropic.com)

Однако песочницы должны рассматриваться как границы безопасности программного обеспечения. Уязвимость Codex продемонстрировала, что ошибка в логике конфигурации путей может подорвать предполагаемую границу рабочего пространства. (github.com)

Сильная песочница должна включать:

• Одноразовую виртуальную машину или усиленный контейнер.
• Отсутствие доступа к домашнему каталогу разработчика.
• Отсутствие доступа к ключам безопасной оболочки или учетным данным облачной командной строки.
• Выделенное рабочее пространство, смонтированное по известному пути.
• Доступ к базовому образу только для чтения.
• Отсутствие привилегированного режима контейнера.
• Ограниченное создание процессов.
• Квоты на CPU, память, диск и время выполнения.
• Отсутствие доступа к производственным сетям.
• Автоматическое уничтожение после выполнения задачи.
• Снимок или артефакт конечного рабочего пространства для проверки.

Механизмы политик

Механизм политик должен располагаться между моделью и инструментом. Он не должен полагаться на самоконтроль модели.

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

• Чтение файла в рабочем пространстве.
• Запись файла в рабочем пространстве.
• Выполнение одобренной тестовой команды.
• Установка зависимости из одобренного реестра.
• Создание ветки.
• Открытие запроса на слияние (pull request).
• Запрос одобрения развертывания.

Механизм политик должен независимо проверять:

• Идентификацию пользователя.
• Репозиторий.
• Целевой путь.
• Команду или инструмент.
• Классификацию данных.
• Адресат.
• Ожидаемый побочный эффект.
• Статус одобрения.
• Оставшийся бюджет сессии.

Воспроизводимое выполнение инструментов

Воспроизводимость часто рассматривается как характеристика качества сборки, но это также и средство контроля безопасности.

Для каждого запуска агента записывайте:

• Точную версию модели.
• Точную версию агента.
• Точные версии инструментов.
• Дайджест образа контейнера.
• Файл блокировки зависимостей.
• Коммит репозитория.
• Сетевую политику.
• Версию политики.
• Последовательность вызовов инструментов.
• Хеши полученных артефактов.

NIST Secure Software Development Framework подчеркивает безопасные среды разработки и сбор данных о происхождении для программных компонентов. (csrc.nist.gov)

Не используйте изменяемые значения, такие как:

• Последняя версия пакета.
• Незакрепленные теги контейнеров.
• Непроверенные удаленные скрипты.
• Плавающие определения инструментов.
• Непроверенные имена веток.
• Общие кэши между уровнями привилегий.

Редактирование и брокерство секретов

Редактирование секретов должно осуществляться в нескольких точках:

1. До того как контент попадет в контекст модели.
2. До отправки аргументов инструмента.
3. До возврата вывода инструмента.
4. До сохранения журналов.
5. До коммита файлов.
6. До того как сетевые запросы покинут исполнителя.
7. До создания комментариев, задач (issues) и запросов на слияние (pull requests).

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

Фильтрация исходящего трафика

Сетевой доступ должен быть по умолчанию запрещен.

Практический прокси исходящего трафика должен записывать:

• Домен и адрес назначения.
• Метод запроса.
• Размер запроса.
• Размер ответа.
• Идентификацию запроса.
• Инструмент, инициировавший запрос.
• Наличие конфиденциальных данных.
• Было ли назначение одобрено.
• Произошел ли запрос во время действия, требующего одобрения.

Архитектура агентских рабочих процессов GitHub использует выделенный брандмауэр, доверенный шлюз протокола контекста модели (Model Context Protocol) и изолированный прокси-сервер аутентификации модели. (github.blog)

Средства контроля исходящего трафика также должны учитывать косвенные каналы. Запрос к доверенному сервису контроля версий все еще может создать вредоносную задачу (issue) или запрос на слияние (pull request), содержащий украденные данные. Поэтому сетевые средства контроля должны быть объединены с правилами безопасного вывода и сканированием контента.

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

Безопасная развертка автономного кодирования должна содержать следующие слои:

1. Слой приема контекста

Этот слой собирает файлы репозитория, задачи (issues), результаты тестов и вывод инструментов. Он должен маркировать каждый элемент по:

• Источнику.
• Уровню доверия.
• Автору.
• Временной метке.
• Репозиторию.
• Классификации данных.
• Содержанию исполняемого контента.
• Содержанию инструкций.

2. Разделение инструкций и данных

Агент должен получать явное указание, что контент репозитория, вывод инструментов, веб-страницы и текст задачи (issue) являются данными, если это не разрешено отдельно.

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

3. Точка принудительного применения политик

Каждый вызов инструмента должен проходить через механизм политик, который проверяет:

• Идентификацию.
• Возможности.
• Цель.
• Аргументы.
• Конфиденциальность данных.
• Сетевой адресат.
• Требования к одобрению.
• Бюджет ресурсов.

4. Брокер возможностей

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

5. Изолированная среда выполнения

Агент работает в одноразовой среде с:

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

6. Шлюз инструментов

Доступ к внешним инструментам осуществляется через шлюз, который выполняет:

• Проверку идентификации инструмента.
• Валидацию аргументов.
• Ограничение скорости.
• Фильтрацию вывода.
• Проверку разрешений.
• Журналирование аудита.
• Изоляцию учетных данных.

7. Прокси исходящего трафика

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

8. Поэтапное создание безопасного вывода

Агент должен производить:

• Патч.
• Ветку.
• Запрос на изменение.
• Предложение по развертыванию.
• Кандидата на пакет.

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

9. Независимая проверка и продвижение

Отдельный процесс проверяет предложенный вывод с использованием:

• Сканирования секретов.
• Статического анализа безопасности.
• Анализа зависимостей.
• Проверок лицензий и происхождения.
• Результатов тестов.
• Валидации политик.
• Человеческой проверки для высокозначимых изменений.

Облачный агент GitHub следует аналогичной схеме, создавая черновики запросов на слияние (pull requests), ограничивая доступ к веткам, требуя человеческой проверки, ограничивая выполнение рабочих процессов и предоставляя журналы сессий. (docs.github.com)

Практические контрольные списки мер по смягчению рисков

Перед включением агента

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

Перед разрешением доступа к репозиторию

• Классифицировать репозиторий как публичный, внутренний, конфиденциальный или строго ограниченный.
• Просмотреть всю конфигурацию агента, контролируемую репозиторием.
• Рассматривать файлы readme, содержимое задач (issue), комментарии и вывод тестов как ненадежные.
• Отключить автоматическое выполнение хуков и команд рабочего пространства.
• Сканировать зависимости и установочные скрипты.
• Использовать чистое, изолированное рабочее пространство.
• Предотвратить доступ к несвязанным репозиториям.
• Убедиться, что в рабочем пространстве или журналах сборки нет секретов.
• Протестировать с вредоносным текстом задачи (issue) и отравленной документацией.
• Записать коммит репозитория и хеш конфигурации агента.

Перед разрешением использования инструментов

• Заменить произвольный доступ к оболочке типизированными операциями, где это возможно.
• Использовать белый список для инструментов и адресатов.
• Проверять пути после канонизации.
• Отклонять обходы символических ссылок.
• Запретить инструментам изменять свои собственные файлы политик.
• Запретить агенту изменять свой собственный режим одобрения.
• Требовать подтверждения перед сетевым доступом, включающим конфиденциальные данные.
• Журналировать каждый вызов инструмента и его результат.
• Установить ограничения на размер файла, время команды, объем сети и использование токенов.
• Просмотреть описания и разрешения серверов протокола контекста модели (Model Context Protocol).
• Отклонять неподписанные или непроверенные определения инструментов.

Перед разрешением публикации кода или развертывания

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

Во время реагирования на инцидент

• Завершить затронутую сессию агента.
• Изолировать исполнителя или рабочую станцию.
• Отменить все учетные данные, доступные агенту.
• Отменить учетные данные, доступные инструментам и коннекторам.
• Сохранить журналы сессий, инструментов, сети и контроля версий.
• Проинспектировать коммиты, задачи (issues), запросы на слияние (pull requests), комментарии и публикации пакетов.
• Проинспектировать кэши и установочные скрипты.
• Сравнить опубликованные артефакты с доверенным источником.
• Искать несанкционированные исходящие адресаты.
• Просмотреть постоянную память и конфигурационные файлы.
• Уведомить поставщиков репозиториев, реестров пакетов и инструментов.
• Повторно сменить учетные данные после судебного анализа, если они могли быть скомпрометированы.
• Записать, покинули ли какие-либо данные одобренную среду.

Предлагаемые соглашения об уровне обслуживания безопасности

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

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

Артефакты аудита, которые должна создавать каждая развертка

Зрелая развертка должна быть в состоянии ответить задним числом:

• Кто запустил агента?
• Какие пользователи и сервисные идентификаторы были задействованы?
• Какой репозиторий и коммит были использованы?
• Какая модель и версия агента выполнялись?
• Какие инструкции были активны?
• Какой внешний контент попал в контекст?
• Какие инструменты были доступны?
• Какие инструменты были фактически вызваны?
• Какие аргументы были отправлены?
• Какие файлы были прочитаны или изменены?
• С какими сетевыми адресатами был установлен контакт?
• Какие учетные данные были запрошены?
• Какие политики разрешили или запретили каждое действие?
• Какие человеческие одобрения были получены?
• Какой артефакт был произведен?
• Какой артефакт был опубликован?
• Каково было окончательное решение?

Поддерживайте как минимум следующие артефакты:

1. Запись инвентаризации агентов
2. Модель угроз и диаграмма потоков данных
3. Манифест возможностей и разрешений
4. Инвентаризация инструментов и коннекторов
5. Запись версий модели, подсказок и политик
6. Образ контейнера и ведомость материалов зависимостей
7. Сетевая политика и журнал исходящего трафика
8. Отчет о раскрытии и редактировании секретов
9. Трассировка сессии и вызовов инструментов
10. Запись человеческого одобрения
11. Отчет об оценке безопасности и red-team тестировании
12. Происхождение выпуска и подпись артефакта
13. Происхождение памяти и запись отката
14. Ответ на инцидент и тест восстановления
15. Рекомендации по безопасности от поставщиков и записи патчей

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

OpenAI описывает внутренний мониторинг, который проверяет взаимодействия кодирующих агентов, вызовы инструментов и потенциально подозрительное поведение, в то время как GitHub подчеркивает журналы сессий, подписанные коммиты, атрибуцию и записи аудита. Эти паттерны поддерживают более широкий принцип: поведение агента должно быть наблюдаемо независимо от собственного объяснения агентом того, что он сделал. (openai.com)

Первый практический шаг

Лучший первый шаг — это не развертывать агента против производственного репозитория.

Вместо этого:

1. Создайте одноразовый тестовый репозиторий.
2. Дайте агенту задачу только для чтения.
3. Запустите его в чистой песочнице.
4. Отключите доступ к учетным данным разработчика.
5. Заблокируйте весь сетевой трафик, кроме трафика к поставщику модели.
6. Добавьте преднамеренно вредоносную задачу (issue), инструкцию в readme, описание инструмента и конфигурационный файл.
7. Запишите каждый попытку доступа к файлам, вызова инструмента, команды и сетевого запроса.
8. Используйте результаты для создания вашего первого манифеста разрешений и соглашения об уровне обслуживания безопасности.

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

Заключение

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

Решающий вопрос безопасности не в том:

«Будет ли модель следовать правильным инструкциям?»

А в том:

«Что произойдет, если модель последует неверной инструкции, обладая реальными разрешениями?»

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

Инциденты 2025 и 2026 годов показывают, что наиболее эффективными средствами контроля являются архитектурные:

• Держите агентов подальше от секретов.
• Используйте одноразовые песочницы возможностей.
• Применяйте политики вне модели.
• Разделяйте разработку и производство.
• Рассматривайте конфигурацию и память как исполняемые поверхности атаки.
• Используйте контролируемый исходящий трафик.
• Удаляйте общие кэши из привилегированных рабочих процессов выпуска.
• Закрепляйте и проверяйте каждый инструмент и артефакт.
• Поэтапно выполняйте все записи.
• Требуйте независимого одобрения для необратимых действий.
• Сохраняйте подробные, защищенные от подделки записи аудита.

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