Чеклист безопасности ИИ-агентов: разрешения и сэндбоксы

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

Безопасность ИИ-агента — это контроль его действий. Чатбот может выдать неверный ответ. ИИ-агент может использовать реальные учетные данные, вызвать инструмент и изменить данные в продакшене.

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

Модель угроз и дата ревью: 2026-08-10. Эти приоритеты предполагают, что ИИ-агент может обрабатывать ввод под контролем атакующего, читать данные или вызывать внешние побочные эффекты. Ассистентам с меньшими возможностями нужно меньше контролей; действия с более высоким уровнем воздействия требуют более строгой изоляции и согласования.

Ранжирование паттернов

ПаттернПриоритетЗащищает отПримечание по реализации
Инструменты с минимальными привилегиямиP0Чрезмерной автономностиСледуйте рекомендациям OWASP по MCP: не предоставляйте инструменты, которыми ИИ-агенту нельзя пользоваться.
Проверки политики перед tool callP0Опасных действийПроверяйте конкретное действие непосредственно перед выполнением.
СэндбоксыP0Ущерба от файлов, shell, браузера и сетиИзолируйте код и недоверенный контент; по умолчанию запрещайте исходящие сетевые подключения.
Согласование с человекомP0Необратимых действий и действий в регулируемых областяхТребуйте согласование для записей, деплоев, платежей, внешних отправок и привилегированных изменений.
Ограниченные учетные данныеP0Чрезмерного использования учетных данных и ошибок confused deputyИспользуйте узкие области доступа для каждого сервера и инструмента.
Изоляция MCP-серверовP1Отравления инструментов, подмены инструментов и атак между серверамиНе объединяйте недоверенные серверы и мощные инструменты в одном контексте без ревью.
Аудиторские трейсыP1Отсутствия истории инцидентаСохраняйте пользовательский запрос, tool call, аргументы, результат, решение политики и данные согласовавшего.
ГардрейлыP1Небезопасного входного и выходного текстаПолезны, но недостаточны для контроля полномочий инструментов.
Red-team эвалыP1Известных путей атакиТестируйте промпт-инъекции, отравление инструментов, эксфильтрацию данных и обход разрешений.

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

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

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

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

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

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

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

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

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

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

Одних гардрейлов недостаточно

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

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

Ссылки