Аналитика · Безопасность AI-агентов

Безопасность AI-агентов: как превратить автономность в управляемый риск

Архитектура полномочий, порядок согласования и журнал действий для корпоративных AI-агентов.

Иллюстрация к материалу «Безопасность AI-агентов: как превратить автономность в управляемый риск»
Темы:AI-агентыизбыточные полномочияконтроль доступажурналирование

AI-агент соединяет вероятностный вывод модели с детерминированными инструментами. Поэтому вопрос безопасности — не только в том, что агент может предложить, но и в том, какая учётная запись выполняет действие, с какими правами, по какой политике и с каким доказательным следом.

01

Не передавайте агенту широкие права

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

02

Проверяйте действие до исполнения

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

03

Ограничивайте радиус и время

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

04

Делайте цепочку объяснимой для SOC

Для расследования нужны учётные записи пользователя и агента, версия модели и политики, найденный контекст с защищёнными ссылками, попытки и результаты вызовов инструментов, а также решения о согласовании или отказе. Журналы следует минимизировать и защищать как чувствительные данные.

Граница применимости. Это защитно-ориентированное объяснение, а не гарантия предотвращения инцидентов. Контроли следует адаптировать через моделирование угроз, требования к данным и процессы реагирования вашей организации.

Продолжите исследование

Связанные риски

Карточки связывают материал с конкретными угрозами, признаками и мерами защиты на интерактивной карте.

A33 · Высокий

MCP/tool poisoning

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
A34 · Критический

Excessive agency / tool permissions

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
A35 · Критический

Confused deputy in agentic workflows

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
A36 · Высокий

Memory poisoning

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
A37 · Высокий

Automatic agent invocation / cross-agent escalation

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
Открыть интерактивную карту угроз
Первоисточники

Международные источники и практики

Сначала мы объясняем практический смысл материала на русском. Ниже — первоисточники для проверки и детального изучения границ применимости.

OWASPLLM06:2025 Excessive AgencyИзбыточные полномочия и автономность агентов.MITREMITRE ATLASТактики и техники против AI-систем.CISA / NSACareful Adoption of Agentic AI ServicesКонтроли для agentic AI.