Here's an uncomfortable exercise: open a project you've pointed an AI coding agent at, and check whether there's a .env in it. If there is, your agent can read it — every key, every value, production included if that's what you had checked out. The file gets swept into context the same way any file does, and from there it can end up in transcripts, logs, or a tool call you didn't review.
Agents genuinely need configuration answers. "What's the Stripe key called?" "Is there a REDIS_URL in staging?" "Which vars does this service expect?" The problem isn't the questions — it's that a plaintext file on disk answers every question, including the ones you'd never approve.
The pattern: secrets behind tools, not in files#
The fix is the same one we apply to every other dangerous capability we give agents: put it behind an API with scope, auth, and an audit trail — which is exactly what MCP (Model Context Protocol) is for.
Envpilot runs a remote MCP server at https://www.envpilot.dev/api/mcp. Point Claude Code at it once:
claude mcp add --transport http envpilot https://www.envpilot.dev/api/mcp \
--header "Authorization: Bearer envpk_your_key_here"Cursor, Claude Desktop, or any MCP client work the same way — it's a standard Streamable HTTP server with a bearer token (client setup docs).
Now the agent can call five tools — envpilot_list_projects, envpilot_get_variables, envpilot_get_variable, envpilot_list_accounts, envpilot_search — and nothing else. Every one of them is read-only by design. There is no write tool, no delete tool, no "update this variable" tool. An agent connected to your secrets manager should be able to answer questions, not mutate your production config, and we'd rather enforce that server-side than trust a system prompt.
Why this beats the .env on disk#
Scope. The bearer token is an API key you create with explicit boundaries: which projects, which environments, which resource types. A key scoped to backend-api + development makes every other project invisible — a tool call outside the scope behaves as if the project doesn't exist. Your agent can see dev config without production ever being reachable, no matter what the model decides to try.
Metadata without values. envpilot_get_variables takes a metadata_only flag. Most agent questions are "what variables exist and what are they for" — answerable from keys and descriptions with zero secret values in the response. The agent only pulls actual values when the task genuinely requires one.
Audit. Every value-returning call is logged: which key, which variable, when, from where. When you wonder "did the agent read the Stripe secret during that refactor?", that's a lookup, not a guess. A .env file answers that question with silence.
Revocation. Done with the experiment? Revoke the key. One click, that access path is dead. Compare that to a value that entered an agent transcript — you can't revoke a leak, only rotate everything it touched.
Rate limits. Value reads draw from the same per-key rate buckets as our REST API, so a misbehaving agent loop gets throttled instead of bulk-exporting your config.
And for actually running the app
The MCP server is for the agent's questions. When the agent (or you) needs to start the dev server, the values should go into the process — not into a file the agent can re-read later:
envpilot run -- npm run devenvpilot run injects variables into the process environment at spawn time. Nothing is written to disk, so there's no .env for the next context sweep to pick up, and the secrets vanish when the process exits.
Together the two halves make a clean policy you can state in one sentence: the agent may ask scoped, audited, read-only questions; the runtime gets values injected in memory; no plaintext secrets exist on disk at all.
Setup notes#
The MCP server is part of Envpilot's Pro tier (pricing is flat per organization, not per seat), and keys are created in Organization Settings → API Keys with the scope picker. The whole platform is open source (MIT) — including the MCP server's authorization path, which shares one enforcement core with the REST API and GitHub Action, so you can audit exactly what an agent can and cannot reach before you connect one.
If you try it with Claude Code or Cursor and something's rough, tell me directly — agent workflows are where the next round of tooling is headed, and real usage reports shape it.