DEV Community: Klavex

Stop AI coding agents from reading your .env secrets

Klavex — Thu, 11 Jun 2026 01:43:38 +0000

I was working in Claude Code when it opened my .env to "understand the configuration" — and then, helpfully, suggested I rotate the keys, since they were now exposed. The thing that exposed them was the agent reading them.

That's the moment the problem clicked. So here's what's actually wrong with .env in an agent-heavy workflow, and the approach I landed on.

The problem: your `.env` is an agent buffet

The same .env file that lets your dev server boot also feeds every tool in your editor. Cursor, Claude Code, Copilot, and any MCP server you've wired up can cat it whenever they want. There's no permission boundary — if it's on disk and your editor can read your project, the agent can read your keys.

Two things make this worse than the old "don't commit your .env" advice:

You can't scope an agent down. It's all-or-nothing file access. The agent that needs to read src/ also gets AWS_SECRET_ACCESS_KEY.
It leaks sideways. The same file gets copy-pasted into Slack to onboard a teammate, screenshared, and synced into who-knows-what.

The root issue is simple: it's a plaintext file sitting on disk, and anything running in your editor can read a file on disk.

The fix: don't keep a `.env` at all

The approach that actually removes the risk is to stop having the file. Instead of reading secrets from disk, inject them into the process at runtime — only for as long as the command runs.

That's what I built Klavex to do. Setup is one command, and it imports your existing .env so there's nothing to rewrite:

pip install klavex

klavex init                 # detects your repo, imports your existing .env, pins the project
klavex run -- npm start     # secrets injected into this process at runtime — nothing on disk

After klavex init, you delete the local .env. From then on, klavex run -- <your command> pulls the secrets from an encrypted vault straight into that one child process. They're never written to a file, so there's nothing for an agent to open.

Scoping agents instead of trusting them

The part I care about most: when you do want an agent or a CI job to have keys, you don't hand it the whole vault. You mint it a read-only token scoped to specific environments:

KLAVEX_TOKEN=<scoped-token> klavex run -e <env-id> -- ./run-tests.sh

Grant a token Dev, and Production is simply unreachable — the API refuses to decrypt anything outside the token's allowlist. The token can read its scoped secrets but can't create, change, or delete anything. So an agent gets exactly the keys you chose, and prod stays invisible.

Why not Doppler or Infisical?

Fair question — they're genuinely good tools, and they also do runtime injection. The honest difference is scope and pricing, not security:

They're full platforms: dozens of integrations, dynamic secrets, rotation, PKI, SSH, audit tiers. A lot to stand up and configure.
They're priced per seat, which climbs fast for a small team.

If what you want is narrow — "get my secrets off disk and scope what my agents can read" — that's a whole platform to adopt for one job. Klavex's bet is the opposite: it does that one thing, you're set up in one command, AI agents are free and unlimited, and team pricing is flat (it never scales per seat). The day you need dynamic secrets or PKI, Doppler and Infisical are exactly where you should go.

What this does not do

To be precise about the threat model, because it matters: this is not a sandbox. Anything running as your user can still read the process environment at runtime — including, in principle, a sufficiently determined tool. What Klavex removes is the plaintext file that sits on disk forever, readable at any time, by anything. That's the realistic, high-frequency exposure, and it's the one worth closing.

It's live, free for solo use: klavex.dev. If you work with coding agents daily, I'd genuinely like to know whether this matches a problem you've hit — or whether I'm the only one who kept watching Claude read my keys.

How to stop your coding agent from reading your .env secrets

Klavex — Wed, 03 Jun 2026 01:46:49 +0000

Open Cursor, Claude Code, or any MCP-enabled agent in your project and ask it to "fix the failing test." To do that, it reads files. Lots of them. And nothing stops it from reading this one:

.env

It doesn't matter that .env is in your .gitignore. .gitignore keeps it out of git — it does nothing about a read_file('.env') tool call dropping STRIPE_SECRET_KEY=sk_live_... straight into a model's context window. The same file that boots your dev server is sitting in plaintext, on disk, readable by every agent you've invited into your editor.

I stared at that for a while and realized the fix isn't "scope the agent down." The fix is: don't have a plaintext secrets file at all.

The idea: inject secrets at runtime, never write them to disk

Instead of a .env, you wrap your command:

klavex init             # pick your project + environment once
klavex run -- npm start # that's it — no flags after this

The CLI pulls that environment's variables from an encrypted vault and injects them into the child process only. Your shell never sees them. Nothing is written to disk. So when the agent goes looking:

$ cat .env
cat: .env: No such file or directory

There's nothing to read, because the keys only ever existed inside the npm start process. That's the whole pitch in one screenshot.

It also quietly fixes the boring team problems: no more "ping six people on Slack for the right keys," no more stale .env after someone rotates a credential — rotate it once, every machine picks it up on the next klavex run.

Getting started

pip install klavex      # Python 3.10+, macOS/Linux/WSL
klavex login            # opens the browser once, token goes in your OS keychain
klavex init 
klavex run -- npm start

That's the entire surface area. I deliberately kept it small — most secrets tools turn into a platform you have to administer. This is three commands.

Letting an agent have some secrets — on purpose

"No .env" handles accidental leakage. But sometimes you genuinely want an agent or a CI runner to use real secrets. For that you mint it its own token, scoped to exactly the environments you pick:

# In the dashboard: New agent → name it → tick the environments it may read → copy the token (shown once).
# On the agent / CI machine — no browser, no interactive login:
export KLAVEX_TOKEN=kx_agent_xxxxxxxx
klavex run -e env_dev_abc123 -- npm test

That token is read-only (it can read its scoped secrets, but can't create, change, or delete anything) and the backend refuses to decrypt any environment it wasn't granted. Grant it dev, and a request for prod comes back 403. Every fetch lands in an audit log, and revoking the token kills it everywhere.

What this does not do (because someone will ask)

Let me be honest about the boundary, since this is a security tool and overclaiming is how you lose a dev audience:

Klavex is not a sandbox. Anything that can execute arbitrary commands as you can still reach the secrets at runtime — it can read /proc/<pid>/environ, or just wrap klavex run itself. What this removes is the persistent, plaintext-on-disk footprint: the .env that lives in your repo for the project's whole life and gets caught by a casual file read, an accidental git add -f, a broad "scan the repo" agent pass, a backup, or a screen-share. It shrinks the exposure window from "always, on disk" to "only inside the one process you launched." That's a real, meaningful reduction — not airtight magic.

Other honest notes: the CLI isn't open source yet, and the encryption is standard envelope encryption (a per-secret data key wrapped by a KMS master key, with an encryption context bound to {team, project} so a stolen token can't cross-decrypt another tenant's data) — nothing I'm claiming is novel crypto.

Try it / tell me I'm wrong

It's early (v0.1.x). Solo is free forever.

pip install klavex

Docs: https://klavex.dev/docs.html
App: https://app.klavex.dev

I'd genuinely like feedback on two things:

Is klavex run in front of every command worth it, or is that friction too high?
Is "your agent can read your .env" a real problem you've felt — or am I solving something nobody cares about?
Should i also provide a typescript CLI?

Rip it apart in the comments.