How to stop AI coding agents from reaching your production secrets

If your API keys and production secrets are available in the same environment where your AI coding agent is running, the agent may be able to access and potentially expose or exfiltrate them.

You might try to prevent this with instruction files such as CLAUDE.md or AGENTS.md, telling the agent not to read .env files or access certain credentials. But these instructions are mostly guidance and do not enforce access controls. They do not prevent the agent from accessing secrets it otherwise has permission to reach.

This article explains how coding agents can gain access to developer credentials and why common restrictions fall short. You’ll also learn how to limit agents to only the secrets they need while keeping access scoped, read-only, and time-bound.

How coding agents reach your credentials

Modern coding agents are very powerful. They can inspect files, execute shell commands, and run scripts within seconds. This also means they can find secrets in places you might not expect, including Docker, shell environments, and Git history.

Docker and container tooling

Suppose you ask an AI coding agent to investigate a configuration issue. While debugging, the agent might run docker compose config to inspect the project’s configuration. Docker Compose resolves environment variables and may include secret values in the command output. The agent can then see those secrets without reading the source file directly.

Shell environment inheritance

Developers often export API keys and other credentials into their shell environment. When an AI coding agent is launched from that shell, it can inherit those environment variables just like any other child process. The secret does not need to exist anywhere in the project. If it is present in the environment used to start the agent, it may already be available to the agent.

Git history

Developers sometimes accidentally commit API keys, tokens, or other secrets to Git and remove them in a later commit. But deleting a secret from the current code does not remove it from the repository’s history. An AI coding agent can inspect previous commits and diffs when debugging issues or tracing changes. If a secret still exists in that history, the agent may find it even though it no longer appears in the current codebase.

The common problem across these paths is not .env, Docker, the shell, or Git. As long as a secret remains accessible somewhere in the agent’s environment, blocking one path to it does not prevent the agent from reaching it another way.

Why separate accounts aren’t enough

Teams often try to limit agent access by creating separate accounts for developers and their coding agents. In such a setup, developers keep their existing access, while agents use accounts with fewer permissions.

However, while separate accounts create a useful boundary between developers and agents, they do not guarantee least privilege. Suppose an agent account has access to GitHub, AWS, and a development database. If the agent is working on a task that only requires GitHub, it still has access to AWS and the database simply because those permissions belong to its account.

Separate accounts also add management overhead as your team grows. Instead of controlling access based on what an agent needs for a specific task, you’d have to maintain additional identities and permissions for each agent.

The better approach is to scope access around the task. Give the agent only the credentials it needs, for only as long as it needs them.

How to give AI coding agents scoped access

To give an AI coding agent least-privilege access to secrets, you need to control what credentials it receives and how long it can use them. This means making access task-specific, read-only where possible, and time-bound, so the agent gets only what it needs before it starts.

With Doppler for AI coding agents, you can put this model into practice by creating a separate config for the agent, limiting which secrets are available, and injecting those secrets when the agent starts. The same approach works with coding agents such as Claude Code, Codex, and Cursor.

Step 1: Create an agent-only config

After installing the Doppler CLI and logging in, create a branch config for your coding agent. For example, create dev_agent under your dev environment:

The agent config is separate from your personal config, so you can control which secrets are available to the agent.

Step 2: Add only the secrets the agent needs

Add only the secrets required for the agent’s work. If it needs an API key, scoped GitHub token, or test database URL, add those individually rather than giving it access to your full development config.

For example:

Keep this config under developer control. The agent should not be able to add, modify, or provision its own secrets.

Step 3: Create a scoped, expiring service token

Next, create a service token for the agent-only config and set an expiration:

With this setup, the service token is scoped to dev_agent, read-only by default, and expires after 24 hours. This limits which Doppler config the agent can access and how long that access remains available.

Step 4: Scope service token to the workspace and launch your agent

From the directory where the agent will work, configure the Doppler CLI to use the scoped service token:

Doppler CLI commands run from that workspace will now use the scoped service token instead of your personal token. You can then launch your coding agent with the same scoped access:

For example:

With this setup, Doppler will fetch the secrets from dev_agent and inject them into the agent process as environment variables. The agent receives only the secrets available through its config without requiring them to be stored in a .env file.

Step 5: Connect the Doppler MCP server

If your coding agent supports MCP, you can also connect the Doppler MCP server to give it controlled access to Doppler, as shown below:

Wrapping the MCP server in doppler run lets the shell resolve $DOPPLER_AGENT_TOKEN without storing the raw token in the MCP configuration. The service token restricts access to the specified Doppler config, while --read-only prevents the MCP server from exposing write tools to the agent.

What you gain from scoped agent access

The benefits of giving coding agents scoped access include:

• Control before execution: You decide which secrets the agent can access before it starts instead of relying on instructions to prevent access afterward.
• Easier access management: Agent secrets can be managed in a dedicated config without creating and maintaining a separate user account for every agent.
• Smaller blast radius: If an agent exposes a credential or takes an unintended action, the damage is limited by the secrets and permissions available to it.
• No inherited developer access: The agent runs with its own scoped credentials instead of automatically receiving the developer’s broader access.
• Short-lived access: Expiring service tokens reduce how long an agent’s access remains valid after a session or task ends.
• No secrets stored in .env: Secrets are injected into the agent process at runtime instead of being written to plaintext files in the workspace.

Together, these controls keep the agent’s access intentional and limited. They also reduce the number of credentials it can reach and how long that access remains available.

When scoped access is not enough

Scoped service tokens work well for coding agents running in a developer’s local environment. For automated workloads such as CI, use workload identity with OpenID Connect where supported.

Scoped access also works best as part of a broader security strategy. While it limits which credentials an agent can reach, other controls are needed to address risks such as prompt injection, sandbox escapes, and unsafe developer approvals. If one of those controls fails, scoped access helps contain the impact. For example, if an agent is compromised or takes an unintended action, it can only use the credentials and permissions it has been given.

Wrapping up

Developers may need access to production secrets to deploy applications, troubleshoot incidents, or manage infrastructure. Your coding agents usually don’t. Rather than relying on file restrictions or instructions to keep secrets out of reach, limit what agents can access from the start. Give them only the credentials they need, make access read-only where possible, and remove it when the task is done.

With Doppler, you can give coding agents scoped access to the secrets they need without exposing the rest of your environment. Try a Doppler demo to see it in action.