AI agent credentials belong in a vault, not a .env file on someone's laptop

Agents need keys to do useful work. The default developer habit is a .env file on disk. The default attacker habit is asking servers for /.env and getting database passwords back.

In February 2026, researchers at Mysterium VPN reported 12,088,677 IP addresses serving publicly accessible .env-style files. No exploit chain required. Just a URL and a misconfigured web root.

That number is not abstract for agent deployments. The moment you wire an agent to Gmail, HubSpot, or Stripe, you are multiplying how often those secrets get read, copied into context, and stored in new places.

What the Mysterium scan actually found

Direct answer: this is a configuration hygiene crisis, not a novel zero-day. Teams deploy apps with environment files web-accessible, often because someone copied a tutorial layout or forgot a deny rule on hidden files.

Reported exposure included:

• Database usernames and passwords
• JWT signing secrets
• Cloud provider API keys
• Third-party SaaS tokens

Geography was broad. The United States led with roughly 2.8 million exposed IPs (~23% of the total). Japan, Germany, India, France, and the UK each had hundreds of thousands more.

Further reading:

• Security Affairs summary
• SC Media brief

Why local .env fails the team-agent test

Solo coding agents (Cursor, Claude Code, local OpenClaw) expect full access to your environment. That is the product design. You are the admin.

Enterprise deployment adds requirements solo setups rarely meet:

1. Separation of duties. The model should not hold raw tokens in context if you can avoid it.
2. Rotation without redeploying fifty laptops. Central vault, not fifty .env copies.
3. Audit. "Who searched this mailbox?" needs an integration log, not a grep through chat history.
4. Offboarding. Disable access in one place when someone leaves.
5. Blast radius. Scope tokens to one integration, one mailbox, one CRM role.

Plaintext .env on a developer machine fails all five the moment the agent browses the web or reads repo files. Prompt injection and accidental logging are not theoretical. They are Tuesday.

The vault pattern I ask vendors to show

A defensible team-agent stack looks like this:

[Agent sandbox] --scoped tool call--> [Integration layer] --token--> [Gmail / CRM / Slack API]
                                              ^
                                              |
                                    [Encrypted secrets vault]

Concrete properties:

• Sandbox execution. Agent code and tool runs happen in a restricted environment, not on an employee's Downloads folder.
• Vault storage. OAuth refresh tokens and API keys live encrypted; not in the agent's default file read path.
• Brokered tool calls. "Search Gmail for PO-4412" hits your integration service, which attaches the token server-side.
• Human approval on writes. Sends, deletes, refunds, and external posts require explicit confirmation in v1.
• Classifier on untrusted input. Email bodies, web pages, and PDFs pass through injection checks before high-privilege tools unlock.

Anthropic's enterprise direction (managed agents, MCP gateways, scoped tool surfaces) moves the same direction: the harness intercepts tool calls; the model does not get a bash shell and a .env with god-mode keys.

Useful references:

• Anthropic agents and tools overview
• Model Context Protocol
• OpenAI agents guide

Prompt injection turns secrets into the payload

Even perfect vault architecture fails if the agent reads a token into its context window and an attacker steers the next step.

Promptfoo's OpenClaw workplace lab showed a browse-capable local agent visiting a malicious page, reading local documents, aggregating secrets into a new file, and sending unauthorized messages through loopback sinks. The issue was not "the model is dumb." The issue was one trust boundary for browsing, file access, and outbound action.

That is why I treat these as paired requirements:

If you are evaluating a team agent product, ask where tokens live and what happens when the agent fetches an untrusted URL mid-task. A pretty vault demo means nothing if browsing and Gmail write share one approval path.

A practical migration path for SMEs

You do not need a six-month IAM project before your first agent ships. You do need to stop treating .env as the long-term plan.

Week 1: inventory

• List every token your agent touches today
• Mark read vs write vs delete
• Find any .env in git history or public deploy roots

Week 2: stop the bleeding

• Deny web access to dotfiles at CDN and origin
• Rotate anything exposed or committed
• Remove production keys from developer laptops where possible

Week 3–6: one brokered integration

• Pick the highest-value workflow (lead inbox, booking calendar)
• Route that integration through a vault or managed OAuth
• Turn on audit logs before you widen scopes

After pilot

• Add human approval on sends and deletes
• Document which guardrails live outside the summarizable chat log (see my post on solo agents at enterprise scale)

The uncomfortable takeaway

Twelve million exposed .env files is a reminder that the industry still treats secrets as config afterthoughts. Agents amplify that laziness because they use secrets constantly and copy context aggressively.

Local plaintext tokens were already a bad default for shared systems. They are an unacceptable default for autonomous agents with inbox and CRM access.

If you are wiring agents into GoHighLevel, WhatsApp, voice, or custom ops stacks and want the first integration vault-backed instead of "paste your API key here," book a free discovery call. Bring your integration list and we will map read vs write vs never-automate before anything touches production data.