Python dotenv still fits prototypes, not team-scale secret governance

At a glance

What this is: This is a practical analysis of why python-dotenv remains fine for small Python projects but breaks down as a secrets governance model for teams, production, and multi-environment operations.

Why it matters: IAM and NHI teams need to treat .env files as a convenience layer, not a control boundary, because they create ungoverned secret sprawl, weak auditability, and brittle rotation workflows.

By the numbers:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Infisical's analysis of why python-dotenv stops scaling for shared secret governance

Context

Python dotenv is a convenience pattern for loading secrets from a .env file into environment variables, but it is not a governance control. The primary issue is not syntax or framework support, it is that plaintext credentials lose boundary, ownership, and auditability the moment they move into a shared project file.

For NHI governance, the failure point appears when a credential is shared across developers, CI jobs, and production systems with no lifecycle control. At that point, the question is no longer whether python-dotenv works, but whether the organisation has a defensible model for secret exposure, rotation, and offboarding.

That makes this topic relevant to IAM, secrets management, and workload identity even in simple Python stacks. The article's basic position is typical: the tooling is fine for a prototype, but the operating model stops being safe as soon as access is shared or productionized.

Key questions

Q: How should security teams handle .env files in team-based Python projects?

A: Use .env files only as a local development convenience, not as a shared secret store. In team environments, move secrets into a centrally managed system that can log access, enforce identity-bound retrieval, and support revocation. The goal is to remove plaintext credentials from shared files and make secret ownership auditable.

Q: Why do .env files create problems for secret rotation?

A: Because one secret is usually copied into many places, and each copy must be changed separately. That makes rotation brittle, slow, and easy to miss. If even one old copy survives in a developer shell, CI job, or deployment file, the credential can remain usable after the supposed fix.

Q: What do teams get wrong about using os.environ for secrets?

A: They assume the runtime lookup is the control, when it is only the retrieval method. os.environ does not provide ownership, audit logging, or revocation. Those controls must exist in the system that supplies the values, otherwise the application is still relying on unmanaged secret distribution.

Q: What should organisations do instead of sharing .env files?

A: Use a secrets manager or workload identity approach that delivers secrets to the process at runtime, tied to a specific human, server, or pipeline identity. That gives you control over access, rotation, and logging, while preserving the same application behaviour inside Python.

Technical breakdown

Why .env files become an NHI control problem

A .env file is a plaintext secret store disguised as convenience. It works because the application reads environment variables at runtime, but that does not change the fact that the credential now exists in a file, in a repository, or on a shared machine. In NHI terms, the file becomes a portable copy of the identity itself, which means access is governed by file distribution rather than by identity controls. That creates exposure in source control, local laptops, build jobs, and copied deployment artefacts.

Practical implication: treat .env as development scaffolding only and map every secret inside it to an accountable identity and storage boundary.

Why rotation and audit break in shared Python configurations

Manual secret management fails because every copy of the credential must be updated independently. If a password or API key appears in multiple .env files, rotation is only complete when every developer machine, CI job, and server has been updated. That also means the credential's lifecycle becomes invisible unless another system logs reads, updates, and revocation. Without those controls, teams cannot prove who had access, when access changed, or whether the compromised value is still live.

Practical implication: centralise rotation and logging so the same secret is never managed as multiple unsynchronised copies.

How secrets managers change the runtime trust model

A secrets manager replaces static distribution with controlled retrieval at execution time. The application still reads environment variables, but the value is injected from a central store tied to a specific identity such as a developer, server, or pipeline. That shifts trust from the file to the policy layer, which is the right architecture for team-scale NHI governance. It also supports short-lived or dynamically generated credentials, which are structurally different from static .env values because they narrow the exposure window.

Practical implication: move Python workloads to centrally managed secret retrieval so access is identity-bound, auditable, and revocable.

NHI Mgmt Group analysis

.env files are a secret distribution mechanism, not an identity governance mechanism. The article is correct that python-dotenv solves local friction, but it also normalises plaintext secret sprawl across repositories, laptops, and shared deployment paths. That is an NHI problem because the credential's reach is now determined by file copying rather than policy, ownership, or lifecycle state. Teams should stop treating .env usage as a configuration preference and recognise it as a governance decision.

