Сейчас модно использовать ИИ-агентов для разработки. Не просто попросить написать функцию, а отдать целую задачу: изучить проект, изменить файлы, запустить Docker, выполнить тесты и исправить ошибки. Причём отдать ему ВЕСЬ контекст проекта.

Удобно? Безусловно. Я и сам иногда использую ИИ, хоть и старовер в разработке. Предпочитаю сам писать код и строить архитектуру. Но если отдавать весь проект ИИ-агенту, есть один нюанс, о котором стоит подумать заранее.

Что будет, если агент увидит .env? В PHP-проекте там могут лежать доступы к БД, Redis и API. В Go-сервисе интеграции с SAP это могут быть адрес SOAP-сервиса, логин, пароль и внутренний токен.

Это уже не просто настройки, а доступы к реальным системам. Агент может прочитать конфигурацию при поиске ошибки, вывести секрет в лог или скопировать его в тестовый файл. Не обязательно из-за ошибки модели. Иногда так устроен сам рабочий процесс.

Поэтому я бы начал с простого: отделил код от секретов.

1. Выносим .env за пределы проекта

Проект: D:\projects\orders-service\ docker-compose.yml Dockerfile .env.example src\

Файл с секретами: D:\dev-secrets\orders-service.env В docker-compose.yml: services: app: build: . env_file: - D:/dev-secrets/orders-service.env

В самом файле: SAP_URL=https://sap-test.example.local/service SAP_LOGIN=test_user SAP_PASSWORD=replace_me INTERNAL_SECRET=replace_me

Значения условные. Docker Compose передаст переменные контейнеру, а сам файл не будет лежать рядом с исходниками.

В .env.example оставляем только названия переменных и заглушки.

2. Внешний .env не решает всё

Если агент работает от моего имени в Windows, запускает команды и имеет доступ к файловой системе, он потенциально сможет прочитать внешний файл. Есть доступ к Docker? Значит, потенциально можно получить и переменные окружения контейнера.

Вынос .env помогает не закоммитить секреты случайно, но не является полноценной границей безопасности.

3. Что делать, если агент работает автономно? Я бы разделил окружения: Код: агент может читать и изменять файлы проекта. База данных: отдельная тестовая БД без реальных персональных данных. Интеграции: тестовый SAP-контур, mock-сервис или учётная запись с минимальными правами.

Секреты: только необходимые для конкретной задачи. Никаких production-паролей по умолчанию.

Окружение агента: отдельная учётная запись Windows или изолированная виртуальная машина без доступа к реальным секретам. Недостаточно попросить агента не читать .env. По возможности доступ нужно ограничивать технически.

4. И не забываем про Git Добавляем в .gitignore: .env .env.* !.env.example Это дополнительная защита, а не основная. Если секрет уже попал в Git, простого удаления файла недостаточно. Утёкшие учётные данные нужно заменить. Также нужны отдельная ветка, тесты и проверка изменений перед слиянием.

В итоге Я не считаю, что ИИ-агентов нужно бояться. Наоборот, хочется делегировать им больше рутины. Но если агент может читать файлы, запускать команды и управлять Docker, он получает возможности того окружения, в котором работает.

Не стоит просто просить агента быть осторожным с секретами. Лучше устроить всё так, чтобы он не имел к ним доступа без необходимости.

Особенно если речь о SAP, внутренних API и других служебных системах.

А вы уже используете ИИ-агентов на реальных проектах? Как решаете вопрос с .env, токенами и доступом к внутренней инфраструктуре?