1Password for Claude lets Claude complete tasks that require signing in, without ever seeing your passwords or other secrets. The agent asks 1Password for access, you approve the request in the 1Password desktop app, and 1Password fills the credentials directly into the page. Secret values are never shown to the agent, never enter the model’s context, and never pass through the agent provider’s infrastructure.
1Password for Claude requires the 1Password desktop app and the 1Password browser extension, and currently supports signing in with login items, including one-time password codes.
This article describes the security model of the 1Password side of the integration: how Claude is identified, how you authorize credential access, and how credentials are protected on their way into the page.
Security model
1Password for Claude is designed around four rules:
- The agent never handles secrets. Claude can describe what it needs and trigger a fill, but credential values are decrypted and filled exclusively by 1Password’s own software. The agent receives item metadata and success or failure statuses, but never passwords or other secret values.
- A human approves every credential release. Each request Claude makes is shown to you in a prompt from the 1Password desktop app. There are no standing approvals: a new agent session means a new prompt.
- Access is scoped and short-lived. Credentials are released to a single Claude session, held encrypted with keys specific to that session, and discarded when the session ends or after a hard time limit.
- Everything sensitive is governed by end-to-end encryption. Vault data remains encrypted at rest, as always. In transit, approved items move from the 1Password desktop app to the 1Password browser extension over a mutually authenticated, end-to-end encrypted channel. Nothing inbetween can read them: not the agent, not the local transport.
Authorization model
One-time app pairing
Before Claude can request anything, the Claude desktop application must pair with the 1Password desktop app. When a pairing request arrives, 1Password identifies Claude using the operating system’s code-signing facilities: the application must be validly signed, its signing identity must appear on 1Password’s allowlist of trusted partner applications, and it must have been published by Anthropic’s verified Apple Developer team. Requests from any other process are rejected.
If those checks pass, 1Password shows a pairing prompt naming the verified application and the account it will be allowed to make requests against. Pairing is per-account, requires your explicit confirmation, and is remembered so that you don’t need to re-pair for every task.
Per-session agent identity
Claude doesn’t get blanket access. It enrolls each agent session individually: when a new agent session starts, Claude declares an identifier for it, and 1Password mints cryptographic session credentials bound to that identifier. This is a local federation model, similar in spirit to OIDC. 1Password verifies the partner application’s identity through OS code signing, then trusts it to accurately name the agent sessions it creates. From that point on, authentication is purely cryptographic: every request must prove possession of that session’s keys, and credentials granted to one session are invisible to every other.
Human-in-the-loop approval
To request credentials, the agent describes what it’s trying to do (for example, sign in to example.com) and can attach a short reason. 1Password treats every field of that request as an untrusted claim:. This claim is only used to find matching items and is rendered as plaintext in the prompt, so nothing in a request can trigger a release or impersonate 1Password’s UI.
The 1Password desktop app then shows an authorization prompt listing the requested access, with matching vault items preselected. You can swap items, add others, or deny the request entirely. Approving releases exactly the items you selected, to exactly that agent session, and only until that session ends. The next request starts with another prompt.
On 1Password Business accounts, administrators additionally control whether Agentic Autofill is available to team members through the “Allow AI agents to autofill for users” security policy.
Technical design
Communication
All credential-bearing communication stays on your Mac; secret values are never routed through 1Password’s or the partner’s servers.
- Claude desktop app ↔ 1Password desktop app: Native local IPC, provided by open source components , used for pairing and for enrolling agent sessions.
- 1Password browser extension ↔ 1Password desktop app: A local loopback relay. The relay is a blind transport: every message crossing it is end-to-end encrypted between the desktop app and the extension using a Noise-based protocol with mutual authentication and per-session keys, so the relay can neither read nor alter payloads.
- Partner browser extension ↔ 1Password browser extension: Standard browser extension messaging, carrying only requests, metadata, and statuses. This API assumes that any extension might attempt to connect to it, which is why every call must cryptographically prove that it belongs to an enrolled agent session. Anything else is rejected.
Credential delivery
When you approve a request, the selected items travel over the end-to-end encrypted channel to the 1Password browser extension. The extension holds them encrypted with AES-256-GCM, under keys derived from that session’s secrets, in memory only. They are never written to disk. The cache is destroyed when the agent signals that its task is complete, when the browser closes, and in any case after a hard cap of nine hours. Every grant is also recorded in the account’s item usage history.
What the agent can see
The agent can list the items you approved, and receives overviews only: item title, username/email, and the websites saved on the item. This is comparable to what 1Password’s own inline autofill suggestions display on a page: enough to pick the right credential, never the secret values. Every other response the agent receives is a success or failure status.
Agentic Mode
While an agent is driving a browser tab, the 1Password browser extension removes all of its user interface from the page: inline suggestions, autosave prompts, and notifications. An agent operating the page therefore can’t click through 1Password’s own convenience surfaces to reach anything you haven’t approved. The only way for it to use 1Password is the consented flow described above. Agentic Mode is scoped to the tab the agent controls and ends when the agent session ends or the tab closes.
Filling and submission
Agentic fills use 1Password’s standard autofill engine, with its standard safeguards. Most importantly, an item is only ever filled into a page that matches the websites saved on that item.
A fill is the one moment where credentials actually exist in the page, so the integration is designed to keep it out of the agent’s sight. While 1Password fills, the agent sleeps: it stops reading and tracking the page until 1Password reports a result. In that window, 1Password fills the credentials, submits the form, and verifies that the submission actually happened. On success, the credentials have left the page by the time the agent looks again. If the submission fails, 1Password clears every filled value from the page before reporting the failure, so the agent never resumes on a page that still holds secret values.
Accepted risks
- A privileged attacker on your Mac. As with any local security boundary, an attacker with administrative or same-user code execution on your device can interfere with these protections. 1Password for Claude’s checks defend against unauthorized software abusing the integration, not against a fully compromised machine.
- Trust in the partner application after pairing. 1Password verifies the Claude desktop app cryptographically at pairing time, then relies on it to accurately represent its agent sessions. A compromised partner application could issue credential requests, but every release would still require your approval in a 1Password prompt that names the requesting app.
- Submitted credentials belong to the website. Once a form is filled and submitted, the values are in the hands of the destination site and any script running on that page. 1Password cannot control what happens to them from there; this is inherent to signing in, whether a human or an agent initiates it. The mitigations are structural: 1Password fills only after your approval and only into matching pages, submits right away, and clears values from the page whenever submission fails.
- The agent acts inside the signed-in session. After a successful sign-in, what the agent does on the website is governed by the agent product’s own safeguards. 1Password’s guarantees cover the storage, approval, delivery, and filling of credentials, not the agent’s behavior once a session exists.
Was this article helpful?
Glad to hear it! If you have anything you'd like to add, feel free to contact us.
Sorry to hear that. Please contact us if you'd like to provide more details.