Анализ архитектурного кризиса в сфере идентификации и новой категории рисков
Управление идентификацией исторически отстаёт от инфраструктурных изменений. Инструменты класса IAM (Identity and Access Management) проектировались в эпоху, когда учётными записями управляли люди через заявки, а сервисные аккаунты выполняли заранее определённые функции. Появление агентного ИИ не просто расширило этот разрыв, а изменило саму его форму, и старые инструменты на это не рассчитаны.
Почему агенты не вписываются в существующие модели
Сервисный аккаунт работает с фиксированным набором ресурсов и заранее ограниченным набором действий. У него есть конкретная функция, узкие права, ключи лежат в хранилище, идентификатор заведён в PAM-процессы. Агент устроен принципиально иначе: он получает инструкцию, сам решает, как её выполнить, динамически выбирает инструменты, выстраивает цепочки вызовов между разными системами и при необходимости делегирует подзадачи другим агентам в рамках одной сессии. Один агент за один прогон может одновременно работать с CRM, репозиторием кода, хранилищем документов и внутренним API — то есть затрагивать ресурсы, которые ни один человек явно не авторизовал ему трогать.
Проблема наследования прав
Это самый глубокий архитектурный дефект. Агент наследует доступ от человека или сервисной учётки, от имени которой работает. У этого доступа исторический контекст: директор по продажам за годы менял роли, получал расширенные права, копились делегированные полномочия. Когда агент запускается «от лица» этого сотрудника, он забирает с собой все его OAuth-токены, все накопленные привилегии и работает с полной унаследованной авторизацией. При этом он не различает «что сделал бы человек» и «что ему поручили сделать». Традиционный IAM регистрирует событие логина и дальше теряет агента из вида: вся последовательность вызовов, обращений к данным, обход систем между ними остаётся прозрачной для слоя управления.
Тёмная материя идентификации становится активной
В каждой крупной среде копится «тёмная материя идентификации» — масса идентификационной активности, которая существует и создаёт реальные риски, но остаётся невидимой для инструментов. Это устаревшие делегирования, избыточно скоупированные учётки, забытые токены. Раньше они лежали мёртвым грузом. Теперь агент, подбирая унаследованные права, активирует их за миллисекунды. Нужен слой, работающий там, где идентификация реально исполняется, а не только там, где она аутентифицируется.
Три силы, разогнавшие внедрение за последний год
Ещё двенадцать месяцев назад запуск надёжного многоагентного воркфлоу требовал серьёзного инженерного труда. Сейчас появились стандартизированные примитивы: фреймворки LangGraph и AutoGen, протокол Anthropic MCP (Model Context Protocol). Параллельно стоимость инференса резко упала у всех крупных провайдеров моделей, и содержание агентов в непрерывном режиме стало экономически оправданным. А бизнес давит: автоматизировать обработку знаний в масштабах, которые человеческие ресурсы уже не вытягивают. В итоге агентный ИИ перешёл из стадии демонстраций в промышленные пайплайны быстрее, чем большинство служб безопасности успело это осознать.
Как обходят жизненный цикл идентификации
Агенты уже ведут закупки, эскалируют запросы клиентской поддержки, рецензируют код, сверяют финансовые данные, ищут информацию по внутренним базам знаний. Бизнес-подразделения заводят их через low-code платформы и готовые вендорские интеграции, часто вообще без согласования с безопасностью. Команда безопасности узнаёт о новых агентах во время инцидента или аудита, а иногда не узнаёт вовсе. Агенты не проходят через заявочные воркфлоу, не попадают в IGA-системы, а просто наследуют учётные данные от существующих идентификаторов и начинают работать. Растёт популяция автономных идентичностей без формальной записи, без привязки к владельцу, без поведенческого базового профиля.
Почему инструменты, которыми пользуются сегодня, тут не сработают
Системы IGA проектировались под человеческий жизненный цикл: приём, перемещение, увольнение, аттестация доступа. Агент не проходит через заявочный воркфлоу, его скоуп прав меняется динамически внутри сессии, а его жизненный цикл вообще не привязан к статусу сотрудника. В IGA нет нативного понятия «агент наследует человеческую идентичность, действует автономно, засыпает, просыпается в другом контексте».
Системы PAM заточены под человеческую сессию: выдача прав на ограниченное время, запись, ответственность. Агент не «берёт в аренду» учётные данные — он работает через унаследованные OAuth-делегирования, привязки к сервисным аккаунтам и ключи API, зашитые в конфигурации оркестрации. PAM видит хранилище, но не видит путь исполнения. Когда агент за одну сессию обходит четыре системы через делегированный OAuth-токен, у PAM нулевая видимость по всему маршруту.
CIEM и AI-SPM
CIEM неплохо справляется с нон-человеческой идентификацией внутри одного облака. Но граница, на которой он работает, и есть его ограничение: один облачный провайдер. А агентские нагрузки легко прыгают между несколькими облаками, SaaS-приложениями, локальными системами и сторонними API в рамках одного процесса. AI-SPM отвечает за конфигурацию и риск-постуру самой AI-инфраструктуры — контроль доступа к моделям, защиту обучающих данных, безопасность API. Это другая модель идентичности, и попытка натянуть её на агентские нагрузки даёт не покрытие, а опасные слепые зоны.
Пять рисков, превращающих неуправляемых агентов в идентификационную тёмную материю
[]Сессии-сироты и устаревшие учётные данные. Сессии агентов не всегда завершаются чисто. Долгоиграющие агенты и запланированные автоматизации держат активные учётки далеко за пределами срока задачи. Когда агента списывают или забывают, учётные данные часто остаются валидными. Особенно остро это в SaaS, где отзыв токена требует осознанного действия по каждому подключённому приложению. Агент-сирота через долгоживущий OAuth-токен сохраняет доступ к чувствительным системам месяцами.
[]Инъекция промптов как вектор эскалации привилегий. Злоумышленник вкладывает вредоносные инструкции в контент, который агент обрабатывает: документ для саммари, веб-страницу, тикет в поддержку. Агент встраивает их в своё рассуждение и выполняет действия, которые пользователь никогда не санкционировал. В среде с избыточно привилегированными унаследованными идентичностями инъекция промпта становится надёжным путём к эскалации привилегий — без касания учётных данных.
[]Боковое перемещение через цепочки вызовов агентов. В многоагентных архитектурах оркестратор делегирует подзадачи специализированным дочерним агентам, и каждое делегирование передаёт часть полномочий оркестратора. Компрометация в любой точке цепочки распространяется дальше. Злоумышленник получает эффективный доступ ко всем системам, которых касается цепочка доверия.
[]Проблема аудиторского следа. Агенты, работающие через неуправляемые SaaS, не оставляют связной криминалистической картины в существующих инструментах. Разбор инцидента превращается в сшивание фрагментированных логов из разрозненных систем, часто без достаточной точности, чтобы понять, какой именно агент совершил какое действие от чьего имени.
Что делать: четыре шага, чтобы вытащить агентов на свет
[]Классифицировать по уровню доверия и скоупу прав. Не каждый агент несёт одинаковый риск. Классификация идёт по трём осям: чувствительность удерживаемых прав, круг доступных систем, уровень доверия исходной идентичности. Агент с правами только на чтение в одной внутренней базе знаний — низкий риск. Агент с делегированными OAuth-токенами одновременно к финансовой системе и к платформе клиентских данных — высокий. Классификация двигает приоритеты: широкое наследование плюс чувствительные системы — немедленная переаттестация под принцип минимальных привилегий. Узкий, хорошо скоупированный доступ — мониторинг и периодический пересмотр. Без классификации все агенты выглядят одинаково, и усилия по ремедиации размазываются без учёта реальной концентрации риска.
[]Принуждать к минимальным привилегиям в рантайме, а не на этапе выдачи. Статический скоуп при провижининге быстро деградирует: агентов начинают использовать под новые задачи, унаследованные учётки редко обновляются под реальные потребности. Принуждение на уровне исполнения ограничивает радиус поражения при компрометации. Инъекция промпта против плотно скоупированного в рантайме агента достанет немного; та же атака против агента с активными полными унаследованными правами — катастрофа.
[]Интегрировать с существующим стеком идентификационной безопасности. Слой управления агентами должен расширять существующие инструменты, а не заменять их. Данные об идентичностях агентов уходят в IGA-платформы для аттестации доступа, в PAM для фиксации экспозиции учётных данных, в SIEM для обогащения алертов поведенческой историей агентов. Интеграционный слой превращает управление агентами из автономной функции в живой входной поток для более широкой платформы идентификационной безопасности. Каждый нижестоящий инструмент получает более точную картину того, что реально исполняется.
Архитектурное различие, которое нельзя обойти
Традиционные IAM отвечают на вопросы идентичности на этапе провижининга или на границе аутентификации. Разница не количественная. Управление автономной идентичностью, которая рассуждает, делегирует и действует, требует плоскости управления, которая рассуждает вместе с ней, наблюдает поведение в движении, а не проводит аудит доступа постфактум. Как метко сформулировано в исходном разборе: «агенты находят существующую тёмную материю идентификации и движутся сквозь неё на машинной скорости».
Практический итог
Скрытый аргумент всей этой конструкции прост: управление идентификацией перестало быть вопросом конфигурации. Агенты с унаследованными правами, обходящие жизненный цикл, делают прежний инструментарий архитектурно нерелевантным. Точка отсчёта новая: непрерывная инвентаризация, привязка каждого агента к ответственному человеку, поведенческий мониторинг с базовой линией и аномалиями, полный аудиторский след по каждому приложению, которого касается автономная идентичность, и принуждение на уровне исполнения. Там, где агенты и идентификация встречаются на машинной скорости, управлять нужно с той же скоростью.
Управление идентификацией исторически отстаёт от инфраструктурных изменений. Инструменты класса IAM (Identity and Access Management) проектировались в эпоху, когда учётными записями управляли люди через заявки, а сервисные аккаунты выполняли заранее определённые функции. Появление агентного ИИ не просто расширило этот разрыв, а изменило саму его форму, и старые инструменты на это не рассчитаны.
Почему агенты не вписываются в существующие модели
Сервисный аккаунт работает с фиксированным набором ресурсов и заранее ограниченным набором действий. У него есть конкретная функция, узкие права, ключи лежат в хранилище, идентификатор заведён в PAM-процессы. Агент устроен принципиально иначе: он получает инструкцию, сам решает, как её выполнить, динамически выбирает инструменты, выстраивает цепочки вызовов между разными системами и при необходимости делегирует подзадачи другим агентам в рамках одной сессии. Один агент за один прогон может одновременно работать с CRM, репозиторием кода, хранилищем документов и внутренним API — то есть затрагивать ресурсы, которые ни один человек явно не авторизовал ему трогать.
Проблема наследования прав
Это самый глубокий архитектурный дефект. Агент наследует доступ от человека или сервисной учётки, от имени которой работает. У этого доступа исторический контекст: директор по продажам за годы менял роли, получал расширенные права, копились делегированные полномочия. Когда агент запускается «от лица» этого сотрудника, он забирает с собой все его OAuth-токены, все накопленные привилегии и работает с полной унаследованной авторизацией. При этом он не различает «что сделал бы человек» и «что ему поручили сделать». Традиционный IAM регистрирует событие логина и дальше теряет агента из вида: вся последовательность вызовов, обращений к данным, обход систем между ними остаётся прозрачной для слоя управления.
Тёмная материя идентификации становится активной
В каждой крупной среде копится «тёмная материя идентификации» — масса идентификационной активности, которая существует и создаёт реальные риски, но остаётся невидимой для инструментов. Это устаревшие делегирования, избыточно скоупированные учётки, забытые токены. Раньше они лежали мёртвым грузом. Теперь агент, подбирая унаследованные права, активирует их за миллисекунды. Нужен слой, работающий там, где идентификация реально исполняется, а не только там, где она аутентифицируется.
Три силы, разогнавшие внедрение за последний год
Ещё двенадцать месяцев назад запуск надёжного многоагентного воркфлоу требовал серьёзного инженерного труда. Сейчас появились стандартизированные примитивы: фреймворки LangGraph и AutoGen, протокол Anthropic MCP (Model Context Protocol). Параллельно стоимость инференса резко упала у всех крупных провайдеров моделей, и содержание агентов в непрерывном режиме стало экономически оправданным. А бизнес давит: автоматизировать обработку знаний в масштабах, которые человеческие ресурсы уже не вытягивают. В итоге агентный ИИ перешёл из стадии демонстраций в промышленные пайплайны быстрее, чем большинство служб безопасности успело это осознать.
Как обходят жизненный цикл идентификации
Агенты уже ведут закупки, эскалируют запросы клиентской поддержки, рецензируют код, сверяют финансовые данные, ищут информацию по внутренним базам знаний. Бизнес-подразделения заводят их через low-code платформы и готовые вендорские интеграции, часто вообще без согласования с безопасностью. Команда безопасности узнаёт о новых агентах во время инцидента или аудита, а иногда не узнаёт вовсе. Агенты не проходят через заявочные воркфлоу, не попадают в IGA-системы, а просто наследуют учётные данные от существующих идентификаторов и начинают работать. Растёт популяция автономных идентичностей без формальной записи, без привязки к владельцу, без поведенческого базового профиля.
Почему инструменты, которыми пользуются сегодня, тут не сработают
Системы IGA проектировались под человеческий жизненный цикл: приём, перемещение, увольнение, аттестация доступа. Агент не проходит через заявочный воркфлоу, его скоуп прав меняется динамически внутри сессии, а его жизненный цикл вообще не привязан к статусу сотрудника. В IGA нет нативного понятия «агент наследует человеческую идентичность, действует автономно, засыпает, просыпается в другом контексте».
Системы PAM заточены под человеческую сессию: выдача прав на ограниченное время, запись, ответственность. Агент не «берёт в аренду» учётные данные — он работает через унаследованные OAuth-делегирования, привязки к сервисным аккаунтам и ключи API, зашитые в конфигурации оркестрации. PAM видит хранилище, но не видит путь исполнения. Когда агент за одну сессию обходит четыре системы через делегированный OAuth-токен, у PAM нулевая видимость по всему маршруту.
CIEM и AI-SPM
CIEM неплохо справляется с нон-человеческой идентификацией внутри одного облака. Но граница, на которой он работает, и есть его ограничение: один облачный провайдер. А агентские нагрузки легко прыгают между несколькими облаками, SaaS-приложениями, локальными системами и сторонними API в рамках одного процесса. AI-SPM отвечает за конфигурацию и риск-постуру самой AI-инфраструктуры — контроль доступа к моделям, защиту обучающих данных, безопасность API. Это другая модель идентичности, и попытка натянуть её на агентские нагрузки даёт не покрытие, а опасные слепые зоны.
Пять рисков, превращающих неуправляемых агентов в идентификационную тёмную материю
- []
[]Сессии-сироты и устаревшие учётные данные. Сессии агентов не всегда завершаются чисто. Долгоиграющие агенты и запланированные автоматизации держат активные учётки далеко за пределами срока задачи. Когда агента списывают или забывают, учётные данные часто остаются валидными. Особенно остро это в SaaS, где отзыв токена требует осознанного действия по каждому подключённому приложению. Агент-сирота через долгоживущий OAuth-токен сохраняет доступ к чувствительным системам месяцами.
[]Инъекция промптов как вектор эскалации привилегий. Злоумышленник вкладывает вредоносные инструкции в контент, который агент обрабатывает: документ для саммари, веб-страницу, тикет в поддержку. Агент встраивает их в своё рассуждение и выполняет действия, которые пользователь никогда не санкционировал. В среде с избыточно привилегированными унаследованными идентичностями инъекция промпта становится надёжным путём к эскалации привилегий — без касания учётных данных.
[]Боковое перемещение через цепочки вызовов агентов. В многоагентных архитектурах оркестратор делегирует подзадачи специализированным дочерним агентам, и каждое делегирование передаёт часть полномочий оркестратора. Компрометация в любой точке цепочки распространяется дальше. Злоумышленник получает эффективный доступ ко всем системам, которых касается цепочка доверия.
[]Проблема аудиторского следа. Агенты, работающие через неуправляемые SaaS, не оставляют связной криминалистической картины в существующих инструментах. Разбор инцидента превращается в сшивание фрагментированных логов из разрозненных систем, часто без достаточной точности, чтобы понять, какой именно агент совершил какое действие от чьего имени.
Что делать: четыре шага, чтобы вытащить агентов на свет
- []
[]Классифицировать по уровню доверия и скоупу прав. Не каждый агент несёт одинаковый риск. Классификация идёт по трём осям: чувствительность удерживаемых прав, круг доступных систем, уровень доверия исходной идентичности. Агент с правами только на чтение в одной внутренней базе знаний — низкий риск. Агент с делегированными OAuth-токенами одновременно к финансовой системе и к платформе клиентских данных — высокий. Классификация двигает приоритеты: широкое наследование плюс чувствительные системы — немедленная переаттестация под принцип минимальных привилегий. Узкий, хорошо скоупированный доступ — мониторинг и периодический пересмотр. Без классификации все агенты выглядят одинаково, и усилия по ремедиации размазываются без учёта реальной концентрации риска.
[]Принуждать к минимальным привилегиям в рантайме, а не на этапе выдачи. Статический скоуп при провижининге быстро деградирует: агентов начинают использовать под новые задачи, унаследованные учётки редко обновляются под реальные потребности. Принуждение на уровне исполнения ограничивает радиус поражения при компрометации. Инъекция промпта против плотно скоупированного в рантайме агента достанет немного; та же атака против агента с активными полными унаследованными правами — катастрофа.
[]Интегрировать с существующим стеком идентификационной безопасности. Слой управления агентами должен расширять существующие инструменты, а не заменять их. Данные об идентичностях агентов уходят в IGA-платформы для аттестации доступа, в PAM для фиксации экспозиции учётных данных, в SIEM для обогащения алертов поведенческой историей агентов. Интеграционный слой превращает управление агентами из автономной функции в живой входной поток для более широкой платформы идентификационной безопасности. Каждый нижестоящий инструмент получает более точную картину того, что реально исполняется.
Архитектурное различие, которое нельзя обойти
Традиционные IAM отвечают на вопросы идентичности на этапе провижининга или на границе аутентификации. Разница не количественная. Управление автономной идентичностью, которая рассуждает, делегирует и действует, требует плоскости управления, которая рассуждает вместе с ней, наблюдает поведение в движении, а не проводит аудит доступа постфактум. Как метко сформулировано в исходном разборе: «агенты находят существующую тёмную материю идентификации и движутся сквозь неё на машинной скорости».
Практический итог
Скрытый аргумент всей этой конструкции прост: управление идентификацией перестало быть вопросом конфигурации. Агенты с унаследованными правами, обходящие жизненный цикл, делают прежний инструментарий архитектурно нерелевантным. Точка отсчёта новая: непрерывная инвентаризация, привязка каждого агента к ответственному человеку, поведенческий мониторинг с базовой линией и аномалиями, полный аудиторский след по каждому приложению, которого касается автономная идентичность, и принуждение на уровне исполнения. Там, где агенты и идентификация встречаются на машинной скорости, управлять нужно с той же скоростью.