The moment an application connects to a model provider, a database, email, payments, or an external data service, it needs credentials. Those credentials are often called secrets because anyone who has them may be able to spend money, read data, change records, or impersonate your application.

An environment variable is a named setting supplied to an application when it runs. It is commonly used to provide secrets without placing them directly in the source code.

What an environment variable looks like

OPENAI_API_KEY=your-secret-value
DATABASE_URL=your-database-connection
STRIPE_SECRET_KEY=your-payment-secret

The left side is a stable name your application expects. The right side is the private value supplied by your local computer or deployment platform.

Why secrets do not belong in code

This is unsafe:

const apiKey = "put-a-real-secret-here";

If you commit that code to Git, share a screenshot, send the repository to a collaborator, or publish a client-side web application, the secret may become available to people who should never have it.

Use an environment variable instead:

const apiKey = process.env.OPENAI_API_KEY;

The code knows the *name* of the secret. It does not contain the secret itself.

.env and .env.example

On your own computer, a project may use a .env file:

OPENAI_API_KEY=...
DATABASE_URL=...

That file should normally be ignored by Git so it never gets committed.

Your project can safely include a .env.example file instead:

OPENAI_API_KEY=
DATABASE_URL=
STRIPE_SECRET_KEY=

The example tells a new collaborator which values they need, without handing them the keys.

Environments are different places to run the same product

Most projects eventually have more than one environment:

Local developmentPreview or stagingProduction

Your local version may use test accounts and fake data. A preview version lets you check a change before real users see it. Production uses live systems.

They should not all share the same credentials. If you accidentally test a destructive feature against your production database, a small experiment can become a real incident.

Give people and agents the least access they need

AI agents need context to work well. They do not need every key in your company.

If an agent only needs to read public documents, it should not receive a database-admin key. If a background job only updates one table, it should not be able to delete all customer data. This is called least privilege: give each system the minimum access needed for its job.

Sonariq is a useful example. A research agent may need access to a financial-data provider and a model. That does not mean it needs access to billing controls, every production database table, or unrelated private credentials.

What to do when a secret leaks

Do not try to hide it with a new commit and assume the problem disappeared. If a secret was exposed, treat it as compromised:

1. Revoke or rotate the key with the provider. 2. Replace it in the appropriate environment. 3. Check recent usage and logs if the provider offers them. 4. Remove it from the repository and prevent it from happening again. 5. Review who and what actually needs that access.

The important action is rotation. A deleted line of code does not make an old key safe again.

Practical exercise: make your project safe to share

For your project:

1. Create .env.example with the names of every required variable. 2. Make sure .env is listed in .gitignore. 3. Search the project for obvious key names and confirm no real values are in source files. 4. Write one sentence beside each variable explaining which part of the system needs it.

Then ask Codex: “Inspect this repository for exposed secrets and unsafe client-side use of environment variables. Report findings only; do not change files.” Review the report before making changes.

Check your understanding

1. What is the difference between a variable name and its secret value? 2. Why should .env.example be committed while .env usually should not? 3. Why should local, preview, and production environments use different credentials? 4. What is the first action to take after exposing a key?