The old secret leakage problem was embarrassing but manageable. A developer forgot to add .env to .gitignore, committed API keys to a public repo, got an alert from GitHub's secret scanning, rotated the keys, added the file pattern, and moved on. Recoverable. Traceable. Most teams caught it within hours.
The problem with AI coding agents is structurally different, and it doesn't show up in git history.
When you open Cursor, Claudee Code](/tools/claude-code/), or GitHub Copilot and ask for help debugging an API integration, the agent reads your project for context. That context includes your directory structure, open files, and - depending on how your project is organized - whatever config files and environment variables happen to be in scope. That context gets sent to an external inference server (the AI provider's infrastructure that runs the model) to generate a response. Your AWS_SECRET_ACCESS_KEY didn't end up in a commit. It ended up in a prompt payload transmitted over the internet.
Three Ways Agents Expose Secrets Without a Commit
Agentic tools that can autonomously execute tasks make this worse. An agent solving a "why is my database connection failing" task might read your connection string, your ORM config, your migration history, and a credentials helper file before concluding it was a timeout issue. None of that ends up in your git diff.
Three specific patterns create exposure:
- Workspace-wide indexing. Several AI coding tools index your entire project at startup to enable codebase-aware suggestions. That operation reads everything - including files you'd never manually include in a context window.
- Prompt logs and data retention. AI providers retain prompts for varying periods. Most enterprise contracts include data retention carve-outs, but default consumer and small-team tiers often do not. If your prompt included a secret, that secret may have been retained.
- Agents hardcoding what they read. Agents generating test files, config templates, or boilerplate sometimes write in literal values they found in the workspace rather than referencing environment variables. The agent pulled your actual key from context and wrote it directly into a file.
Practical Fixes for a Non-Git Problem
Traditional defenses - secret scanning in CI and .gitignore hygiene - don't address any of this. They catch secrets in committed code. They do nothing about secrets transmitted in prompt context.
Three things that actually reduce exposure:
Scope your agent's file access. Most AI coding tools let you configure which directories they can read. Keep secrets files (.env, credentials.json, keyring paths) explicitly excluded. Treat this the same way you'd treat filesystem permissions on a production server.
Inject secrets at runtime, not in files. If your secrets are served via a secrets manager like AWS Secrets Manager or HashiCorp Vault at runtime - rather than stored in a file - there is nothing for an agent to read from the filesystem. The secret only exists in memory at the moment your code calls for it.
Read your provider's actual data terms. There is a real difference between "your data is not used for training" and "your data is not retained after inference." Those are two separate commitments, and many providers only make one of them. Free and low-tier plans rarely offer either.
The irony is that AI coding tools are genuinely useful for security work - finding injection vulnerabilities, reviewing authentication logic, generating edge-case tests. The same capabilities that make them effective at reading code make them capable of reading secrets. The answer is not to avoid them. It is to configure them with the same care you would apply to any tool that touches your production environment.