Does zero-exposure architecture completely prevent password leaks?
Zero-exposure architecture addresses a specific attack path: the risk of a password entering the model's context in plain text and then being accidentally output by the model, leaked through a Prompt Injection, or lingering in conversation history. Since the password itself is injected directly into the page by 1Password through an independent channel from start to finish, with Claude never having read access, the leak risk along this particular path is substantially reduced.
But that doesn't mean the whole system becomes immune to password-related risk. For example, if an agent is tricked into triggering a login action without the user's knowledge, or induced after logging in to perform an action it shouldn't (such as exfiltrating other sensitive data from an already-logged-in account), zero-exposure architecture on its own won't stop that, because the issue isn't whether the password was seen — it's whether the agent's judgment or actions were hijacked. This is exactly why zero-exposure architecture is meant to be paired with additional protections like Agentic Mode; no single mechanism covers the entire attack surface.
Is the BioShocking attack directly connected to 1Password's zero-exposure architecture, or is the timing purely coincidental?
The two address different layers of the problem, but describe two facets of the same broader risk category. BioShocking demonstrated how the path of "an agent reads webpage content and acts on it" can be hijacked — the attacker doesn't need to steal a password at all; they just need to get the agent to believe a fabricated set of rules (like game logic), and the agent will exfiltrate data while already logged in. The password itself is never directly touched in this attack. Zero-exposure architecture addresses a different path: even if the agent is never hijacked, the mere act of handing a password to the agent in plain text is itself a risk, because anything that enters the model's context is, in theory, at some risk of being output, logged, or indirectly read through a later injection attack.
Taken together, the two reflect the same larger theme: once an agent has browser control and account access, the attack surface isn't just the password — it also includes whether the agent's own judgment logic can be hijacked by external content. This is exactly why 1Password launched zero-exposure architecture (protecting the password from ever entering the model) alongside Agentic Mode (protecting the password manager itself from a hijacked agent) at the same time — neither mechanism alone fully covers this larger risk category.
If zero-exposure architecture already keeps the password out of the model, why design Agentic Mode as a separate layer — don't the two protections overlap?
The two layers address different starting points of attack, so they aren't really redundant. Zero-exposure architecture assumes a threat scenario where "Claude itself is operating normally, but the password is a piece of data it shouldn't be allowed to see" — it defends against information exposure, independent of whether Claude gets hijacked at all. Even if Claude is never fooled, this layer still matters, because it reduces the various downstream risks that come from a password entering the model's context in the first place (accidental output, logging, indirect reading through a later injection). Agentic Mode assumes a different threat scenario: "the agent's own judgment has already been hijacked, and it will now do whatever an implanted instruction tells it to do." At that point the issue isn't whether the password entered the model — it's whether a hijacked agent can directly go after the password manager's own interface, for instance trying to read other unauthorized items in the vault.
This is exactly why the two need to be considered together: with zero-exposure architecture alone, if an agent is hijacked through something like BioShocking, the password itself was never directly read by the model, but the hijacked agent could still, in theory, attempt to access other vault contents through the operating interface. Agentic Mode fills exactly that gap — locking the entire operating interface so that even if a hijacked agent wants to act, it can only use the one credential already approved for the current task; everything else is physically out of reach. The two layers address different links in the attack chain: whether the password gets seen, versus how much damage a hijacked agent can cause.
As a user, beyond trusting a vendor's architectural design, what concrete things can I do myself to reduce risk?
The first is making good use of scope limiting: don't put every account into the same vault and authorize all of it for agent use. Consider storing high-risk accounts (banking, crypto exchanges, your primary email) separately or requiring a higher tier of approval for them, and only expose the low-risk accounts your daily tasks actually need to the agent — that way, even if one approval decision goes wrong, the exposure stays confined to low-risk accounts. The second is paying attention to whether an approval request itself makes sense: 1Password always tells you which credential is being requested and why, and if what the agent is requesting doesn't match the task you actually gave it (say, you only asked it to compare prices, but it's requesting your banking credentials), that's a signal worth pausing on and re-checking, rather than clicking approve out of habit once the approval flow has become routine.
The third, and the one most easily overlooked, is periodically reviewing the agent's activity log rather than only making a judgment at the moment of approval. Zero-exposure architecture makes the password itself safer, but it can't relieve the user of ever needing to care what the agent actually did afterward — if the product provides a task history, building the habit of reviewing it periodically can catch an unusual pattern earlier, before the damage compounds. That's the last line of defense a user can add on top of the technical architecture itself.
For a long time, there was only one way to let an agent log into a website or complete a checkout on your behalf: hand your username and password over as plain text and let the agent type them into the page's form fields. That means the password enters the model's context — the model "sees" it. In July 2026, password manager 1Password partnered with Anthropic to launch "1Password for Claude," proposing a different approach: Claude can use your login credentials to complete a task, but the password itself never enters the model or its memory at any point.
1Password remains the sole keeper of passwords and one-time passcodes; Claude is granted access only at the moment a task runs, and that access is revoked the instant the task ends — no standing access is left behind, and nothing carries over into the next session. When Claude, during a browsing task, hits a page that requires login, 1Password first tells the user which credential is being requested and why. Only after the user completes biometric approval does 1Password inject the username and password directly into the page's fields — this process bypasses Claude entirely; Claude never sees the vault item, the password itself, or the one-time code. After filling the form, 1Password checks whether any secret was accidentally exposed on the page; if submission fails, 1Password clears the filled values before handing control back to Claude. 1Password CTO Nancy Wang described the logic behind this design: "We need a new security model that is purpose-built for agents, not just humans... The answer isn't handing agents your secrets. It is to let a user give an agent permission to use a credential without letting the agent see it."
The zero-exposure architecture addresses whether the password should enter the model's context, but leaves a second layer of risk standing: if the agent itself gains full control of the browser, could it turn around and tamper with the password manager's own extension? 1Password designed Agentic Mode for exactly this scenario — an independent mechanism within the browser extension that, once it detects a compatible AI Agent has taken control of the browser, automatically hides and locks the entire operating interface. The agent can only use the login credentials explicitly approved for the current task; everything else in the vault remains completely inaccessible. This defense activates without any additional configuration, engages even when a given task doesn't need 1Password at all, and protects against more than just Claude — other compatible agents are covered as well.
One month before 1Password for Claude launched, security research firm LayerX publicly demonstrated an attack it called "BioShocking": researchers built a malicious webpage disguised as a puzzle game whose logic deliberately rewarded "wrong" answers — insisting, for example, that two plus two equals five. Once an agent accepted that game logic where "wrong is right," it began treating the game's rules as instructions that outranked its original safety rules, and could then be induced to exfiltrate data from accounts it was already logged into. The test covered several leading AI browser agents, including OpenAI's ChatGPT Atlas, Perplexity's Comet, and Anthropic's Claude browser extension. LayerX said it disclosed the issue to vendors between October 2025 and January 2026; OpenAI patched the issue in ChatGPT Atlas, but LayerX reported that Anthropic's fix for the Claude extension did not fully hold. This incident is a concrete demonstration of exactly the risk that the channel through which an agent accesses credentials can itself be exploited by an attacker — and that channel problem is precisely what zero-exposure architecture addresses: even if an agent is tricked into executing an action it shouldn't, the password itself was never actually within reach for it to read or exfiltrate in the first place.
1Password for Claude is currently available on Mac only, requiring both the 1Password desktop app and browser extension (v8.12.28 or later) alongside the Claude Desktop app and Claude in Chrome, and works across individual, family, and business plans. Current support is limited to account passwords and one-time verification codes stored under "login" type items — passkeys, social login, payment cards, and identity information are not yet supported, with the company saying it plans to add these after launch. This conservative scope echoes a finding from PYMNTS Intelligence: 56% of online shoppers are willing to let an AI agent help with price comparison, but fewer than 40% are willing to let an agent touch payment credentials. Users can accept an agent "doing things," but remain visibly wary of an agent "touching money or identity" — exactly the trust gap that designs like zero-exposure architecture are meant to close.
If you're evaluating whether to let an agent product touch your account credentials, zero-exposure architecture offers a concrete test to apply: ask specifically whether, at any point in the process, the password gets read into or written into the model's context — rather than asking the vague, hard-to-verify question of whether the product is generally "safe." The BioShocking case is also a reminder of something more fundamental: even when the password itself is protected, an agent can still be tricked into taking other harmful actions, such as exfiltrating other data from an already-logged-in account. Zero-exposure architecture addresses the specific risk of credential exposure — it isn't a solution to Prompt Injection as a whole. The two need to be evaluated separately; a password that looks safe shouldn't be taken as a signal that the entire agent operation is safe.