Proposal: Built-in secret management for Claude Code

This is a real gap. I've seen teams adopt Claude Code and immediately start pasting API keys into .env files that the agent can read — zero access control, zero audit trail.

We built KeyEnv (keyenv.dev) to handle this: secrets are encrypted at rest, pulled via CLI, and injected at runtime. The agent gets the env vars it needs without ever seeing the raw secret values stored anywhere on disk.

The approach works well with AI coding tools because: (1) no secrets in any file the agent can read/commit, (2) rotation happens server-side without touching the dev environment, (3) audit trail shows exactly which secrets were accessed and when.

This is my own proposal, based on my own experience in helping guide a startup through adoption of Claude Code across all roles. Right now, Claude does very little to encourage safe secret handling, which seems like a significant miss. Most engineers know how to mitigate risks of secret exposure (or avoid giving Claude secrets at all via proxies and such), but non-engineers simply don't have that learned skillset.

Of course, none of this prevents Claude from running scripts that read and expose secret values at runtime. However, with LLMs building and testing so much software, this is one proposed piece to help reduce some vectors of exposure.

[Note: my submission was written with assistance from Claude.]