AI coding agents expose .env secrets and break old secrets models

At a glance

What this is: This post argues that .env files are no longer safe in AI-assisted development because coding agents can read and transmit plaintext secrets during ordinary coding tasks.

Why it matters: For IAM and NHI teams, it shows why secrets management now has to account for developer agents, runtime injection, and process-scoped access rather than file-based controls alone.

By the numbers:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Infisical's analysis of .env files, AI coding agents, and runtime secret injection

Context

AI coding agents change the secrets problem because they do not just execute code, they read project context and can pull plaintext credentials into the request path. In practice, that makes a .env file part of the agent's working set, which is a weak fit for modern secrets management and an even weaker fit for identity governance.

For years, .env files were tolerated because the main risk was accidental commit. Once an agent can traverse the workspace and transmit file content to an inference service, the trust boundary shifts from repository hygiene to runtime access control. That is the right place to judge secrets exposure in agent-enabled development.

The primary issue is not the brand of coding assistant. It is the assumption that a file excluded from version control is effectively protected. In agent-heavy workflows, that assumption fails because the secret is still readable in the workspace before any code is shipped.

Key questions

Q: How should security teams handle secrets in AI-assisted development workflows?

A: Use runtime secret injection instead of plaintext files, and keep secrets out of the workspace where coding agents can read them. The control objective is to prevent the secret from entering agent context at all. That means process-scoped delivery, short-lived credentials where possible, and revocation when exposure is suspected.

Q: Why do .gitignore rules fail as a secrets control for coding agents?

A: Because .gitignore only affects version control, not what an AI agent can read in the local filesystem. If the agent can traverse the project and ingest .env contents, the secret has already been exposed before any commit occurs. Repository hygiene is useful, but it is not a protection boundary.

Q: What do security teams get wrong about local secret storage?

A: They often treat convenience as an acceptable proxy for control. Plaintext local storage is easy to use, but it shifts protection to developer discipline and ignores new file-reading behaviour in AI coding tools. A better model keeps secrets in memory for the duration of a run, not on disk.

Q: When should organisations replace .env files with runtime injection?

A: They should do it as soon as developers are using AI coding agents that can read workspace files. At that point, file-based secrets are no longer just a commit risk. They are a context exposure risk, and the right response is to move delivery into the runtime path.

Technical breakdown

Why .env files break in agent-enabled development

A .env file is just plaintext storage for environment variables, usually protected by convention rather than enforcement. That worked when the main consumers were humans and build tools. AI coding agents are different because they inspect files for context, and many are designed to send that context to external inference infrastructure. Once the agent can read the file, .gitignore no longer matters. The secret has already entered the agent's context window, which is outside the repository boundary and often outside the organisation's direct control.

Practical implication: stop treating repository exclusion as a secrets control and move sensitive values out of the workspace entirely.

Runtime secret injection versus file-based secret storage

Runtime secret injection changes the control point from storage to process startup. Secrets are fetched from a secrets manager, placed into memory, and exposed only to the running application through environment variables or equivalent runtime mechanisms. That means the agent may still read source files, but it cannot directly read the process environment of a live application. This is a materially different trust model from a plaintext file, because access becomes ephemeral, scoped, and tied to execution rather than persistence.

Practical implication: use process-scoped secret delivery for local development and treat plaintext files as a legacy exception, not the default.

Why opt-out ignore files do not solve the underlying problem

Agent-specific ignore files can reduce exposure, but they are partial controls. They depend on every developer, every IDE, and every agent implementation honouring the same conventions, and they do nothing for other paths where secrets can still surface, such as copied snippets, cached context, or adjacent files. In governance terms, that is a control for file selection, not for secret lifecycle. The secret still exists in the workspace until the agent decides not to read it, which is the wrong layer to rely on for protection.

Practical implication: treat ignore files as a hygiene aid only, and back them with runtime injection, access scoping, and auditability.

Threat narrative

Attacker objective: The objective is to obtain reusable application secrets from ordinary development workflows without needing to compromise the application itself.

