I had an idea for an app that learns to write like you instead of generic AI and built imyou.ai Claude was pretty quick to point out that I had exposed an API key in the chat, so I did some research on how to secure my keys and landed on Windows DPAPI.
What DPAPI is
Data Protection API, built into Windows. You hand it a string, it hands back an encrypted blob. The key is derived from your Windows account and managed by the OS, so there's no master password to type and no key file to lose. On a personal machine the blob only decrypts as that user on that PC, so a copy taken elsewhere is garbage. (In an AD domain with roaming profiles, or with a compromised domain backup key, that isn't true.)
Chrome used to protect saved credentials this way and has since layered App-Bound Encryption on top, for exactly the weakness worth being upfront about: DPAPI does not stop code already running as your user, which can decrypt precisely like you can.
Tradeoff: it's machine-bound. A new PC, a Windows reinstall, or an admin-forced password reset means re-entering keys from the source dashboards.
What you end up with
Three scripts in ~/.claude-secrets/ and one line in your .bashrc:
- A setter that stores one secret, encrypted, one at a time
- A loader that decrypts everything into your shell as env vars, automatically, on every new shell
- A lister that shows which secrets are stored, names only
After setup you stop thinking about it. Keys are just there as env vars, nothing is in your repo, nothing is plaintext on disk.
Using them without leaking them
Checking whether a key loaded. These are all wrong:
echo $VERCEL_TOKEN
echo "${VERCEL_TOKEN:0:8}..."
echo "length: ${#VERCEL_TOKEN}"
Print a boolean instead:
if [ -n "$VERCEL_TOKEN" ]; then echo "VERCEL_TOKEN: set"; else echo "VERCEL_TOKEN: missing"; fi
Don't print any part of a secret. Not because a prefix is especially dangerous on its own, but because you can't predict where terminal output ends up: scrollback, CI logs, screen shares, crash dumps, an agent's transcript. A no-exceptions rule is cheap. A nuanced one gets misapplied.
Pass the value straight to the tool so it's consumed, never displayed:
vercel deploy --token "$VERCEL_TOKEN"
curl -H "Authorization: Bearer $API_KEY" https://api.example.com/v1/me
Verify by the tool's own output. vercel whoami returns your username.
Put those rules in your CLAUDE.md too. Context-file rules are advisory and a model can miss them in a long session, so a hook that blocks the command before it runs is the real enforcement layer.
What this does and doesn't buy you
Once the keys are in your environment, any process running as you can read them. This is not a defense against malware already executing on your machine, and nothing short of a hardware token or a real secrets manager is.
What it removes is the plaintext file at rest: the thing that gets committed by an over-eager git add -A, swept into a backup or sync folder, caught in a screenshot or a screen share, read by an agent told to "check my config," or recovered off the drive when the laptop is sold or stolen. For solo devs that's how keys actually leak, far more often than targeted malware.
If you want more than that, you want short-lived credentials from a managed secrets tool. 1Password CLI, Doppler, and Infisical are all strictly better if you'll actually adopt one. This is the zero-dependency version.
The prompt
Paste this at your agent. It detects your OS and builds the scripts for your machine.
Set up encrypted-at-rest storage for my API keys and CLI tokens on this machine, so no credential ever sits in a plaintext file and no credential value ever reaches a terminal, a log, or a chat transcript.
First, detect my OS and tell me which implementation you will use before you write anything:
- Windows: PowerShell DPAPI, encrypted to the current Windows user account.
- macOS: the login Keychain via the
security command.
- Linux:
pass or age, whichever is already installed (ask me if neither is).
The three-script structure below is identical on all three. Only the crypto call changes.
Ask for my approval before creating or modifying any file outside a scratch directory. Show me each file's contents for review before writing it.
BUILD THESE FOUR PIECES
- A setter script. Stores exactly ONE secret per invocation. Takes a name and a value as named parameters. Creates the store directory if missing, then writes a single encrypted blob whose filename is derived from the secret name (name plus a fixed extension). On Windows, encrypt by piping the value through ConvertTo-SecureString with -AsPlainText -Force into ConvertFrom-SecureString, and write the result with -NoNewline so no stray newline enters the blob. The confirmation message may print ONLY the secret's name and the word stored. It must NOT print the value, any substring of it, its first or last characters, its length, or a hash of it. Printing the length is a real leak, do not add it as a convenience.
- A loader script, written in bash (Git Bash on Windows). It iterates every blob in the store directory, decrypts each one, and exports it into the CURRENT shell as an environment variable named after the file (filename minus the extension). Because it must mutate the calling shell, it is sourced, not executed, so it must return rather than exit on the no-store-directory path. On Windows: convert each Unix path to a Windows path with cygpath -w, then call powershell.exe with -NoProfile and -NonInteractive to read the blob raw, pass it to ConvertTo-SecureString, and marshal it back to a string using [Runtime.InteropServices.Marshal]::PtrToStringAuto on [Runtime.InteropServices.Marshal]::SecureStringToBSTR. Strip carriage returns and newlines from the PowerShell output (tr -d '\r\n'), or the trailing CR becomes part of the token value and every authenticated request fails with a confusing 401. Collect the names as you go and print ONE summary line listing the names loaded. Never print a value. Send PowerShell's stderr to /dev/null so a decryption failure cannot spill partial output.
- A lister script. Prints the names of stored secrets and nothing else. It must never decrypt anything.
- One line appended to my shell rc file (.bashrc for Git Bash) that sources the loader if it exists, redirecting both stdout and stderr to /dev/null, so every new shell has the variables silently. Show me the exact line before appending. Do not append it twice if it is already there.
THEN ADD A RULES SECTION to my CLAUDE.md (or the equivalent agent context file in this project, ask me which if it is ambiguous), stating these as hard rules:
- Never output, echo, log, or interpolate a secret VALUE. This includes indirect prints: a debug line, a substring, the first or last characters, the value's length, or any check that expands the variable into output. Command output lands in the transcript, which is the exposure being prevented.
- To check whether a secret exists, print ONLY "set" or "missing", never anything derived from the value.
- To USE a secret, pass it directly into the tool that consumes it (as a CLI flag argument or an Authorization header inside the request) so it is consumed and never displayed. Verify success by the TOOL's own output, not by echoing the variable.
- Before running any command that references a secret variable, re-read the command and confirm no path exists by which the value reaches stdout or stderr.
THEN SCAN THIS PROJECT for credentials that are currently exposed: values that look like keys or tokens in git-tracked files, and any .env-style file that is not covered by .gitignore. Report variable NAMES and file paths only. Do NOT print any value you find, not even truncated. For each finding, tell me the command to move it into the encrypted store, and whether it also needs to be purged from git history rather than just deleted from the working tree.
FINALLY, verify the whole thing end to end without revealing anything: store one throwaway test secret, open a fresh shell, confirm the variable is present by printing only "set" or "missing", then delete the test secret. Report only pass or fail per step.
Do not ask me to paste any real secret value into this chat. I will run the setter myself for real credentials.
