Каждый новый агент — это новая идентичность с доступами. Только в отличие от сотрудника у нее нет HR-владельца, даты увольнения и ежегодного ревью. В среднем на одного человека приходится 45 нечеловеческих идентичностей (service accounts, ключи, токены), в cloud-native — до 144:1. Агенты ускоряют этот разрыв: только в Copilot Studio создан миллион агентов, и управлять ими старыми IAM-инструментами уже не получается.
Чем идентичность агента отличается от service account
Четыре особенности делают агента сложнее обычного NHI:
- Автономия. Агент сам решает какие инструменты вызвать и в каком порядке, без подтверждения каждого шага. Компрометация одного токена амплифицируется цепочкой вызовов.
- Динамическое расширение прав. Агент может запросить новый scope во время выполнения, принять другую роль или получить токен через tool calling — blast radius не фиксирован на момент выдачи.
- Иерархия. Один оркестратор порождает десятки эфемерных под-агентов с разными правами на секунды работы. Жизненный цикл измеряется не годами, а вызовами.
- Эфемерная перманентность. Агент удален, а credential остался в конфиге, env или Vault. CSA называет это persistent blast radius — доступ живет дольше задачи.
Оценивать такую идентичность теми же процессами что и human — значит оставить ее без владельца и без срока жизни.
4 провала жизненного цикла
Опросы 2024–2026 сходятся:
- Sprawl. >16% компаний вообще не отслеживают создание AI-идентичностей.
- Over-privilege. Токен выдают «с запасом» чтобы не падал вызов — и одна утечка открывает десятки систем.
- Нет владельца. 51% организаций не имеют владельца для AI-идентичностей; 8% теряют связь с HR после ухода создателя.
- Нет мониторинга. 60% не наблюдают за активностью NHI как за логинами людей, аномалии не алертятся.
Результат — две трети предприятий пережили breach через скомпрометированную NHI, причем 66% таких инцидентов стали успешной атакой.
Кейс: как один поставщик открыл 700 клиентов
Цепочка 2025 года: компрометация GitHub-аккаунта поставщика → доступ к AWS окружению чат-бота Drift → кража long-lived over-scoped OAuth-токенов к Salesforce у 700+ клиентов → массовый экспорт CRM-данных. Токены не ротировались, scope был избыточен, отзыва не было. Один vendor-компромисс каскадировался по всей клиентской базе именно потому что токены были долгоживущими и стоячими.
Тот же паттерн — standing access — лежит в основе большинства 2026 инцидентов, включая poisoned MCP-описания, где агент не нарушал правил, но каждый шаг выглядел штатно.
Модель: inventory → least privilege → short-lived → аудит → offboard
Дисциплина в правильном порядке важнее платформы:
- Инвентарь. Найдите всех агентов, токены, service accounts, OAuth-приложения и связи между ними. Без реестра политика — бумага.
- Владелец на каждую идентичность. Как у сотрудника: кто отвечает, когда ревью, когда offboard. Нет владельца — нет ротации.
- Least privilege по умолчанию. Read-only где можно, scope на действие и ресурс, deny по умолчанию. Одна роль на агента, не shared service account.
- Short-lived и secretless где возможно. Credential на час, а не на год. Идеал — агент вообще не держит секрет, а получает его just-in-time через брокер (Aembit, Vault, gateway).
- Мониторинг и аудит каждого вызова. Кто (агент + human delegator), что вызвал, с какими аргументами, что вернулось. Аномалия — алерт.
- Offboard в день вывода. Агент выключен — идентичность отозвана. Иначе persistent blast radius.
Два принципа объединяют это: zero standing privilege и криптографическая привязка workload (SPIFFE/WIMSE) вместо копирования секретов.
Где Codenik: identity-aware шлюз
Codenik выдает идентичность агенту как управляемый шлюз: агент аутентифицируется один раз в шлюз, дальше шлюз применяет downstream-секреты сам — агент их не видит и не хранит. Доступ scoped по Cedar/OPA-правилам с учетом human delegator, каждый tools/call логируется, отзыв применяется мгновенно на все сессии, а при выключении агента его доступ исчезает без обхода ноутбуков. Это переносит NHI из конфигов в одно место с владельцем и сроком жизни.
Короткий вывод
Агент — это сотрудник без увольнения. Если не инвентаризовать его идентичности, не ограничить время жизни и не назначить владельца, рано или поздно его токен станет входом в инцидент. Начните с реестра и короткоживущих прав — платформа вторична.