Why Environment Variables Are Insecure for AI Agents

Quick answer: Environment variables feel like a secure way to pass credentials to AI agents — they're not in source code, they're not in the UI. But any env var readable by your app is readable by anything running in the same process, including an agent. The checklist: audit what's in your .env; never inject agent-facing credentials into the process environment; route agent credential access through a broker instead; and treat the process environment as a shared bus, not a secrets store.

The problem: the process environment is not a security boundary

When you set STRIPE_SECRET_KEY=sk_live_... in a .env file or in your hosting provider's environment variable panel, that value is loaded into the process at startup. From that point on, every library, every plugin, every piece of code running in that process can read it with process.env.STRIPE_SECRET_KEY.

That includes an AI agent operating in the same runtime. It doesn't matter if the agent was only "supposed" to handle a narrow task — if the key is in the environment, the agent can access it. And if the agent has a tool that evaluates code, reads files, or passes values to an external API, that key can leave your infrastructure entirely.

This isn't an edge case. It's the default outcome when you give an agent access to a process that inherits a full production .env.

Where this bites in practice

Coding agents (Cursor, Copilot, Claude Code): These agents read your project files as context, including .env files and shell history. Even if the agent doesn't execute code, a key that appears in its context window may be included in conversation logs, debug traces, or provider-side telemetry — depending on the agent and how it's configured.

CI/CD agents: CI pipelines inject secrets as environment variables for legitimate build steps. An AI agent that runs in the same CI job — to generate documentation, run tests, or summarize diffs — has access to every secret in that environment.

Background job workers: An AI agent running as a worker process inherits whatever secrets the worker was configured with. If the worker was set up to access a database and a payment provider, the agent can too, even if the task it was given requires neither.

LLM function-calling setups: When an agent calls a function that reads from process.env and returns the value — even indirectly, as part of a formatted string or an error message — the secret surfaces in the model's context.

The .env file is worse than the environment

A .env file is a file. It can be:

• Read directly by the agent if it has filesystem access
• Committed to git accidentally (.gitignore entries get deleted)
• Included in context windows when an agent is asked to "look at the project setup"
• Copied between environments without review

The .env file feels local and controlled. It isn't — it's plaintext secrets on disk in your project directory.

What to do instead

Don't inject agent-facing credentials into the environment at all. If an agent needs Stripe access, don't put STRIPE_SECRET_KEY in the process environment. Instead, give the agent a scoped credential it retrieves at runtime through a broker — one that's specific to that agent, that service, and that task.

Separate your app's runtime credentials from agent credentials. Your app legitimately needs a database connection string, a mailer API key, a CDN token. Those belong in the environment. Agent credentials are different — they're narrower, shorter-lived, and need their own audit trail. Keep them out of the shared process environment entirely.

Treat .env files as app config, not secrets delivery. Connection strings, feature flags, port numbers — fine in .env. API keys that an agent will access — move them to a vault and broker access.

Review what your CI environment injects before adding AI steps. If your CI job injects 12 secrets for the build process and you're adding an AI agent step to that same job, create a separate job with a minimal environment for the agent. Don't share the build environment with the AI step.

The Vercel environment variables pattern

Vercel's environment variable panel is a common place where this goes wrong. Teams add OPENAI_API_KEY, STRIPE_SECRET_KEY, and DATABASE_URL to Vercel's environment, deploy an app that uses them, and then give an AI agent access to the Vercel project to help manage configuration.

That agent — if it has the Vercel API scope to read environment variables — can now read every secret in the panel. The Vercel environment variables workflow guide covers how to manage Vercel env vars through a broker rather than exposing the Vercel API token directly to an agent.

The broader pattern: when you give an agent access to an infrastructure platform (Vercel, AWS, GCP, GitHub), audit what that platform's API can return. If the platform API can read secrets, the agent with that API token can read secrets.

The checklist

