1Password published usage instructions for "1Password for Claude" on July 16, 2026, implementing a change that lets Claude Cowork use saved passwords and one-time codes to log into websites without exposing them to the model. When Claude requests a needed login and a human approves it on the 1Password screen, the 1Password browser extension takes over everything from entry to submission.
Previously, having an AI agent that operates a browser authenticate required either the user taking over midway through the operation or accepting the risk of secret values entering the agent's context. This integration removes the authentication process from the LLM's reasoning path, returning only "which login was used" and the processing result to Claude. However, the scope starts with Claude Cowork on Mac, and 1Password does not guarantee safety for actions taken after login.
Anthropic Integration Connected Through Cowork on Mac
Using this requires a Mac, the 1Password desktop app and browser extension version 8.12.28 or later, Claude Desktop, and the Claude browser extension. From Claude Desktop's "Customize" menu, open "Connectors," select 1Password, and approve the connection with Touch ID or your 1Password account password. After that, when you ask Cowork to perform a task using a website, 1Password presents candidate login items. Once a human selects and approves the item to use, the 1Password browser extension handles the input and submission on their behalf.
For 1Password, autofill for AI agents itself is not entirely new. The company's developer documentation has offered Agentic Autofill using Browserbase Director as early access. This time, because the connection can be made from Claude Desktop's settings screen, developers can bring this into Cowork's browser tasks without building their own agents.
There is also a gap between the scope of the announcement and the current implementation. In March 2026, 1Password revealed Anthropic's plan to integrate 1Password with the Claude browser extension, Cowork, and Claude Code. The official July procedures describe usage with Claude Cowork on Mac, and a method for introducing this to Claude Code has not yet been shown. Of the broader partnership vision, general web login functionality is the first piece to reach the product.
A 9-Hour-Capped Encrypted Cache and Three Local Pathways
The mechanism begins with initial app verification. 1Password uses macOS's code signing feature to check whether the connecting Claude Desktop is properly signed, whether its signing ID is on the allowlist, and whether it was published from Anthropic's verified Apple Developer Team. Connections from processes that don't meet these conditions are rejected.
Even after pairing, blanket permissions are not handed to Claude. Each time a new agent session begins, 1Password issues encrypted credentials tied to that session's identifier. Subsequent requests must cryptographically prove possession of the session key, and items authorized for a different session cannot be referenced.
The integration's communication consists of three pathways within the Mac. Claude Desktop and the 1Password desktop app connect via local IPC. Between the 1Password app and the company's browser extension, an end-to-end encrypted channel with mutual authentication using the Noise protocol operates. The Claude-side and 1Password-side extensions exchange only requests, metadata, and success/failure via standard browser extension messaging, with each call verified using the registered session's key. The channel carrying secret values is the encrypted channel from the 1Password app to the company's extension.
Approved login items are encrypted in memory within the 1Password browser extension using AES-256-GCM and are never written to disk. They are erased when the task finishes or the browser closes, and even if they persist, 9 hours is the maximum. What Claude receives is the item name, username or email address, the saved website, and whether the process succeeded or failed—not the password or one-time code. This narrows exposure from a method that fully exposes the secret value to one that reveals only the necessary metadata.
A boundary is also placed at the moment of input. While 1Password enters and submits the form, Claude stops reading and tracking the page. It only enters values on pages matching the saved website, and if submission fails, it clears the values before notifying of the failure. This design leaves no window for the model to observe the password field.
Why a Dedicated Authorization Path Instead of MCP?
This implementation concretizes the policy that 1Password has previously articulated: "don't let the LLM make authorization decisions." In 2025, the company stated that while it evaluates the Model Context Protocol (MCP) as a mechanism for connecting to app information and tools, it would not flow raw credentials through MCP's data path. The idea is that the non-deterministic communication the model handles and the authorization processing that decides who is allowed to do what should be separated.
1Password does not treat the credential request text arriving from Claude as a trusted instruction either. The reason for the request and the target site are merely plaintext used to surface search candidates; by themselves they cannot open the vault. A human confirms the target item on a 1Password-specific screen and decides whether to substitute it or refuse. Because secret values are not directly released from chat-based text, the authorization decision remains on 1Password's deterministic screen.
When the agent operates a browser tab, the 1Password extension switches to Agentic Mode. It removes UI such as inline suggestions and save notifications from the page, preventing Claude from touching other items outside the approved flow. During Agentic Mode, humans also cannot use the normal autofill UI, and this state is not released until Claude's tab group is closed. This behavior prioritizes session boundaries over convenience.
For enterprise use, administrators must enable the "Allow AI agents to autofill for users" policy before a connection can be made. Each authorization is recorded in the 1Password item's usage history. However, the broader auditing functionality spanning human and AI activity, which was described as "coming soon" in the March 2026 Unified Access announcement, has not all been completed in this release. What currently remains is a record of authorized credentials, which is distinct from auditing what actions Claude performed after login.
Protecting Pre-Login, But Post-Login Is Claude's Responsibility
The scope of protection that 1Password provides extends to storing credentials, requesting human approval, and entering them into forms via a secure channel. After a successful login, what Claude reads on the site and which buttons it presses are entrusted to Claude's own safety features and the user's instructions. Even if the authentication secret can be hidden, the privileges of the authenticated session itself cannot be neutralized.
The destination site also lies outside this boundary. Once a form is submitted, credentials pass to the site and to scripts on the page. 1Password restricts input targets to pages matching the saved URL and clears values on failure, but it cannot control how the legitimate site itself stores or processes them. Nor can this local separation prevent a case where the device itself is fully compromised with administrator or same-user privileges.
Trust in the partner app also remains. After verifying Claude Desktop's signature at the initial connection, 1Password assumes that the app correctly identifies each agent session. If Claude Desktop is compromised, it could still issue credential requests, but even in that case, the requester and target item are displayed on 1Password's screen, requiring human approval.
Functionally, what can currently be handled is the username, password, and one-time password of Login items. Social logins such as "Sign in with Google" may not work correctly, and passkeys are not supported. The integration with Claude Code and expansion to other environments that 1Password outlined in March are also not included in this procedure.
What enterprises should verify before expanding adoption is whether credential usage history and Claude's action logs can be cross-referenced at the same session level. Once expansion beyond Mac, passkey support, and post-login action auditing are all in place, this design will become a practical management layer for connecting browser agents to business accounts. For now, this should be evaluated as a limited initial implementation—a significant step in keeping secret values outside the model.