Сегодня агент чаще всего работает от имени человека: берёт его учётные данные, заходит в CRM, облако и документы и действует с теми же правами, что и сотрудник. Пока агентов немного, это терпимо. Когда их становится десятки, а каждый умеет самостоятельно вызывать инструменты и передавать работу другим агентам, такой подход перестаёт отвечать на простой вопрос: кто именно сейчас действует и за что он отвечает.
CrowdStrike предлагает ответ: относиться к агенту как к отдельному участнику инфраструктуры. В начале сентября 2026 года на конференции Fal.Con компания представила Agentic Identity Provider — систему, которая выдаёт каждому ИИ-агенту собственную доверенную идентичность и управляет его доступом. Разберём, как это устроено и почему это шире одного продукта.
Агент перестаёт прятаться за учётной записью человека
Классический провайдер идентичности отвечает на вопрос «кто ты». Для человека ответ строится на сотруднике, пароле и процедуре входа. У агента ничего этого нет: его нельзя завести как нового работника. Поэтому компании вынуждены представлять агентов сервисными учётными записями, API-ключами и идентичностями рабочих нагрузок — статичными моделями, которые не рассчитаны на программу, действующую автономно от имени пользователя и делегирующую задачи другим агентам.
Из-за этого агент фактически наследует личность и права человека, от имени которого работает. Трудно отделить агента от сотрудника, независимо управлять тем, что агенту разрешено, и надёжно связать каждое действие с ответственным. Прежде чем постоянно контролировать доступ агента, его самого нужно сначала завести как доверенную идентичность.
Ключевая мысль: нельзя непрерывно авторизовать того, кого ты не смог установить. Традиционные провайдеры ломаются в момент, когда агент начинает действовать сам.
Четыре шага от обнаружения агента до ответственности за действие
Agentic Identity Provider решает четыре задачи, которые вместе складываются в замкнутый контур. Каждая закрывает свой разрыв в том, как агенты работают на самом деле.
| Шаг | Что делает | Зачем |
|---|---|---|
| Доверенная идентичность | Falcon Guardian находит агентов, Agentic IdP регистрирует каждого и выдаёт криптографически проверяемую идентичность | Её нельзя подделать или передать другому |
| Обогащение контекстом | К идентичности добавляются сведения о риске, компрометации и привилегиях | Понятно, что стоит за агентом и какой риск он несёт |
| Короткоживущий доступ | Доступ выдаётся токенами под конкретную задачу | Минимум прав на минимум времени |
| Привязка действий | Каждое действие связано с человеком или системой | Понятно, кто отвечает за каждый шаг |
Первый шаг — доверенная идентичность. Falcon Guardian обнаруживает агентов по всей компании, а Agentic IdP регистрирует каждого в едином каталоге и выдаёт криптографически проверяемую идентичность, которую нельзя подделать или передать другому. Доступ получают только агенты с доверенной идентичностью.
Второй шаг — обогащение контекстом. К каждой идентичности добавляются сведения о том, скомпрометирован ли агент, насколько он рискован и какие привилегии держит. Это даёт службе безопасности ясную картину, кто или что стоит за агентом и какой риск он несёт.
Третий шаг — самый важный для практики. Агент не получает постоянных учётных данных. Вместо этого провайдер выдаёт короткоживущие токены, ограниченные минимальным доступом и минимальным временем, нужным для конкретной задачи. Четвёртый шаг замыкает контур: каждое действие агента привязано к человеку или рабочей нагрузке, от имени которых он действует, поэтому каждый шаг можно проследить.
Идентичность отвечает «кто», авторизация — «что можно»
Agentic IdP не работает в одиночку. Ранее в 2026 году CrowdStrike представила Continuous Identity — механизм, который заменяет разовую проверку доступа непрерывной оценкой в реальном времени. Он выдаёт доступ, когда он оправдан, и отзывает его, как только условия меняются.
Разделение ролей здесь принципиальное. Agentic Identity Provider устанавливает, кто такой агент. Continuous Identity определяет, к чему этому агенту можно обращаться и что ему можно делать — непрерывно, с учётом живой идентичности, устройства, угроз и бизнес-контекста. Вместе они дают модель идентичности, рассчитанную на автономные действия, а не на разовый вход.
Тем же анонсом CrowdStrike расширяет современный привилегированный доступ на SaaS-приложения, конечные точки, репозитории кода и облачную инфраструктуру. Логика та же: доступ не считается доверенным только потому, что его однажды одобрили. Он остаётся доверенным, пока идентичность, устройство, безопасность и бизнес-контекст продолжают его оправдывать.
Почему это шире одного продукта
Главная новость здесь не в конкретной платформе, а в смене модели. Если в компании появятся десятки или сотни агентов, им понадобятся собственные аккаунты, права доступа и контроль — примерно так же, как сотрудникам и сервисным учётным записям. Агент перестаёт быть «расширением человека» и становится отдельным участником инфраструктуры со своей зоной ответственности.
Для бизнеса это меняет практический вопрос. Сегодня при внедрении агента обычно спрашивают: «какой ключ ему выдать?». Новая модель ставит вопрос иначе: «какая у агента идентичность, к каким ресурсам ему нужен доступ и кто отвечает за его действия?». Это тот же сдвиг, который раньше прошли сервисные учётные записи, только теперь он касается программ, способных действовать самостоятельно.
Стоит помнить и про ограничение. В анонсе CrowdStrike прямо указано, что часть возможностей ещё в разработке и может измениться. Это заявление о направлении, а не о готовом продукте, который можно включить завтра. Оценивать стоит по функциям, которые уже доступны.
С чего начать, если агентов становится больше
Даже без покупки платформы CrowdStrike из этого анонса можно вынести рабочий принцип. Прежде чем выдавать агенту доступ, зафиксируйте три вещи: кто этот агент, какой минимальный набор прав ему нужен и кто отвечает за его действия.
На практике это значит: не давать агенту учётные данные сотрудника, а заводить отдельную идентичность с узким доступом; выдавать права на время задачи, а не навсегда; и вести журнал, по которому каждое действие можно связать с человеком или системой. Это дешевле и надёжнее, чем разбирать последствия, когда агент с чужими правами сделал что-то не то.
Начинать стоит с одного повторяющегося процесса, где агент обращается к ограниченному набору систем. Если на этом контуре удаётся ответить на три вопроса выше, его можно масштабировать. Если нет — сначала стоит разобраться с идентичностью и правами, а не добавлять новых агентов.
Идентичность становится первым слоем агентной безопасности
CrowdStrike фиксирует сдвиг, который назревал давно: безопасность агентов начинается не с модели и не с промпта, а с того, кем агент является в системе. Пока агент работает под чужой учётной записью, ни ограничение прав, ни журнал действий не дают полной картины. Собственная идентичность — это точка, от которой можно строить всё остальное: минимальные права, короткоживущий доступ и ответственность за каждый шаг.
Для компаний, которые только начинают запускать агентов, это повод заложить идентичность в архитектуру с первого дня, а не добавлять её потом. Для тех, у кого агенты уже работают, — повод проверить, от чьего имени они действуют и можно ли связать каждое действие с ответственным. В обоих случаях вопрос уже не «какой ключ выдать», а «кто этот агент и за что он отвечает».
Ссылки