Why Plaintext .env Files Are Failing OpenClaw

OpenClaw broke into the security headlines in early 2026 the same way every viral developer tool eventually does: a researcher ran a shodan-style scan and found that a lot of deployments were exposing credentials in ways their operators didn't expect.

The numbers, as reported by independent security firms during early 2026:

• Over 40,000 publicly accessible OpenClaw instances detected on the open internet
• Plaintext API keys, OAuth tokens, and cloud credentials sitting in config files
• In several documented cases, attackers used exposed credentials to establish persistent access to internal Salesforce, GitHub, and Slack workspaces

The reporting that followed was tonally familiar — "AI agents are insecure" — but the underlying technical story is more specific. OpenClaw isn't insecure. The .env file is.

This post is about why the .env file primitive, which has carried the JavaScript/Python/Ruby ecosystems for fifteen years, is the wrong shape for autonomous agents — and what the right shape looks like.

What .env was designed for

Twelve-factor apps published the .env idea in 2011. The premise is sound: keep configuration out of code, inject it at runtime via environment variables, and have a single canonical place to store the dev-time defaults.

For a web app deployed to a single host, .env works. The deployment runs as one process, the config is read once at boot, and the file lives on a controlled server.

But .env carries some implicit assumptions that don't survive the move to autonomous agents:

1. One process, one host. Not "an AI agent the operator has scattered across cloud VMs, Render services, container deployments, and a teammate's laptop."
2. Config that doesn't change at runtime. OpenClaw agents legitimately add new tools, new credentials, new integrations during their lifecycle.
3. A bounded threat model. The .env file is sensitive, you protect it with file permissions, you don't commit it to git. Done.

The autonomous-agent threat model is different. The .env file is no longer the only attack surface — the agent itself is. Prompt injection, model jailbreaks, and tool-use exploits can convince an agent to read its own credentials and exfiltrate them. The "file permissions" defence doesn't apply when the legitimate process holding the file can be tricked into leaking its contents.

Why OpenClaw specifically lit this up

A few things compounded for OpenClaw in early 2026:

Easy deploy paths

OpenClaw runs on commodity infrastructure. There's a Docker image, a one-line Render template, a Fly.io recipe. People who would never have stood up a long-running service in 2020 can run an OpenClaw agent in 2026.

That's mostly good. It means the credential discipline of "we have a platform team that runs services" doesn't apply, because anyone might be running one.

IDENTITY.md as the standard config

OpenClaw's IDENTITY.md template is genuinely useful for declaring an agent's persona. But the implicit pattern that grew up around it — "put your credentials next to your IDENTITY.md, in a file the agent loads at startup" — extended .env's bad habits to a new context.

That file then ends up:

• Committed to a public GitHub repo (the most common cause of leaks)
• Uploaded as part of a Docker layer (the next most common)
• Pasted into a Render env var that's visible to anyone with read access to the service

High-value credentials

OpenClaw agents tend to authenticate to high-value services: GitHub, Slack, email, internal APIs, payment providers. The blast radius of a leaked credential is correspondingly large. A leaked Postgres password is bad. A leaked GitHub PAT with repo:write scope is worse, because the attacker can quietly add a backdoor to your build pipeline.

Long-running

A web app reads its .env on boot and the file becomes uninteresting. An OpenClaw agent runs continuously, calling APIs over and over with the same credentials. That makes the credential a much more attractive target — get it once, replay it forever, until someone notices.

What the right shape looks like

The fix isn't "encrypt the .env file" or "use a different file format." It's a different primitive entirely.

Short-lived sessions, not long-lived bearers

The agent never holds a long-lived API key. It holds an agent token that exchanges into a 30-minute session at startup (and refreshes itself transparently). If the session token leaks in transit, it expires before it's useful.

Server-side allowlists

The agent doesn't decide what secrets it can read. The server does, on every request, against an explicit list. If the agent's code asks for a credential it isn't allowlisted for, the read fails — regardless of whether the agent itself has been compromised.

Per-agent identity

Each OpenClaw deployment has a typed secr_agent_* identity, scoped to one project and one environment, with an expiry, an owner, and an audit trail tied to its specific ID. Not a generic API key the agent shares with three other things.

Tool-level governance

For destructive actions, no single credential is sufficient. The agent token gets the call to the API; the MCP approval queue gates the action. Both have to grant for a delete_repo to actually delete.

Observability the agent can't avoid

Every secret read, every tool call, every approval decision goes into an immutable log. Not because it's nice to have a dashboard — because when the post-mortem starts, you need to be able to answer "what did this agent do between 14:00 and 15:00 on Tuesday."

The migration path

This isn't a green-field problem. There are real OpenClaw deployments running today on plaintext .env files. Migration looks like this:

1. Inventory what's running. Shadow-agent detection (covered in the previous post) gives you a list of every OpenClaw user-agent observed against your secret store. That's your starting point.

2. Replace the .env file with a broker call. This is the getting-started tutorial. One package install, one method call. The agent code that reads process.env.SLACK_TOKEN doesn't change — only the part that populates process.env does.

3. Set an allowlist. Look at the .env file the agent was using. Those keys go in --allowlist. Anything else doesn't.

4. Wrap the destructive tools. Mark delete_repo, refund, send_email, etc. as approval-required. The first time the agent hits one, it'll block — and that's the audit you've been missing.

5. Add expiry and ownership. --expires 90d, --owner you@team.com. Rotation forces a quarterly conversation; ownership ensures someone is on the hook.

6. Run the posture checklist. It surfaces anything you missed.

The whole thing is a single afternoon for one agent, a week for an org-wide migration. Compared to the cost of being one of the 40,000 in the next scan report, the math isn't close.

The closing point

The .env file was the right primitive for a different problem. It's the wrong primitive for an autonomous agent that runs for weeks, calls high-value APIs, and might be tricked into reading its own configuration aloud.

The frameworks (OpenClaw included) are getting better at making the right thing easy. But the operator decisions matter most: what shape of credential the agent holds, what scope it has, who can approve its actions, and what audit trail exists when something goes wrong.

If your OpenClaw deployment still reads credentials from a file on disk in 2026, the news cycle is going to keep finding deployments like yours.

---

Read next:

• Getting started with OpenClaw and secr — the migration tutorial
• The OpenClaw NHI posture checklist — what good looks like
• Securing OpenClaw Agents — what NHI means in practice — the conceptual framing

External references:

• Industry reporting on the OpenClaw exposure scans is summarised in security research from Astrix, Permiso, and Identity Automation. Specific incident counts vary by methodology; the consistent throughline is that the .env file pattern is the common cause — not OpenClaw itself.

---

The OpenClaw plugin (@secr/openclaw-plugin) is on ClawHub and free for 1 agent. Install reference → · The /agents pillar · Approve tool calls from Telegram · Approval webhooks