1Password for Agents keeps the password out of the model, but the session cookie is still yours to guard

1Password launched 1Password for Agents on 22 October 2026. It lets a personal AI agent use a login from your vault without the agent ever receiving the password. The agent asks, you approve on your own device, and 1Password fills the credential into the sign-in form itself. Anthropic and OpenAI are named partners, along with Meta, SpaceXSI's Grok Bot, Town and nine others.

My read: this is the right primitive, because an injected model can't leak a secret it never saw. But that is half the design. The other half is limiting what an injected model does with the access it gets after login, which is what the dual-LLM / privileged-LLM pattern covers.

What actually shipped

From 1Password's press release and launch blog, the flow works like this: the agent identifies itself to 1Password with a unique digital key. You see which credential is requested and why, and you approve or decline on your own device. In 1Password's words, "1Password directly auto-fills the credentials in the destination site so the agent doesn't have access to the credentials."

On availability, it comes "at no additional cost" for 1Password Individual and Family accounts on 1Password.com. Accounts on 1Password.eu and 1Password.ca are not supported yet.

As for partners, Muse (Meta), Grok Bot (SpaceXSI) and Townie (Town) are live or rolling out. On the launch blog, Anthropic's Claude Duet and OpenAI's ChatGPT Work and dots are listed as "integrations coming soon". Instinct, Browserbase, Browser Use, Dana, KERNEL, Perplexity, Ramp, Tomo and Wajo are listed as coming.

Then there is the caveat 1Password states itself: "the safeguards and controls vary by integration," and "availability, platforms, and capabilities vary by partner integration."

There is an earlier, better-documented version: 1Password for Claude from 16 July 2026, which works through Claude in Chrome on Mac only. Each use requires biometric approval, and access is scoped to the current task and ends when the task does. After filling, 1Password checks that the secret wasn't exposed on the page, and if submission fails it clears the filled values before handing control back. The October launch extends that approve-and-fill model to other vendors' agents.

On the developer side, 1Password's docs describe a separate set of tools for coding agents. op run injects secrets into MCP server processes at startup. The Environments MCP server "doesn't read or return secrets to the AI agent." A beta integration with NVIDIA OpenShell works so that "inside the sandbox, the agent only ever works with placeholders", and a gateway swaps in real values only for approved hosts.

What the product does vs what the marketing implies

Approve-and-fill protects the long-lived secret, not what the session is used for.

The gap: what happens after the fill

Once 1Password fills the form and the site logs in, the agent's browser session holds a session cookie. That cookie is a bearer credential. An agent injected after login can't steal your password, but it can move money, read email or post as you for as long as the session lives. Approve-and-fill protects the long-lived secret, not what the session is used for. That's my read; 1Password doesn't claim to solve it.

The dual-LLM pattern is aimed at exactly that gap. Simon Willison proposed it in April 2023 with three parts. A privileged LLM takes only trusted input (the user) and can call tools. A quarantined LLM reads untrusted content (web pages, emails) and has no tools. A controller, "regular software, not a language model", runs both and executes actions. Untrusted outputs are stored as variables ($VAR1), and "the Privileged LLM only ever sees those variable names."

Willison himself called it "pretty bad" on UX and complexity. Google DeepMind's CaMeL (2025) fixed a real hole in it: the quarantined model could still influence values such as a recipient address. CaMeL has the privileged model emit a restricted Python plan, tracks capability tags on every value, and enforces policies such as "send email only to trusted recipients, otherwise ask the user." The paper says plainly that prompt injection is not fully solved.

Reference architecture

Here is how I'd combine the two, in five layers.

The planner (privileged LLM) sees the user's request and the tool schemas. It never sees raw page or email content, and it never sees any secret. It refers to both only by handle.

The reader (quarantined LLM) parses untrusted content into typed fields. It has no tools. Its outputs are tagged untrusted.

The controller, or policy engine, is deterministic code. It executes the plan and enforces data-flow rules (an untrusted value can't become a recipient, URL or amount without approval). It logs every action.

The credential broker is 1Password for Agents for consumer logins. For API keys, use OpenShell-style placeholders or op run. The secret is injected at the edge (form fill or egress proxy), scoped to one host and one task, and approved per request.

Session hygiene closes it out: run a fresh browser profile per task, kill the session when the task ends, and require step-up approval for irreversible actions (payments, deletes, outbound messages) even inside an authenticated session.

This is the split from non-human identity for agents: the agent gets an identity and a scoped grant, never the human's secret. The controller layer is what the ChatGPT-in-Messages injection shows you can't skip.

What I'd do

If you build agents, never put API keys or passwords in the prompt, the tool output or the environment the model can read. Broker them at the edge.

For personal-agent use, turn on 1Password for Agents, but treat each approval prompt as approving a session, not a single action.

Watch for approval fatigue. Willison flags it in his CaMeL write-up, and per-request prompts on a busy agent turn into reflexive approvals. Batch approvals by task, not by request.

Ask 1Password for documentation of the agent key and for an audit log of approvals before you roll this out to a team.

What I couldn't verify

I couldn't find how the agent identity key is issued, bound and revoked; neither 1Password nor TechCrunch's coverage explains it. I also don't know whether credentials pass through the browser DOM on "cloud computer" agents, where 1Password doesn't control the client. The brief's framing that the product was "developed with Anthropic and OpenAI" doesn't hold up: the primary sources describe partners whose integrations are mostly not yet live. And the Rio Rundown item on privileged-LLM design only excerpts a Towards Data Science piece, so I relied on Willison's primary posts instead.

I'll revisit when Claude Duet's integration goes live and 1Password publishes the protocol.

Sources

Primary: 1Password press release: 1Password for Agents launches as the trust layer for personal AI agents; 1Password blog: Introducing 1Password for Agents; 1Password blog: 1Password for Claude (July 2026); 1Password developer docs: Secure AI access. Coverage: SiliconANGLE: 1Password for Agents lets personal AI agents log in without ever seeing the password; TechCrunch: 1Password launches a way for AI agents to log in on your behalf. Background: Simon Willison: The Dual LLM pattern for building AI assistants that can resist prompt injection; Simon Willison on Google DeepMind CaMeL (April 2025); Rio Rundown: Trending AI news, Oct 11 2026.