97% организаций, столкнувшихся с инцидентами, связанными с ИИ, не имели выделенных контролей доступа для таких систем, а 63% вообще обходились без политик управления ИИ. На этом фоне безопасность ИИ-агентов перестает быть темой для слайдов про «будущее» и становится инфраструктурной задачей на уровне продакшена, сообщает The New Stack. Для разработчиков, платформенных команд и ИБ это плохая новость в одном смысле и полезная в другом: старый IAM для мира автономных агентов уже тесен, зато требования к новому стеку понятны довольно четко.
Главная мысль материала проста: опасной оказывается не сама автономность агента, а сочетание двух факторов. Первый — у агента слишком широкие права. Второй — эти права оформлены через статические, долгоживущие учетные данные, которыми плохо управляют, редко ротируют и которые трудно нормально аудировать. Именно такую связку IBM и HashiCorp называют особенно рискованной: агент получает большой радиус действия, а команда при этом слабо видит, куда он ходил, что менял и почему вообще оказался в критичной системе. На практике это означает вполне приземленные сценарии: агент обновляет базу, дергает API, запускает скрипт, лезет во внутренний веб-сервис или облачную платформу и, ошибившись в логике либо контексте, портит данные, создает простой или случайно раскрывает чувствительную информацию.
Проблема не в том, что у ИИ-агентов «слишком много интеллекта», а в том, что они действуют не как обычные пользователи, под которых исторически и строился IAM. У человека есть более-менее предсказуемые паттерны доступа: рабочие часы, понятная роль, ограниченный набор действий. У агента все иначе. Он может работать непрерывно, вызывать инструменты цепочкой, соединять между собой сервисы, забирать секреты, инициировать пайплайны и принимать локальные решения на машинной скорости. В материале The New Stack это описано через типичный enterprise-сценарий: агент влияет на аналитику для руководства, создает новые API-связи, меняет записи в БД и обращается к ресурсам по всей инфраструктуре. Для русскоязычной IT-аудитории здесь нет никакой экзотики: это уже не демо-бот в песочнице, а заготовка под нового привилегированного участника инфраструктуры.
В качестве ответа HashiCorp продвигает подход, в котором у каждого агента должна быть собственная идентичность и доступ по модели just-in-time — только к конкретному ресурсу, только под конкретное действие и только на время одной сессии. Компания напоминает, что ее Boundary появился как open source-проект еще в 2020 году, а после перехода HashiCorp под IBM в феврале 2025 года логика продукта стала звучать еще актуальнее для эпохи агентных систем. Идея довольно здравая: если агенту не выдавать постоянный пропуск в инфраструктуру, а открывать дверь ровно под задачу и на короткий срок, уменьшается ущерб от утечки, ошибки конфигурации или злоупотребления. В связке с HashiCorp Vault это дополняется динамической выдачей краткоживущих секретов: credential перехватили — хорошо, жить ему все равно осталось недолго. На бумаге это выглядит как давно знакомый zero trust, только без иллюзии, что сервисный аккаунт с вечным токеном еще кого-то спасает.
Но и этого, по мнению собеседников The New Stack, уже мало. Гендиректор Teleport Ев Концевой говорит жестче: агентам нужны не только краткоживущие привилегии, но и изолированные среды исполнения плюс криптографически защищенная идентичность, завязанная на аппаратный корень доверия. Перевод с вендорского на инженерный здесь такой: если агент недетерминирован и действует на скорости автоматики, контролировать его надо до того, как он дотронется до продакшена, а не после красивой записи в логах. Иначе аудит превращается в посмертный разбор, почему агент с хорошими намерениями и валидным токеном внезапно ушел не туда. Для платформенных команд это означает неприятный, но логичный сдвиг: доступом придется управлять не в момент деплоя, а в момент использования, а сами рантаймы агентов — делать временными, изолированными и наблюдаемыми.
Еще один важный кусок — замечание SpecterOps о том, что идентичности разработчиков и агентов уже сидят на маршрутах атаки к критичным системам. Это не абстрактный страх из whitepaper, а очень конкретная модель риска: через такие идентичности можно поднимать инфраструктуру, забирать секреты, запускать пайплайны, ходить в хранилища данных и наследовать доверие от других сервисов. Если эти сущности переуполномочены, подменены или просто скомпрометированы, атака идет по той же логике, по которой в норме работает сама инфраструктура: от одной идентичности к одной системе, потом через следующую границу доверия. Для бизнеса отсюда следует неприятный вывод: агент в корпоративной среде — это не «умный помощник», а новый тип нелинейного привилегированного субъекта. Для разработчиков — что вопрос уже не в том, давать ли агенту доступ к CI/CD, данным и облаку, а в том, как доказуемо ограничить этот доступ и быстро отозвать его без поломки всего процесса.
Отдельно показательно, что в материале всплывает и позиция CNCF TAG Security and Compliance: для облачных и автоматизированных сред контроль доступа должен быть встроен в жизненный цикл приложений, а не навешан сверху как поздняя бюрократия. Это хорошо ложится на текущий тренд: workloads становятся короче по жизни, границы периметра размыты, а у агентов окно полезного действия измеряется уже не 90 днями и даже не сутками, а минутами. И вот тут безопасность ИИ-агентов неожиданно становится близка не только CISO, но и тем, кто отвечает за DX, внутренние платформы и скорость релизов. Если доступ по-прежнему живет дольше самой задачи, ради которой запускается агент, значит, инфраструктура все еще проектируется под прошлую эпоху.
Следующий спор в отрасли, похоже, будет не о том, нужны ли компаниям ИИ-агенты, а о том, кто быстрее превратит их из хаотичного набора сервисных аккаунтов в управляемые сущности с короткой жизнью, внятной идентичностью и нормальным аудитом. Иначе безопасность ИИ-агентов останется красивым термином для конференций, а в продакшене все сведется к старой истории про слишком широкие права, только теперь на машинной скорости. Подробности исходного разбора можно посмотреть у .