КИБЕРБЕЗОПАСНОСТЬ

AI-агентам в коде нужны границы для секретов

94 дня занимает медианное устранение утечек секретов в GitHub: AI-агенты могут унести токен еще до коммита и CI-проверок.

✍️ Редакция iTech News | 23.09.2026 | ⏱ 4 мин | Источник: The New Stack
🕵

94 дня — столько, по данным Verizon DBIR 2025, занимает медианное устранение утечек секретов, найденных в GitHub-репозиториях. Но безопасность AI-агентов ломает привычную схему: токен может утечь еще до коммита, pull request и CI, просто потому что агент прочитал локальный файл и отправил его в контекст модели. Для русскоязычных команд, которые уже пускают Copilot, Cursor, Claude Code или Codex в рабочие репозитории, это не философия про «доверие к ИИ», а вполне практичный вопрос: что именно агент имеет право читать.

AI coding agents стали частью разработки не потому, что индустрии не хватало еще одного модного слова. Они действительно помогают: расследуют баги, проходят по зависимостям, предлагают патчи, рефакторят сервисы и вытаскивают из проекта контекст, который разработчик раньше собирал вручную. Проблема в цене этого удобства, пишет The New Stack: чтобы быть полезным, агенту нужен широкий доступ к коду, конфигам, логам, выводу терминала, переменным окружения и другим кускам локальной реальности.

Именно здесь появляется новый маршрут утечки секретов. Классический сценарий знаком всем: разработчик случайно вставил API-ключ в чат, закоммитил пароль в репозиторий или оставил токен в логах. Агентный сценарий тише и неприятнее. Инструмент получает задачу «разобраться, почему падает авторизация», сканирует рабочую директорию, находит забытый .env, профиль облачных credentials, SSH-конфиг или чувствительный лог и добавляет это в контекст. С его точки зрения все штатно: он ищет данные, нужные для ответа. С точки зрения security — секрет уже покинул контролируемую зону.

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

Это неудобная новость для команд, которые строили безопасность вокруг устойчивых чекпоинтов: pre-commit hooks, pull request scanning, SAST, проверки в CI/CD, quality gates перед релизом. Эти механизмы остаются нужными, но они приходят слишком поздно для агентной разработки. Если credential попал в запрос к модели, репозиторий может быть идеально чистым, а инцидент уже произошел. Получается странная, но логичная картина: пайплайн зеленый, а секрет уже живет где-то в истории промптов.

Отдельный слой риска — supply chain. The New Stack упоминает атаки вроде Mini Shai-Hulud, где злоумышленники искали credentials и конфигурационные данные в developer- и CI-окружениях, включая настройки AI coding tools. Это важная подсказка: конфиги агентов и локальный контекст вокруг них сами становятся целью. Чем шире права инструмента на чтение директорий, логов и домашних конфигураций, тем больше поверхность атаки. Агент здесь не злодей и не магический стажер с root-доступом, а автоматизированная система перемещения данных. Просто очень быстрая и голодная до контекста.

Практический вывод звучит почти скучно, а потому полезно: контекст агента надо считать каналом исходящего трафика. Перед тем как файл или фрагмент промпта уйдет к модели, его нужно проверять локально на секреты. Не просить LLM решить, похожа ли строка на ключ, а использовать детерминированные правила и специализированный secrets detection: нашли credential-shaped value — заблокировали, заредактировали или заставили разработчика явно разобраться. В материале приводится пример Sonar: компания продвигает детектирование секретов и плагины для Claude Code, GitHub Copilot, Codex и Cursor. Важно помнить контекст: публикация спонсирована Sonar, а автор связан с компанией, так что это еще и продуктовая позиция. Но сама проблема от этого не становится рекламной выдумкой.

Для разработчиков это означает меньше романтики вокруг «агент сам все поймет» и больше явных правил. Какие директории агент может читать? Исключены ли по умолчанию .env, credential stores, домашние cloud-профили, production-логи и SSH-конфиги? Разрешено ли отправлять промпты напрямую провайдеру или только через корпоративный gateway? Какие retention, audit и training-настройки включены у поставщика модели? Пока ответы живут в личных настройках каждого инженера, безопасность AI-агентов держится на привычке не ошибаться. Это, мягко говоря, ненадежный контроль.

Для бизнеса картина еще проще. AI coding tools обещают ускорить delivery, но без границы контекста они добавляют новый класс утечек, который плохо ловится старыми процессами. Security-командам придется двигаться левее не только к коммиту, а к моменту, когда агент решает, что читать и что отправлять. Следующий спор в разработке будет не о том, какой агент пишет лучший код, а о том, какой агент умеет быть полезным, не превращая локальную машину разработчика в неучтенный экспорт чувствительных данных.

Поделиться: Telegram X LinkedIn