Безопасность ИИ-агента: разрешения, сэндбоксы и подтверждения

Автоматический перевод

Эта статья была автоматически переведена с оригинальной английской версии.

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

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

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

Меры защиты по возможностям

ВозможностьМера защитыЧто обеспечивать
Любое использование инструментовМинимальные привилегииПредоставляйте только необходимые инструменты, как рекомендуют руководства OWASP по MCP.
Чтение приватных данных или изменения во внешних системахПроверки разрешенийПроверяйте пользователя, аргументы, целевой объект и разрешённое действие непосредственно перед выполнением.
Код, файлы или автоматизация браузераСэндбоксОграничивайте доступные файлы, процессы, состояние браузера и адресаты исходящих соединений.
Действия с серьёзными последствиямиПодтверждение от человекаПоказывайте точный целевой объект и изменение перед деплоем в продакшен, платежом, удалением или внешней отправкой.
Сервисы с аутентификациейОграниченные учётные данныеОграничивайте каждую интеграцию необходимыми ресурсами и действиями.
Недоверенные MCP-серверыИзоляция серверовПроверяйте определения инструментов и не допускайте, чтобы инструкции, возвращённые одним сервером, предоставляли доступ к другому инструменту.
Выполнение инструментовАудиторские трейсыЗаписывайте идентификатор участника, целевой объект, решение о разрешении, подтверждение и результат; удаляйте приватное содержимое из записываемых данных.
Обработка ввода и выводаГардрейлыПроверяйте покрытие для каждого инструмента. Текстовый фильтр не предоставляет разрешение и не отменяет завершённое действие.
Проверки релизов и регрессионное тестированиеТесты атакТестируйте промпт-инъекции, вводящие в заблуждение определения инструментов, раскрытие приватных данных и обходы разрешений.

Что реализовать в первую очередь

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

Затем проверяйте политику перед каждым tool call. Анализируйте имя инструмента, аргументы, целевой ресурс, пользователя, окружение и побочный эффект. Безобидный на вид запрос всё равно может привести к опасной команде оболочки.

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

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

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

Риски, специфичные для MCP

MCP полезен, поскольку стандартизирует доступ к инструментам. Он несёт риски, потому что описания инструментов, схемы, идентификаторы серверов, области доступа OAuth и результаты инструментов становятся частью контекста принятия решений моделью.

Для MCP я бы закрепил следующие правила в проверке кода:

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

Гардрейлов недостаточно

Гардрейлы могут проверять текст и tool calls. В OpenAI Agents SDK гардрейлы входных данных инструментов могут заблокировать защищённый инструмент-функцию до его запуска. Инструменты, выполняемые на стороне сервиса, и встроенные инструменты выполнения не используют тот же пайплайн, поэтому проверяйте покрытие для каждого предоставляемого инструмента. Проверки выходных данных выполняются после запуска и не могут отменить побочный эффект.

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

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

Дополнительные материалы

Источники