Для автономного агента не существует pull request
Традиционные проверки безопасности полагаются на diff. Кто-то открывает pull request. Кто-то его читает. Код в продакшене соответствует коду, который вы проверили.
Автономные агенты нарушают эту модель.
Агент планирует действия и вызывает инструменты во время выполнения (runtime). Он не отправляет действия в виде коммита. Он принимает решения в процессе работы. Если вы проверяете только код приложения, вы упускаете реальный риск.
Агент — это не просто код. Это конфигурация среды выполнения. Эта конфигурация включает в себя:
• Системный промпт • Оболочку (harness) или цикл • Поверхность инструментов (tool surface) • Память и идентификацию • Политики исходящего трафика (egress policies) • Образы контейнеров
Два агента, использующие одну и ту же модель, могут действовать по-разному в зависимости от этих настроек. Модель остается неизменной. Конфигурация меняет всё.
Многие команды относятся к системным промптам как к простым настройкам в текстовом поле. Они редактируют их в панели управления (dashboard). Это ошибка. Изменение всего одной строки может убрать защитный барьер (guardrail). Редактируемый промпт — это непроверенный путь выполнения кода.
Реальные инциденты доказывают это:
• Бот в течение нескольких недель давал арендодателям незаконные советы. • Бот поддержки начал ругаться с клиентами из-за обновления промпта. • Вредоносные файлы использовали невидимые символы для обхода правил.
Это не были сбои модели. Это были изменения конфигурации, которые никто не проверил.
Вы должны относиться к конфигурации как к коду.
Поместите свои системные промпты и конфигурации оболочки (harness) в систему контроля версий. Изменяйте их только через pull request. Используйте diff, чтобы видеть, что изменилось.
Используйте хеш содержимого (content hash) для развернутой конфигурации. Этот хеш должен включать версию промпта, ID модели и дайджест контейнера. Если вы меняете промпт, меняется и идентичность агента. Вы не можете незаметно заменить промпт.
Применяйте обнаружение дрейфа (drift detection) к поверхности агента. Не ограничивайтесь мониторингом хоста. Отслеживайте списки MCP-серверов и конкретные политики исходящего трафика (egress policies) для этого агента.
При логировании отслеживайте две вещи:
• Размер контекста в момент принятия решения: какой объем информации был у модели в момент совершения действия? • Родительский промпт: в мультиагентных системах — что именно отправил вызывающий агент?
Вам не нужны новые инструменты. Используйте существующие системы контроля версий и структурированное логирование. Вам просто нужно направить их в правильное место.
Ведете ли вы версии и проверяете ли свои системные промпты? Или любой, у кого есть доступ к консоли, может изменить их бесследно?
Optional learning community: https://t.me/GyaanSetuAi