1Password for Claude Logs an Agent In Without the Password. The Part It Doesn't Fix Is the Part That Bites.

Zero-exposure credential delegation means a leaked model context can't leak your login. It does nothing about the agent doing the wrong thing with a login you approved.

1Password shipped a feature on July 16 that sounds like a password manager update and is actually an argument about identity. An AI agent can now finish a task that needs a login, and the password never enters the model, its memory, or Anthropic's servers. Claude knows it signed in. It never sees what it signed in with.

Read that again, because the gap between those two sentences is the whole story. For the first time there is a supported way to let software act with your credential without handing it the credential. That is a real thing that did not exist a week ago, and it closes a hole that everyone building browser agents has been staring at.

It also creates a very specific kind of false comfort, and the marketing is going to lean on it hard. So let me take a clear position up front: 1Password for Claude is a genuine improvement to one part of the agent security problem, and it leaves the harder part exactly where it was.

What actually shipped

Here is the mechanism, because the mechanism is what makes the claim true or false.

Claude in Chrome can already click around a site, add items to a cart, edit account details, complete a checkout. The wall it hits is the login page. Until now you had two bad options: type the password yourself and break the automation, or hand the agent your password and hope. 1Password calls its third option zero-exposure architecture.

When Claude reaches a sign-in page, 1Password shows you which credential is being requested and why. You approve with a biometric prompt, Touch ID on a Mac. 1Password then injects the credential and any one-time code straight into the page through its own channel, outside the agent's view. The password and the TOTP never land in the model's context. Access is scoped to that one task and ends when the task ends. After autofill, 1Password checks the secret wasn't exposed on the page, and if submission fails it clears the filled values before handing control back (1Password).

The example in their own post is mundane on purpose. Your Audible credits are about to expire, so you ask Claude to look at your wishlist and redeem one. Claude navigates to the store, you approve the login, 1Password supplies it, the audiobook lands in your library, and you never typed a password or a code. Same pattern for a small business owner asking Claude to pull a Stripe revenue summary without walking through MFA by hand.

There is a second feature that matters more than it looks. It's called Agentic Mode, and it addresses a different attack: what happens when a browser agent takes control of a browser where your whole vault lives. The moment a compatible agent takes over, the 1Password extension locks itself down. The interface hides, and the agent can only touch the specific logins approved for the current task. The rest of the vault goes out of reach. This works even if you never set up the Claude integration, and it covers agents beyond Claude (1Password, Engadget).

That's the build. It's careful work. The scoping, the biometric gate per request, the post-fill exposure check, the vault lockdown when an agent is driving. None of that is theater.

Why this is the right shape for the problem

The framing 1Password put on it is the real news, more than any single feature: agents are becoming a new class of identity, and they need governed access the same way employees and service accounts do. Their CTO put it plainly. The answer isn't handing agents your secrets. It's letting a user give an agent permission to use a credential without letting the agent see it.

I think that's correct, and I think it's the pattern that wins. We spent the last two years treating an agent as a smarter chatbot that happens to have tools. That mental model is wrong once the thing can click "buy" and "submit." At that point it's an actor in your systems, and actors get identities, scopes, and audit trails, not a shared password taped under the keyboard.

1Password is not the only place this is landing. Their same access-layer play already covers developer credentials for OpenAI's Codex and an MCP server for Kiro. The MCP spec itself is moving its authorization model onto OAuth and OpenID Connect footing in the revision landing July 28. The whole industry is answering the same question this month: what identity does an agent act under, and what access should it get. Credential delegation that keeps the secret out of the model is a clean answer to the first half.

If you use Claude in Chrome for anything that touches a login, turn this on. It removes a real category of exposure for close to zero effort, and "the model literally cannot leak a password it never received" is a property worth having.

Now the part the announcement glides past

Zero-exposure is not zero-risk, and those two words are close enough that the difference will get lost. So let me make the difference concrete.

The exposure 1Password removes is credential leakage. If Claude's context gets logged, scraped, cached, or exfiltrated, your password isn't in it. Good. That's a genuine class of attack, gone.

