v0.19.0 · 15 backends · MCP-ready · 779 live-backend assertions

Agents use secrets.
Models never see.

SecretEnv stands between your AI coding agents and your real secrets. They wire up config and run code against live backends, while every value stays invisible to the model.

Get started Read the docs $ brew install secretenv
$ codex "add stripe billing to checkout" agent works · SecretEnv handles the secrets
What the agent sees
What's really there
VALUES STOP HERE
one prompt · real backends · the model never sees a value through MCP, logs, or traces
v0.19.0 · 15 backends · 779 live-backend assertions

One registry.
Every repo. Every backend.

Multi-backend secrets orchestration via an alias registry that lives in your own backend. No SaaS. No re-encryption. No lock-in. No .env files. Migrate from one backend to another without touching a single repo.

Get started Read the docs $ brew install secretenv
~/projects/checkout-svc · secretenv run
--registry dev
resolution flow
resolved · fetched in parallel · injected into child process · gone on exit
The problem

Every existing tool assumes it is your only backend.

Your org uses AWS SSM for infra credentials, 1Password for team secrets, and Vault for service tokens. Every developer assembles a slightly different .env from manual fetches. Onboarding takes a day. Offboarding is a checklist nobody fully trusts.

Three backends. One .env per developer. Drift everywhere.

Each repo cobbles its own glue. Paths leak topology. Migration means PRs across every service.

checkout-svc
STRIPE_KEY=op://payments/stripe/api_key
1Password
orders-api
DB_URL=aws ssm get-parameter --name /prod/db/url
AWS SSM
notifier
DD_KEY=vault read -field=key kv/datadog
Vault
…and 23 more
↳ no two of them assemble env the same way
3+
backends per org, on average
1day
onboarding, asking where things live
Nrepos
to touch, every backend migration
The three-file model

Three files. Three owners. Three lifecycles.

SecretEnv separates what every other tool conflates. The manifest tells SecretEnv what is needed. The registry tells where things live. The machine config tells which backends exist on this machine.

Concrete workflows

The day-to-day SecretEnv was built for.

Backend migration

One registry set.
Every repo follows.

Move a secret from 1Password to Vault. Update one line in the registry. Every repo using stripe-key picks it up on its next secretenv run. No PRs. No re-encryption. No coordination.

One command. Source to destination.

Stripe moves from 1Password to Vault. registry migrate reads the source, writes the destination, and flips the pointer atomically, all on the platform team's machine.

$ secretenv registry migrate stripe-key \
    "vault-prod://secret/payments/stripe_key" --dry-run
✓ dry run · source readable · destination writable · pointer-flip previewed
$ secretenv registry migrate stripe-key \
    "vault-prod://secret/payments/stripe_key"
✓ migrated · pointer flipped · source kept · 0 PRs · 0 re-encryption
14 repos · same alias · routed to vault
Runtime redaction · since v0.14

Secrets never reach your logs.

A secret in a stack trace is a leaked secret. secretenv run automatically removes secret values from a program's output by default, before they can land in your logs, a CI artifact, or your terminal history.

On by default. Nothing to configure.

SecretEnv watches the program's output as it streams by and replaces any secret the moment it appears, even one split across two chunks of output. When you're working in an interactive terminal it steps out of the way so nothing interferes with your session.

While it runs. Every secretenv run cleans the program's live output as it happens.
After the fact. secretenv redact <file> cleans a file that already exists, safely rewriting it in place.
Nothing left behind. Secret values are wiped from memory when the run ends, and nothing is ever written to disk.
program output · secrets replaced as they stream by
$ secretenv run -- ./worker.sh # the worker logs its config on boot… [boot] connecting to postgres… [error] auth failed for DSN postgres://app:[redacted:db-url]@db.internal:5432 [error] STRIPE_KEY=[redacted:stripe-key] rejected by API 2 values redacted from 1 stream · 0 written to disk
without SecretEnv these lines ship sk_live_… straight to your log pipeline
Model Context Protocol · since v0.16

