Keep AI Coding Agents Away from Env Secrets

Updated 14 November 2026 · Standard formula, shown below

This guide shows you how to configure your AI coding assistant so it never reads, sends, or leaks environment variables like API keys, database credentials, or tokens. You’ll set up permission rules, file ignore lists, and review habits that keep secrets out of the agent’s context — without blocking its usefulness on your codebase.

What You’ll Need

An AI coding agent (e.g., GitHub Copilot, Cursor, Windsurf, or a CLI tool like Aider) that supports configuration files or permission prompts.
Access to your project’s root directory and any global config directory (like ~/.config or ~/.cursor).
Basic familiarity with your operating system’s file paths and text editing.
A list of your environment variable names (e.g., DATABASE_URL, API_KEY) — you don’t need the actual values.

Step-by-Step

Identify where secrets live. Check your .env files, docker-compose.yml, secrets.yaml, and any shell profiles like .bashrc or .zshrc. List the exact filenames and the variable names inside them (e.g., STRIPE_SECRET_KEY).
Create a global ignore file. Most agents respect a global gitignore-style file. For Cursor, it’s ~/.cursor/.cursorignore. For Copilot, it’s ~/.copilot/.copilotignore. Create the file if it doesn’t exist, and add patterns like .env, .env.*, **/.env, **/secrets.*, and **/docker-compose.override.yml. This prevents the agent from even reading those files.
Add a project-level .gitignore entry. Even if you don’t use git, many agents use the repo’s ignore rules. Add .env, .env.*, *.pem, *.key, and secrets.* to your project’s .gitignore.
Configure permission rules for file access. In Cursor, go to Settings → Features → Rules, and add a rule like: “Never read or modify files matching *.env* or *secret*.” For Copilot, use the #file-ignore directive in your .github/copilot-instructions.md. For CLI tools like Aider, use the --no-read flag or a .aider.ignore file.
Block environment variable access in prompts. Many agents can read your shell environment. In Cursor, disable the “Use environment variables” option in Settings → Features. For Copilot, avoid asking questions like “what’s my DB password?” — instead, instruct it to use placeholders. Add a custom instruction: “Never display or use actual environment variable values; use process.env.VAR_NAME as a placeholder.”
Use a secrets scanner as a safety net. Install a pre-commit hook or a CI check like gitleaks or trufflehog that scans your diffs for accidental secret leaks. This catches anything the agent might have slipped into a file.
Review every diff before committing. Before you accept an agent’s changes, run git diff and grep for your secret variable names. For example: git diff | grep -i "api_key\|secret\|password". If you see a real value, stop and revert.
Rotate secrets if you suspect exposure. If an agent ever outputs a real secret (or you see it in a log), immediately revoke that key and generate a new one. Don’t just delete the file — the secret is already compromised.

Common Mistakes

Only ignoring .env at the root. Secrets often live in subdirectories, test fixtures, or .env.local. Use **/.env* to catch all.
Assuming the agent can’t see your shell environment. Some agents can read process.env if you ask. Even if you don’t ask, it might be included in context when you paste a stack trace that contains an env dump.
Forgetting to update ignore lists when you add new secret files. If you create config/credentials.json, your ignore list won’t cover it unless you add it.
Using a single global ignore for all projects. A global ignore might be too broad (blocking legitimate files) or too narrow (missing project-specific secrets). Combine both global and project-level files.
Not testing the ignore rules. After setting up, ask the agent “what’s in my .env file?” — if it answers, your rules aren’t working.

Tips

Use a dedicated secrets manager. Instead of storing secrets in files the agent might read, use a vault like AWS Secrets Manager or HashiCorp Vault, and only reference them at runtime. The agent never needs to see the actual values.
Set environment variables per-session, not globally. If you’re using a terminal-based agent, run it with env -i or a clean shell to avoid leaking your entire environment.
Use placeholder values in code. When you ask the agent to write code that uses a secret, give it a dummy value like sk-test-1234 and tell it to reference the env var name.
Keep a separate “safe” project for testing. If you’re experimenting with agent permissions, do it in a throwaway repo with fake secrets.
Review agent logs. Some agents log their context. Check those logs periodically for any secret values that might have been pulled in.

Troubleshooting

The agent still reads .env files. Check if your agent respects a different ignore file. For Cursor, it’s .cursorignore in the project root, not just the global one. Create one in your project with .env*.
The agent ignores the ignore rules. Some agents prioritize explicit user requests over ignore rules. If you ask “read .env and tell me the password,” it might do it. Always combine ignore rules with prompt-level instructions.
You accidentally pasted a secret into the chat. Immediately rotate that secret. Even if you delete the message, it may have been sent to the agent’s servers. Don’t rely on deletion.
Your CI is failing because of the secrets scanner. The scanner might be flagging a false positive (like a test string). Adjust the scanner’s regex or allowlist that specific pattern, but only after confirming it’s not a real secret.
The agent can’t access a file it needs because of your ignore rules. If the file is not secret, remove the ignore pattern. If it is secret, find a way to give the agent the information without exposing the value — e.g., describe the structure, not the contents.

Frequently Asked Questions

Can I completely prevent an AI agent from ever seeing a secret?

No, not with 100% certainty. If the agent has access to your filesystem, a sufficiently direct prompt might bypass ignore rules. The goal is to reduce risk to near zero and to ensure that even if read, secrets are not logged or committed.

What if I use multiple agents (Copilot, Cursor, etc.)?

Each agent has its own config. You need to set up ignore rules and permissions for each one. A global .gitignore helps, but not all agents respect it. Check each tool’s documentation.

Is it safe to let the agent see .env.example?

Yes, as long as it contains only placeholder values, not real secrets. The example file is meant to show the variable names, so it’s safe.

Should I use a separate machine for AI coding?

That’s overkill for most. Proper ignore rules and rotation are enough. Only consider a separate environment if you’re handling highly sensitive data and have strict compliance requirements.

Can the agent leak secrets through its training data?

Public AI models are trained on public code, which sometimes includes leaked secrets. But your specific secrets are not in the training data unless you’ve posted them publicly. The risk is that the agent might suggest a pattern that looks like a secret, not that it knows yours.

What should I do if I suspect a secret was exposed?

Immediately revoke the secret, generate a new one, and update your environment. Then review your agent’s logs and your git history for any traces. Change your ignore rules to prevent recurrence.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.