Secrets reach a coding agent through five paths: files in the project tree, shell environment variables, terminal output, text pasted by the developer, and tool server results. Cut each path separately, because fixing one leaves the others open. The cheapest fix is to keep secrets out of places the agent reads.
Why this matters
Whatever enters an agent's context can be sent to a model provider, written to a log, or echoed into code. OWASP's sensitive information disclosure guidance lists security credentials among the data at risk and recommends least privilege access, sanitization, and user education. It also warns that instructions telling a model not to reveal data are not reliable on their own.
The five paths
1. Files in the project tree. An env file, a config with a token, a test fixture with a real key. The agent reads files to do its job, so anything readable is in play. Fix: move secrets to a secret manager or an untracked location outside the project, and give the agent no access to the old paths.
2. Environment variables. A shell started by the agent inherits what you exported. Cloud keys exported for another task ride along. Fix: start agent sessions from a clean environment with only the variables the task needs.
3. Terminal output. A failing command prints a connection string, and the agent reads the output. Fix: tell developers to avoid commands that print credentials in agent sessions, and prefer tools that mask them.
4. Pasted text. A developer pastes a stack trace or a config file into the chat to ask for help. Fix: a short rule in your usage guide plus a habit: scrub before pasting. Education is on OWASP's list for a reason.
5. Tool server results. A tool returns a record that contains a token or personal data. Fix: review what each connected tool returns, and scope it to the fields the task needs.
A short rollout order
- Search for existing secrets in repositories and rotate what you find. A secret already exposed should be treated as burned.
- Move the remaining secrets out of the tree.
- Standardize a clean launch environment for agent sessions.
- Publish the paste rule.
- Review tool outputs once per tool, then when a tool changes.
Pre commit hooks and repository secret detection from your existing tooling are a reasonable backstop for the first path. Use the secret detection you already run for that backstop.
What does not work
Telling the agent never to read env files. That is a request, not a control. Enforce the boundary in the environment, using file permissions and a sandbox, so a manipulated model cannot ignore it. For a related walk through, see agent secret handling patterns.
Safeguard provides SBOM and dependency scanning, an MCP Guardrail for tool access, and a free scan for your repositories.
Quick check
Is a gitignore entry enough to hide an env file from an agent?
No. Gitignore controls what git tracks, not what a local tool can read. Move the file or restrict access.
Should we rotate secrets after an agent pilot?
Rotate any secret that sat in the project tree or exported environment during the pilot. It is cheap insurance.
Sources
Last reviewed: 19 October 2026.
