AI-ассистент прочитал ваш .env — и никто не спросил разрешения
Разработчик подключал 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-кодовые ассистенты не работают как git-клиент. Для генерации точного, контекстно-осведомлённого кода агенту нужно «видеть» структуру проекта — и он индексирует файловую систему напрямую, через собственный файловый доступ или механизм «теневого воркспейса», а не через git.
.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-ключами внутри, наглядно показала, что происходит, когда такие данные накапливаются на стороне провайдера.
Способы защиты
Временные меры, к которым сейчас прибегают разработчики — вручную выносить .env за пределы папки проекта перед сессией с AI или шифровать секреты — работают, но убивают саму идею автоматизации и держатся только на дисциплине конкретного человека. При росте команды и количества проектов такой подход ограничивает масштабируемость.
Устойчивое решение — контроль на уровне канала между AI-агентом и провайдером модели, а не надежда на то, что инструмент сам не прочитает лишнее. Именно для этого и нужен прокси-слой безопасности: он видит каждый запрос AI-ассистента к внешней модели и может остановить утечку до того, как секрет покинет инфраструктуру компании — независимо от того, какой именно файл или почему прочитал агент.
Здесь работает продукт Strazh — AI Coding Assistant Security. Он разворачивается между корпоративной сетью и AI-провайдерами одной строкой конфигурации (переменная окружения, split DNS или корпоративный прокси) — без переписывания кода и интеграций в сами Claude Code или Codex. Strazh в реальном времени видит, что именно агент читает, исполняет и отправляет наружу, проверяет используемые skills, tools и агентов на вредоносность, и — что критично именно в этом сценарии — распознаёт и маскирует API-ключи, токены и другие секреты в исходящем трафике до того, как они дойдут до провайдера LLM. Политики можно настраивать гранулярно: по пользователю, проекту и типу действия, так что доступ к .env в одном проекте не означает автоматического доступа во всех остальных.