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

At a glance

What this is: This article argues that python-dotenv is still fine for prototypes, but .env files fail as a team-scale secret governance model because they are plaintext, hard to rotate, and leave no audit trail.

Why it matters: IAM and NHI teams should treat shared .env files as an immature secret distribution pattern, because the control problem shifts from developer convenience to lifecycle, access, and accountability once multiple identities touch the same credentials.

Context

python-dotenv is a convenience layer for loading plaintext KEY=value files into environment variables at runtime. It works when one developer controls the file, but the security model changes as soon as secrets are shared across people, environments, CI jobs, or production systems.

The governance gap is not the library itself. The gap is that .env files turn secret handling into file distribution, which creates leak exposure, no reliable audit trail, and manual rotation work that does not scale across NHI governance.

Key questions

Q: When does python-dotenv stop being a safe choice for teams?

A: It stops being a good fit when more than one person, environment, or deployment path depends on the same secrets. At that point the problem is no longer local convenience. It becomes secret ownership, auditability, and revocation, which a plaintext .env file cannot enforce.

Q: Why do shared .env files create more risk than they remove?

A: They increase the number of secret copies without adding controls around access, rotation, or logging. That makes leaked credentials easier to miss, slower to revoke, and harder to attribute. The risk is not just exposure, but the inability to prove where the secret still exists.

Q: How should teams replace .env files in production workflows?

A: Use a centrally managed secrets store that injects values at runtime and scopes access by identity and environment. That preserves the app’s existing environment-variable pattern while removing file sharing, reducing drift, and making rotation and audit trails practical.

Q: What is the difference between local environment variables and governed secrets management?

A: Local environment variables are a runtime convenience, while governed secrets management adds identity-based access, audit logging, and controlled rotation. One tells an app what value to read. The other controls who can supply that value, when, and from which environment.

Technical breakdown

Why .env files are not a governed secret store

A .env file is just plaintext configuration copied into a project folder, then read into process memory at startup. That makes it convenient for local development, but it is not a control plane for secrets. There is no access policy attached to the file itself, no built-in rotation logic, and no durable record of who accessed which value. The result is that the credential lifecycle exists outside the application and outside any identity governance process. In practice, the file behaves like a distribution artifact, not a security boundary.

Practical implication: treat .env files as development convenience only, not as the source of truth for shared or production credentials.

Where plaintext secrets create operational and NHI risk

Once a credential is copied into multiple .env files, the secret acquires a larger attack surface than the application. It can leak through commits, shared drives, chat, or CI artifacts, and each copy becomes a separate revocation problem. That is classic NHI sprawl: the same API key or database password is reused across identities and environments without governed ownership. Because the file has no audit trail, organisations cannot reliably prove who had access, when it changed, or whether every instance was updated after rotation.

Practical implication: inventory every place a .env value is copied, then remove any workflow that depends on manual synchronisation.

Why environment separation by naming convention fails at scale

Naming files .env.development and .env.production creates an illusion of separation, but the boundary is procedural rather than enforced. The application still depends on whichever file a developer or script chooses to load, which means a typo, wrong symlink, or copied command can point a non-production workflow at production credentials. This is a governance failure, not a framework failure. Access, environment targeting, and credential scope should be explicit controls, not conventions embedded in filenames.

Practical implication: replace filename-based environment separation with centrally managed secrets and explicit environment scoping.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Plaintext secret files are a convenience mechanism, not a governance model: .env files work only while the secret set remains small, local, and manually curated. Once a credential is copied to more than one identity or environment, the control problem becomes lifecycle governance, not application configuration. Practitioners should stop treating file-based loading as a substitute for identity-controlled secret distribution.

Secret drift is the real scaling failure: the same API key or database password can exist in developer machines, CI jobs, and deployment scripts at the same time. That breaks ownership, revocation, and auditability because no single system can prove where the current copy lives. The implication is that secret governance has to move to a central authority before the number of copies outgrows human tracking.

Environment-by-filename creates identity ambiguity: the operating system hands the process whatever file the operator selected, which means the boundary is procedural rather than enforced. That assumption works for a prototype and fails for shared teams because the wrong file can be loaded quietly. Practitioners should treat environment targeting as an access-control decision, not a naming convention.

Leaked NHI credentials are not an edge case: service accounts and API keys are now common breach material, and plaintext distribution multiplies their exposure window. A .env pattern gives no rotation evidence, no access history, and no revocation workflow when the secret is compromised. The practitioner conclusion is that governed lifecycle control matters more than local developer convenience.

Named concept: credential-by-file sprawl: when the same secret is distributed through project files instead of an identity-aware secrets system, the organisation loses track of where it exists and who can use it. That pattern is operationally brittle even before a breach, and it becomes a governance failure the moment multiple environments depend on it.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Buyer's Guide

What this signals

Credential-by-file sprawl: the immediate issue is not whether Python can load .env files, but whether the organisation can still answer where a shared secret lives after it has been copied into multiple hands and environments. That question has to be answered by governance, not convention.

Secret distribution needs to move from file copying to identity-scoped access before the same API key or database password becomes unrecoverable across developer machines, CI jobs, and production hosts.

For practitioners

• Audit every .env copy in the delivery chain Map where secrets exist on developer laptops, in CI jobs, in deployment scripts, and in production hosts. Remove any workflow that depends on a manually copied file as the source of truth.
• Move shared credentials into a central secrets store Use an access-controlled secrets manager for any credential that is shared across people, environments, or runtime systems. Grant access to identities, not to files.
• Replace filename-based environment targeting Stop relying on .env.development and .env.production naming as the control boundary. Make environment selection explicit through managed variables, scoped permissions, and deployment policy.
• Rotate secrets that ever touched shared files Assume any secret that has been emailed, posted, or copied into a shared file has an expanded exposure surface. Reissue it and remove obsolete copies rather than trying to track every replica.
• Log secret access and revocation events Require audit records for reads, changes, and revocations so teams can answer who touched a credential and when. Without that evidence, incident response becomes guesswork.

Key takeaways

• python-dotenv is acceptable for individual prototypes, but plaintext .env files do not provide the access control or lifecycle governance that team environments require.
• The main failure mode is not syntax or framework compatibility. It is secret sprawl, because the same credential can be copied, shared, and forgotten across multiple systems.
• Production secret handling needs identity-based access, auditability, and rotation at the storage layer, not file naming conventions and manual copy discipline.

Key terms

• Environment Variable: An environment variable is a value provided to a program at runtime to control configuration without hardcoding it into source code. In identity and secrets workflows, these values often carry credentials or connection details, so the delivery method must preserve confidentiality and avoid persistent plaintext exposure.
• Env File: A .env file is a local text file used to store environment variables for an application, including API keys, database URLs, and access tokens. It simplifies developer workflows, but plaintext storage creates leakage risk if the file is copied, committed, synced, or left unprotected on disk.
• 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.
• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.

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 programme, it is worth exploring.