ИИ-агент за время проверки одного pull request способен прочитать проект целиком, изменить файлы, сгенерировать конфигурацию, выполнить команды, вызвать API, подключиться к внешнему сервису или серверу Model Context Protocol (MCP). Он может поправить системные настройки и развернуть приложение на тестовом стенде. Скорость разработки растёт вместе с числом мест, где оказываются учётные данные. Агент порой переносит ключ в новый файл, копирует его в другую систему или оставляет там, куда сканер репозитория никогда не заглянет. Сам ИИ старую уязвимость не создал: он сделал заметным беспорядок в управлении машинными доступами.
Расползание секретов начинается, когда API-ключи, токены и данные сервисных учётных записей накапливаются быстрее, чем организация успевает их учитывать, ограничивать и менять. Один секрет может одновременно лежать в исходном коде, файле.env, локальной конфигурации, настройках IDE, переменной CI/CD, конфигурации агента или MCP-сервера. Копия встречается и в Jira: разработчик вставил ключ в заявку, разбираясь с неудачным развёртыванием, а потом забыл удалить. Добавим корпоративные чаты, другие системы заявок и рабочие станции. Каждая действующая копия остаётся полноценным средством входа.
Раньше защиту часто строили вокруг сканеров репозиториев, pre-commit-проверок, поиска утечек и последующей ротации. Эти средства по-прежнему нужны, но видят лишь часть картины. Если сканер нашёл ключ в Git, а тот же ключ сохранился в Jira или локальном файле, исправление одного коммита мало что меняет: действительны не строки текста, а лежащие за ними полномочия. Каждая новая функция агента добавляет место, где требуется аутентификация, и ещё один маршрут распространения секрета. Поиск утечки срабатывает уже после того, как секрет успел размножиться.
Широкий контекст нужен агенту для нормальной работы. Помощник, которому приходится запрашивать разрешение на чтение каждого файла, быстро превращается в помеху. Но рядом с кодом часто лежат.env, локальные настройки и файлы, оставшиеся после старой отладки. Там может находиться производственный API-ключ, совершенно не нужный для текущей задачи. Агент не воспринимает такую конфигурацию как чужую записную книжку: это доступная часть рабочей среды. Прежнее предположение, будто локальный пароль видят лишь разработчик и специально настроенное приложение, больше не годится. Теперь его может прочитать автономная программа с теми же правами.
Отдельная неприятность скрыта в инструкциях по настройке агентов и MCP-серверов. Для быстрого подключения к базе данных, API или внешней системе разработчику предлагают вставить токен прямо в конфигурационный файл. Файл не попадает в систему контроля версий, и потому кажется безопасным. На деле секрет хранится открытым текстом на рабочей машине, нередко в каталоге, который агент вправе просматривать. Удобная инструкция на пять минут создаёт постоянную точку доступа, о которой через полгода никто уже не помнит.
Любое полезное действие агента опирается на идентичность: запрос к базе, вызов API и развёртывание на стенде требуют учётных данных. Поэтому расползание секретов разумнее рассматривать как проблему нечеловеческих идентичностей, или Non-Human Identities (NHI), а не как странность поведения модели. Нельзя заранее предсказать каждый шаг автономного инструмента, зато можно определить, под какой идентичностью он работает, какие ресурсы видит, какие операции вправе выполнять и когда разрешение истечёт. Для каждого агента нужна отдельная учётная запись. Общий сервисный аккаунт стирает авторство действий и раздаёт всем участникам самые широкие права, потребовавшиеся хотя бы одному из них.
Чрезмерные полномочия обычно появляются буднично. Во время прототипирования агенту дают широкий доступ, чтобы не возиться с ошибками разрешений. Затем прототип встраивают в производственный процесс, а «временные» права остаются навсегда. В многоагентной системе риск выше: оркестратор может хранить ключи сразу нескольких агентов. Взлом такого узла запускает цепную реакцию, при которой злоумышленник получает все ресурсы, доступные оркестратору. По данным опроса Keeper Security на RSAC 2026, 46% респондентов сообщили, что инструменты с ИИ имеют доступ к критическим системам и чувствительным данным. При этом 76% признали, что такие идентичности не всегда управляются по правилам привилегированного доступа.
Статические секреты стоит убрать из.env, настроек IDE, конфигураций MCP и прочих локальных файлов. Рабочая станция должна получать их из централизованной системы управления только в момент использования. Если открытого ключа нет на диске, агент не прочитает его случайно. Долгоживущие ключи лучше заменить данными, которые действуют минуты, автоматически обновляются либо меняются по строгому расписанию. Тогда украденная копия быстро теряет ценность, а службе безопасности не приходится сначала разыскивать каждый забытый дубль.
Доступ агенту следует выдавать примерно как подрядчику: конкретная задача, конкретные ресурсы, разрешённые операции и установленный срок. Обращение к секретам, развёртывание в производственной среде и изменение привилегий требуют явного подтверждения человека. Режимы auto-approve допустимы лишь как осознанное правило для ограниченного участка работы с регулярным пересмотром. Однажды включённое разработчиком автоматическое подтверждение не должно незаметно становиться постоянной политикой компании.
Одновременно нужен реестр всех агентов и MCP-серверов: кто их установил, кому они принадлежат, какие идентичности используют и куда имеют доступ. Особенно легко потерять счёт инструментам, которые разработчики подключают самостоятельно. Для каждой нечеловеческой идентичности журналируют применённые учётные данные, посещённые ресурсы и выполненные операции. Без этих записей команда реагирования не восстановит ход атаки, аудиторы не получат доказательств соблюдения требований, а опасное действие останется без установленного источника. Контроль обязан охватывать CI/CD, рабочие станции, Jira, корпоративные средства общения и локальные конфигурации, а не один лишь исходный код.
Keeper Secrets Manager предлагает централизованное хранение инфраструктурных секретов, удаление жёстко прописанных данных из процессов разработки и управление их использованием в рамках платформы zero-trust и zero-knowledge. Практическая схема шире отдельного продукта: короткий срок жизни учётных данных, автоматическая ротация, раздельные идентичности, минимальные права, полный аудит и отсутствие постоянных привилегий. При таком устройстве найденный агентом секрет либо недоступен ему, либо годится лишь для узкой операции и быстро истекает. Автономный код продолжит ускоряться; машинный доступ придётся делать короче, уже и прозрачнее.
Изображение носит иллюстративный характер
Расползание секретов начинается, когда API-ключи, токены и данные сервисных учётных записей накапливаются быстрее, чем организация успевает их учитывать, ограничивать и менять. Один секрет может одновременно лежать в исходном коде, файле.env, локальной конфигурации, настройках IDE, переменной CI/CD, конфигурации агента или MCP-сервера. Копия встречается и в Jira: разработчик вставил ключ в заявку, разбираясь с неудачным развёртыванием, а потом забыл удалить. Добавим корпоративные чаты, другие системы заявок и рабочие станции. Каждая действующая копия остаётся полноценным средством входа.
Раньше защиту часто строили вокруг сканеров репозиториев, pre-commit-проверок, поиска утечек и последующей ротации. Эти средства по-прежнему нужны, но видят лишь часть картины. Если сканер нашёл ключ в Git, а тот же ключ сохранился в Jira или локальном файле, исправление одного коммита мало что меняет: действительны не строки текста, а лежащие за ними полномочия. Каждая новая функция агента добавляет место, где требуется аутентификация, и ещё один маршрут распространения секрета. Поиск утечки срабатывает уже после того, как секрет успел размножиться.
Широкий контекст нужен агенту для нормальной работы. Помощник, которому приходится запрашивать разрешение на чтение каждого файла, быстро превращается в помеху. Но рядом с кодом часто лежат.env, локальные настройки и файлы, оставшиеся после старой отладки. Там может находиться производственный API-ключ, совершенно не нужный для текущей задачи. Агент не воспринимает такую конфигурацию как чужую записную книжку: это доступная часть рабочей среды. Прежнее предположение, будто локальный пароль видят лишь разработчик и специально настроенное приложение, больше не годится. Теперь его может прочитать автономная программа с теми же правами.
Отдельная неприятность скрыта в инструкциях по настройке агентов и MCP-серверов. Для быстрого подключения к базе данных, API или внешней системе разработчику предлагают вставить токен прямо в конфигурационный файл. Файл не попадает в систему контроля версий, и потому кажется безопасным. На деле секрет хранится открытым текстом на рабочей машине, нередко в каталоге, который агент вправе просматривать. Удобная инструкция на пять минут создаёт постоянную точку доступа, о которой через полгода никто уже не помнит.
Любое полезное действие агента опирается на идентичность: запрос к базе, вызов API и развёртывание на стенде требуют учётных данных. Поэтому расползание секретов разумнее рассматривать как проблему нечеловеческих идентичностей, или Non-Human Identities (NHI), а не как странность поведения модели. Нельзя заранее предсказать каждый шаг автономного инструмента, зато можно определить, под какой идентичностью он работает, какие ресурсы видит, какие операции вправе выполнять и когда разрешение истечёт. Для каждого агента нужна отдельная учётная запись. Общий сервисный аккаунт стирает авторство действий и раздаёт всем участникам самые широкие права, потребовавшиеся хотя бы одному из них.
Чрезмерные полномочия обычно появляются буднично. Во время прототипирования агенту дают широкий доступ, чтобы не возиться с ошибками разрешений. Затем прототип встраивают в производственный процесс, а «временные» права остаются навсегда. В многоагентной системе риск выше: оркестратор может хранить ключи сразу нескольких агентов. Взлом такого узла запускает цепную реакцию, при которой злоумышленник получает все ресурсы, доступные оркестратору. По данным опроса Keeper Security на RSAC 2026, 46% респондентов сообщили, что инструменты с ИИ имеют доступ к критическим системам и чувствительным данным. При этом 76% признали, что такие идентичности не всегда управляются по правилам привилегированного доступа.
Статические секреты стоит убрать из.env, настроек IDE, конфигураций MCP и прочих локальных файлов. Рабочая станция должна получать их из централизованной системы управления только в момент использования. Если открытого ключа нет на диске, агент не прочитает его случайно. Долгоживущие ключи лучше заменить данными, которые действуют минуты, автоматически обновляются либо меняются по строгому расписанию. Тогда украденная копия быстро теряет ценность, а службе безопасности не приходится сначала разыскивать каждый забытый дубль.
Доступ агенту следует выдавать примерно как подрядчику: конкретная задача, конкретные ресурсы, разрешённые операции и установленный срок. Обращение к секретам, развёртывание в производственной среде и изменение привилегий требуют явного подтверждения человека. Режимы auto-approve допустимы лишь как осознанное правило для ограниченного участка работы с регулярным пересмотром. Однажды включённое разработчиком автоматическое подтверждение не должно незаметно становиться постоянной политикой компании.
Одновременно нужен реестр всех агентов и MCP-серверов: кто их установил, кому они принадлежат, какие идентичности используют и куда имеют доступ. Особенно легко потерять счёт инструментам, которые разработчики подключают самостоятельно. Для каждой нечеловеческой идентичности журналируют применённые учётные данные, посещённые ресурсы и выполненные операции. Без этих записей команда реагирования не восстановит ход атаки, аудиторы не получат доказательств соблюдения требований, а опасное действие останется без установленного источника. Контроль обязан охватывать CI/CD, рабочие станции, Jira, корпоративные средства общения и локальные конфигурации, а не один лишь исходный код.
Keeper Secrets Manager предлагает централизованное хранение инфраструктурных секретов, удаление жёстко прописанных данных из процессов разработки и управление их использованием в рамках платформы zero-trust и zero-knowledge. Практическая схема шире отдельного продукта: короткий срок жизни учётных данных, автоматическая ротация, раздельные идентичности, минимальные права, полный аудит и отсутствие постоянных привилегий. При таком устройстве найденный агентом секрет либо недоступен ему, либо годится лишь для узкой операции и быстро истекает. Автономный код продолжит ускоряться; машинный доступ придётся делать короче, уже и прозрачнее.
