GitGuardian: ИИ-коммиты вдвое чаще раскрывают секреты

GitGuardian в отчёте State of Secrets Sprawl 2026 сообщил, что коммиты с признаками использования ИИ раскрывают секреты примерно вдвое чаще кода, написанного разработчиками без такой помощи. Быстрее всего растёт число утечек учётных данных, связанных с ИИ-сервисами: API-ключей, токенов и реквизитов сервисных аккаунтов.

Проблема не в том, что ИИ-агент может встретить секрет. Автономные инструменты ускоряют распространение уже существующих практик: они читают проект целиком, изменяют файлы и конфигурации, выполняют команды, вызывают API и взаимодействуют с серверами Model Context Protocol. Каждое такое действие требует идентичности и может создать новую точку хранения учётных данных.

Секреты становятся проблемой машинных идентичностей

Под secrets sprawl понимают накопление ключей, токенов и сервисных реквизитов в таком числе систем, что организация не может надёжно их учесть и отозвать. Один и тот же ключ может оказаться в исходном коде, файле .env, переменной CI/CD, конфигурации MCP или тикете Jira.

Проверка репозиториев и pre-commit-хуки остаются полезными, но работают уже после распространения секрета. Если ключ отозван только в репозитории, его копии в рабочих средах, системах совместной работы или настройках интеграций могут остаться действительными.

Авторы материала предлагают рассматривать ИИ-агентов как non-human identities, а не как отдельную проблему поведения модели. Когда агент запрашивает базу данных, вызывает API или развёртывает код в тестовой среде, действие разрешает конкретная учётная запись. Организация не всегда может заранее предсказать все действия автономного инструмента, но способна ограничить доступ идентичности, от имени которой он работает.

Где появляются дополнительные риски

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

Отдельный риск создают настройки агентов и MCP-серверов. Для упрощения подключения к базам данных и внешним сервисам разработчики могут вставлять ключ прямо в конфигурационный файл. Такой файл может не попадать в репозиторий, но всё равно остаётся в открытом виде на рабочей станции и доступен агенту при соответствующих разрешениях.

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

В опросе Keeper Security на RSAC 2026 46% респондентов указали, что ИИ-инструменты имеют доступ к критическим системам и чувствительным данным. При этом 76% сообщили, что такие идентичности не всегда управляются в рамках политик привилегированного доступа.

Какие меры предлагают для разработки с ИИ

• Убирать статические секреты с рабочих станций и получать их из централизованной системы управления секретами только при необходимости.
• Заменять долгоживущие ключи краткосрочными учётными данными с автоматической ротацией.
• Выдавать каждому агенту отдельную идентичность с правами, ограниченными задачей и сроком действия.
• Расширять инвентаризацию и контроль на CI/CD, рабочие станции, MCP-конфигурации, тикет-системы и средства совместной работы.
• Требовать явного одобрения человека для доступа к секретам, развёртывания в production и изменения привилегий.
• Вести журнал действий агентов, использованных учётных данных и доступных ресурсов.

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