Разработчик подключал Node.js-сервис к облачному хранилищу Tencent Cloud и попросил AI-ассистента помочь с кодом. Тот справился с задачей — и заодно прочитал файл .env, нашёл там API-ключ и Secret ID и передал их в контексте запроса к облачной модели. О том, что ключи «уехали» вместе с остальным кодом, разработчик узнал только благодаря собственной проверке — сам ассистент об этом не предупредил.
Как это было
История, которую недавно разобрало китайское техническое сообщество Linux.do, выглядит как обычная повседневная задача, именно поэтому данный кейс примечателен. Разработчик писал интеграцию с Tencent Cloud Object Storage и работал через AI-редактор (команда Strazh по описанию предполагает, что это была связка Cursor или Claude Code). Чтобы «точнее» сгенерировать код, ассистент автоматически проиндексировал файлы проекта, включая .env (текстовый файл, который содержит переменные окружения в формате "ключ=значение" и используется для хранения конфиденциальной информации, такой как API-ключи, пароли к базам данных, настройки сервера и других параметров конфигурации) с боевыми учётными данными, и включил их содержимое в контекст, отправленный языковой модели в облаке.
Ключевой момент в том, что разработчик не давал AI прямого разрешения читать .env. Он просто попросил помочь с интеграцией — а ассистент сам решил, что для «точности» ему нужен доступ к конфигурации проекта. Это не единичный случай и не баг конкретного инструмента, а системная особенность того, как современные AI-агенты строят контекст.
Масштаб проблемы подтверждают независимые данные. По отчёту GitGuardian State of Secrets Sprawl за 2026 год, в публичных репозиториях GitHub обнаружено 29 миллионов захардкоженных секретов — на 34% больше, чем годом ранее, а количество утёкших ключей от AI-сервисов (OpenAI, Anthropic и др.) выросло на 81% за год. Отдельное исследование показало, что коммиты, сделанные с помощью AI-ассистентов, содержат утечки секретов примерно в 3,2% случаев против 1,6% у коммитов, написанных вручную — риск удваивается там, где в разработке участвует AI.
Ключевой момент в том, что разработчик не давал AI прямого разрешения читать .env. Он просто попросил помочь с интеграцией — а ассистент сам решил, что для «точности» ему нужен доступ к конфигурации проекта. Это не единичный случай и не баг конкретного инструмента, а системная особенность того, как современные AI-агенты строят контекст.
Масштаб проблемы подтверждают независимые данные. По отчёту GitGuardian State of Secrets Sprawl за 2026 год, в публичных репозиториях GitHub обнаружено 29 миллионов захардкоженных секретов — на 34% больше, чем годом ранее, а количество утёкших ключей от AI-сервисов (OpenAI, Anthropic и др.) выросло на 81% за год. Отдельное исследование показало, что коммиты, сделанные с помощью AI-ассистентов, содержат утечки секретов примерно в 3,2% случаев против 1,6% у коммитов, написанных вручную — риск удваивается там, где в разработке участвует AI.
Технический аспект реализации
Секрет в том, что современные AI-кодовые ассистенты не работают как git-клиент. Для генерации точного, контекстно-осведомлённого кода агенту нужно «видеть» структуру проекта — и он индексирует файловую систему напрямую, через собственный файловый доступ или механизм «теневого воркспейса», а не через git.
.gitignore в этой модели угроз бесполезен в принципе. Этот файл — инструкция для Git о том, что не нужно коммитить и пушить в репозиторий. Он ничего не знает про AI-агента, который читает файлы прямо с диска, независимо от того, находятся они под контролем версий или нет. Файл, годами исключённый из git через .gitignore, оказывается полностью видим для AI-ассистента, потому что тот обращается к файловой системе, а не к истории коммитов.
Дальше содержимое .env — переменные окружения, ключи, токены — попадает в контекстное окно запроса к модели вместе с остальным кодом проекта. Этот контекст уходит на сервер провайдера LLM для обработки. Что происходит с ним дальше — используется ли он для дообучения, сколько хранится в логах, кто имеет к нему доступ — зависит от политики конкретного провайдера и обычно не контролируется ни разработчиком, ни его компанией. Исследователи Check Point отдельно отмечали, что часть ассистентов не просто читает такие файлы, но и потом воспроизводит захваченные токены в сгенерированном коде — секрет может «утечь» повторно, уже в виде готового сниппета.
.gitignore в этой модели угроз бесполезен в принципе. Этот файл — инструкция для Git о том, что не нужно коммитить и пушить в репозиторий. Он ничего не знает про AI-агента, который читает файлы прямо с диска, независимо от того, находятся они под контролем версий или нет. Файл, годами исключённый из git через .gitignore, оказывается полностью видим для AI-ассистента, потому что тот обращается к файловой системе, а не к истории коммитов.
Дальше содержимое .env — переменные окружения, ключи, токены — попадает в контекстное окно запроса к модели вместе с остальным кодом проекта. Этот контекст уходит на сервер провайдера LLM для обработки. Что происходит с ним дальше — используется ли он для дообучения, сколько хранится в логах, кто имеет к нему доступ — зависит от политики конкретного провайдера и обычно не контролируется ни разработчиком, ни его компанией. Исследователи Check Point отдельно отмечали, что часть ассистентов не просто читает такие файлы, но и потом воспроизводит захваченные токены в сгенерированном коде — секрет может «утечь» повторно, уже в виде готового сниппета.
В чем фокус
Проблема касается не только облачных API-ключей вроде Secret ID Tencent Cloud. По тому же принципу AI-ассистент может прочитать и передать в облако токены доступа к базам данных, приватные SSH-ключи, сертификаты, пароли от внутренних сервисов и токены CI/CD — всё, что лежит рядом с кодом в файлах конфигурации.
Для бизнеса это утечка не «случайного» уровня, а прямой канал компрометации инфраструктуры. Похищенный ключ облачного хранилища — это доступ к данным клиентов, возможность их подмены или удаления, а иногда и прямые финансовые потери от неавторизованного использования ресурсов. В российских реалиях такие инциденты дополнительно попадают под требования Федерального Закона №98 "О коммерческой тайне" : если ключи и код передаются во внешний AI-сервис без контроля, компания теряет формальные основания считать эту информацию защищаемой тайной, а значит теряет и юридические рычаги против нарушителя.
Особенно тревожно то, что утечка происходит без злого умысла — ни разработчик, ни поставщик AI-инструмента не пытаются украсть данные. Секрет просто становится частью «облачной памяти» модели или логов провайдера, где его дальнейшая судьба компании неподконтрольна. Утечка логов DeepSeek в 2025 году, где обнаружили более миллиона диалогов с API-ключами внутри, наглядно показала, что происходит, когда такие данные накапливаются на стороне провайдера.
Для бизнеса это утечка не «случайного» уровня, а прямой канал компрометации инфраструктуры. Похищенный ключ облачного хранилища — это доступ к данным клиентов, возможность их подмены или удаления, а иногда и прямые финансовые потери от неавторизованного использования ресурсов. В российских реалиях такие инциденты дополнительно попадают под требования Федерального Закона №98 "О коммерческой тайне" : если ключи и код передаются во внешний AI-сервис без контроля, компания теряет формальные основания считать эту информацию защищаемой тайной, а значит теряет и юридические рычаги против нарушителя.
Особенно тревожно то, что утечка происходит без злого умысла — ни разработчик, ни поставщик AI-инструмента не пытаются украсть данные. Секрет просто становится частью «облачной памяти» модели или логов провайдера, где его дальнейшая судьба компании неподконтрольна. Утечка логов DeepSeek в 2025 году, где обнаружили более миллиона диалогов с API-ключами внутри, наглядно показала, что происходит, когда такие данные накапливаются на стороне провайдера.
Способы защиты
Временные меры, к которым сейчас прибегают разработчики — вручную выносить .env за пределы папки проекта перед сессией с AI или шифровать секреты — работают, но убивают саму идею автоматизации и держатся только на дисциплине конкретного человека. При росте команды и количества проектов такой подход ограничивает масштабируемость.
Устойчивое решение — контроль на уровне канала между AI-агентом и провайдером модели, а не надежда на то, что инструмент сам не прочитает лишнее. Именно для этого и нужен прокси-слой безопасности: он видит каждый запрос AI-ассистента к внешней модели и может остановить утечку до того, как секрет покинет инфраструктуру компании — независимо от того, какой именно файл или почему прочитал агент.
Здесь работает продукт Strazh — AI Coding Assistant Security. Он разворачивается между корпоративной сетью и AI-провайдерами одной строкой конфигурации (переменная окружения, split DNS или корпоративный прокси) — без переписывания кода и интеграций в сами Claude Code или Codex. Strazh в реальном времени видит, что именно агент читает, исполняет и отправляет наружу, проверяет используемые skills, tools и агентов на вредоносность, и — что критично именно в этом сценарии — распознаёт и маскирует API-ключи, токены и другие секреты в исходящем трафике до того, как они дойдут до провайдера LLM. Политики можно настраивать гранулярно: по пользователю, проекту и типу действия, так что доступ к .env в одном проекте не означает автоматического доступа во всех остальных.
Устойчивое решение — контроль на уровне канала между AI-агентом и провайдером модели, а не надежда на то, что инструмент сам не прочитает лишнее. Именно для этого и нужен прокси-слой безопасности: он видит каждый запрос AI-ассистента к внешней модели и может остановить утечку до того, как секрет покинет инфраструктуру компании — независимо от того, какой именно файл или почему прочитал агент.
Здесь работает продукт Strazh — AI Coding Assistant Security. Он разворачивается между корпоративной сетью и AI-провайдерами одной строкой конфигурации (переменная окружения, split DNS или корпоративный прокси) — без переписывания кода и интеграций в сами Claude Code или Codex. Strazh в реальном времени видит, что именно агент читает, исполняет и отправляет наружу, проверяет используемые skills, tools и агентов на вредоносность, и — что критично именно в этом сценарии — распознаёт и маскирует API-ключи, токены и другие секреты в исходящем трафике до того, как они дойдут до провайдера LLM. Политики можно настраивать гранулярно: по пользователю, проекту и типу действия, так что доступ к .env в одном проекте не означает автоматического доступа во всех остальных.
Первоисточник на языке оригинала - https://www.80aj.com/2026/06/29/ai-api-key-security/
