Secrets Management.
API keys belong in a vault, never in a chat window or a config file. This card is the why. What a secret manager actually buys you, the three storage paths the workshop supports (Infisical, 1Password, or a locked .env), and why Infisical is the recommended setup. When you are ready to wire it up for real, the Wire Your Secrets Manager build walks every step.
- The one rule that prevents the most expensive beginner mistake never paste a real key into a chat, and the placeholder pattern that makes that rule easy to keep.
- A clear picture of the three storage paths Infisical, 1Password, and the
.envfallback. What each is best at and which one to reach for first. - Why Infisical is the default the installer signs you in, the free tier covers the workshop, and
infisical runinjects secrets at runtime so the real value never touches a file you could leak.
How this fits in the OS.
Nothing, to read it. To act on it you need Claude Code installed and a secret manager you actually use. Infisical is the recommended setup. The workshop installer already signs you into it. 1Password works the same way if you prefer it.
One idea. The real credential lives in a controlled store, and your agent reaches it through a reference that resolves at runtime, so the secret value never sits in a file you could leak.
Every later card. MCPs (Claude Desktop calls these connectors), overnight cron jobs, the Morning Brief capstone, and any fleet of agents that runs while you sleep. None of those are safe to wire up until credentials are out of reach. When you are ready, Wire Your Secrets Manager is the hands-on build.
The first rule.
The single most expensive mistake a new user makes is pasting an API key into a Claude conversation. The moment that happens, the key is in a chat log. It might be cached, reviewed, replayed, or screenshotted. Treat it as burned and rotate it: generate a fresh key in the service it came from, update the value in your manager, and restart Claude Code. The old key dies the moment you revoke it.
You will never paste your actual API keys into this chat with Claude, or into any chat, ever. The real value gets typed directly into your secret manager. The agent only ever sees the placeholder.
The fix is structural, not behavioral. You stop trusting yourself to be careful and put credentials somewhere Claude has to reach for them through a controlled door. The pattern is the same on Mac and Windows, and the same whether you use Infisical or 1Password: the agent scaffolds the secret name, you type the real value yourself.
If Claude ever offers to write an API key into a file, a prompt, or a chat reply, say no. Always. The right answer is "put the placeholder in, I will load the real value from my vault." Real keys do not belong in anything the agent can read or write. Agents can be over-eager to help. That is the moment to decline.
What a reference actually is.
The whole trick is one swap. Instead of the real key, your config file holds a pointer to where the key lives. Same file, completely different risk:
"BRAVE_API_KEY": "sk-ant-a1b2c3d4..."
The real key sits in the file. Commit it, screenshot it, or paste the file into Slack and it is compromised. One slip and you are rotating keys.
"BRAVE_API_KEY": "${BRAVE_API_KEY}"
The file only names the variable. On Infisical, infisical run injects the real value at launch; on 1Password, the reference is an op://Vault/Item/field path. Either way the secret stays in memory and never gets written to the file. Safe to commit, share, or screenshot.
So how does the agent ever get the real key? It is fetched the moment it is needed, and nowhere else:
What changes for you.
The mechanical fix is small. The internal shift is bigger. Three things change the first day your keys live in a vault:
- You stop being scared of credentials. Once keys live in Infisical or 1Password and load through a runtime reference, the worry that "I might leak something" becomes "the system will not let me leak something." That fear was eating real cycles.
- Your config files become safe to share. You can paste your
settings.jsoninto a screenshot, a workshop Slack thread, or a teammate's pull request without thinking. There is no secret in it. The vault holds the secret, the file holds a reference. - You start running things overnight. A token scoped to that one store, a machine identity in Infisical or a 1Password service account, is what lets a fleet of agents work while you sleep without you reauthenticating every five minutes. The agent fetches the credential in memory, uses it, and the value lives nowhere on disk.
The first time the agent finishes an eight-hour overnight run and you never had to wake up to enter a key, this posture is what made that possible.
/upgrade-8d-secrets sets up a machine identity. This deck walks the whole flow.
Three durable paths. Pick one.
The workshop supports three credential storage patterns. They all share the same shape (secret lives in a controlled store, agents read by reference) but trade off differently. Pick the one that matches where you are:
infisical run injects secrets at runtime so the key never touches a config file.
op:// references resolve at runtime via the desktop app integration so the key never touches a config file.
No. Pick one for the job that matters here: holding the credentials your agents use. They overlap, so there is no reason to run both. The difference is scope. Infisical is the recommended setup because the installer signs you in and it is built for agent and machine secrets, the API keys and tokens your tools authenticate with, like a Brave or Firecrawl key or the token behind a Gmail or Slack MCP. It is free, but it will not replace the password manager you use for your bank or your email. 1Password works the same way if you prefer it, especially if you already use it for everyday logins and want one tool for everything.
First time through, pick Infisical. The installer already set up the CLI and signed you in, so it is the recommended path for this workshop. If you prefer 1Password, follow the 1Password notes where they appear.
You could keep a key in a plain file and be careful. The reason we do not is that "be careful" fails at the worst time: the day you paste a config into Slack, the day a script logs an environment dump, the day you push a repo you forgot had a key in it. A secret manager moves the value somewhere those accidents cannot reach it. Infisical is the recommended setup because the workshop installer already signs you in; 1Password works the same way if you prefer it.
What actually goes in it.
Concretely, your secret manager holds the API keys and tokens for the tools you wire up across the workshop. A sample of what ends up in there:
| Kind of tool | Workshop examples | What the key lets the agent do |
|---|---|---|
| Models and search | Anthropic, OpenAI, Brave, Firecrawl, Exa | Call the model, and search or scrape the web |
| Data and backend | Supabase | Read and write your database and the vector store behind Cairns |
| Deploy and hosting | Vercel | Ship and update the apps you build, like the Morning Brief capstone |
| Messaging | Telegram, Slack | Send you updates and post in your channels |
| Connected apps | Gmail, Google Calendar, Notion | Act in the tools you already use, wired up through an MCP |
| Observability | Langfuse | Record what your fleet does so you can see it later |
Every one of these is a credential the agent reads at runtime through a reference, never a value sitting in a file. Add a new tool, add its key the same way. The list grows, the pattern never changes.
Double-check your setup.
Not sure your keys are actually out of reach? Hand this to Claude in your workshop repo and let it audit you, without ever printing a real value:
Audit my secrets setup for safety, and do not print or echo any real key values in your reply. Check that my .env and .env.local are gitignored (run git check-ignore -v .env .env.local), scan my settings.json and config files for any raw API keys that should be references instead (long tokens, or strings starting with sk- or BSA-), and confirm my secret manager is set up (for Infisical, check the CLI is installed with infisical --version; for 1Password, op whoami). Do not run any command that prints a token or secret value. Then list anything exposed and exactly how to fix it. Never paste a real secret into your response.
Where to go next.
You have the why. The next move is to actually put your keys out of reach. About 45 minutes, once, and every later build inherits it.