Agentic IAM: что это и почему это неизбежно
AI-агенты уже участвуют в бизнес-процессах — от обработки заявок до торговых операций. Но традиционный IAM заточен под человека, а не под миллионы эфемерных сущностей. Agentic IAM меняет саму парадигму управления доступом.
Agentic IAM: что это и почему это неизбежно
От человека к субъекту
Identity and Access Management (IAM) зародился вокруг человека: сотрудник входит в систему, получает сессию, работает в рамках ролей. Эта модель десятилетиями служила основой корпоративной безопасности и легла в основу Keycloak, Okta, Auth0, Microsoft Entra ID.
Однако цифровая среда перестала быть человеко-центричной. AI-агенты обрабатывают заявки, микросервисы обмениваются данными, serverless-функции запускаются на секунды, IoT-устройства действуют автономно. Все они — субъекты без биометрии, рабочего графика и постоянного рабочего места. Для них нужна новая модель управления идентичностью.
Agentic IAM — это эволюция IAM, в которой центральным объектом становится автономная или полуавтономная сущность, действующая от имени делегирующей идентичности. Ключевые отличия таких субъектов:
- Эфемерность: агенты живут секунды или минуты, а не часы.
- Масштаб: речь идёт о миллионах конкурентных экземпляров.
- Делегирование: оркестратор поручает задачу рабочему агенту, тот — специализированному подагенту.
- Контекст: права зависят от намерения, цепочки делегирования и рискового профиля, а не только от роли.
В рабочей группе AIMS при IETF эта область формализуется как семейство стандартов от идентификаторов до политик авторизации. Вершина архитектуры — не аутентификация, а непрерывная авторизация: каждое действие оценивается в контексте делегации и намерения.
Почему устаревший IAM не справляется
Традиционный IAM не плох — он просто предназначен для других условий.
| Парадигма IAM | Требования агентов | Проблема |
|---|---|---|
| RBAC | Динамические контекстные права | Статичные роли не выражают эфемерные задачи |
| Сессии на часы | Миллионы коротких сессий | Перегруз серверов и устаревшие токены |
| Липкие сессии | Горизонтальное масштабирование | Узкое место в распределённых системах |
| Человеческая аутентификация | Машинное делегирование | Нет механизма доверия агент-агент |
Технически многие enterprise-IAM написаны на Java. JVM даёт надёжность, но несёт накладные расходы: паузы сборщика мусора, высокое потребление памяти, долгий цикл исправления уязвимостей. Монолитные IAM-серверы не поддерживают аттестацию рабочих нагрузок, непрерывную верификацию и ослабление токенов — паттерны, критичные для агентов.
С бизнес-точки зрения каждый ИИ-проект упирается в эти ограничения. Компания внедряет агентов, но вынуждена приспосабливать их к устаревшей модели доступа. Это замедляет time-to-market, увеличивает операционные риски и превращает IAM в налог на инновации.
Non-Human Identities: цифры, которые меняют расчёты
Аналитики оценивают соотношение non-human identities (NHI) к человеческим как 50:1. Каждый CI/CD-конвейер, под Kubernetes, Lambda-функция и AI-агент — это NHI, которому нужна идентичность, права и аудит.
AI-агенты усугубляют проблему:
- они порождают подчинённые агенты;
- делегируют задачи динамически;
- оперируют контекстом, который статические роли не выражают.
При этом 80% инцидентов с NHI связаны с неуправляемыми учётными данными: устаревшие секреты, забытые сервисные аккаунты, избыточно широкие токены. Компрометация одного звена в цепочке агентов распространяется каскадом: если скомпрометирован оркестратор, все делегированные агенты становятся векторами атаки.
Четыре столпа Agentic IAM
Для бизнес-аудитории полезно представить Agentic IAM как систему из четырёх взаимосвязанных слоёв:
- Идентичность рабочих нагрузок. Стандарты SPIFFE/SPIRE и WIMSE позволяют выдавать криптографически подтверждённую идентичность микросервисам, функциям и агентам.
- Делегирование. Обмен токенами OAuth и транзакционные токены фиксируют, кто поручил задачу кому, и сохраняют аудит-трейл через цепочку
act-утверждений. - Привязка к отправителю. DPoP гарантирует, что токен не может быть украден и использован с другого устройства или процесса.
- Внешняя авторизация. AuthZEN выносит решение о доступе из приложения в политический движок, который учитывает риски и намерения.
Вместе эти слои позволяют ответить на три ключевых вопроса безопасности: кто действует, от чьего имени и в каких рамках.
Почему сейчас: бизнес-императивы
Рост числа агентов ускоряется по нескольким причинам. Во-первых, крупные вендоры — Google, Anthropic, OpenAI, Microsoft — внедряют агентные платформы в корпоративные продукты. Во-вторых, стоимость запуска агента падает, и даже средние компании получают выгоду от автоматизации. В-третьих, регуляторы начинают требовать прозрачности действий ИИ-систем.
Для руководителей и BDM Agentic IAM — это ответ на конкретные вызовы:
- Снижение рисков. Понятная цепочка делегирования и краткосрочные токены ограничивают радиус взрыва при компрометации.
- Ускорение цифровизации. Агенты получают доступ к данным и инструментам без ручного согласования ролей.
- Соответствие регуляторике. EU AI Act и NIST уже требуют аудита действий ИИ-систем и контроля со стороны человека.
- Экономия инфраструктуры. Лёгкие, безсостоятельные потоки аутентификации дешевле масштабировать, чем монолитные IAM.
Что делать уже сегодня
Переход к Agentic IAM не требует снесения действующих систем. Большинство компаний может начать с трёх шагов:
- Инвентаризация NHI: понять, сколько нечеловеческих идентичностей уже работает в инфраструктуре.
- Пилот делегирования: протестировать обмен токенами и транзакционные токены для одного агентного сценария.
- Выбор платформы: оценить, поддерживает ли текущий IAM стандарты SPIFFE, DPoP и AuthZEN, или нужна современная альтернатива.
От ролей к намерениям
В классическом IAM права человека обычно привязаны к роли: менеджер, аналитик, администратор. Роль выдаётся на месяцы и годы, и её изменение требует заявки. В мире агентов такая модель не работает: один и тот же агент в одном вызове может читать данные, а в другом — отправлять платёж. Права зависят не от роли, а от намерения и контекста.
Поэтому Agentic IAM опирается на более гибкие модели:
- ABAC — авторизация на основе атрибутов: время, география, рисковый профиль, тип данных.
- ReBAC — авторизация на основе отношений: агент А является подчинённым оркестратора Б.
- PBAC — политики, которые могут обновляться без изменения кода приложения.
Эти модели позволяют выражать права вида: «этот агент может читать счета клиента X в течение 30 секунд в рамках задачи Y, одобренной оператором Z».
Бизнес-примеры перехода
Рассмотрим три примера, где Agentic IAM становится критичным:
- Банковский кредитный агент. Агент анализирует заявку, запрашивает данные бюро, формирует рекомендацию. Каждый шаг требует доступа к разным системам, но только в контексте конкретной заявки. Транзакционные токены фиксируют эту цепочку.
- Логистический оператор. Агенты компаний А и Б обмениваются данными о доставке через границы доверия. DID и федерация SPIFFE позволяют аутентифицироваться без единого IdP.
- Служба поддержки клиентов. Эфемерный агент обрабатывает один тикет, получает доступ к базе знаний и CRM, затем исчезает. JIT-идентичность гарантирует, что доступа не останется после завершения задачи.
Во всех трёх случаях классический IAM замедляет процесс и повышает риски, а Agentic IAM делает автоматизацию безопасной и масштабируемой.
Вывод
Agentic IAM — не вопрос «если», а вопрос «когда». Рост числа агентов, масштаб NHI и требования регуляторов делают переход неизбежным. Компании, которые начнут формировать агенто-центричную стратегию идентичности сегодня, получат преимущество в скорости, безопасности и соответствии стандартам завтра.
