Environment Variables in Local Development

In local development environment, it is common for developers to use .env files to manage their environment variables. Often, it contains sensitive information such as API keys to different services. It is not exaggerated that they almost always contain production credentials.

This used to not be a problem but with agentic development, the .env can be read by agents and sent to LLMs services to be processed. Sometimes it can be expected behavior that you want to troubleshoot your .env. It may also be possible to configure the agent to not read some files but it is not the only way to read files it can use grep or other shell tools to workaround the safeguards.

Encrypt the .env file

Note: If you are using Windows, consider using Dev Containers with Linux-based images so that openssl is available.

The first step is to put the secrets outside the project directory e.g. ~/configs/.env.enc. To further isolate this, you could put it inside Dev Container or mount it and run the agent in sandbox outside the Dev Container. Purely based on directory approvals, the agents cannot access it unless you explicitly allow it. I myself use further isolation so that the agents run in a sandbox outside the Dev Container so the .env.enc file is not available to the agents.

To encrypt the plaintext file at ~/configs/.env file, run the following script

openssl enc -aes-256-cbc -pbkdf2 -salt -in ~/configs/.env -out ~/configs/.env.enc

Use a strong password that you can remember, then proceed to delete .env after encrypting it.

rm ~/configs/.env

Then before starting your application, you must load the environment variables into the shell session:

# You can replace "npm start" with you own application startup script
(set -a; source <(openssl enc -d -aes-256-cbc -pbkdf2 -in ~/configs/.env.enc); npm start)

I think this the most legacy-compatible way to isolate the environment variables with least effort. It will prompt the password everytime but security comes with trade-offs.