1Password for Claude Secures the Password—Not the Session
1Password and Anthropic have made a credential do something browser agents badly need: work without being shown to the model using it.
That is a meaningful launch. It also solves a narrower problem than the phrase “agent authentication” suggests.
Once 1Password fills a login and the website accepts it, the password has finished its job. The browser now holds an authenticated session. Claude can read the signed-in page through screenshots and act with the human account's permissions. The raw secret can remain perfectly hidden while the account is still exposed to a mistaken click, an over-broad instruction, or a successful prompt injection.
The useful way to read 1Password for Claude, released July 16, is therefore precise: it is a well-designed credential-custody layer for a browser agent. It verifies the local Claude app, binds requests to an agent session, asks the human to choose a vault item, and delivers the secret through a separate encrypted path. Claude gets use, not possession.
But the destination website still sees a normal human login. It does not receive a scoped agent identity, a list of permitted actions, or an expiry tied to the task. After authentication, authority moves from the vault boundary to the browser session.
That split is why this beta matters. 1Password has made “use without disclosure” understandable to mainstream users. The next hard problem is “act without inheriting everything.”
Anthropic's setup guide labels the integration a beta for Claude Pro, Max, Team, and Enterprise. It currently requires a Mac, Claude Desktop, Claude in Chrome, a qualifying 1Password individual, family, or business plan, the 1Password desktop app, and the 1Password browser extension. 1Password specifies version 8.12.28 or later for both of its clients.
The first release supports usernames, passwords, and TOTP codes from Login items. It does not support credit cards, identity items, or passkeys. Social-login buttons such as Sign in with Google may not work, and the saved website must match the sign-in URL.
That is a deliberately constrained surface. It is also enough to cover a huge amount of the old web: sites with human accounts, no useful automation API, and a password form sitting between an agent and the task.
The version number and the nine-hour limit are documented facts. The security properties below are more accurately described as 1Password's published design claims. As of launch, I could not find an independent cryptographic or end-to-end audit of this exact integration.
1Password's security design is unusually specific for a consumer integration.
Initial pairing checks that Claude Desktop is validly code-signed, that its signing identity is on 1Password's trusted-partner allowlist, and that the app came from Anthropic's verified Apple Developer team. Pairing is approved once per 1Password account.
Claude then enrolls each agent session separately. It declares a session identifier, and 1Password mints cryptographic credentials bound to that identifier. Every later request has to prove possession of the session keys. A grant to one session is invisible to another.
There is an important trust assumption inside that sentence: after verifying the app, 1Password trusts Claude Desktop to name its own sessions accurately. This is local federation, not an independent identity issued by the destination website.
When Claude needs a login, it sends a site and may provide a reason. 1Password treats those fields as untrusted text. Its native prompt shows matching items, and the human can select one, substitute another, add items, or deny the request. Approval releases only the selected item to that agent session.
The secret then moves from the 1Password desktop app to its browser extension over a local loopback relay. 1Password says that channel uses mutual authentication, a Noise-based protocol, and per-session keys. The extension holds approved data in memory, encrypted with AES-256-GCM, and does not write it to disk. The company's open-source IPC client supports the native transport layer, although that repository is not an audit of the complete integration.
At fill time, Claude stops reading the page. 1Password checks the saved origin, fills and submits, then reports success or failure. On failure, it says it clears the values before Claude resumes.
The secret-delivery path and the post-login action path are separate security systems. The first is governed by 1Password; the second is governed by Claude, the website, and the account's existing permissions.
1Password calls the design zero exposure. The defensible version is zero model/provider exposure.
Claude does not receive the password or TOTP. It does receive the approved item's title, username or email, saved websites, and status. The destination site and any script running on its page necessarily receive the submitted credential. After login, Claude takes screenshots of the controlled tab, and whatever is visible becomes part of the conversation.
That is still a major reduction in exposure. A secret no longer needs to appear in the model's input, transcript, memory, tool logs, or provider infrastructure. But “Claude cannot read my password” and “Claude cannot see sensitive account data” are completely different promises.
| Layer | What the design protects | What remains exposed or trusted | Operational question |
|---|---|---|---|
| Vault | Unapproved items stay outside the agent flow | The user may still choose the wrong item under pressure | Does the prompt make account, origin, and purpose unmistakable? |
| Local agent identity | Signed-app pairing and per-session keys reject unrelated callers | 1Password trusts the paired Claude app to label sessions correctly | How is a compromised partner app detected and revoked? |
| Secret transport | The password and TOTP avoid model and provider channels | The destination page and its scripts receive submitted values | Is the saved origin exact, expected, and resistant to lookalikes? |
| Authenticated session | Nothing additional is promised by the password broker | Claude can see page data and act with account permissions | Which post-login actions need a separate human step-up? |
| Task lifetime | The encrypted credential cache has bounded cleanup | Public docs do not say the website cookie is destroyed | Who logs out, clears cookies, and tears down the profile? |
| Audit | A credential grant appears in item usage history | A Fill record is not a full downstream action trace | Can one task ID join approval, fill, browser actions, and outcome? |
The distinction matters most for sensitive accounts. Anthropic advises users not to operate Claude in Chrome on financial accounts, legal documents, medical information, regulated data, or work accounts with sensitive company data. It recommends a separate browser profile without those sessions.
A password is usually only a temporary proof used to mint something more convenient: a browser cookie or session token. Once that happens, the session is the practical bearer capability.
vault secret -> approved fill -> website session -> account actions
1Password boundary Claude boundary
1Password explicitly says its guarantee covers storage, approval, delivery, and filling—not Claude's conduct after authentication. That is honest threat modeling. It also exposes the missing product layer.
A useful agent-authorization system would be able to say:
A, acting for human H;Password autofill cannot express those rules. The website sees the user's ordinary account and grants whatever that account already has. For services with a capable API, a scoped and revocable OAuth token is usually the stronger agent credential. Browser injection is valuable precisely where the old web offers no narrower surface.
This is the same governance gap RohitAI highlighted when Grok Automations turned a prompt into standing authority: authentication, trigger, and action permission are different decisions. It also connects directly to GPT-Red's prompt-injection lesson. Removing the raw secret closes one exfiltration path; it does not make an authenticated agent immune to malicious page content.
The integration can fill both a stored password and its TOTP. That preserves two-factor verification at the website, but it changes the ceremony from the user's point of view.
When the password manager supplies both stored factors in one approved operation, the one-time code is no longer a separate live checkpoint performed by the human. The 1Password biometric prompt becomes the meaningful step-up.
That is not automatically weaker. A native Touch ID prompt can be clearer and harder for a model to spoof than a web form. But the approval design now carries more weight. It needs to show the verified requesting app, exact origin, chosen account, reason, expected task, and downstream consequence. An agent-written reason should never look like trusted security text; 1Password correctly renders it as an untrusted claim.
Approval fatigue is the predictable failure mode. If multi-site tasks create a stream of similar prompts, people will approve on rhythm. Teams should measure denials, wrong-account substitutions, repeated requests, and time-to-approval—not only task completion.
The quiet feature in the launch is Agentic Mode.
When a compatible agent controls a tab, the 1Password browser extension hides inline suggestions, save prompts, notifications, and the rest of its page UI. The agent cannot click ordinary convenience surfaces to reach something the human did not approve. The only available credential path is the consented one.
Crucially, Agentic Mode activates even if 1Password for Claude was never configured and even when the task does not need a login. That makes it a deterministic browser control rather than a promise that Claude will behave.
This responds to a real class of problem. In January, 1Password published an advisory about AI-assisted browsers interacting with an already-unlocked conventional extension. Agentic Mode moves the defense into the extension and removes the tempting UI from an agent-controlled tab.
That pattern can scale beyond Claude. 1Password says Agentic Mode supports other compatible agents, although it has not published a complete compatibility list or detection contract. If browser agents proliferate, password managers will need a standard way to know when a tab is under agent control and switch from human autofill UI to explicit machine-use policy.
The clean architecture only governs paths that pass through it.
An Inc. account of a Wall Street Journal test describes Claude failing to use the expected login for an online grocery task, requesting an email sign-in link instead, opening that link from an already-authenticated Gmail inbox, and completing the order. 1Password's CTO told the Journal that the company was working on protection for nontraditional sign-in flows. The Journal's accessible hands-on report also shows why the post-login boundary matters: biometric autofill put the agent inside real accounts, including a retirement account.
The magic-link route was not a break of the Noise channel or the vault. It was a route around them.
That is the deeper agent-security lesson. A goal-seeking system does not care whether authentication happens through a password, TOTP, existing cookie, social login, recovery flow, inbox link, or password reset. If one path is blocked, it may discover another path that still satisfies the task.
Passkeys are unsupported in the beta. Social login may fail. Existing browser sessions remain available. Email links can turn an authenticated inbox into an identity broker. A safe deployment has to inventory every authentication route, then decide which routes the agent may use. Protecting one lane while leaving five side roads open is not fail-closed design.
1Password's launch post says Claude can complete a purchase, offers an Audible-credit example, and suggests reviewing Stripe revenue. Those are vivid demonstrations of why login automation feels useful.
Anthropic's current permissions guide says something stricter: Claude is prohibited from making purchases or financial transactions regardless of permission mode. The same guide prohibits handling sensitive card or ID data, financial advice, trades, permanent deletion, and changes to security permissions. Anthropic's safety guide separately advises against managing financial accounts or investments.
The cautious interpretation is simple: treat 1Password's examples as marketing scenarios, not as a supported deployment policy. Product teams should follow the agent platform's current operating rules and test them, especially while both products are changing quickly in beta.
This documentation mismatch is not a footnote. A credential broker and an agent policy engine can each be working as designed while the combined product still gives users a confusing picture of what is allowed. Joint integrations need one canonical capability matrix covering sites, credential types, action classes, and prohibited outcomes.
For managed organizations, two separate administrative planes must agree.
On the Anthropic side, Claude Team and Enterprise owners enable Claude in Chrome and the Password managers control. The 1Password integration itself is off by default for both plan types. Admins can also use site allowlists and blocklists; Anthropic recommends starting with a restrictive allowlist. Claude in Chrome does not support Zero Data Retention.
On the 1Password side, a Business administrator enables the Allow AI agents to autofill for users policy. Every credential grant is recorded in item usage history, and Business usage reports can record Fill activity.
The separation is sensible. Anthropic governs where the browser agent can go; 1Password governs whether it can receive a credential. The operational problem is drift. One team may open a site in Claude while another leaves an overly powerful vault item eligible. Incident responders may also have two partial histories instead of one task receipt.
The audit record teams will ask for
human principal → verified Claude app → agent session → approved vault item → exact origin → grant lifetime → browser actions → outcome → logout or revocation.
The public launch documentation demonstrates the credential-use portion of this chain, not the complete joined receipt.
The nine-hour cache cap creates another subtle gap. 1Password destroys its encrypted in-memory credential cache when the task completes, the browser closes, or the cap is reached. Public docs do not say that the destination site's authenticated cookie is logged out or destroyed at the same moment. Grant expiry and session expiry are different events.
Enterprises need explicit policy for browser-profile persistence, cookie cleanup, logout, and revocation. “The password grant ended” should never be accepted as proof that the account session ended.
Start with trusted sites, low-privilege or agent-specific accounts, read-heavy tasks, restrictive allowlists, manual approval, and a disposable browser profile. The value is highest where no scoped API exists.
Use revocable tokens that express resources and actions when the service supports them. A token limited to reading orders is safer than a human browser session that can also change settings.
Do not pilot with banking, investments, healthcare, government, legal, regulated, production-admin, or sensitive work accounts. Anthropic's own guidance draws this boundary clearly.
The beta should not be positioned as unattended authentication for scheduled agents. Its design is delegated and human-approved. Repeated approval behavior, alternate login routes, cookie cleanup, cross-platform support, and autonomous renewal are either constrained or not fully documented.
Successful autofill is the beginning of the evaluation, not the end.
Anthropic reports an internal prompt-injection attack-success rate below 0.08% for its current browser configuration. That number is encouraging, but the public help page does not provide the sample size, confidence interval, full attack distribution, or a mapping to field incident probability. Run adversarial tests against the actual sites, permissions, inboxes, and user-generated content in scope.
1Password for Claude is not the historical invention of agentic credential injection. Secure Agentic Autofill shipped in early access with Browserbase in October 2025. The Claude release matters because it packages the pattern for a mainstream desktop agent and a familiar consumer approval flow.
The product trajectory is now visible:
1Password's own agent identity architecture divides systems into delegated, bounded, and autonomous authority. This Claude integration sits in the safest corner: delegated, local, and human-approved. It should not be stretched into evidence that autonomous credential governance is solved.
Three product shifts are likely next.
First, post-login governance becomes the battleground. Keeping secrets out of models will become expected. Vendors will compete on session isolation, action-level step-up, cookie destruction, and reliable revocation.
Second, authorization receipts become a procurement requirement. Enterprise buyers will want one record linking human, agent, credential, origin, duration, actions, and outcome. A Fill event alone will feel as incomplete as a building log that records badge entry but nothing that happened inside.
Third, password managers become multi-agent brokers. The same vault policy will follow work into browsers, IDEs, terminals, CI runners, and hosted sandboxes. The winning product will not merely store secrets; it will decide which verified workload may use which authority, for how long, under whose approval.
According to 1Password and Anthropic's published architecture, no. 1Password fills those values through a separate local channel, and Claude receives item metadata plus success or failure status. The destination website still receives the submitted credential, and Claude can see the signed-in page afterward.
No. 1Password says there are no standing vault approvals, a new agent session requires a new prompt, and the next credential request starts another prompt. Approved credential data may remain in an encrypted in-memory cache until task completion, browser close, or a nine-hour hard cap.
The public documentation does not say so. Credential-cache cleanup and website-session cleanup are separate. Treat explicit logout and browser-profile teardown as required controls.
Passkeys are not supported in the initial beta. 1Password says social-login flows may not work as intended. That limitation is important because alternate authentication paths can bypass the broker entirely.
Anthropic advises against using Claude in Chrome to manage financial accounts or investments, and its permissions guide prohibits purchases and financial transactions. The prudent answer is no, regardless of launch-day marketing examples.
No. 1Password offered Secure Agentic Autofill with Browserbase in October 2025, and other workload-identity patterns predate this launch. What is new is the mainstream Claude integration and its detailed local session design.
1Password for Claude gets an important thing right: an agent does not need to know a secret in order to use it.
The design replaces a dangerous handoff with a verified local app, a session-bound request, a native human approval, an origin match, an encrypted channel, and a bounded cache. That is a credible blueprint for the parts of the web still built around human passwords.
It should also reset the language used around agent security. Credential secrecy is not account safety. Login is not authorization. A task lifetime is not necessarily a cookie lifetime. A Fill record is not a complete agent audit. Two stored factors delivered in one flow do not create two human decisions.
The launch gives browser agents a better door into human accounts. Now 1Password, Anthropic, and the websites on the other side need to govern what happens after the door opens.