How to Protect Your Credentials and Secrets from AI Coding Tools

Here’s a question I’d ask you to answer honestly: do you know what your AI coding assistant can read right now? Not what it writes — what it reads.

Most developers don’t. I didn’t either, until I started digging into it while setting up guardrails for my own projects. The uncomfortable answer is that tools like Claude Code, Cursor, and GitHub Copilot can read almost any file in your project folder — including the .env file holding your database password, your Stripe key, and that WordPress application password you created last month.

So in this guide, I’ll show you how to protect secrets from AI coding tools — which files to lock down, the exact configuration for each major tool, and the honest limits of each approach. This is the security companion to my AI project guardrails guide: that article covered what AI writes into your project, and this one covers what it can read and leak out of it.

Reading Secrets Is a Different Risk from Writing Them

When people think about AI and credentials, they usually picture the AI hardcoding an API key into a file and committing it to GitHub. That’s a real risk, and a secret scanner like gitleaks catches it.

But reading is a separate problem, and it’s sneakier. Your AI assistant doesn’t need to write a single bad line of code to expose a credential. It just needs to open the wrong file while gathering context for a task.

Think about how these tools work. You ask for help debugging a connection issue, the agent explores your project to understand it, and your .env file is sitting right there in the project root. Unless you’ve told the tool otherwise, that file is fair game.

AI Tools, Guides & Insights

Artificial Intelligence (AI) Impact on Blogging: Is It the End — or a New Beginning?

14 min read

What Happens When an AI Tool Reads Your .env File?

Let’s define the problem properly before fixing it.

Protecting secrets from AI coding tools means blocking AI assistants from reading credential files like .env, so passwords and API keys never enter the AI’s context or leave your machine. It’s separate from preventing committed secrets — this is about controlling what the AI can see, not what it writes.

When an AI tool reads a file, the contents become part of the prompt sent to the model provider’s servers. Your secrets travel over the network, sit in the model’s context window for the rest of the session, and may be retained on the provider’s side for a period that depends on your plan — API traffic is typically kept for a limited abuse-monitoring window, while consumer chat products may use conversations for training depending on your settings.

That’s three exposure points from one innocent file read. And here’s the part that surprised me: security researchers have documented coding agents loading .env files into memory automatically, and real incidents where agents included credential files in uploads without being asked. This isn’t theoretical.

Why .gitignore Won’t Save You

This is the most common misconception I see, so let’s clear it up first.

A .gitignore file controls what Git commits to your repository — it does not stop any software on your machine from reading files. AI coding agents read directly from your filesystem, so a file excluded from version control is still fully visible to them. If your protection plan for secrets starts and ends with .gitignore, your AI assistant can read every one of them.

Some tools do use .gitignore as a hint for what to skip when indexing your project. But that’s a courtesy, not a boundary. For an actual boundary, each tool needs its own configuration — which is exactly what we’ll set up next.

How to Block Each AI Tool from Reading Your Secrets

Each major tool has its own mechanism, and they’re not equally strong. Here’s the landscape:

Let’s set up each one.

Claude Code — Permission Deny Rules

Claude Code uses a permission system with explicit deny rules. Create a .claude/settings.json file in your project root:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./**/credentials.json)"
    ]
  }
}

Deny rules block Claude from reading those files as context during a session. The official Claude Code settings documentation covers the full syntax, including rules for blocking edits and shell commands too.

I’d suggest adding these rules at the user level as well (~/.claude/settings.json), so every project you open gets the protection — not just the ones where you remembered to add the file.

Cursor — The .cursorignore File

Cursor reads a .cursorignore file from your project root, using the same syntax as .gitignore:

.env
.env.*
secrets/
*.pem
*.key

Files listed here are excluded from indexing and AI context. Though, be aware of the catch: Cursor’s own documentation describes this as best-effort protection. An agent running shell commands can still cat a file that the index ignores. It raises the bar; it doesn’t seal the room.

GitHub Copilot — Content Exclusion

Copilot takes a different approach. Content exclusion for GitHub Copilot is configured in your repository or organisation settings on github.com, not in a project file — and it’s only available on Copilot Business and Enterprise plans. Free and individual Pro users don’t get this control, which means individual developers need to rely on the off-disk strategies later in this article.

