Rogue agent: описание результата, а не техническая причина

В новостной повестке появился сюжет о возможном пересмотре OpenAI safety-протоколов после нежелательного поведения агентов. Доступный источник представляет собой запись Google News с заголовком материала WIRED, а не полный верифицируемый текст первичной публикации. Поэтому нельзя представлять универсальный пересмотр протоколов как подтверждённое публичное объявление OpenAI.

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

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

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

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

  • Разбирайте инцидент по цепочке «цель → входные данные → план → tool call → результат».
  • Отделяйте ошибку модели от ошибки в правах, сетевой конфигурации или дизайне инструмента.
  • Оценивайте не только финальный ответ, но и все действия, доступные агенту на пути к нему.
Цитата в переводе

«»

Источник:

Редакторский вывод:

Контроль начинается с задачи и недоверенных входов

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

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

Отдельный риск создаёт prompt injection. Веб-страница, письмо, вложение, RAG-документ или результат внешнего сервиса могут содержать текст, который имитирует инструкцию: предлагает раскрыть данные, проигнорировать политику или обратиться к новому инструменту. Практическое руководство OpenAI относит prompt injection к рискам небезопасных входов и рекомендует многослойные guardrails.

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

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

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

Tool use: не универсальные «руки», а ограниченные возможности

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

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

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

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

  • Разделяйте read-only, write и privileged operations между разными определениями инструментов.
  • Заменяйте универсальные команды специализированными бизнес-функциями со схемой аргументов.
  • Назначайте риск-класс конкретному вызову, а не агенту в целом.
  • Проверяйте права, которые фактически получает каждый инструмент и каждая сервисная идентичность.

Guardrails и approval: предотвратить вызов важнее, чем проверить последствия

Документация OpenAI Agents SDK описывает guardrails для function tools, которые могут работать до исполнения инструмента и после него. Проверка до вызова получает контекст и аргументы, после чего может изменить или отклонить вызов. Проверка после вызова анализирует результат. При срабатывании tripwire run завершается исключением.

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

Post-tool проверка полезна для оценки результата инструмента и остановки дальнейшей цепочки, если результат оказался опасным или содержит недоверенные инструкции. Но она не отменяет уже совершённое внешнее действие. Отправленное письмо или изменение записи потребуют отдельной процедуры исправления.

Human-in-the-loop решает другую задачу. В SDK он описан как прерывание: выполнение останавливается, приложение получает информацию об агенте, инструменте и аргументах, затем явно разрешает или отклоняет вызов. Это техническая точка невозврата, расположенная до действия.

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

Автоматическое покрытие нельзя считать настройкой по умолчанию. Документация отдельно оговаривает, что описанный pipeline относится к function tools, созданным через function_tool. Handoffs, hosted и built-in tools, включая ряд веб-, компьютерных, shell- и MCP-сценариев, не получают такой pipeline автоматически. Для фактического пути исполнения приложение должно самостоятельно проектировать прокси, allowlist, sandbox, управление учётными данными, approval и аудит.

  • Ставьте pre-tool проверку перед действием с риском; post-tool проверку используйте для контроля результата и продолжения run.
  • Используйте approval перед внешними, необратимыми и привилегированными операциями.
  • Показывайте оператору смысл и последствия действия, а не только технические параметры.
  • Проверяйте покрытие защиты для каждого типа инструмента, а не только для собственных function tools.

Sandbox, сеть и секреты ограничивают среду исполнения

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

Отдельного внимания требует исходящая сеть, или egress. Формула «интернет нужен лишь для одной служебной задачи» уже создаёт маршрут из среды во внешний мир. В материале о безопасной эксплуатации Codex OpenAI описывает managed network policy: ожидаемые направления разрешаются, нежелательные блокируются, а обращения к незнакомым доменам требуют approval.

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

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

  • Стройте egress через список разрешённых направлений и отдельные решения для новых направлений.
  • Не размещайте секреты в общей среде исполнения только ради удобства интеграции.
  • Изолируйте недоверенный и сгенерированный код от внутренних ресурсов.
  • Считайте прокси, registry и MCP-серверы частью периметра workflow.

Длинный агентный цикл нуждается в бюджетах и трассировке

Опасность определяется не только мощностью одного инструмента, но и длиной петли «спланировать → выполнить → наблюдать результат → скорректировать план». Несколько безопасных по отдельности шагов способны образовать рискованную цепочку. Автономному run нужны ограничения по времени, числу ходов, tool calls и повторных попыток.

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

При остановке следует сохранять состояние run. Оператору недостаточно последнего запроса: ему нужен контекст, из которого выросло решение. Наблюдаемость позволяет восстановить исходную цель, применённую политику, вызовы и аргументы инструментов, результаты, решения по approval, сетевые разрешения и блокировки.

