Your AI agent can use your keys without seeing them

I have a confession. I paste API keys into Claude and Cursor all the time. I know better, I built an entire company around knowing better, and yet there I am at 1 a.m. debugging an agent, and the fastest path is the wrong one: copy the key, paste it into chat, move on.

The cloud vault fixes this for production. But the gap was always the laptop — the part where you're iterating locally, the agent needs a key, and the quickest thing to do is the dumbest thing to do. Today we shipped the fix.

What shipped

Three things, all in the CLI at @1claw/cli@0.34.2:

1. Local vault — an encrypted JSON store on your machine. ~/.config/1claw/local-vault.enc, AES-256-GCM, passphrase-derived key via PBKDF2 (100k iterations). Put secrets in, get secrets out, optionally sync to the cloud vault when you're ready.
2. Local daemon — a Unix socket server that decrypts the vault once, holds it in memory, and serves secrets over ~/.config/1claw/daemon.sock. The passphrase prompt happens once at startup. After that, clients talk to the socket without re-authenticating.
3. Secret proxy — the daemon also proxies HTTP requests, injecting the secret into the outgoing request (as a Bearer token, header, basic auth, or query param) without ever handing the raw value to the caller. The AI model asks the daemon to make the call. The daemon makes the call. The model never sees the key.

The five-minute demo

Start to finish, no cloud account needed:

# Create an encrypted local vault
1claw local init

# Add a secret
1claw local add stripe-key
# (prompts for passphrase, then the secret value)

# Check what's in there
1claw local list

That gives you encrypted-at-rest storage. The file is AES-256-GCM with a random salt and 100k PBKDF2 rounds. Permissions are set to 0600. Nothing clever, just solid defaults.

Now the interesting part — the daemon:

# Start the daemon (prompts for passphrase once)
1claw daemon start

# Tell the daemon which hosts can use which secrets
1claw daemon policy add stripe-key --hosts api.stripe.com --inject bearer

# Check it's running
1claw daemon status

The daemon is now listening on a Unix socket. It holds the decrypted vault in memory. It has a policy file that says "stripe-key can only be sent to api.stripe.com, as a Bearer token." That's the trust boundary.

The part that matters: the model never sees the key

When you connect an MCP client (Claude, Cursor, etc.) to the local daemon, it gets two tools:

• list_secrets — returns secret names only. No values, ever.
• proxy_request— the model says "use stripe-key to call https://api.stripe.com/v1/charges". The daemon checks the policy, injects the key into the Authorization header, makes the request, and returns the response. The key never enters the context window.

Setting up MCP to use the daemon is one command:

1claw setup --local --client cursor

That writes the right env vars (ONECLAW_LOCAL_VAULT=true, ONECLAW_DAEMON_SOCKET) into your MCP client config. The MCP server sees those and talks to the daemon instead of the cloud API. No API key, no cloud account, works offline.

Fail-closed by default

The policy engine is fail-closed. If you haven't explicitly told the daemon "this secret can go to this host," the request is blocked. No policy, no injection. The daemon won't send your Stripe key to some random URL the model hallucinated.

Policies support exact hostnames and wildcards:

# Exact match
1claw daemon policy add github-token --hosts api.github.com --inject bearer

# Wildcard — any subdomain of openai.com
1claw daemon policy add openai-key --hosts "*.openai.com" --inject bearer

# Custom header injection
1claw daemon policy add weather-key \
  --hosts api.openweathermap.org \
  --inject header \
  --header-name X-API-Key

Cloud sync when you're ready

The local vault is standalone. You can use it forever without a 1Claw account. But when you're ready to move a secret to HSM-backed storage with audit logging, policy-based access control, and multi-agent support, the path is:

# Push local secrets to a cloud vault
1claw local sync --direction push --vault <vault-id>

# Or pull cloud secrets into local
1claw local sync --direction pull --vault <vault-id>

Synced secrets are tagged so you can see what's local-only and what's backed up. Import from .env files works too:

1claw local import .env

That reads every line, adds each key-value pair to the encrypted vault, and you can delete the plaintext .env file. One fewer secret sitting on disk in the clear.

Why not just use the cloud vault?

You should, for production. But local development has different constraints. You're on a plane. You're iterating on something that doesn't exist yet. You don't want a network round-trip on every secret fetch. You want to test an agent integration without signing up for anything. The local vault covers that gap.

More importantly: the daemon changes the trust model. When you use the cloud vault through the SDK, the agent still receives the secret value at runtime — it's in process memory. With the local daemon, the agent never receives it. The daemon is the last hop. The model says "make this call with this secret" and the daemon does it. That's a meaningfully different security posture, especially for local dev where you're running untrusted MCP tools and agents you're still debugging.

Architecture

Here's how the pieces fit together:

  AI Model (Claude / Cursor / GPT)
       │
       │  MCP: proxy_request("stripe-key", "https://api.stripe.com/...")
       ▼
  1claw MCP Server  (ONECLAW_LOCAL_VAULT=true)
       │
       │  HTTP over Unix socket
       ▼
  1claw Daemon  (~/.config/1claw/daemon.sock)
       │
       │  1. Resolve secret from in-memory vault
       │  2. Check policy (fail-closed)
       │  3. Inject into request headers
       ▼
  Upstream API  (api.stripe.com, etc.)
       │
       │  Response
       ▼
  Back to model  (secret never in context)

What's next

This is the foundation. Planned additions include a system tray UI (so you don't need a terminal to unlock the vault), brew install support, per-tool MCP policy scoping, and secret rotation reminders. It's all tracked in our public roadmap.

If you've been putting secrets directly into AI chat — and I know you have, because I was too — try this instead. It takes about two minutes to set up, works offline, and keeps your keys out of context windows.

Get started for free · Read the docs · View on GitHub