[FEATURE] Built-in secrets management with optional third-party integrations

Workaround today: Combination of hooks + CLAUDE.md to prevent secret exposure

While waiting for native secrets management, you can build a safety net with hooks:

1. PreToolUse hook to block secrets from being written to files:

#\!/bin/bash
# ~/.claude/hooks/secret-leak-guard.sh
# PreToolUse hook — blocks writing known secret patterns to files

INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty')

case "$TOOL_NAME" in
  Edit|Write)
    CONTENT=$(echo "$INPUT" | jq -r '.tool_input.new_string // .tool_input.content // empty')
    ;;
  Bash)
    CONTENT=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
    ;;
  *) exit 0 ;;
esac

# Check for common secret patterns
if echo "$CONTENT" | grep -qE '(sk-[a-zA-Z0-9]{20,}|ghp_[a-zA-Z0-9]{36}|AKIA[0-9A-Z]{16}|xox[bprs]-[a-zA-Z0-9-]+)'; then
  echo "BLOCKED: Detected what looks like an API key or token in this content." >&2
  echo "Use environment variables instead: export MY_API_KEY=... in your shell, then reference \$MY_API_KEY in code." >&2
  exit 2
fi

# Check for generic secret assignment patterns
if echo "$CONTENT" | grep -qiE '(api_key|api_secret|access_token|secret_key|password)\s*[=:]\s*["\x27][a-zA-Z0-9+/=]{16,}'; then
  echo "BLOCKED: Hardcoded secret detected. Use environment variables or a .env file (which should be in .gitignore)." >&2
  exit 2
fi

exit 0

2. CLAUDE.md rule for the team:

## Secrets Policy
- NEVER paste API keys, tokens, or passwords into the chat
- NEVER write secrets directly into code files
- Use environment variables: `process.env.MY_API_KEY` or `os.environ["MY_API_KEY"]`
- .env files must be in .gitignore BEFORE any secrets are added
- If someone pastes a secret, immediately tell them to rotate it

3. For non-engineers (the simplest path):

Add a helper script they can run:

#\!/bin/bash
# ~/bin/add-secret.sh
# Safe secret storage for non-engineers
echo -n "Secret name (e.g., OPENAI_API_KEY): "; read NAME
echo -n "Secret value: "; read -s VALUE; echo
echo "export $NAME=\"$VALUE\"" >> ~/.env.local
echo "Added $NAME to ~/.env.local"
echo "Claude can now use it as \$$NAME"

Then in .bashrc: source ~/.env.local 2>/dev/null

The hook prevents the "paste key into chat → write to code" pattern even when non-engineers don't know better.

This still stores the secrets in plain text in .env.local preventing Claude from leaking secrets is a different problem from storing them securely (More or less) in the first place.

This still stores the secrets in plain text in .env.local preventing Claude from leaking secrets is a different problem from storing them securely (More or less) in the first place.

Actually that is not at all what I am suggesting here. The secrets would be stored in an encrypted vault file (like other password managers). The secrets.json file would just contain references to secrets ids for lookup.

It looks like they are still hitting a file though? Best to just have your script define the env vars directly and source it rather then execute so it can effect the current shell session.

Great proposal @brianbowden, and @segevfiner raised the key point: preventing leaks is a different problem from secure storage. You need both.
I was already building an MCP server for this when Claude wiped around 25K docs from my Firebase project because it had access to production credentials. Thankfully it was my own side project, but that incident made me stop questioning the idea and just focus on finishing it.
What I built:

• Encrypted vault (AES-256-GCM, envelope encryption with Cloud KMS), not plaintext .env.local
• Secrets injected via MCP, never exposed in chat or written to files
• Full audit trail: who, when, which model, from what IP
• Tag-based access rules: block, require confirmation, restrict by model

Setup: claude mcp add securecode -- npx -y @securecode/mcp-server

It's live at securecodehq.com with a free tier.

I'm looking for early users to try it and help me improve it. If you're dealing with this problem, I'd love your feedback.