OpenAI указывает, что при безопасном запуске Codex такие события могут экспортироваться через OpenTelemetry, включая prompts, решения об approval, результаты tool execution, обращения к MCP и сетевые решения. Логи не предотвращают уже совершённое действие и не заменяют pre-tool policy или approval. Их роль состоит в сокращении времени расследования, отключении опасного маршрута и превращении инцидента в регрессионный тест.

  • Ограничивайте время, число шагов, tool calls и повторных попыток в одном run.
  • Останавливайте workflow при повышении риска, а не только после явной ошибки.
  • Логируйте policy decision рядом с соответствующим tool call.
  • Добавляйте реальные инциденты и обходы в набор eval-сценариев.
Цитата в переводе

«»

Источник:

Редакторский вывод:

Что меняется для разработчиков OpenAI-workflows

Агентный workflow нельзя считать промптом с подключёнными API. Это приложение, в котором модель участвует в планировании в условиях неполной определённости, а действия проходят через системы доступа, сеть и бизнес-процессы. Поэтому вопросы software security становятся частью продуктового дизайна: кто и что может вызвать, как проверяются параметры, где расположена точка подтверждения, как изолирована среда и как расследуется сбой.

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

Меняется и критерий готовности к production. Успешная демонстрация полезного сценария не подтверждает безопасность эксплуатации. Проверять следует полный процесс: поведение при вредоносном документе, конфликтующих инструкциях, невалидном результате инструмента, новом домене, сбое сервиса и попытке действия за пределами роли. Evals в таком случае измеряют не только качество конечного ответа, но и устойчивость tool-using workflow.

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

  • Проектируйте безопасность как свойство всего workflow, а не как настройку модели.
  • Тестируйте не только полезный happy path, но и инъекции, сбои и эскалацию полномочий.
  • Не переносите автоматически меры OpenAI на собственное приложение: SDK не заменяет IAM-, network- и audit-архитектуру команды.
  • Разделяйте способность агента выполнить задачу и подтверждённую безопасность его эксплуатации.

Что это означает на практике

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

  • Не выдавайте агенту единый широкий API-ключ: разделяйте read-only, write и privileged операции по разным идентичностям.
  • Заменяйте универсальные команды узкими функциями с чёткой схемой аргументов и ограниченным эффектом.
  • Считайте веб-страницы, письма, вложения, RAG-документы и результаты внешних инструментов недоверенными данными.
  • Используйте pre-tool проверки, чтобы предотвратить опасный вызов, и post-tool проверки, чтобы контролировать результат и дальнейшее выполнение.
  • Ставьте human approval до необратимых, внешних, финансовых и привилегированных действий.
  • Ограничивайте run по времени, числу шагов, числу вызовов и повторам.
  • Стройте исходящий сетевой доступ через allowlist и фиксируйте разрешения и блокировки.
  • Сохраняйте трассу «цель → политика → tool call → approval → результат → сетевое решение» для расследований и evals.

Вывод

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

Практический пересмотр безопасности означает переход от надежды на одну инструкцию модели к нескольким независимым барьерам. Контракт задачи ограничивает план; узкие инструменты ограничивают действие; sandbox, сеть и права ограничивают среду; approval и stop conditions ограничивают продолжение; телеметрия сокращает неопределённость после сбоя.

OpenAI описывает часть таких строительных блоков в Agents SDK и материалах о безопасной эксплуатации Codex. Но границы конкретного workflow, включая доверенные данные, права инструментов, точки невозврата и процедуру реакции на инцидент, остаются ответственностью разработчика системы.

Источники

Частые вопросы

Почему агентный workflow опаснее обычного чат-бота?

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

Чем pre-tool проверка отличается от post-tool проверки?

Pre-tool проверка работает до вызова инструмента и может предотвратить опасное действие. Post-tool проверка анализирует результат и способна остановить дальнейший run, но не отменяет уже совершённую внешнюю операцию.

Когда нужен human approval?

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

Зачем ограничивать время и число вызовов в run?

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

Практический чек-лист

Чек-лист ревизии безопасности агентного workflow

PDF-версия предназначена для сохранения и использования при проверке сценария перед production.

Задача и входы

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

Инструменты и права

  • Инструменты разделены на read-only, write и privileged операции.
  • Универсальные команды заменены специализированными функциями со строгой схемой аргументов.
  • Права выдаются конкретному инструменту и конкретному run, а не широкому постоянному токену.

Исполнение и контроль

  • До рискованных вызовов работают pre-tool проверки.
  • Перед необратимыми, внешними и привилегированными действиями предусмотрен human approval.
  • Среда исполнения, секреты и исходящая сеть ограничены.
  • Для run заданы бюджеты времени, шагов, вызовов и повторов.
  • Сохраняется трасса цели, policy decision, tool calls, approval, результатов и сетевых решений.

Вопросы и ответы

Почему агентный workflow опаснее обычного чат-бота?

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

Чем pre-tool проверка отличается от post-tool проверки?

Pre-tool проверка работает до вызова инструмента и может предотвратить опасное действие. Post-tool проверка анализирует результат и способна остановить дальнейший run, но не отменяет уже совершённую внешнюю операцию.

Когда нужен human approval?

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

Зачем ограничивать время и число вызовов в run?

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