AI-агенты сломали управление жизненным циклом идентификации. Что с этим делать
Классические IAM-системы заточены под людей, а AI-агенты не проходят через HR. Разбираем, почему ломается joiner-mover-leaver и как адаптировать ILM под автономных цифровых сотрудников.
Корпоративные системы управления идентификацией до сих пор живут по правилам, написанным для людей: HR создаёт запись, менеджер подтверждает доступы, увольнение отключает аккаунты. Но в продакшен уже врываются AI-агенты — автономные цифровые сущности, у которых нет трудового договора, начальника и даты увольнения. Их права появляются из Terraform-скрипта, OAuth-консенса или переменной окружения, а классическая модель joiner-mover-leaver об этом узнаёт слишком поздно — или никогда.
Identity Lifecycle Management (ILM, управление жизненным циклом идентификации) — это процесс, который контролирует доступ цифровой личности от первого provisioning-события до окончательного отключения. В его основе три канонических перехода: joiner (новый сотрудник), mover (перевод) и leaver (увольнение). Всё это работает, пока каждая идентичность однозначно отображается на человека с должностью, отделом и руководителем.
AI-агенты ломают эту модель на корню. Они не приходят через HR, не меняют должностей в Workday и не увольняются по заявлению. Вместо этого их создают инженеры, оркестраторы вроде LangChain или AutoGen, и CI/CD-пайплайны. Результат: в инфраструктуре появляются принципалы с правами, но без governance-записи — слепое пятно, которое растёт быстрее, чем его успевают находить.
Ключевые выводы
- Классический ILM построен вокруг HR-событий: приём, перевод, увольнение человека.
- AI-агенты не порождают ни одного из этих событий, поэтому IGA-платформы их не видят.
- Агенты получают избыточные права при создании, накапливают доступы во время работы и оставляют живые учётные данные после отключения.
- Решение — не «натянуть» HR-логику на агентов, а перестроить governance вокруг их реального жизненного цикла: discovery, behavioral monitoring, policy-driven provisioning и deprecation по факту неактивности.
- В России тема особенно актуальна: Яндекс GPT, GigaChat, VK LLM и корпоративные облака уже внедряют агентов, а регуляторика пока не даёт чётких ILM-стандартов для них.
Как ILM работает для людей
HR — источник истины
В классической схеме HR-платформа (Workday, SAP SuccessFactors, ServiceNow HR) является системой записи. Новый сотрудник появляется в HR — IGA-коннекторы автоматически создают аккаунт в Active Directory, Entra ID или Google Workspace, а оттуда права распространяются на корпоративные приложения. Перевод в другой отдел пересчитывает роли, увольнение запускает деактивацию.
Сила модели — в детерминизме. Права отражают проверяемый организационный факт: человек занимает конкретную роль в конкретной команде. RBAC-политики, SoD-контроли и аттестационные кампании строятся поверх этой структуры, давая аудиторские следы для SOX, HIPAA, PCI DSS и 152-ФЗ.
Joiner, mover, leaver
- Joiner — HR-событие создаёт идентичность, запускает onboarding и одобрение доступов.
- Mover — изменение атрибутов пересчитывает entitlement set: старые права отзываются, новые выдаются.
- Leaver — прекращение трудовых отношений триггерит деактивацию во всех подключённых системах.
- Между этими событиями работают периодические access review, где менеджер или владелец приложения подтверждает актуальность прав.
Почему AI-агенты не вписываются в ILM
Нет авторитетного источника
Человек появляется в IAM, потому что HR считает его сотрудником. Агент появляется, потому что кто-то закоммитил YAML, вызвал API Bedrock Agents или развернул оркестратор. Ни одно из этих событий не попадает в IGA-платформу. У агента нет владельца в governance-реестре, нет manager-атрибута и нет даты создания, которую можно было бы отследить.
Динамическая область доступа
RBAC работает, потому что человеческие роли относительно стабильны: бухгалтер, DBA, DevOps-инженер. У AI-агента роль меняется во время работы: агент, созданный для суммирования документов, через tool-calling может начать писать в хранилище, которого не было в исходном скоупе, или вызывать API, для которого не было explicit-разрешения. Область доступа расширяется runtime, а не governance-решением.
Множественные экземпляры и делегирование
Человек существует в одном месте в каждый момент времени. Агент может работать десятками параллельных инстансов в Kubernetes, serverless-функциях и SaaS-API одновременно. В мультиагентных архитектурах оркестратор порождает суб-агентов, передаёт им задачи и креденшелы — и IGA-система не знает, что эти сущности связаны между собой.
События, которые агенты никогда не порождают
No joiner — нет управляемого входа
При создании агента не возникает HR-записи, не запускается approval workflow и не прикрепляется владелец. Права выдаются «в проёде»: сервисный аккаунт создаётся вместе с инфраструктурой, API-ключ пишется в переменную окружения, OAuth-консенсент проходит через developer flow. Governance-запись начинается с пустоты.
No mover — нет пересчёта прав
Когда агент начинает обращаться к новому источнику данных или вызывать дополнительный API, никто не обновляет его атрибуты в IGA. Нет события, которое пересчитало бы entitlement set. Права накапливаются поэтапно, и ни одна из итераций не проходит ревью.
No access review — некому аттестовать
Кампании аттестации маршрутизируются по manager-атрибуту или владельцу приложения. У агента нет менеджера, а владелец приложения часто — это команда, которая не отслеживает, какие API агент реально вызывает сегодня. Ревьюер подтверждает то, что видит в IGA — а там зачастую лишь первоначальный provisioning.
No leaver — учётные данные переживают нагрузку
Агент «увольняется», когда команда архивирует репозиторий, удаляет workflow или закрывает проект. Но это событие не доходит до Secrets Manager, authorization server и AD. API-ключи остаются валидными, OAuth-гранты не отзываются, сервисные аккаунты не удаляются. Со временем в инфраструктуре накапливается цифровой «зомби-кладбище» из неуправляемых креденшелов.
Что это значит на практике
Over-permissioning по умолчанию
Человек получает минимум прав, необходимых роли. Агент получает столько, чтобы «точно заработало». AWS IAM-политики с wildcard, OAuth-скоупы, запрошенные разом, и permissive service accounts — типичная отправная точка. Минимально необходимые права не определяются, approval-цепочки не проходят, IGA не фиксирует бизнес-обоснование.
Access review находит не того владельца
Даже если агент попадает в кампанию аттестации, ревьюер видит статичную учётную запись, а не реальное поведение. Аттестация формально выполнена, но операционно бессмысленна: подтверждаются права, которые агент давно перерос или, наоборот, не использует.
Живые креденшелы мёртвых агентов
Долгоживущий API-ключ с доступом к production-базе, привязанный к workload, который больше не запускается, — это не проблема гигиены, а уязвимость. У такого доступа нет владельца, нет истории ревью и нет срока действия. В средах с сотнями агентов ручной аудит не справляется.
Как адаптировать ILM под AI-агентов
Расширять ILM на агентов — не значит натягивать HR-процессы на цифровых сотрудников. Нужно перестроить governance вокруг их реального жизненного цикла.
1. Автоматическое discovery по всем поверхностям
Агенты живут в IAM-провайдерах, OAuth-серверах, Kubernetes service accounts, secrets manager’ах и CI/CD. ILM для агентов требует непрерывного сканирования: читать policy-attachments в AWS/Azure, извлекать OAuth-клиенты, находить service account’ы в неймспейсах, выявлять API-ключи в runtime-конфигурациях. Discovery должен быть постоянным — деплои меняются чаще, чем проходят квартальные аудиты.
2. Модель атрибутов для агентов
Вместо department / job title / manager агенту нужны другие атрибуты: команда-владелец, документированная цель, разрешённые системы и API, timestamp деплоя, ожидаемый срок жизни. Поведенческие атрибуты не менее важны: какие API вызывает, с какой периодичностью, к каким данным обращается. Эти данные становятся входом для пересчёта прав.
3. Policy-driven provisioning
Права выдаются не «на вырост», а на основе документированной функции агента. Запрос на доступ к production API или чувствительным данным проходит через governance-воркфлоу, а не через deployment pipeline в обход. Credential привязывается к владельцу, который несёт ответственность за изменения скоупа.
4. Поведенческий мониторинг вместо периодических ревью
Для агентов периодическая аттестация не даёт actionable-сигнала. Замена — непрерывный behavioral monitoring: сравнивать реальные вызовы с provisioned entitlement set и флагать отклонения в реальном времени. Если агент начал обращаться к API вне скоупа, это governance-событие, а не повод для следующего квартального отчёта.
5. Deprecation по операционному статусу
Offboarding агентов должен запускаться по сигналам неактивности: API-ключ, не использовавшийся 30 дней, попадает в кандидаты на отзыв. Изменение скоупа в деплое генерирует governance-событие для повторного одобрения. Интеграция с Vault, AWS Secrets Manager и Azure Key Vault позволяет автоматизировать отзыв.
Российский контекст: агенты уже в облаках
В России ситуация осложняется одновременным развитием локальных LLM и корпоративных облаков. Яндекс GPT, GigaChat, VK LLM, а также собственные развёртывания на базе открытых моделей в Yandex Cloud, SberCloud и других провайдерах уже используются для автоматизации процессов. Агенты появляются в биллинге, HR, логистике, клиентском сервисе — там, где традиционно работает ILM.
Регуляторика пока не даёт отдельных стандартов для управления жизненным циклом AI-агентов. 187-ФЗ и требования ЦБ РФ к информационной безопасности фокусируются на критической информационной инфраструктуре, персональных данных и инцидентах, но не описывают, как аттестовать доступы автономных цифровых сотрудников. Компаниям приходится самим формировать практики: выделять владельцев агентов, вести реестры, ограничивать скоупы и мониторить поведение.
Практический совет:
Если в вашей организации уже есть пилот с AI-агентом, начните с инвентаризации: составьте список всех service account’ов, API-ключей и OAuth-грантов, которые агент реально использует. Сравните его с тем, что записано в IGA. Разница — ваше первое слепое пятно.
Часто задаваемые вопросы
Чем AI-агент принципиально отличается от обычного service account?
Service account обычно имеет фиксированную цель и статичные права. AI-агент — это автономный принципал, который принимает решения о доступе в runtime, может расширять область действия через tool-calling и существовать множеством параллельных экземпляров. Традиционный service account не делает самостоятельных authorization-решений.
Почему нельзя просто создать для агента «фиктивную» HR-запись?
Можно, но это костыль, а не решение. HR-события не отражают реальность агента: у него нет менеджера, даты приёма и увольнения, а скоуп меняется не по переводу, а по обновлению кода. Вместо имитации человеческого lifecycle нужно моделировать lifecycle агента: deployment, scope change, inactivity, deprecation.
Какие первые шаги для адаптации ILM под агентов?
Начните с discovery: найдите все agent identities в своей инфраструктуре. Затем зафиксируйте владельца, цель и разрешённые API для каждого агента. Внедрите behavioral monitoring и автоматический отзыв неактивных креденшелов. Только после этого масштабируйте governance на всю agent-популяцию.
Как это соотносится с российскими требованиями к ИБ?
187-ФЗ и требования ЦБ РФ требуют контроля доступа, инцидент-менеджмента и защиты персональных данных. Хотя они прямо не описывают AI-агентов, принципы минимальных прав, аудита доступа и управления жизненным циклом учётных записей применимы и к ним. Досрочное внедрение ILM для агентов снижает риск санкций со стороны регулятора.
Можно ли решить проблему только инструментами класса IGA?
Современные IGA-платформы плохо видят agent identities, созданные вне их коннекторов. Нужен слой discovery, который интегрируется с оркестраторами, cloud IAM, Kubernetes и secrets manager’ами. IGA остаётся execution-слоем для revocation и review, но источником истины для агентов становится их operational footprint, а не HR.
Выводы
AI-агенты — не просто новый тип workload. Это новый тип цифрового принципала, для которого классические HR-driven ILM не работает. Они не порождают joiner/mover/leaver, не имеют manager-атрибута и не увольняются. Вместо того чтобы натягивать на них человеческие процессы, компаниям нужно строить governance вокруг реального жизненного цикла агента: discovery, policy-driven provisioning, behavioral monitoring и deprecation по факту неактивности.
Главный вызов не в том, чтобы запретить агентам доступ, а в том, чтобы увидеть их в своей identity-поверхности до того, как это сделает злоумышленник.
Источник: The Hacker News — Identity Lifecycle Management Wasn't Built for AI Agents.
CTA: Если в вашей компании уже есть AI-агенты в продакшене, проведите инвентаризацию их креденшелов на этой неделе. Скорее всего, вы найдёте доступы, о которых никто не знал, — и именно они станут первым шагом к зрелой модели управления автономными идентификациями.
