The AI Agent Credential Safety Checklist

AI agents can now log into websites for you. On July 16, 2026, 1Password and Anthropic shipped 1Password for Claude — Claude completes login-gated tasks in the browser while, in 1Password’s words, the credential never reaches the model, its memory, or Anthropic’s systems. The Wall Street Journal even tested it by letting Claude into a retirement account (with a real password, closely watched — their conclusion: some chores are still better left to humans).

This launch matters for one reason bigger than the product: it settles the core question of the agent era. Where the secret lives decides what can leak. A password sitting in a model’s context can end up in logs, transcripts, or a cleverly-manipulated response. A password the model never sees cannot be leaked by the model — that scoped little sentence is the entire design philosophy.

Here is the checklist that follows from it. Seven points, each one actionable today.

1. Never paste secrets into a chat

The most common mistake is also the simplest: pasting a password, API key, or database connection string into an agent’s chat “just this once.” The moment a secret enters model context, it exists in that conversation’s history, possibly in provider logs, and in anything the agent later writes based on it. Type secrets into password fields and secret managers — never into prompts.

2. Secrets live in a manager; agents get them at runtime

The 1Password-for-Claude design is the pattern to copy: the credential stays in the vault, and it is injected at the last second, directly into the page — decrypted only when needed, gone when the task ends. The model plans around a placeholder; the tool layer resolves the real value at call time. This pattern is not exclusive to 1Password — it works with the macOS Keychain, a cloud secret manager, or any vault with a CLI. I am building the same pattern into my own agent gateway, and the demo below shows how simple the core idea is.

3. Approval is per task, not forever

1Password’s flow shows you which credential the agent wants and why, then waits for your biometric approval — and access ends when the task completes. Their “Agentic Mode” locks the rest of the vault while an agent has the browser. Copy the principle everywhere: an agent should get one login, for one job, for one session — never standing access to everything you have.

4. Treat invites, emails, and webpages as untrusted input to your agent

The scary story, and it is real: security researchers at Zenity showed that a single calendar invite carrying hidden instructions could hijack a different browser agent — Perplexity’s Comet — with zero clicks, steal local files, and reach into a password vault. It was disclosed and patched. To be clear: this was not 1Password for Claude, and not Claude — but the lesson is universal. Everything your agent reads — invites, emails, webpages, PDFs — is input, and input can carry instructions. This attack class is called prompt injection, and it is active, not theoretical.

Two settings to change today: in Google Calendar, set Settings → Event settings → Add invitations to my calendar to “When I respond to the invitation in email.” In Outlook, disable automatic invite processing. An invite that never lands on the calendar can never whisper to an agent that reads your calendar.

5. Some accounts, an agent never touches

Draw the line in advance, while you are calm: banking and retirement accounts, 2FA seeds, recovery codes, and your primary email (it resets everything else) stay human-only. The WSJ let Claude into a 401(k) as a monitored experiment and walked away saying some chores are better left to humans. Convenience compounds; so do blast radii.

6. Prefer scoped tokens over master passwords

When an agent needs API access, do not hand it the account password — mint a token that can do only the needed thing: read-only if possible, one service, an expiry date, a spending cap if the platform offers one. A leaked scoped token is an incident; a leaked master credential is a catastrophe. Every serious platform (GitHub, AWS, Google Cloud) supports this — use it.

7. Know what your agent can reach (and prove the secret is not in context)

Once a month, ask: what credentials, files, and connected apps can my agents currently touch? Remove what is stale. And if you build agents yourself, make the safety testable. In our demo, the agent logs into a local site with a password resolved from the macOS Keychain at call time — and the last line of its output is the audit:

MODEL CONTEXT (everything the model sees):
  "username": "shiv",
  "password": "<runtime-injected -- never in context>"
TOOL CALL: browser.login(site, username, ******)
  -> resolving secret from macOS Keychain at call time
  -> POST /login  ->  HTTP 200
RESULT: "Welcome back, shiv"
Password bytes inside model context: 0

That final number is the whole philosophy as a unit test: count the secret’s bytes inside the model’s context — the answer must be zero. If you can print that line for your own agent, you understand this better than most teams shipping agents today.

The one-sentence version

Agents will get more capable every month, and prompt injection will not disappear — so put your secrets where the model cannot see them, approve access per task, scope every token, and keep a short list of accounts no agent touches. Defense in depth, not blind trust: that is how you get the convenience without donating your passwords to the future.