You can build basic secrets management with hooks today:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
case "$TOOL" in
    Read)
        FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
        if echo "$FILE" | grep -qiE '(\.env|credentials|\.secret|\.key|\.pem|\.p12)'; then
            echo "BLOCKED: Cannot read secret files directly." >&2
            echo "Use environment variable references instead." >&2
            exit 2
        fi
        ;;
    Bash)
        COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
        if echo "$COMMAND" | grep -qE '^\s*(env|printenv|set)\s*$'; then
            echo "BLOCKED: Cannot dump all environment variables." >&2
            exit 2
        fi
        if echo "$COMMAND" | grep -qE '(cat|less|head|tail)\s+.*\.env'; then
            echo "BLOCKED: Cannot display secret files." >&2
            exit 2
        fi
        ;;
    Edit|Write)
        CONTENT=$(echo "$INPUT" | jq -r '.tool_input.new_string // .tool_input.content // empty' 2>/dev/null)
        if echo "$CONTENT" | grep -qE '(sk-[a-zA-Z0-9]{20,}|AKIA[A-Z0-9]{16}|ghp_[a-zA-Z0-9]{36})'; then
            FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""' 2>/dev/null)
            if [[ "$FILE" != *".env"* ]]; then
                echo "BLOCKED: Cannot write API key patterns to source code." >&2
                exit 2
            fi
        fi
        ;;
esac
exit 0

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
if echo "$COMMAND" | grep -qE 'git\s+add\s+.*\.env'; then
    echo "BLOCKED: Cannot stage .env files." >&2
    exit 2
fi
if echo "$COMMAND" | grep -qE 'git\s+add\s+(-A|\.)\s*$'; then
    [ -f ".env" ] && { echo "BLOCKED: git add with .env present." >&2; exit 2; }
fi
exit 0

