Системы управления жизненным циклом идентификаторов (ILM) строились десятилетиями с одним базовым допущением: каждая корпоративная учётная запись принадлежит человеку. У этого человека есть HR-запись, руководитель, должность и дата увольнения. Вся логика — от выдачи прав до их отзыва — держится именно на этом. ИИ-агенты не имеют ни одного из этих атрибутов. И именно здесь начинаются серьёзные проблемы.
Классическая модель работает через три события: Joiner (новый сотрудник), Mover (смена роли или отдела) и Leaver (увольнение). Платформы Workday, SAP SuccessFactors и ServiceNow HR служат авторитетным источником данных, который запускает автоматическую выдачу прав через IGA-коннекторы в Active Directory и Azure AD. Когда сотрудника переводят в другой отдел, атрибуты роли меняются, набор прав пересчитывается. Когда он уходит, инструкция на деprovisioning уходит во все подключённые системы. Модель детерминированная, привязанная к проверяемым организационным фактам и покрывает требования SOX, HIPAA и PCI DSS. Она работает хорошо — ровно до тех пор, пока в систему не попадает сущность, которая через HR вообще не проходила.
ИИ-агентов создают инженеры, оркестрационные фреймворки и автоматизированные пайплайны развёртывания. Они появляются в продакшне через Terraform apply, вызов API платформы или коммит конфигурационного файла. LangChain, AutoGen, AWS Bedrock Agents — ни одна из этих точек входа не касается IGA-платформы. Учётные данные создаются прямо в процессе деплоя: вручную созданные сервисные аккаунты, API-ключи в переменных окружения, OAuth-гранты через developer consent flow. Для IGA-системы агент выглядит как статичная машинная идентификация. Что она реально делает — система не видит.
Ролевое управление доступом (RBAC) предполагает, что функции сотрудника относительно предсказуемы. Агент, созданный для суммаризации внутренних документов, может начать вызывать API, для которых его никто не провизионировал, записывать результаты в хранилища за пределами исходного периметра и выстраивать цепочки действий через несколько корпоративных систем. Его поверхность доступа расширяется в рантайме — не на этапе выдачи прав, а в процессе работы, которую ILM отследить уже не может.
Человеческая идентификация существует в одном месте одновременно. Агент может работать как десятки параллельных инстанций — в облачных средах, контейнерных нагрузках, через SaaS API-поверхности. Каждая инстанция несёт свой набор учётных данных, разрешений и сессионный контекст. В IGA-системе они никак не коррелируют. В мультиагентных архитектурах оркестраторы порождают суб-агентов, задачи делегируются, учётные данные передаются между контекстами выполнения. Ни одна существующая IGA-модель не рассчитана на принципала, который разветвляется, делегирует и снова объединяет права доступа.
Ни одно из трёх ключевых событий жизненного цикла агент не запускает. Нет Joiner — при деплое не срабатывает IGA-воркфлоу, не подаётся запрос на доступ, нет руководителя, который утверждает набор прав, и governance-запись с первого дня остаётся пустой. Нет Mover — когда агента дорабатывают или перенаправляют на другую среду, никакой HR-системы это не касается, IGA-коннектор не получает изменения атрибутов, расширение периметра происходит невидимо. Нет Leaver — когда воркфлоу архивируется или вычислительный ресурс отключается, сервисный аккаунт продолжает жить в Active Directory или Entra ID, API-ключ остаётся валидным в secrets manager, OAuth-грант продолжает действовать на сервере авторизации. Никто не послал инструкцию на отзыв, потому что никто не мониторил операционный статус агента.
На каждом из этих этапов возникают конкретные риски. При провизионировании разработчик выдаёт доступ достаточно широкий, чтобы задача точно выполнилась: AWS IAM политики с wildcard-ресурсами, OAuth consent flow, выдающий все запрошенные скоупы без проверки отдельных разрешений, создание сервисных аккаунтов в Azure AD или Google Workspace без встроенной проверки entitlement governance. Агент стартует с избыточными правами, без минимально необходимого базового набора и без IGA-записи, связывающей доступ с бизнес-требованием. Кампании сертификации доступа не могут найти владельца — большинство агентных идентификаторов не имеют атрибута manager, а записи о владельцах указывают на команды, а не на конкретных людей. Аттестация формально завершается, оставаясь операционно бессмысленной. Долгоживущий API-ключ с доступом к production-базе данных, прикреплённый к давно списанной нагрузке — это реальный сценарий, а не теоретический.
Починить это путём адаптации HR-ориентированных воркфлоу не получится — логику governance нужно перестраивать вокруг реальных операционных характеристик агентов. Первое, что требуется — непрерывное обнаружение идентификаторов по всей поверхности развёртывания: облачные IAM-системы провайдеров, OAuth authorization servers у SaaS-платформ, Kubernetes service accounts, secrets managers, CI/CD пайплайны. Ни одна из этих систем не ведёт полного инвентаря. Обнаружение должно быть постоянным: агентные деплойменты меняются быстрее, чем квартальные аудиторские циклы.
Вместо атрибутов организационной структуры (отдел, должность, руководитель) для агентов нужна другая модель: ответственная команда, задокументированная операционная цель, ограниченный список авторизованных систем и API, timestamp деплоя, ожидаемое время жизни, привязанное к воркфлоу, и поведенческие атрибуты — какие API вызываются, с какой частотой, через какие поверхности данных. Наблюдаемые паттерны доступа используются как входные данные для governance, а не как факультативная информация. Это позволяет выявлять разрешения, которые агент имеет, но никогда не использует.
Периодическая сертификация доступа не даёт никакого полезного сигнала для агентов. Её заменяет непрерывный поведенческий мониторинг: отслеживание реальных вызовов каждого агента, сравнение наблюдаемого доступа с провизионированным набором прав, мгновенная индикация расхождений. Когда агент вызывает API за пределами провизионированного скоупа — это должно быть немедленное governance-событие, а не квартальная находка. Депрекация агента должна запускаться мониторингом неактивности, привязанным к логам использования учётных данных. API-ключ без аутентифицированных запросов за определённый период — кандидат на ревью с последующим отзывом. Обнаружение изменения скоупа при деплое должно автоматически маршрутизировать реавторизацию к ответственной команде. Целевые системы для автоматического отзыва — AWS Secrets Manager, Azure Key Vault, HashiCorp Vault.
Orchid Security — один из немногих вендоров, строящих решение именно под эту задачу. Компания разворачивает легковесные оркестраторы, которые инструментируют приложения напрямую и извлекают аутентификационные потоки, логику авторизации, конфигурации аккаунтов и паттерны хранения учётных данных — в том числе из неуправляемых сред. Результат — постоянно обновляемый инвентарь идентификаторов, включающий всех агентов, сервисные аккаунты и API-учётные данные, которые никогда не проходили через IGA-intake. На основе этих данных строится identity graph, отображающий каждого принципала — человека и не-человека — вместе с аутентификационными потоками, правами и реально используемыми путями доступа. Для агентных идентификаторов граф показывает ответственную команду, провизионированный набор разрешений, наблюдаемые поведенческие паттерны и возраст учётных данных. Применяемые политики работают с существующей IAM, PAM и IGA-инфраструктурой, маршрутизируя remediation через инструменты, которые в организации уже используются.
Классическая модель работает через три события: Joiner (новый сотрудник), Mover (смена роли или отдела) и Leaver (увольнение). Платформы Workday, SAP SuccessFactors и ServiceNow HR служат авторитетным источником данных, который запускает автоматическую выдачу прав через IGA-коннекторы в Active Directory и Azure AD. Когда сотрудника переводят в другой отдел, атрибуты роли меняются, набор прав пересчитывается. Когда он уходит, инструкция на деprovisioning уходит во все подключённые системы. Модель детерминированная, привязанная к проверяемым организационным фактам и покрывает требования SOX, HIPAA и PCI DSS. Она работает хорошо — ровно до тех пор, пока в систему не попадает сущность, которая через HR вообще не проходила.
ИИ-агентов создают инженеры, оркестрационные фреймворки и автоматизированные пайплайны развёртывания. Они появляются в продакшне через Terraform apply, вызов API платформы или коммит конфигурационного файла. LangChain, AutoGen, AWS Bedrock Agents — ни одна из этих точек входа не касается IGA-платформы. Учётные данные создаются прямо в процессе деплоя: вручную созданные сервисные аккаунты, API-ключи в переменных окружения, OAuth-гранты через developer consent flow. Для IGA-системы агент выглядит как статичная машинная идентификация. Что она реально делает — система не видит.
Ролевое управление доступом (RBAC) предполагает, что функции сотрудника относительно предсказуемы. Агент, созданный для суммаризации внутренних документов, может начать вызывать API, для которых его никто не провизионировал, записывать результаты в хранилища за пределами исходного периметра и выстраивать цепочки действий через несколько корпоративных систем. Его поверхность доступа расширяется в рантайме — не на этапе выдачи прав, а в процессе работы, которую ILM отследить уже не может.
Человеческая идентификация существует в одном месте одновременно. Агент может работать как десятки параллельных инстанций — в облачных средах, контейнерных нагрузках, через SaaS API-поверхности. Каждая инстанция несёт свой набор учётных данных, разрешений и сессионный контекст. В IGA-системе они никак не коррелируют. В мультиагентных архитектурах оркестраторы порождают суб-агентов, задачи делегируются, учётные данные передаются между контекстами выполнения. Ни одна существующая IGA-модель не рассчитана на принципала, который разветвляется, делегирует и снова объединяет права доступа.
Ни одно из трёх ключевых событий жизненного цикла агент не запускает. Нет Joiner — при деплое не срабатывает IGA-воркфлоу, не подаётся запрос на доступ, нет руководителя, который утверждает набор прав, и governance-запись с первого дня остаётся пустой. Нет Mover — когда агента дорабатывают или перенаправляют на другую среду, никакой HR-системы это не касается, IGA-коннектор не получает изменения атрибутов, расширение периметра происходит невидимо. Нет Leaver — когда воркфлоу архивируется или вычислительный ресурс отключается, сервисный аккаунт продолжает жить в Active Directory или Entra ID, API-ключ остаётся валидным в secrets manager, OAuth-грант продолжает действовать на сервере авторизации. Никто не послал инструкцию на отзыв, потому что никто не мониторил операционный статус агента.
На каждом из этих этапов возникают конкретные риски. При провизионировании разработчик выдаёт доступ достаточно широкий, чтобы задача точно выполнилась: AWS IAM политики с wildcard-ресурсами, OAuth consent flow, выдающий все запрошенные скоупы без проверки отдельных разрешений, создание сервисных аккаунтов в Azure AD или Google Workspace без встроенной проверки entitlement governance. Агент стартует с избыточными правами, без минимально необходимого базового набора и без IGA-записи, связывающей доступ с бизнес-требованием. Кампании сертификации доступа не могут найти владельца — большинство агентных идентификаторов не имеют атрибута manager, а записи о владельцах указывают на команды, а не на конкретных людей. Аттестация формально завершается, оставаясь операционно бессмысленной. Долгоживущий API-ключ с доступом к production-базе данных, прикреплённый к давно списанной нагрузке — это реальный сценарий, а не теоретический.
Починить это путём адаптации HR-ориентированных воркфлоу не получится — логику governance нужно перестраивать вокруг реальных операционных характеристик агентов. Первое, что требуется — непрерывное обнаружение идентификаторов по всей поверхности развёртывания: облачные IAM-системы провайдеров, OAuth authorization servers у SaaS-платформ, Kubernetes service accounts, secrets managers, CI/CD пайплайны. Ни одна из этих систем не ведёт полного инвентаря. Обнаружение должно быть постоянным: агентные деплойменты меняются быстрее, чем квартальные аудиторские циклы.
Вместо атрибутов организационной структуры (отдел, должность, руководитель) для агентов нужна другая модель: ответственная команда, задокументированная операционная цель, ограниченный список авторизованных систем и API, timestamp деплоя, ожидаемое время жизни, привязанное к воркфлоу, и поведенческие атрибуты — какие API вызываются, с какой частотой, через какие поверхности данных. Наблюдаемые паттерны доступа используются как входные данные для governance, а не как факультативная информация. Это позволяет выявлять разрешения, которые агент имеет, но никогда не использует.
Периодическая сертификация доступа не даёт никакого полезного сигнала для агентов. Её заменяет непрерывный поведенческий мониторинг: отслеживание реальных вызовов каждого агента, сравнение наблюдаемого доступа с провизионированным набором прав, мгновенная индикация расхождений. Когда агент вызывает API за пределами провизионированного скоупа — это должно быть немедленное governance-событие, а не квартальная находка. Депрекация агента должна запускаться мониторингом неактивности, привязанным к логам использования учётных данных. API-ключ без аутентифицированных запросов за определённый период — кандидат на ревью с последующим отзывом. Обнаружение изменения скоупа при деплое должно автоматически маршрутизировать реавторизацию к ответственной команде. Целевые системы для автоматического отзыва — AWS Secrets Manager, Azure Key Vault, HashiCorp Vault.
Orchid Security — один из немногих вендоров, строящих решение именно под эту задачу. Компания разворачивает легковесные оркестраторы, которые инструментируют приложения напрямую и извлекают аутентификационные потоки, логику авторизации, конфигурации аккаунтов и паттерны хранения учётных данных — в том числе из неуправляемых сред. Результат — постоянно обновляемый инвентарь идентификаторов, включающий всех агентов, сервисные аккаунты и API-учётные данные, которые никогда не проходили через IGA-intake. На основе этих данных строится identity graph, отображающий каждого принципала — человека и не-человека — вместе с аутентификационными потоками, правами и реально используемыми путями доступа. Для агентных идентификаторов граф показывает ответственную команду, провизионированный набор разрешений, наблюдаемые поведенческие паттерны и возраст учётных данных. Применяемые политики работают с существующей IAM, PAM и IGA-инфраструктурой, маршрутизируя remediation через инструменты, которые в организации уже используются.