IAM для AI-агентов: почему контроль доступа должен видеть исполнение
AI-агенты получают доступ к корпоративным системам, вызывают инструменты и действуют с делегированными полномочиями, поэтому для них нужна отдельная архитектура управления идентификацией и доступом. В материале The Hacker News ключевыми элементами названы собственная нечеловеческая идентичность агента, человек-владелец, ограниченная цель, срок действия полномочий и постоянное наблюдение за действиями.
Проблема состоит в разрыве между назначенными правами и фактическим исполнением. IAM-платформа обычно показывает, какой доступ был выдан, а приложения и инфраструктура фиксируют, что агент действительно сделал после аутентификации. Между этими уровнями могут оставаться неучтённые агенты, учётные данные, локальные аккаунты и пути входа, которые не видны центральной системе идентификации.
Почему привычный IAM не покрывает автономных агентов
Традиционный IAM управляет жизненным циклом, выдачей прав, политиками и входом через SSO. Эти механизмы важны, но они не описывают цепочку действий автономного агента внутри приложения. Агент способен динамически выбирать инструменты и соединять несколько операций, которые не были предусмотрены при очередной проверке роли.
OWASP относит такой сценарий к риску excessive agency, или избыточной агентности, в категории LLM06. Широкая функциональность, разрешения либо автономность могут позволить агенту выполнить действия за пределами согласованной задачи. Конфигурация показывает возможность такого поведения, тогда как телеметрия позволяет увидеть совершившееся действие.
Какие контроли нужны для агентной идентичности
Каждому агенту требуется уникальная и атрибутируемая идентичность: нельзя использовать общий сервисный аккаунт или заимствованную пользовательскую сессию. Для учётных данных предпочтительны федерация идентичности рабочей нагрузки и короткоживущие автоматически обновляемые токены вместо встроенных секретов. При работе от имени пользователя OAuth 2.0 Token Exchange из RFC 8693 помогает разделить личность агента и делегированные ему полномочия.
Авторизация должна находиться близко к точке действия. Практические ограничения включают выдачу прав на конкретную задачу с окончанием срока, разрешённый список API и функций, границы для источников данных и подтверждение человеком операций с высокими последствиями. Такой подход соответствует принципам минимальных привилегий и разделения обязанностей из NIST SP 800-53 Rev. 5.
Наблюдаемость и отзыв прав становятся частью защиты
Для аудита недостаточно доказать, что политика была настроена. Нужны записи, позволяющие восстановить последовательность вызовов инструментов, доступа к данным и применения привилегий. Это особенно важно при злоупотреблении легитимными учётными данными: события входа могут выглядеть штатно, хотя реальное поведение агента уже не соответствует его задаче.
При выборе подхода стоит оценивать не только коннекторы и процессы выдачи доступа, но и наличие владельца у каждого агента, обнаружение идентичностей в приложениях и инфраструктуре, качество телеметрии, скорость отзыва делегированных прав и доказательства для аудита. Для бизнеса практический вывод прост: агентные доступы нужно инвентаризировать и ограничивать на этапе жизненного цикла, а затем непрерывно сопоставлять назначенную цель с фактическим исполнением.