1. Entry occurs when an AI coding agent is given normal access to a developer workspace and can read files such as .env without special approval gates.
2. Credential exposure happens when the agent ingests plaintext secrets into its context and sends that context to an external inference server as part of the request.
3. Impact follows when sensitive API keys or database credentials leave the local trust boundary and become exposed to unnecessary retrieval, retention, or downstream misuse.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Plaintext developer secrets are now a context-leak problem, not just a commit-risk problem. The old model assumed the danger was accidental publication to source control. AI coding agents break that assumption because the secret can be exposed before any commit happens, simply by being read into the agent's working context. That makes the workspace itself a trust boundary, and practitioners need to treat it as such.

Runtime secret injection is the right control plane because it removes secrets from file system reach. When credentials live only in process memory and are fetched on demand, the agent can inspect code without automatically inheriting the secret payload. This aligns better with OWASP-NHI and zero trust thinking than static files ever did, because access becomes scoped to execution rather than stored alongside code.

Secret sprawl is now amplified by developer tooling, not just by poor repository hygiene. The industry has spent years focusing on leaked files, but agentic development adds a second exposure path through context assembly. The practical implication is that secrets governance must now cover editor behaviour, local runtime injection, and the path from file visibility to inference requests.

Ephemeral credential trust debt: the longer teams rely on plaintext files for values that are only needed at runtime, the more they accumulate exposure they cannot see or revoke in time. That debt becomes harder to justify once agents can read the same files developers do. Practitioners should treat this as a structural secrets governance issue, not a tooling preference.

Lifecycle governance now has to include developer-facing secrets delivery. Joiner-mover-leaver controls and access reviews were built to manage entitlements, but a .env file sidesteps that model entirely because it is a static object rather than a governed identity grant. The implication is that secrets handling for local development needs the same discipline as workload identity and privileged access.

From our research:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• For a broader view of why secrets governance has to move beyond file hygiene, see Guide to the Secret Sprawl Challenge.

What this signals

Ephemeral credential trust debt: once developers rely on agents that ingest workspace context, file-based secrets create exposure that outlives the original development task. The programme response is to reduce the number of places secrets can exist at all, not to trust agent-specific exclusion rules.

The next maturity step is to align developer tooling policy with workload identity and secrets lifecycle controls. Teams that already manage service-account sprawl should recognise the pattern immediately: if a secret can be read casually by a tool, it is already too persistent for the environment it serves.

For practitioners

• Remove plaintext secrets from the workspace Move development credentials out of .env files and into runtime injection so the agent cannot read them as ordinary project content. Use process-scoped delivery for local runs and reserve plaintext only for short-lived exceptions that are tightly controlled.
• Audit agent-visible file paths Review which files your coding agents can read by default, including hidden files, configuration files, and local caches. Then align editor settings, agent policies, and project conventions so secrets are excluded before the agent starts building context.
• Treat secret exposure as a revocation problem When a secret is discovered in a workspace or prompt context, revoke and reissue it rather than relying on detection alone. Pair that with rotation paths for API keys, database credentials, and other long-lived secrets used in developer environments.
• Update developer governance for AI-assisted coding Add agent-aware controls to your secure development standard, including approved secret delivery patterns, prohibited file locations, and review points for local tooling. This keeps secrets management aligned with how code is actually written now.

Key takeaways

• AI coding agents turn plaintext secrets into a context-exposure problem, which means .env files no longer fit modern development risk.
• Runtime injection changes the trust boundary by keeping secrets in memory and out of agent-readable files.
• Teams should respond by removing file-based secrets, auditing agent-visible paths, and treating any exposure as a revocation event.

Key terms

• Runtime Secret Injection: Runtime secret injection is a delivery pattern where credentials are fetched at process start and placed in memory instead of stored in a file. It reduces exposure in local development because sensitive values are present only while the application runs and are not sitting in agent-readable workspace content.
• Context Leak: A context leak happens when sensitive material is pulled into an AI agent's prompt or working context even though the user did not intend it to be processed. In development workflows, this often occurs when agents read configuration files, logs, or copied snippets that contain secrets.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the accumulated risk created when teams keep using persistent storage for values that should exist only for a short runtime window. The debt grows when secrets remain easy to read, hard to revoke quickly, and accessible to tools that were not meant to see them.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact CLI flow for injecting secrets at runtime into local development processes.
• Examples across Python, Go, Rust, Java, and other runtimes that read environment variables.
• The practical trade-offs of building your own secrets delivery stack versus using a managed approach.
• The one-line migration pattern from .env-based development to runtime injection.

👉 Infisical's full post explains the runtime injection workflow and the cross-language dev setup examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.