Secret rotation fails when one credential exists in many unmanaged copies. The breaking point is not the library, it is the assumption that a secret can be updated manually everywhere it lives. Once a key is embedded in multiple .env files, rotation becomes a coordination problem with no reliable completion signal. The implication is that the organisation has no single revocation event, only a best-effort cleanup exercise.

Ephemeral credential trust debt: Python teams often adopt .env files as temporary scaffolding and then leave them in place long after the environment becomes shared or production-grade. That creates trust debt because the operating model depends on temporary convenience behaving like a permanent control. The result is a false sense of separation between development and production that audit and security teams cannot verify.

Access to secrets must be bound to identity, not file possession. The decisive shift is from whoever has the file to whichever human, server, or pipeline is authorised to retrieve the value at runtime. That is why NHI governance, secrets management, and workload identity converge in mature Python programmes. Practitioners should design around controlled retrieval, not shared secret files.

Python teams need lifecycle thinking, not just better config loading. The relevant question is not whether os.environ still works. It is whether the organisation can offboard a secret, revoke a compromised value, and prove that old copies are gone. If it cannot, the application is functioning inside an unmanaged NHI lifecycle.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• For deeper context on lifecycle governance and rotation, see Ultimate Guide to NHIs , Static vs Dynamic Secrets and the Guide to the Secret Sprawl Challenge.

What this signals

Ephemeral credential trust debt: once a Python team accepts .env files as the default, the organisation accumulates unmanaged secret copies faster than it can account for them. That creates a governance gap that is invisible in small projects but material in any environment with multiple developers, CI, or production boundaries.

The practical signal is simple. If a secret can be copied, emailed, pasted into chat, or left in a repo without an expiry mechanism, the programme is operating outside a modern NHI lifecycle. Teams should move their focus from configuration convenience to revocation, audit, and controlled retrieval.

This is where shared secret files intersect with broader identity controls such as OWASP Non-Human Identity Top 10. A small development shortcut becomes a structural exposure once the same credential is used by developers, pipelines, and live services.

For practitioners

• Inventory every .env file and secret copy Map where each credential appears across local machines, repositories, CI jobs, and deployment artefacts. Treat each copy as a separate exposure point until it is replaced with centrally managed retrieval.
• Move shared environments to controlled secret retrieval Replace team-shared .env files with a secrets manager or workload identity flow that injects secrets at runtime. Keep application reads on os.environ, but remove file-based secret ownership from the workflow.
• Separate prototype convenience from production governance Allow .env usage only in isolated development or single-user contexts where the blast radius is small. Require a production-ready path for any service with multiple developers, multiple environments, or external access.
• Test rotation completion, not just rotation start Validate that a revoked credential is removed from every place it was copied, including shells, pipelines, and config artefacts. A rotation is not complete until the old secret no longer authenticates anywhere.

Key takeaways

• python-dotenv is convenient, but .env files are not a governance boundary once secrets are shared across teams and environments.
• The main failure mode is unmanaged secret sprawl, where rotation, audit, and revocation become manual and unreliable.
• Teams should move Python workloads toward identity-bound secret retrieval so credentials are controlled at runtime, not copied into files.

Key terms

• Dotenv File: A dotenv file is a plaintext configuration file that stores key value pairs for loading into a process environment. In identity terms, it is a convenience mechanism, not a security control, because the secrets remain copyable, shareable, and difficult to govern once they leave the local machine.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.
• Environment Separation: The practice of keeping development, staging, and production access distinct so a machine identity cannot discover or use higher-risk tools by default. For AI agents, environment separation is a practical boundary that prevents a single catalog from flattening risk across systems.

What's in the full article

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

• Side-by-side Python examples for os.environ, python-dotenv, pydantic-settings, and Infisical runtime injection
• Framework-specific notes for Django, Flask, and FastAPI configuration flows
• CLI and SDK usage patterns for importing .env files and fetching runtime secrets
• Practical migration detail for moving from local files to centrally managed secrets without rewriting application logic

👉 The full Infisical post covers Python configuration patterns, migration details, and runtime secret injection 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 building or maturing an IAM or secrets management programme, it is worth exploring.