If you do have a Business plan, go to your repository settings → Copilot → Content exclusion, and add patterns like **/.env and **/secrets/**. The GitHub content exclusion documentation lists the full pattern syntax and which Copilot features respect it.

Windsurf — The .codeiumignore File

Windsurf follows the same pattern as Cursor: a .codeiumignore file in your project root with .gitignore-style syntax. It also respects your existing .gitignore patterns automatically, which is a nice touch. The same best-effort caveat applies.

AI Tools, Guides & Insights

How to Save AI Tokens (And Why It Matters More Than Ever)

16 min read

The Honest Truth: Ignore Files Are Best-Effort

I won’t pretend these configurations make you bulletproof, because they don’t.

Here’s the gap: most AI coding agents can run shell commands. An ignore file stops the tool’s file-reading features, but an agent that runs cat .env in a terminal — because you approved a broad shell permission, or because auto-run is on — walks right past it. Vendors are honest about this when you read the fine print; the protections are described as best-effort, not guaranteed.

So treat ignore files and deny rules the way you treat a lock on an internal door. Worth having, genuinely useful, but not the only thing standing between your secrets and the outside world.

Two habits close most of the remaining gap. First, keep auto-approve modes off in any project containing real credentials — review shell commands before they run. Second, if you know an AI session has already read a secret, rotate that key. It takes five minutes and removes the doubt entirely.

The Stronger Fix: Keep Secrets Off Your Disk

The configurations above limit what AI tools can read. The better long-term play is making sure there’s nothing worth reading.

The simplest version is the .env.example pattern. Keep a committed .env.example listing variable names with placeholder values, and tell your AI (in your AGENTS.md or CLAUDE.md) to read that file whenever it needs to know what variables exist. The AI gets the structure it needs to write correct code — it never needs the real values.

The stronger version is runtime secret injection. Tools like the 1Password CLI, Doppler, and Infisical store your secrets in an encrypted vault and inject them into your app’s process only at launch. Your .env file then contains references — something like op://Work/Stripe/api_key — instead of actual credentials. An AI tool reading that file learns nothing useful.

In practice, this is the setup I’d recommend working towards. The ignore rules take five minutes and you should do them today. The vault migration takes an afternoon, and after it’s done, the question “can my AI read my secrets?” stops mattering — there are no secrets on disk to read.

Watch Your MCP Servers Too

There’s one more exposure path that almost nobody covers: the connectors you plug into your AI tools.

MCP (Model Context Protocol) servers give AI agents new abilities — web fetching, database access, file operations beyond the project folder. Each one widens what your agent can reach, and a poorly built or malicious server can become an exfiltration channel. Researchers have already documented real-world cases of MCP integrations being used to steal credentials, SSH keys, and tokens.

The risk compounds with prompt injection — hidden instructions planted in content your AI reads, like a webpage it fetches or a file in a dependency. A poisoned instruction can tell the agent to read your credentials file and send the contents somewhere, and an agent with both file access and network access has everything it needs to comply.

You don’t need to avoid MCP servers — I use them myself. But apply three checks before connecting one: install only from publishers you can verify, question any server that wants both filesystem and network access, and never grant a server more scope than the task needs. I’m working on a full MCP setup guide for the AI-Powered Blogging series that goes deeper into evaluating servers before you connect them.

AI Tools, Guides & Insights

How to Write Better AI Prompts (and Actually Get Useful Answers)

13 min read

Your 15-Minute Security Setup

Let’s turn all of this into a checklist you can finish today:

1. Add deny rules or ignore files for your AI tools — .claude/settings.json deny rules for Claude Code, .cursorignore for Cursor, content exclusion if you’re on Copilot Business.
2. Create a .env.example and add a rule to your AGENTS.md telling the AI to read it instead of .env.
3. Turn off auto-approve modes in projects that hold real credentials.
4. Rotate any key an AI session has already read — when in doubt, rotate.
5. Plan the vault migration — 1Password CLI or Doppler — for a free afternoon this month.

The first three steps take about fifteen minutes combined. That small investment closes the most common exposure paths, and pairs naturally with the instruction files and pre-commit hooks from the guardrails guide to give you proper defence-in-depth: control what the AI writes, control what it reads, and verify everything before it ships.

Frequently Asked Questions