The risk it does not touch is the agent taking a wrong action under access you approved. Think about what the approval actually authorizes. You biometric-approve Claude to use your Stripe login for a task. From that moment the agent is operating inside an authenticated Stripe session. The password never entered the model, and it doesn't need to. The session is already live. If that agent has been steered by a poisoned web page, a malicious support-ticket, a comment in a document it read, it can issue a refund, change a payout account, or pull data, and every one of those actions rides on the access you granted. The lock on the front door got much better. The person you handed the key to still does whatever the note in their pocket says.

This isn't hypothetical hand-waving. An agent built on a language model cannot reliably separate data from instructions. Text it reads while doing your task can rewrite what it thinks the task is. Security teams spent 2026 reporting that prompt injection shows up in a large share of the production agent deployments they assess, and researchers keep showing these attacks transfer across systems better than anyone would like. 1Password's own model doesn't claim to solve this. It solves credential exposure, which is a different and narrower thing.

Agentic Mode narrows the blast radius, and that's the right instinct, assume the agent will eventually be compromised and cage what it can reach. But scoping access to "only the credentials approved for this task" still leaves the agent free to misuse the one credential it was correctly given for the one task you actually wanted. Scope limits how many wrong things it can do. It doesn't stop the wrong thing inside the scope.

There's a quieter design tension too. The friction this removes is the friction that used to make you pay attention. When redeeming a credit meant logging in yourself, you saw the account, the balance, the thing you were buying. Now you biometric-approve a credential request and look away while the agent works. Approval fatigue is real, and a system that asks for a thumbprint fifteen times a day trains you to press the thumb without reading the screen. The consent prompt is only a control if you actually read it.

Put this into practice

If you're going to use it, use it with the risk in view, not despite it.

Start narrow. Turn it on for low-stakes, read-heavy tasks first: pulling a summary, checking a wishlist, reading a dashboard. Save the write-capable and money-moving accounts until you've watched how the agent behaves on things where being wrong costs an afternoon, not a payout.

Read the approval screen every time, especially which credential and why. That prompt is the last human checkpoint before the agent is inside an authenticated session. The whole security model assumes you looked. If you're rubber-stamping, you've removed the one control that separates delegation from handing over the keys.

Keep the account's own guardrails on. Zero-exposure is a layer, not the layer. Transaction limits, payout-change confirmations, email alerts on account changes, and MFA on the actions that matter still do work the credential model doesn't. If Stripe emails you when a payout account changes, that alert is now part of your agent-security stack.

Prefer accounts with real audit logs and easy revocation. When you're delegating to something that can be steered by input you don't control, the questions that matter are "can I see what it did under my identity" and "can I cut it off fast." Design for revocation before convenience.

Check that you're actually covered. This is Mac-only right now, and it needs four pieces installed and talking to each other: the 1Password desktop app, the 1Password browser extension, the Claude desktop app, and the Claude in Chrome extension (1Password). Support for payment cards and personal details like names and addresses is coming after launch, not in the box today.

Where I land

The honest summary is small and worth holding onto. 1Password for Claude moved a boundary. It did not close one.

The boundary it moved is credential exposure, and moving it is real progress that I'd adopt today for the right tasks. The boundary it did not close is agent misbehavior under authorized access, and that's the one that shows up in the incident report. Treat every authorized agent action as possibly the product of input you never saw. Log what agents do under your identity. Assume the agent will get steered, and build so that when it does, the damage is bounded and reversible.

Governed access is the floor. It's a good floor, and most agent setups don't have it yet. Just don't mistake the floor for the finish line, and don't let "the model never saw your password" slide into "so the agent is safe." Those are not the same sentence, and the gap between them is exactly where you'll get hurt.

Sources: 1Password blog: 1Password for Claude; Engadget; SiliconANGLE. Prompt-injection prevalence figures referenced are vendor-reported and described qualitatively. This piece touches security topics; verify specifics against the primary documentation before relying on them.