Give AI agents the registry.
Never the secrets.

secretenv mcp serve lets coding agents read and manage your alias registry through 14 tools. The agent can see which backend an alias points to and repoint it, but the secret values themselves never reach it. Works out of the box with 8 IDEs.

agent calls set_alias · server responds with structure, not secrets
→ agent calls tool set_alias alias = "datadog-api-key" target = "vault-prod://secret/datadog/key" reason = "rotating to vault" ← server ✓ written · operator approved via elicitation { "alias": "datadog-api-key", "backend": "vault-prod", "status": "set" // no value. no token. no secret field. ever. }

The agent never sees a secret value.

Secret values are walled off from the agent server in the code itself, so there is no path that could hand one over, even by accident. And every release runs a test that inspects the server's actual replies to prove no value slipped through.

14 tools to read the registry, change it, generate passwords, and migrate aliases. Each one takes a small, clearly defined input.
Every change waits for you. You approve it right in your editor or terminal, and a tamper-resistant log records who changed what and why.
One command to set it up: secretenv mcp setup --ide <name>.
8 IDEs, day one
Claude CodeCursorCodexVS Code CopilotContinueClineGeminiOpenCode
In practice

Let your coding agent handle the secrets plumbing. It declares the aliases your code needs, repoints them, and generates fresh credentials. Then it runs your code against your real backends.

It wires up everything your code depends on, and never reads a single value. You move at agent speed, with the peace of mind that the model can never see what it is connecting.

OpenTelemetry · since v0.17

Observe every resolution. Leak nothing.

Optional traces and metrics for every secret it resolves, every backend it checks, every agent tool call, and every registry change. Point your OpenTelemetry endpoint at a collector and it turns on. Set nothing, and it adds no startup cost at all.

It can only record what's on the allow-list.

Every piece of information SecretEnv is allowed to attach to a trace is listed out ahead of time. There is no general "record anything" option, so sensitive things like a secret value, a backend address, or a generated password simply have no way to be written out. Automated checks on every release enforce it.

✓ recorded
how long a fetch took which backend was used success or failure
✗ never recorded
the secret value the backend address a generated password
what one run records
secretenv.run 12.4ms outcome=ok secretenv.resolution stripe-key 2.1ms secretenv.resolution db-url 1.8ms secretenv.backend.fetch 1password 6.2ms secretenv.backend.fetch aws-ssm 5.4ms secretenv.exec.prepare npm start 0.3ms # 10 metrics · joins an existing trace if one is running # records of changes are never dropped, even under sampling
Supported backends

15 backends. One binary. No plugins.

SecretEnv delegates all authentication to each backend's native CLI. You inherit your existing MFA, SSO, biometric unlock, with no new auth surface to audit.

Stability proof

Every backend tool claims stability. SecretEnv proves it.

The smoke harness exercises the real binary against real backend CLIs in real shells, not mocks. 779 assertions across 15 backends as of v0.19.0.

Live-backend assertion growth

If a test doesn't pass, it doesn't ship. Every release exercises every backend, end-to-end, against the live CLI, before the tag is cut.

backends
15
assertions
779
800 600 400 200 0
How SecretEnv compares

Honest tradeoffs. No marketing math.

Property SecretEnv .env fnox direnv
Multi-backend in one invocation n/a manual per-project
Backend migration without editing repos ✓ one registry set n/a edit every config n/a
Infrastructure topology hidden from repos ✓ aliases only ✗ paths in .envrc
Centrally-shared mutable alias registry ✓ in your backend n/a n/a n/a
One-line offboarding (single revoke covers all repos) depends on mode
Stores no secret material on disk depends
No SaaS dependency
Inherits backend MFA / SSO / biometric ✓ native CLI n/a partial n/a

Stop assembling .env files.
Start orchestrating.

One binary. Your backends. No SaaS.
Built with frustration at .env files and multiple password managers.