.env и ИИ-агенты: правило безопасности, которое спасёт ключи

Проблема: агент видит то, что не должен

Когда вы интегрируете ИИ-агента в рабочий проект, возникает соблазн дать ему широкий доступ к файловой системе — для гибкости и удобства отладки. Именно здесь прячется один из самых частых и опасных сценариев утечки данных.

Агент с доступом к рабочей директории может прочитать .env-файл. Дальше ключи попадают в контекст разговора, в логи, в трассировку запросов — и иногда в коммит, если агент имеет право записывать файлы. Языковые модели не различают конфиденциальные и обычные данные: они работают с текстом и могут процитировать ключ при объяснении ошибки или анализе конфигурации.

Результат — скомпрометированный API-ключ, который нужно немедленно отзывать. А если он попал в публичный репозиторий — он там остаётся навсегда, даже после удаления файла.

Решение: два файла и одно правило

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

.env.example — файл с именами переменных и плейсхолдерами вместо реальных значений. Он документирует структуру конфигурации, помогает новым участникам команды и абсолютно безопасен для публикации. Этот файл идёт в git.

.env — файл с реальными ключами. Существует только локально, никогда не попадает в репозиторий. Добавляется в .gitignore с первого дня проекта.

Правило для агента — явный запрет на доступ к .env через системный промпт или ограничения инструментов. Не надейтесь на то, что агент «не догадается» туда заглянуть.

Пример системного промпта:
```
You do NOT have access to .env files. Never read, write, or reference files matching *.env pattern.
```

Результат: контроль без лишних рисков

Правильная схема выглядит так:

• .env.example с плейсхолдерами → в git, доступен команде
• .env с реальными ключами → только локально, в .gitignore
• Агент → не имеет доступа к .env ни при каких условиях

Для продакшн-окружений добавьте переменные окружения через CI/CD (GitHub Actions Secrets, Vercel Environment Variables) или vault-системы (Doppler, AWS Secrets Manager). Так ключи не хранятся в файлах вообще — агент не может получить их даже теоретически.

Если ключ всё же попал в коммит — немедленно отзывайте его и генерируйте новый. История git хранит всё, и автоматические сканеры публичных репозиториев находят такие утечки в течение минут.

Это не сложная архитектура. Это базовая гигиена, которая отделяет рабочий агентный проект от потенциальной катастрофы.