TL;DR: .env files store secrets as plaintext on disk, making them easy to leak through git, Slack, and filesystem reads, while AI coding agents now expand that exposure by reading project files automatically, according to Akeyless. The practical endpoint is runtime injection of short-lived credentials, because static secrets on disk no longer match how developers and agents work.
At a glance
What this is: This is an analysis of why .env files are no longer a safe place for real secrets, with the key finding that plaintext files now intersect badly with AI coding agents, git leakage, and runtime access.
Why it matters: It matters because IAM and NHI teams need to separate harmless config from credentials and move sensitive values into governed runtime controls before agents and pipelines expose them.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
👉 Read Akeyless's analysis of why .env files are failing as secret storage
Context
A .env file is a plaintext container for key-value configuration, which makes it convenient for development but weak for secrets governance. For identity and access teams, the real issue is not the file format itself but the fact that credentials, tokens, and passwords are being treated as if they were harmless configuration.
That weakness now collides with modern developer tooling and AI coding agents. When project files are read automatically, secrets on disk can move into prompts, generated code, chat logs, and downstream audit trails, which turns a local convenience into a governance problem for NHI, secrets, and software delivery.
Akeyless frames the safer path as a progression from plain files to encrypted files, then to secrets managers, and finally to runtime injection of short-lived credentials. That progression is typical for teams that start with developer ergonomics and later discover they need stronger lifecycle control over secrets and machine access.
Key questions
Q: How should security teams reduce the risk of developer secrets stored in local .env files?
A: Security teams should make the safer path the easiest path. That means detecting plaintext secrets on local devices, guiding developers to move them into a managed secrets store, and giving admins visibility into what was exposed. The goal is to preserve developer speed while removing plaintext persistence, so teams can monitor, revoke, rotate, and govern credentials before they spread.
Q: Why do .env files create a bigger risk when AI coding agents are in the workflow?
A: Because AI coding agents read project files automatically, a plaintext secret can move from a local file into a model’s context, generated output, or chat history without any deliberate sharing. That means the leak path is built into the workflow, not just caused by user error.
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.
A: Environment variables are a deployment convenience, while a secret manager is a control designed to protect sensitive values. Variables can be exposed through configuration access, logs, process inspection, or accidental sharing. A secret manager centralises storage, supports tighter access controls, and reduces secret sprawl across functions and environments. For serverless workloads, that difference materially changes the blast radius of a compromise.
Technical breakdown
Why plaintext .env files fail as secret storage
A .env file is not a security boundary. It is a plaintext file on disk, so anything that can read the filesystem can read the secrets inside it, including scripts, local tools, backup processes, and developer utilities. The common failure is not exotic compromise but ordinary operational drift: the file gets copied, shared, committed, or synced beyond its intended use. Once that happens, the secret is no longer governed by the application. It is governed by every place the file has touched, which is exactly the wrong model for credentials.
Practical implication: Treat .env as configuration only, and move any real credential into a governed secret lifecycle.
How AI coding agents change the leak path
AI coding tools read project files to help with debugging and code generation, so a .env file in the workspace can be ingested automatically even when it was never meant to leave the developer machine. That changes the leak path from accidental exposure to structured exposure through prompts, context windows, generated output, and logs. The problem is not that the agent is malicious. The problem is that the agent operates on files, and plaintext secrets are sitting in the same file tree as source code. That makes the file itself the disclosure mechanism.
Practical implication: Keep secrets out of any directory that AI coding agents can index or summarize.
Runtime injection and dynamic credentials as the end state
Runtime injection moves the secret from a static file into the moment of use, which removes the durable artifact that attackers and agents can reuse. Dynamic credentials go further by issuing short-lived values on demand, so even if something is observed, it expires quickly and limits blast radius. This is the direction that aligns machine access with modern identity governance: no standing secret, no durable file copy, and less dependence on developer memory. It also supports better auditability because the access event is tied to runtime issuance rather than local storage.
Practical implication: Design pipelines and workloads to receive short-lived credentials at runtime instead of reading static secrets from disk.
Threat narrative
Attacker objective: The attacker aims to collect reusable credentials from developer workspaces and use them to access code, infrastructure, or sensitive data.
- Entry occurs when a secret is placed in a .env file on a developer machine, shared workspace, or repository clone, making plaintext credentials available to any local process or tool with file access.
- Credential access follows when the file is committed, copied into chat, read by an AI coding agent, or harvested by malware that targets developer environments and CI/CD artefacts.
- Impact comes when the exposed secret is reused for repository access, database access, cloud access, or API calls, creating downstream compromise and audit sprawl.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
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 credential storage is no longer just a developer hygiene issue, it is a lifecycle failure. When a secret lives in a .env file, it is outside the normal controls that identity teams rely on for inventory, rotation, revocation, and audit. The practical conclusion is that credentials stored on disk should be treated as unmanaged NHIs, not as harmless configuration.
AI coding agents turn static file exposure into contextual disclosure. The governance assumption that a secret stays local because it sits in a developer workspace breaks when an agent reads project files automatically and reproduces the values in prompts, logs, or generated output. That means file-based secret storage now carries an exposure path that traditional secret scanning does not fully cover.
Ephemeral credential trust debt: this article surfaces the gap between how teams provision machine access and how modern development actually consumes it. Static secrets are still being used because they are easy, but their easy path is now the reason they spread across git, Slack, and AI tooling. Practitioners should read that as a signal to reduce standing credential populations, not merely to police file names.
Environment variables are not a vault, they are a softer landing zone. Moving from .env to process variables improves the situation, but it does not solve governed access because memory-backed secrets can still be inspected by local processes under the same user context. The stronger point is that identity governance has to move closer to issuance time, where access can be created, observed, and removed with less residue.
Runtime secret delivery is becoming the baseline control for NHI hygiene. A model that issues short-lived credentials at use time fits the direction of OWASP NHI and Zero Trust thinking better than static file storage does. The wider implication is that NHI programmes should measure success by how little durable secret material remains on disk, not by how many files are protected with convention.
From our research:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, showing that exposed credentials are already a business problem, not just a hygiene issue.
- For a wider view of the attack pattern, Emerald Whale breach shows how secret leakage in developer environments can cascade into broad repository compromise.
What this signals
Plaintext secret storage is becoming a governance debt item, not a developer preference. Teams that still rely on .env files are carrying an exposure model that breaks once project directories are scanned by automation, so the next programme step is to reduce the number of durable secret artefacts on disk and in chat. That is the practical boundary between configuration and credential management.
The strongest control shift is from file-based handling to issuance-based handling, where credentials are created for use and then disappear. That model aligns better with OWASP Non-Human Identity Top 10 thinking because the risk is no longer just disclosure, it is persistence and reuse.
Ephemeral credential trust debt: the operational debt created when teams keep static machine secrets because they are convenient. The reader takeaway is to inventory where AI tools, CI/CD jobs, and developer workflows can see those values, then remove the durable copies first before trying to optimise rotation.
For practitioners
- Classify .env contents by sensitivity Split non-sensitive configuration from real credentials, API keys, database passwords, and tokens. Keep only the former in simple files and move the latter into governed secret storage.
- Remove plaintext secrets from developer workspaces Prevent secrets from sitting in directories that AI coding agents, backup jobs, or shared tools can read automatically. If the file tree can be scanned, the secret is already too exposed.
- Adopt runtime injection for production access Inject short-lived secrets at execution time for applications, CI/CD jobs, and ephemeral workloads so the credential does not exist as a durable file on disk.
- Use secrets managers for lifecycle control Centralise issuance, rotation, audit, and revocation in a secrets manager so machine credentials can be governed as identities, not just stored as values.
- Stop sharing .env files over chat and email Replace ad hoc file sharing with a controlled access path, because the file itself becomes a long-lived copy of every secret it contains.
Key takeaways
- .env files fail as secret storage because they make credentials durable, readable, and easy to spread across developer workflows.
- AI coding agents amplify that weakness by automatically reading project files and exposing secrets through prompts, generated output, and logs.
- The durable fix is runtime secret delivery with short-lived credentials, not simply a new convention for storing plaintext values.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is centered on plaintext secret exposure in files and chat logs. |
| NHI-07 — Long-Lived Secrets | Static .env values persist far longer than the access they support. | |
| NHI-10 — Human Use of NHI | Developers handling secrets manually in files and chat is exactly the misuse pattern described. | |
| Recommendation — Eliminate plaintext secret storage and route credentials through governed secret delivery. Replace durable file-based credentials with short-lived secrets issued at runtime. Reduce manual handling of machine credentials and remove human-visible secret copies. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are central once secrets leave secrets managers. |
| Recommendation — Apply authenticator lifecycle controls so machine credentials can be rotated and revoked cleanly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article argues for governed access and runtime issuance instead of uncontrolled file access. |
| Recommendation — Tighten entitlement paths so only approved workloads can receive runtime secrets. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern is credential theft from developer environments and later reuse. |
| Recommendation — Map secret-leakage indicators to credential access and exfiltration behaviors in detection logic. | ||
Key terms
- Cleartext Secret Storage: The practice of storing passwords, API keys, or other credentials in readable form rather than protected by encryption, hashing, or secure secret management. If an attacker reaches the file, database, or application state, the secret can often be used immediately without further cracking.
- Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
- Dynamic credentials: Dynamic credentials are secrets issued on demand and allowed to expire automatically after a defined use window. They reduce exposure by limiting how long a credential can be reused, but they only work when applications and access policies can support short-lived authentication without manual exceptions.
- Integration Window Exposure: The period after an acquisition when systems remain separate but are already under the buyer’s responsibility. In that window, inherited identities, weak authentication, and inconsistent logging can stay live even though accountability has shifted, which makes the estate especially vulnerable to breach and regulatory scrutiny.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- A practical comparison of plain .env handling, encrypted file tools, and secrets managers for different development stages
- Examples of how runtime injection works across local development, CI/CD, containers, and ephemeral workloads
- Guidance on where environment variables still help and where they stop being a safe boundary
- Operational examples of keeping AI coding agents away from raw secret values while still supporting developer workflows
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