{
  "hooks": {
    "PreToolUse": [
      {"hooks": [{"type": "command", "command": "bash ~/.claude/hooks/secret-manager.sh"}]},
      {"matcher": "Bash", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/secret-commit-guard.sh"}]}
    ]
  }
}

Three layers of protection:

1. Can't read secret files (blocks exfiltration to API)
2. Can't hardcode secrets into source code
3. Can't commit secret files to git

I don't want to build a hack around it,... And I don't want to store secrets in env vars like this to begin with...

The chances of correctly blocking the agent from all possible ways of reading secrets from env vars are slim to put it mildly when you let it execute arbitrary shell commands and not the point here to begin with, its about storing them securely locally to begin with...

For the VS Code extension specifically, ${input:id} + SecretStorage API could be a pragmatic first step toward the broader secrets management described here - small surface area, fully backward-compatible, and reuses a pattern VS Code developers already know from tasks.json and launch.json.

Detailed implementation proposal in #44158. Ready to submit a PR if the team is aligned.

A hook compatible with Claude was just added on Lade.

Secrets management built into Claude Code seems like a reasonable feature, but especially until a first-party feature exists (and thus Anthropic is on the hook to do whatever is necessary to manage those secrets correctly and prevent disclosure), I wanted strict isolation between Claude and my secrets. Leaving this note here in case this approach is useful to others looking into the same thing who might feel similarly.

My solution was to only run Claude inside a devcontainer, use SOPS along with Age to encrypt all secrets, but keep the private key completely out of the devcontainer. My use case is primarily for personal and homelab use where I am prioritizing simplicity and minimizing maintenance, so adjust as appropriate for your environment and preferred tools. In my case I used 1Password to hold the private key for Age since I already use 1Password heavily for SSH keys, and I like that I get an explicit UI prompt to approve each usage, but there are many different approaches possible here.

Specifically, I set SOPS_AGE_SSH_PRIVATE_KEY_CMD through direnv(/.envrc) to read from the 1Password vault, and have SOPS configured to encrypt against that key by default through creation_rules in .sops.yaml. The devcontainer and Claude is thus completely unable to even request the private key to decrypt secrets; the 1Password CLI isn't even installed inside the devcontainer, and AFAIK would not have the host connections to work even if it was installed.

I can give more details if anyone is interested, and certainly you might need to adapt this approach. For example, I'm currently doing this for Ansible playbooks, so I set up my project to support separate venvs for host and devcontainer and just run my playbooks on the host. If you have a more complex devcontainer setup or only having secrets access when on the host is not ideal, you might want to instead create variants of the devcontainer; one for development that has Claude but no secrets access, and one for production/deployment that excludes Claude but gets the key needed to decrypt SOPS secrets.

I really need something like this. The user experience for secrets is nonexistant. Adding hooks and such to make claude resistant to storing secrets is not the same as having a way users can add secrets to claude and have him use them to log into things and do things an a repeatable way. Without secret management, pretty much every enterprise use case won't pass a security inspection.

Strong +1 on the core principle — secrets entering the chat context is exactly the
thing to eliminate, and the dedicated-UI / name-reference / value-blind model you
describe is spot on.

I want to add a separate, complementary implementation of the same principle,
scoped to authoring and propagating secret files rather than consuming them at
runtime. Where your proposal centers on using a secret (claude-secrets run --,
process-level injection), this covers getting values into .env and CI safely in the
first place. Same value-blind guarantee, different surface — and deliberately a
different implementation so it can ship on its own.

Concretely, two MCP tools routed through the harness so their inputs never reach
the model:

manage_env — create, write, overwrite, and sync .env files.

• The model supplies structure only: key names, scopes, and hints (where to obtain

each value). The user enters the actual values via a dedicated masked input surface.
Values are written straight to .env; only a masked confirmation returns to the
model.

• Sync from .env.example: rebuild .env using .env.example as canonical. The

harness (not the model) reads the existing .env and carries forward values for
keys that still exist. Keys in the old .env but not in .env.example are kept and
annotated (# (not in example)). New keys with no value are collected via the masked
surface. The model receives only a structural report (counts and key names, never
values).

push_git_secrets — register selected keys as GitHub Actions secrets.

• The model proposes which keys and the target scope (repo / org / environment),

excluding local-only values. Values are piped into gh secret set (which encrypts
locally before sending to GitHub), bypassing the model entirely. Only registered key
names return.

These are also relatively cheap to ship: the one genuinely new piece is the
value-blind input surface itself — a masked entry UI whose input is routed through the
harness so it never reaches the model context, transcript, or logs. That part does need
to be built. But everything downstream of it is existing machinery: manage_env is
file writes, push_git_secrets just wraps gh secret set (which already handles local
encryption and transport), and .env.example sync is a pure text/structure operation
with zero external dependencies. No backend plugins, no .claude/secrets.json reference
format, no runtime-injection wrapper. So once the input surface exists, these tools sit
on top of it as a small, self-contained unit that can land well ahead of the full
pluggable-backend system.

<img width="1443" height="831" alt="Image" src="https://github.com/user-attachments/assets/998b8150-1a0d-4241-a522-268b5bfdc72f" />
This UX is already validated in production — Manus surfaces an
inline input card where the user enters the secret directly; in the conversation it
then appears masked (••••) next to its key name, while the value remains viewable and
manageable in settings. Secrets are kept centrally and referenced by name in later
steps, with the value never transiting the model.

(Manus describes its secrets handling in its
third-party integrations docs,
though that page documents the general model rather than this specific input-card flow,
which is observed in the product itself.)

+1, and I think there are really two groups here with different needs.

Engineers will set up a proper secrets platform. Powerful, but a fair amount of work to wire up. Non-engineers using agents (wiring up PostHog, filing Linear issues, configuring Stripe) usually just paste the key into chat or drop it in a .env, because the existing tools assume DevOps knowledge they don't have.

That second group is the real gap. Whatever Claude Code ends up building in here, the thing that would actually help them is low friction by default: the agent gets scoped access to the one service it needs, you can see what it used, you have an overview of secrets grants, and you never have to learn a technical secrets platform.

Disclosure: that is the niche I am building for (ScopeHold), so I am biased. Happy to share what we have learned about the non-engineer flow either way.