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

Лучшие паттерны безопасности ИИ-агент в 2026 году

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

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

Ранжирование шаблонов

ШаблонПриоритетзащищает отПримечание к реализации
Инструменты с принципом минимальных привилегийP0Чрезмерная автономностьНе разрешайте доступ к инструментам, которые агент вообще не должен использовать.
Предварительные проверки политики инструментаP0Опасные действияПроверьте конкретную операцию непосредственно перед её выполнением.
СэндбоксыP0Повреждение файлов, оболочки, браузера и сетевого оборудованияИзолируйте код и ненадёжный контент.
Утверждение человекомP0Нерегрессивные или управляемые операцииЗаписи в шлюз, деплои, платежи, внешние отправки и изменения с привилегиями.
Облаченные учетные данныеP0Проблемы чрезмерных привилегий у сертификатов и сбои из-за некорректной работы заместителейИспользуйте узкие диапазоны применения на уровне отдельных серверов и инструментов.
изоляция серверов MCPP1Отравление инструментов, затенение инструментов, атаки между серверамиНе следует объединять ненадёжные серверы и мощные инструменты в одном контексте без предварительной проверки.
Проведение аудита трейсыP1Неизвестная история инцидентовСохранять информацию о запросе пользователя, tool call, аргументах, результатах, принятом решении по политике и лице, утвердившем его.
ГардрейлыP1Небезопасный входной и выходной текстПолезно, но недостаточно для предоставления полномочий инструменту.
Атака красной команды эвалыP1Известные пути атакиПровести тестирование промпт-инъекция, а также проверку на отравление инструментов, утечку данных и обход прав доступа.

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

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

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

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

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

Специфические риски MCP

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

Что касается MCP, я бы оставил эти правила в процессе кодового ревью:

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

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

Дополнительная литература

Список литературы