ИИ-кодовые агенты теперь основная часть вашей проблемы non-human identity
Безопасность non-human identity (NHI) выросла в отдельную категорию, потому что сервисные аккаунты, API-ключи и идентичности ворклоадов незаметно обогнали по числу человеческие логины ещё несколько лет назад. Отчёт Palo Alto Networks Identity Security Landscape 2026, опрос 2930 руководителей по безопасности, даёт текущее соотношение в 109 машинных идентичностей на одну человеческую, против 82 к 1 всего годом ранее. Деталь, задающая категорию: из этих 109 целых 79 это ИИ-агенты. ИИ-кодовые и рабочие агенты не новое дополнение к проблеме NHI. Они уже большая её часть.
Почему существующий playbook NHI не совсем подходит
Безопасность NHI сложилась вокруг сервисных аккаунтов и API-ключей: credentials, выданных один раз, используемых для узкой цели и ротируемых по расписанию. ИИ-агент ломает эту модель конкретным образом. Это не статичный credential, выполняющий одну задачу, это актор, который решает, в рамках того, что позволяет его credential, что делать дальше. Реальный инцидент уже показал, что происходит, когда эта способность принимать решения сидит за credential, ограниченным как у традиционного сервисного аккаунта: широко, статично и не построено различать «этой задаче нужно чтение из staging» от «этот credential может ещё и удалить продовый volume».
Вопросы жизненного цикла, которые команды NHI уже задают (кто владеет этой идентичностью, до чего у неё есть доступ, когда она ротируется, откуда мы знаем, что она всё ещё нужна) всё ещё применимы. Разница в том, что «до чего есть доступ» теперь должно учитывать актора, принимающего автономные решения внутри этого скоупа, а не просто выполняющего фиксированную функцию.
Что реально меняется на практике
Обнаружение становится сложнее, прежде чем станет проще. Сервисный аккаунт появляется в инвентаре, потому что кто-то намеренно его выпустил. MCP-подключение агента может запустить разработчик, пробующий новый инструмент во вторник днём, без тикета, без ревью и без записи в каком бы то ни было инвентаре NHI, который ведёт служба безопасности. Цифра в 72,5% от машинных идентичностей это снимок того, что кто-то знал, как посчитать. Реальное число почти наверняка выше.
Ротация больше не главный контроль. Ротация утёкшего API-ключа ограничивает, как долго статичный credential полезен тому, у кого он оказался. Credential агента используется непрерывно, по замыслу, поэтому более уместный вопрос это что этот credential авторизует в момент использования, а не как часто его заменяют. Именно скоуп, а не частота ротации, это то место, где реально живёт риск.
Атрибуция должна переживать нескольких агентов на общей инфраструктуре. Традиционные инструменты NHI приписывают активность сервисному аккаунту. Если три разных агента подключаются через один и тот же общий токен, эта атрибуция схлопывается до «что-то, использующее этот credential, сделало это», что почти бесполезно для реагирования на инцидент. Агенту нужен собственный принципал, так же как у сотрудника-человека есть аккаунт, отдельный от общего логина отдела, чтобы идентичность вообще что-то значила в момент, когда что-то пошло не так.
С чего начать
Относитесь к ИИ-кодовым агентам как к отдельной категории NHI в любом уже существующем инвентаре или процессе governance, а не как к подтипу «сервисного аккаунта», который по умолчанию наследует те же контроли. Контроли, которые реально имеют значение для этой категории: отдельный принципал на каждого агента, скоуп, встроенный в credential, а не в политику, которую кто-то обязан помнить, и короткоживущие credentials вместо долгоживущих. Ничего из этого не требует нового инструментария с нуля. Требуется относиться к самой быстрорастущей части инвентаря NHI, тем самым 72,5%, как к полноценной категории, а не к погрешности округления в прошлогоднем аудите.