1. Audit your .env and environment panels — list every secret currently in the process environment and ask whether an agent running in that process should have access to it.
2. Remove agent-facing credentials from the shared environment — move them to a vault; issue scoped credentials at runtime.
3. Separate AI agent job steps in CI — minimal environment, no shared secrets with build steps.
4. Never put API keys in .env files in agent-accessible project directories — if the agent can read your project files, it can read your .env.
5. Scope platform API tokens before giving them to agents — understand what a Vercel, GitHub, or AWS token can read before handing it to an AI tool.
6. Log every credential retrieval — if an agent is getting credentials through a broker, every retrieval should be in an audit log so you can see what it accessed and when.

For the underlying model that makes this tractable, see what is secrets management for AI agents and secrets management best practices for AI agents.

If you've already done this

Most teams reading this have already made the mistake. The agent has been running in the process, the .env was readable, the CI environment was shared. Here's how to clean it up.

Step 1: Establish what the agent could have accessed

Don't start by rotating keys. Start by scoping the problem.

Pull your agent's execution logs — every run, every tool call, every function invocation. You're looking for two things: what environment the agent ran in, and whether any tool call could have surfaced a secret (reading files, formatting strings, calling external APIs, evaluating code).

If you don't have logs, assume the worst. If the agent ran in a process with a populated .env, assume every key in that file was accessible.

List the credentials. Every one of them. Don't filter yet.

Step 2: Triage by blast radius

Not all credentials carry equal risk. Prioritize rotation in this order:

Rotate immediately:

• Payment processor keys (Stripe, Braintree) — direct financial exposure
• OAuth client secrets — can be used to impersonate your application
• Database credentials with write access
• Any key that grants access to other secrets (AWS root credentials, Vault tokens, 1Password service accounts)

Rotate within 24 hours:

• Third-party API keys with write or delete permissions
• Email provider credentials (can be used for phishing at scale)
• Cloud provider API tokens with broad IAM scope

Rotate on a scheduled basis:

• Read-only API keys
• Analytics and monitoring tokens
• Keys for services with their own rate limiting and fraud detection

Don't skip the lower tiers. They're lower priority, not low risk.

Step 3: Rotate, then audit usage

When you rotate a key, don't just replace it. Check the old key's usage logs in the provider's dashboard first. Stripe, AWS, GitHub, and most major providers expose per-key access logs. Look for:

• Requests from IP addresses that don't match your infrastructure
• Unusual request timing (outside business hours, burst patterns)
• API methods that your application doesn't use

If you see anomalies, this moves from remediation to incident response. Involve your security team before continuing.

Step 4: Fix the environment before redeploying

Rotating keys into the same broken environment accomplishes nothing. Before you push new credentials anywhere, restructure where they live:

• Remove agent-facing credentials from .env files and environment panels
• Move them to a vault
• Update your agent to retrieve credentials through a broker at runtime, not from the environment at startup

Then deploy. In that order.

GitHub Actions specifically

GitHub Actions is where this pattern does the most damage. Teams inject secrets.STRIPE_KEY, secrets.DATABASE_URL, and secrets.OPENAI_API_KEY into a workflow, then add an AI agent step — a coding agent, a doc generator, a PR reviewer — to the same job.

Every secret exposed to that job via env: is available to the agent step. Full stop.

The fix is structural, not configurational:

Split AI agent steps into separate jobs. GitHub Actions jobs have isolated environments. A review job that runs your AI agent doesn't need the secrets from your deploy job. Use job-level env: blocks, not workflow-level ones.

Use environment protection rules. GitHub's Environments feature lets you restrict which secrets are available to which jobs. Put production secrets behind an environment that only your deployment job can access.

Audit your ${{ secrets }} references. Search your workflow files for every secret reference. For each one, ask whether the AI agent step in that workflow needs it. If not, it shouldn't be in scope.

Don't pass secrets as step outputs. A common pattern is capturing a secret into a step output so a later step can use it. If an AI agent step runs between those two steps, the output may be in the shared step context.

One concrete change: if you're running an AI agent for PR review in the same workflow that deploys to production, separate them into two workflow files triggered by different events. The PR review workflow gets no production secrets. The deploy workflow has no AI agent steps.

Gazebo's approach: services are connected once, credentials stay in the vault, and agents get a scoped token that retrieves only what their access profile permits — nothing from the process environment, nothing in plaintext, everything logged.