How to keep your secrets out of AI-generated code and Git commits

AI coding agents are fast, but they have a blind spot: they happily paste an API key into a file, echo a token into a log, or commit a .env you meant to keep local. Every agent with terminal access — Claude Code, Cursor, Gemini CLI, Codex — can also read your shell config and project files, which is exactly where credentials tend to hide. This guide walks through a practical, layered setup so your secrets stay out of AI-generated code and out of your Git history.

Why this matters more with AI

A leaked key is one of the most common and most expensive mistakes in software, and AI assistants raise the stakes in two ways. First, they generate code quickly, so a hardcoded key can land in a dozen files before you notice. Second, agents ingest context aggressively — as one secret-management write-up puts it, your shell config should reference keys, not contain them, because the agent can read whatever your dotfiles expose. The fix isn't to distrust the tool; it's to make sure there are no plaintext secrets for it to find in the first place.

Step 1: Keep secrets in environment variables, never in code

The baseline rule: no API key, password, or token should ever appear as a literal string in source code. Put them in a .env file in your project root and read them at runtime.

# .env  — never committed
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://...

// app.js — reads from the environment, no secret in the file
const apiKey = process.env.ANTHROPIC_API_KEY;

This way the code you (and your AI agent) edit contains only the name of the secret, never its value.

Step 2: Make sure .env can never be committed

Add it to .gitignore before you write a single secret:

.env
.env.local
*.env

Commit a .env.example with empty placeholders instead, so collaborators know which variables to set:

ANTHROPIC_API_KEY=
DATABASE_URL=

If you've already committed a real .env, removing it in a new commit is not enough — it lives in history. Rotate the exposed key immediately and treat it as compromised.

Step 3: Turn on GitHub push protection

GitHub's push protection scans commits as you push and blocks the push if it spots a secret, stopping the leak before it reaches the remote. It recognizes 200+ secret patterns from providers like AWS, OpenAI, Stripe, and many more, and 2026 updates expanded the patterns blocked by default. It's free for public repositories — enable it in your repo's Settings → Code security. Think of it as a seatbelt for the moment an agent (or you) slips up.

Step 4: Don't let agents harvest your shell config

Agents with shell access can read .zshrc, .bashrc, and .zshenv. If you've exported keys there for convenience, the agent can see them. Keep machine-wide secrets out of your dotfiles — load them from a secrets manager or OS keychain on demand instead of exporting plaintext at shell startup.

Step 5: Scope and rotate

Two habits limit the damage if something does leak, advice echoed in OpenAI's API key safety guide:

• Least privilege: give each key the narrowest scope it needs, and use separate keys per project and environment so one leak doesn't expose everything.
• Rotate regularly: rotate keys on a schedule and immediately whenever you suspect exposure. A rotated key turns a breach into a non-event.

A quick checklist

Before you let an agent loose on a repo:

1. Secrets live in .env, read via process.env — never hardcoded.
2. .env is in .gitignore; only .env.example is committed.
3. Push protection is enabled on the remote.
4. No plaintext keys in shell dotfiles.
5. Keys are narrowly scoped and rotated on a schedule.

None of this slows you down once it's set up — and it lets you hand more work to your AI agent with far less to worry about.