Don't Put Secrets in .claude - How Password Managers Handle AI Agents.

AI coding agents leak whatever you leave in a config file. A short map of how Proton Pass, Dashlane, 1Password, Bitwarden, and Keeper treat agent access — token-and-read, inject-never-reveal, or no access at all — plus free and local options if you do not want another subscription.

Posted by jforge on September 29, 2026 · 7 mins read

AI coding agents are useful. They are also excellent at leaking whatever you leave in a config file.

A growing number of people store API keys next to Claude Code settings. Proton Pass tried to fix that with Agent Mode: an isolated vault, a token that is not the password, a mandatory reason on every read, an activity log, and one-click revoke.

That feature is good. It is also paid, and it is not the only model in the market. If you use Dashlane — or you just want something free — here is the short map.

The three models

Almost every product falls into one of these.

1. Token-and-read (Proton’s model)
You create a vault just for the agent. You hand it a token. The agent retrieves the secret when it needs it, states a reason, and the vendor logs the read. Blast radius is one vault. Weakness: a prompt-injected agent can still see the value.

2. Inject-never-reveal
The agent only knows a name (stripe_key). A local broker or the password manager injects the real value into a subprocess, a browser field, or an HTTP proxy. The model never gets the bytes. Stronger against prompt injection. This is where 1Password, Keeper, and Bitwarden’s Agent Access SDK are going.

3. No agent access on purpose
The vault stays human-only. Autofill stays user-driven. That is Dashlane’s public position: credentials must stay under explicit user control, and an AI browser must not scrape the extension.

Tracking (a log of what was read) is common in model 1 and in enterprise PAM.
Alerting on your own rules (“page me if prod-db is read more than three times an hour”) is rare. Consumer apps show a log. Custom alerts live in SIEM, PAM, or a JSONL file you tail yourself.

What the big password managers actually offer

Proton Pass
Agent Mode is the cleanest consumer UI for model 1: scoped vault, expiring token, required reason, activity view, revoke. Included on Pass Plus / Unlimited / Family / Professional / Workspace — not on free Pass.

Dashlane
No Agent Mode. Business plans have a Secrets CLI (inject by secret ID) and a beta MCP server that lets an agent query audit logs, not pull passwords. Their own engineering team runs Claude Code in Dev Containers and keeps tokens off the agent. Stay on Dashlane for personal logins; do not punch an agent hole in that vault.

1Password
Two tracks. For the browser: 1Password for Claude (beta) — biometric approve per task, fill into the page, Agentic Mode locks the rest of the vault. Claude never sees the password or TOTP. For developers: Service Accounts, op run / op:// references, a Claude Code plugin that validates mounted .env files, usage reports. Paid account required. Closest thing to “use the login without exposing it.”

Bitwarden
Secrets Manager: machine accounts and secret IDs instead of plaintext. Free tier exists (unlimited secrets, tight limits on users / projects / machine accounts). Event logs and SIEM-style alerting are on Teams/Enterprise. Separately, the open-source Agent Access SDK does just-in-time, human-approved injection (aac run). Full agent-access auditing is still maturing.

Keeper
Most “enterprise-complete” of the bunch. Agent Kit teaches Claude Code / Cursor / Copilot to call ksm exec so values stay out of chat. Same RBAC and audit as a human. PAM adds agentic policies: allow, deny, require justification or MFA before an agent even runs. Session recording and SIEM on higher tiers. Overkill for a solo .claude folder; right if you already pay for Keeper.

Free and local options

If you do not want another subscription:

  • Bitwarden Secrets Manager free — closest hosted Proton-shaped token + isolated project.
  • Infisical — free cloud tier or MIT self-host; Agent Vault proxies HTTP so the agent never holds the key.
  • secretctl, keymaxxer, passman, agent-vault, Wundervault MCP — local encrypted store + MCP. Agent references a name, the broker injects, output is scrubbed, use is written to a JSONL audit log. This is where you add your alert rules (ntfy, Slack, a cron that greps the log).

These last tools are usually safer than handing Claude a password, even a scoped one.

A simple recommendation

Keep Dashlane (or whatever you already use) for personal logins. Do not give Claude that vault.

Put agent-only secrets somewhere else:

You want… Use
Proton-like token + vault, free, hosted Bitwarden Secrets Manager free
Secret never enters the model secretctl or Infisical Agent Vault
Per-task approve in the browser 1Password for Claude
Policy + SIEM + “this binary may not run” Keeper PAM
Custom alerts this week Local JSONL vault + a 20-line script

Practical hygiene for Claude Code, regardless of vendor:

  • Store values in the vault, not in .claude/ or a committed .env.
  • In project files, keep references (op://Agent/openai/credential), not values.
  • Deny the agent those paths:
{
  "permissions": {
    "deny": [
      "Read(**/.env*)",
      "Read(~/.ssh/**)",
      "Bash(env)"
    ]
  }
}
  • Treat the one bootstrap token (machine account, MCP unlock) like a privileged API key. Keep it in the OS keychain, not in the repo.

The honest takeaway

Proton Agent Mode is still the only mainstream password manager that combines isolated vault + agent token + mandatory reason + one-click revoke in one consumer screen.

Everyone else either refuses to open the vault (Dashlane), injects without showing the secret (1Password, Keeper, Bitwarden SDK), or makes you assemble audit and alerts yourself.

For a coding agent, prefer inject-never-reveal. A reason log is useful after an incident. It does not stop a hijacked agent from reading a vault it was allowed to read.

Next Post →