Разбросанные секреты — это не проблема ИИ. Это проблема идентичностей, и ваши агенты только что сделали её срочной

Индустрия упорно подаёт утечки учётных данных в эпоху ИИ как проблему поведения кодинг-агента: агент оплошал, значит, надо ужать агента. Рамка удобная и неверная. Настоящая суть в том, что автономные системы — это нечеловеческие идентичности (non-human identity, NHI) с реальным доступом, и почти никто не управляет ими соответственно. ИИ-агенты не создали проблему разбросанных секретов. Они взяли медленную, переживаемую проблему и сжали её до машинной скорости.

Мы в SecurityLab профессионально ломаем агентов и всю обвязку идентичностей вокруг них, поэтому хотим быть точными в том, что реально изменилось и где на самом деле сидит риск. Цифры прямые. По отчёту GitGuardian 2026 State of Secrets Sprawl, коммиты, сделанные с помощью ИИ, сливают секреты примерно вдвое чаще, чем код, написанный человеком. По опросу Keeper Security на RSAC 2026, 46% респондентов сказали, что ИИ-инструменты имеют доступ к критичным системам и чувствительным данным, а 76% сказали, что эти идентичности не покрыты последовательным управлением по политикам привилегированного доступа. Сложите две цифры: большинство организаций уже выдали автономным системам реальный доступ, и большая часть этого доступа не управляется никак.

Почему агент — ускоритель, а не причина

Кодинг-агент успевает прочитать весь проект, изменить файлы, сгенерировать конфигурацию и обратиться к внешним сервисам за то время, что разработчик тратит на ревью одного пул-реквеста. Эта скорость и есть весь сдвиг. Кред, который человек оплошал бы раз в месяц, агент оплошает по сотне файлов за день. Но утечка была возможна и раньше. Агент просто ставит её на поток.

С наступательной точки зрения векторы экспозиции ровно те, что мы проходим на любом проекте, и ни один из них не новый. Новое здесь только объём:

• Доступ к окружению разработчика. Агент читает файлы .env и локальные конфиги, оставленные разработчиком, и эти секреты едут дальше туда, где агент работает следующим.
• Конфиги с захардкоженными кредами. Установочные файлы агентов и MCP-серверов сплошь и рядом несут ключи в открытом виде, и эти файлы редко получают ту же проверку, что код приложения.
• Дублирование кредов. Один и тот же секрет живёт в репозитории, в CI/CD, в тикете Jira, в конфиге на рабочей станции. Сканирование одного репозитория пропускает большинство копий.
• Избыточные права. Агент получает широкий доступ на этапе прототипирования, чтобы всё заработало, и этот доступ тихо переезжает в продакшен.

Каждый из них — это путь утечки кредов, который мы тестируем напрямую. Конфиг MCP-сервера с ключом в открытом виде, переживший прототип токен с избыточным скоупом, секрет, продублированный в тикет-систему, — это находки, и найти их раньше атакующего — это ровно то, ради чего существуют аудит безопасности ИИ-агентов и аудит исходного кода.

Переформулировка, которая реально помогает: управляйте идентичностью, а не поведением

Вот фраза, которую стоит повесить на стену: вы не можете надёжно предсказать каждое действие автономной системы, но можете контролировать, к чему идентичности за этой системой вообще разрешено обращаться. В этом вся суть. Пытаться ограничить поведение агента — заведомо проигранная гонка с недетерминированной системой. Ограничить, до чего дотягивается его идентичность, — решённая дисциплина, надо лишь применить её к машинным идентичностям так же, как вы уже применяете к людям.

Конкретно это означает:

• Централизованное управление секретами. Агент получает секрет от платформы в момент выполнения, а не читает его из .env или конфига. Секрет никогда не лежит в покое там, откуда агент может его слить.
• Короткоживущие, авторотируемые креды. Замените статические ключи, действительные месяцами, на креды, протухающие за минуты. Слитый секрет, который уже мёртв, — это не инцидент.
• Заскоупленные идентичности агентов. У каждого агента своя идентичность со своими узкими правами, как у подрядчика с определённым окном доступа, а не общий супер-ключ.
• Петли одобрения человеком на доступ к кредам, продакшен-деплои и изменения привилегий.
• Инвентаризация агентов: какие агенты работают в вашем окружении, кто их владелец, какую идентичность несёт каждый и к чему он авторизован обращаться.
• Полное логирование каждого действия агента под его машинной идентичностью, потому что после инцидента журнал — это всё, что у вас есть.

Это инженерия идентичностей, и здесь абстрактный совет превращается в конкретную проверяемую позицию. Избыточно привилегированная машинная идентичность, дотянувшаяся до продакшена, — это находка уровня облачного IAM, которую вскрывает аудит облачной инфраструктуры. Токены, которыми агенты ходят к API, их выдача, скоупинг и валидация, — это ровно те поверхности, что мы прощупываем в пентесте API и микросервисов. А держатся ли ваши постоянные привилегии и дублированные секреты под атакующим, у которого уже есть один слитый ключ, на этот вопрос отвечает Red Team операция.

Где на этом стоят наши собственные разработки

Два вектора выше ложатся прямо на продукты, которые мы вырастили из этой самой проблемы. Секрет, который утёк и затем был использован, — это двухстадийное событие, и у каждой стадии свой контроль.

На исходящей стороне агент с реальными кредами и выходом в сеть может слить или злоупотребить секретом сам, без всякого атакующего. Наш файрвол Airlock стоит на этом пути наружу и не даёт вашему собственному агенту слить кред или подействовать по нему, к которому он вообще не должен был прикасаться. На входящей стороне, когда атакующий (человек или его собственный агент) уже держит слитый ключ и приходит его использовать, BastionAgent превращает этот момент в западню: он раскладывает мёртвые водяные креды ровно там, где агент ожидает их найти, так что сценарий «использую слитый секрет» заходит в клетку из сфабрикованных данных, и само использование кредов становится детектом. Обратите внимание на синергию с советами выше: короткоживущие и водяные секреты — это один и тот же инстинкт, сделать слитый кред либо уже мёртвым, либо активно изобличающим самого себя.

Вывод

Разбросанные секреты в эпоху ИИ — это не история о неаккуратном агенте. Это история о нечеловеческих идентичностях с постоянным доступом, который никто не заскоупил, не инвентаризировал и не ротировал, движущихся со скоростью, которая превращает латентную проблему в активную. Вы не почините это, пытаясь заставить агентов вести себя хорошо. Вы чините это, управляя тем, до чего дотягиваются их идентичности, и проверяя это управление так, как это сделал бы атакующий. Инвентаризируйте машинные идентичности, ужмите их, сделайте секреты короткоживущими, а затем дайте кому-то доказать, что границы держат, прежде чем это докажет кто-то другой.

Если вы запускаете агентов с реальным доступом, хотите проверить свой облачный IAM и выдачу токенов с места атакующего или нужна инвентаризация того, до чего реально дотягиваются ваши нечеловеческие идентичности, это наша повседневная работа: безопасность ИИ-агентов, аудит облачной инфраструктуры и Red Team операции.