Secrets checklist for agents

1. Why this matters right now

Most people working with agents have done at least one of these:

• Pasted a password into chat "just this once" to get the agent moving.
• Put real keys in an environment file the agent reads.
• Gave an agent a broad token "so it would not get stuck" and forgot about it.
• The problem: anything that enters an agent's context stops being a secret. It sits in the conversation history, can get pulled back up later in the session, can leak into a file, a log, a commit, or a screenshot the agent produces.
• You can't undo sharing a secret. You can only rotate it.

2. The right pattern: 1Password for Claude

On July 16, 2026, an official integration shipped that demonstrates the right pattern: 1Password for Claude.

• Claude asks to log into a site, you approve, and the 1Password extension fills the password directly on the page.
• The password and the one-time verification code never reach the model at all: not into context, not into memory, not into Anthropic's systems.
• Claude only gets a status: succeeded or failed.
• This is the pattern worth adopting everywhere: the agent gets access to the task. Never the secret itself.

3. What an agent is allowed to see

• The vault item's name, username, and site URL: metadata that lets the agent request the right item, without a secret value.
• Succeeded or failed status: everything the agent needs to continue the task.
• A scoped, short-lived token issued for a specific task: if it leaks, the damage is bounded in scope and time.
• Public keys: public by definition.
• Passwords for an isolated test environment with no real data: no real harm if exposed, as long as it is genuinely isolated.

4. What it should never see

• Passwords, including "just this once" in chat: they stay in history, you can't undo exposure.
• Two-factor codes and recovery codes: they bypass your last line of defense.
• Private keys (SSH, signing, wallets): one exposure equals a full takeover.
• Broad API keys, especially with billing permissions: an agent that makes a mistake can burn real money.
• Production database credentials: one agent mistake is customer data loss.
• Customers' personal details and payment info: legal liability, not just technical.
• Rule of thumb: if you'd rotate the secret after an employee leaves, it shouldn't reach an agent's context.

5. Setting up 1Password for Claude, step by step

What you need (as of launch, July 2026):

• A Mac. The launch is Mac-only, no Windows or Linux support.
• The 1Password app for Mac, version 8.12.28 or later, and the 1Password browser extension at the same version or later.
• The Claude Desktop app for Mac, and the Claude in Chrome extension.
• A paid Claude subscription: Pro, Max, Team or Enterprise. It is in beta, and not available on the free tier.
• A personal, family or business 1Password subscription.
• In organizations: on Claude Team and Enterprise plans the feature is off by default and the org owner needs to turn it on. On a 1Password Business account, an admin needs to separately enable the permission that lets agents fill passwords for users.

How it works the first time:
  1. Update both 1Password apps (desktop and extension) to the required version.
  2. Make sure Claude Desktop and Claude in Chrome are installed and signed into the same paid account.
  3. Give Claude a task that requires logging into a site. When it reaches a login page, it sends a request to the vault for the item it needs.
  4. You get a 1Password approval window showing exactly which item was requested. You approve with your fingerprint or account password, switch to a different item, or deny.
  5. After approval, the extension fills the password directly on the page. Claude only gets succeeded or failed.

6. What happens in the background, and what this still doesn't solve

While the agent controls the browser:

• The vault locks automatically: only the items you approved for that task are accessible, everything else is blocked.
• Access is valid for that session only. There's no standing access, and approval doesn't carry over to other sessions.
• A task that runs across several sites gets the logins along the way, without stopping you at every site again.
• When the task ends or the tab closes, access ends.
• What's not supported at launch: credit cards, identity details, and passkeys. Login through Google may not work as expected.
• And most importantly: once Claude is logged into a site, what it does inside the account rests on Claude's own safeguards, not 1Password's. They say so themselves in their security docs. Login permission is not permission to act.

7. Secrets outside the browser: my rules

The 1Password pattern solves the browser. For working agents like Claude Code, these are the rules I work by:

• Secrets live in a secrets manager, not in files. Keep keys in Keychain or a vault, and the agent gets the secret's name, not its value. The value gets injected at runtime.
• A real environment file never goes into the repo or into context. The agent gets an example file with variable names only. The real file is in git's ignore list and the agent tool's ignore list.
• A token per task, not a token for life. Minimal permissions, short expiry, a separate token per agent. A leaked token can be traced back to the agent that received it.
• A secret that enters chat once is a burned secret. No debating it. Rotate it now, then fix the process that caused it.
• Logs and screenshots are context too. Before sending an agent's transcript, log, or screenshot to anyone, scrub sensitive values.
• Every action that costs money or touches production goes through a human approval gate. Even when the agent is right.

8. Red flags: stop the agent immediately if

• It asks you to paste a password or verification code into chat.
• It suggests turning off or bypassing the password manager "to move forward."
• It prints a secret's value back out in its output.
• It asks for standing access to something that is only needed once.

9. The compact checklist

Copy, paste, go section by section:

- [ ] No password, verification code, or private key anywhere in chat history. If there is, it has been rotated.
  - [ ] The real environment file is outside the repo and outside the agent's read permissions.
  - [ ] Every agent has its own scoped, short-lived token.
  - [ ] Browser logins go through a password manager with human approval per item.
  - [ ] No agent has standing access. Everything is per-task.
  - [ ] Money and production actions sit behind an approval gate.
  - [ ] Logs and screenshots are scrubbed before sharing.
  - [ ] There is a procedure: an exposed secret gets rotated the same day.