Корпоративные системы управления идентификацией до сих пор живут по правилам, написанным для людей: 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 — источник истины

В классической схеме 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 привязывается к владельцу, который несёт ответственность за изменения скоупа.

			agent_id: invoice-processor-v2
owner_team: finance-automation
purpose: summarize invoices and write to ERP
allowed_apis:
  - api://erp.company/invoices.read
  - api://storage.company/invoices.write
max_token_lifetime: 90d
review_trigger: scope_change | inactivity_30d
		

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-агенты — не просто новый тип workload. Это новый тип цифрового принципала, для которого классические HR-driven ILM не работает. Они не порождают joiner/mover/leaver, не имеют manager-атрибута и не увольняются. Вместо того чтобы натягивать на них человеческие процессы, компаниям нужно строить governance вокруг реального жизненного цикла агента: discovery, policy-driven provisioning, behavioral monitoring и deprecation по факту неактивности.

Главный вызов не в том, чтобы запретить агентам доступ, а в том, чтобы увидеть их в своей identity-поверхности до того, как это сделает злоумышленник.

The Hacker News / Orchid Securityисследование Identity Lifecycle Management for AI Agents

Источник: The Hacker News — Identity Lifecycle Management Wasn't Built for AI Agents.

CTA: Если в вашей компании уже есть AI-агенты в продакшене, проведите инвентаризацию их креденшелов на этой неделе. Скорее всего, вы найдёте доступы, о которых никто не знал, — и именно они станут первым шагом к зрелой модели управления автономными идентификациями.