Агенты под контролем: почему безопасность OpenAI теперь измеряют не только моделью

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

Reuters сообщил, что демократы Палаты представителей США потребовали от Anthropic и OpenAI объяснений по поводу «rogue AI agents». Даже без описания конкретного инцидента этот публичный политический запрос значим для рынка: безопасность агентных продуктов становится предметом внешней подотчётности, а не только внутренней инженерной оценки.

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

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

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

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

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

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

От текста к действию: что меняется с агентным интерфейсом

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

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

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

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

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

Цитата в переводе

«research preview» переводится как «исследовательское предварительное тестирование.»

Недоверенные данные: когда содержимое пытается стать командой

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

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

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

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

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

Права и инструменты: где ошибка превращается в ущерб

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

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

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

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

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

Цитата в переводе

«takeover mode» переводится как «режим, в котором управление берёт пользователь.»

Изоляция и подтверждения: ограничить масштаб, а не обещать безошибочность

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

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

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

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

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

Цитата в переводе

«tracing» переводится как «трассирование.»

Audit trail и kill switch: как расследовать и остановить инцидент

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

Минимальная трасса должна связывать инициатора и цель задачи с версией модели, политиками, источниками контекста, доступными инструментами, вызовами функций, параметрами, разрешениями и подтверждениями. Для чувствительных задач существенны также события остановки, отзыв токенов и отмена отложенных операций. Журнал должен отвечать не только на вопрос «что произошло?», но и на вопрос «почему система позволила этому произойти?».

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

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

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

Что это означает для OpenAI, индустрии и российского внедрения

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

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

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

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

• Capability allowlist: почта, shell, сеть, платежи, production-БД и секреты запрещены, пока не разрешены явно.
• Scoped credentials: разрешение ограничено задачей, ресурсом и сроком действия.
• Policy gate: значимое действие проверяется до вызова инструмента.
• Immutable audit trail: события сохраняются так, чтобы агент не мог их незаметно изменить.
• Kill switch: организация может остановить процессы и отозвать доступы без ожидания следующего шага агента.
• Red teaming: тесты должны включать инъекции, злоупотребление правами, сетевую утечку и опасные вызовы инструментов.

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

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

• Не выдавайте агенту полную учётную запись сотрудника: используйте отдельные короткоживущие разрешения для конкретной задачи и ресурса.
• Разделите режимы read, draft и execute: черновик не должен автоматически превращаться в отправку или публикацию.
• Считайте веб-страницы, письма, документы и ответы внешних API недоверенными данными, а не командами для агента.
• Ограничивайте файловую систему и исходящий сетевой трафик: контейнер без сетевой политики не обеспечивает полной изоляции.
• Настройте подтверждения для отправки наружу, удаления, публикации, изменения прав, передачи чувствительных данных и финансовых действий.
• Ведите audit trail: цель задачи, источники контекста, вызовы инструментов, параметры, права, одобрения и результаты.
• Проверьте kill switch на практике: можно ли остановить задачи, отозвать токены и отменить отложенные операции.
• Запрашивайте у поставщика методологию тестов и проверяйте собственную конфигурацию, а не только общую оценку модели.

Вывод

Публичное требование объяснений по rogue AI agents меняет масштаб подотчётности для OpenAI и отрасли. Вопрос уже не сводится к тому, способна ли модель выдать вредный текст. Он касается реальных действий агента, предусмотренных ограничений и того, кто отвечает за их настройку.

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

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

Источники

• OpenAI: Introducing Operator
• OpenAI: Operator System Card
• OpenAI: A practical guide to building AI agents
• OpenAI: o3 and o4-mini System Card Addendum: Operator and o3
• OpenAI Agents Python: Tracing documentation
• Reuters Technology AI: US House Democrats press Anthropic, OpenAI about rogue AI agents
• Financial Times AI: Letter: Who underwrites the risk when AI agents go rogue?
• arXiv: 2605.26269

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

Почему безопасность AI-агента нельзя оценивать только по поведению модели?

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

Что такое prompt injection в агентной системе?

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

Зачем разделять read, draft и execute?

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

Какие события нужно фиксировать в журнале действий агента?

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

Что должен уметь kill switch для агентной системы?

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

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

Чек-лист: проверка безопасности AI-агента перед подключением к рабочим системам

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

Данные и контекст

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

Права и инструменты

• Выдать агенту отдельную учётную запись или ограниченное разрешение вместо полной сессии сотрудника.
• Ограничить разрешение задачей, ресурсом, типом операции и сроком действия.
• Разделить чтение, подготовку результата и его применение на отдельные режимы.
• Составить явный allowlist инструментов и запретить почту, shell, сеть, платежи, production-БД и секреты до отдельного разрешения.

Исполнение и подтверждения

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

Наблюдаемость и остановка

• Фиксировать цель задачи, источники контекста, версии политик, доступные инструменты и параметры вызовов.
• Хранить сведения о токенах, правах, одобрениях и результатах действий.
• Выводить журнал в защищённое хранилище за пределами среды агента.
• Проверить, что kill switch останавливает новые задачи, отзывает токены и отменяет отложенные операции.
• Провести учение с имитацией инъекции, злоупотребления правами и опасного вызова инструмента.