Коммиты, помеченные как созданные с помощью AI, приводят к утечкам секретов примерно вдвое чаще, чем код, написанный людьми. По данным The Hacker News, GitGuardian в отчете State of Secrets Sprawl 2026 связывает самый быстрый рост утечек ключей уже не только с человеческой невнимательностью, а с тем, как AI-агенты получают доступ к проектам, конфигам и внешним сервисам. Для русскоязычных команд это неприятный, но практичный сигнал: внедрять AI-кодинг без пересмотра доступов теперь примерно как выдавать стажеру prod-ключи и надеяться на лучшее.
Речь не о новой дыре в конкретной модели и не о магическом сбое LLM. Проблема старше: API-ключи, токены, сервисные аккаунты и пароли годами расползаются по репозиториям, .env-файлам, CI/CD, тикетам и локальным настройкам. AI просто увеличил скорость. Агент может за минуты прочитать проект, поправить несколько файлов, сгенерировать конфигурацию, дернуть API и подключиться к MCP-серверу. Там, где раньше один разработчик случайно вставлял ключ в один файл, теперь автономный инструмент может размножить этот ключ по нескольким поверхностям до того, как ревьюер откроет pull request.
GitGuardian описывает это как проблему non-human identity, то есть нечеловеческих идентичностей. Логика простая: когда AI-агент запрашивает базу, вызывает API или деплоит стенд, за каждым таким действием стоит учетная запись, токен или ключ. Команды не могут предсказать все действия автономной системы, зато могут управлять тем, что разрешено идентичности, от имени которой она работает. Если агент работает через общий сервисный аккаунт с широкими правами, расследование инцидента быстро превращается в археологию: кто именно ходил в систему, зачем и каким ключом?
Самый очевидный сценарий — локальные файлы разработчика. В .env и временных конфигах часто лежат ключи, оставшиеся после отладки. Они не должны попасть в Git, но AI-агенту это не важно: если файл входит в доступный контекст проекта, он может быть прочитан как обычная часть рабочей среды. Раньше plaintext-секрет на ноутбуке был доступен разработчику и приложению, которое его использует. Теперь рядом появляется еще один участник — агент, способный анализировать весь проект и предлагать изменения там, где его об этом даже не просили.
Второй источник риска — конфигурации самих агентов и MCP-серверов. Инструкции по подключению AI-инструментов к базам, API и внутренним сервисам часто оптимизированы под скорость: вставьте токен сюда, добавьте строку туда, запустите. Раз файл не попадает в репозиторий, возникает иллюзия безопасности. Но секрет все равно лежит в открытом виде на машине разработчика, а агент или связанный с ним инструмент может иметь право его прочитать. Это не экзотика, а нормальный путь быстрого прототипирования, который потом неожиданно становится частью рабочего процесса.
Третья проблема — копии. Один и тот же ключ может жить в репозитории, переменной CI/CD, Jira-тикете, чате с разбором инцидента и локальном конфиге. Сканер кода находит одну копию, команда ее ротирует, закрывает задачу и чувствует легкое облегчение. Но если тот же ключ все еще валиден в другом месте, утечки секретов фактически не устранены. AI-агенты ухудшают ситуацию тем, что подключаются сразу к нескольким системам: к коду, тикетам, документации, окружениям, иногда к базам и облачным API. Репозиторий перестает быть главным полем боя.
Отдельно The Hacker News приводит данные опроса Keeper Security к RSAC 2026: 46% респондентов заявили, что AI-инструменты имеют доступ к критичным системам и чувствительным данным, при этом 76% сказали, что такие идентичности не всегда управляются через политики привилегированного доступа. Перевод на язык эксплуатации: AI уже пустили туда, где живут важные данные, но часто не повесили на него те же ограничения, аудит и ротацию, которые применяются к администраторам, сервисным аккаунтам и production-интеграциям.
Практический вывод не в том, чтобы запретить AI-кодинг и вернуться к ручному копированию YAML, хотя у некоторых безопасников сейчас наверняка дернулся глаз. Нужна нормальная гигиена идентичностей. Статические ключи стоит убирать с рабочих станций и доставать из централизованного менеджера секретов только на время выполнения операции. Долгоживущие токены лучше заменять короткоживущими учетными данными с автоматической ротацией. Каждому агенту нужна собственная ограниченная идентичность, а не общий всемогущий сервисный аккаунт. Права, выданные на прототипе, должны иметь срок жизни, иначе временное быстро становится вечным.
Для разработчиков это означает меньше привычки хранить все нужное в .env под рукой. Для бизнеса — необходимость включить AI-агентов в IAM, PAM, аудит и процессы incident response, а не держать их в серой зоне между IDE-плагином и почти-сотрудником. Для AppSec-команд утечки секретов становятся не задачей сканера, а задачей инвентаризации доступов: кто или что имеет право читать, менять, деплоить и аутентифицироваться. Следующий этап гонки будет не за тем, чей AI пишет больше кода, а за тем, чьи агенты умеют работать полезно, не превращаясь в разносчиков ключей по всей инфраструктуре.