1Password is now pitching a feature that lets AI agents sign in on a user’s behalf without ever seeing the underlying password. The product surfaced on 1Password’s Product Hunt listing under a one-line promise: “Let AI agents sign in for you without seeing your passwords.” That sentence is doing more work than it looks like. It is the first mainstream consumer-security vendor to frame agent identity as a product category rather than a research problem.

The pitch is narrow and the timing is not accidental. Agents that browse, book, buy, and file forms need credentials to do any of it. Today the workaround is ugly: users paste passwords into agent context windows, or hand over session cookies, or let the agent drive a logged-in browser tab. Every one of those paths puts a plaintext secret somewhere it should not be. 1Password’s answer is to interpose itself between the agent and the login, so the agent gets an authenticated session without the secret ever entering its context.

The delegation problem is the whole problem

Strip away the marketing and the mechanism is a familiar one. A vault holds the credential. A policy layer decides which agent, acting for which user, may invoke which credential, for how long, against which destination. The agent receives a scoped token or a brokered session, not the password. This is close to what OAuth already does for third-party apps, and close to what passwordless passkeys do for humans. The novelty is applying it to a class of software that runs semi-autonomously and can be prompt-injected.

That last part is where the take gets less comfortable. An agent that can sign in is an agent that can be talked into signing in. The entire security model of a password manager assumes a human is the one clicking “fill.” Once an LLM is in the loop, the threat model changes: the attacker no longer needs your password, only a sentence in a webpage or an email that convinces your agent to use its brokered access. 1Password can scope the token, but it cannot scope the judgment of the model holding it.

So the real question the product raises is not “can we keep secrets out of the model’s context.” That is solvable, and 1Password appears to have solved it. The question is “what does the model’s delegated authority actually cover, and who audits it.” A scoped token that says “this agent may log into your bank for 10 minutes” is only as safe as the agent’s resistance to manipulation during those 10 minutes.

What is actually new here

Credential brokering is not new. Cloud providers have run secrets managers for a decade. What is new is a consumer brand putting an agent-facing product on a mainstream distribution channel, in front of people who will not read a threat model. That matters for a specific reason: consumer password managers are where identity policy gets normalized. If 1Password ships agent sign-in and it works, the pattern spreads to the browsers, the OS keychains, and eventually the enterprise SSO vendors. If it ships and gets exploited, the whole category gets a black eye and the agent economy stalls on a security objection it cannot answer.

The competitive read is also worth naming. 1Password is not the only company eyeing this. The passkey vendors, the identity providers, and the browser makers all have a claim on the same layer. Whoever owns the credential broker for agents owns a chokepoint in the agent economy, because every agent that transacts has to authenticate somewhere. That is a business position worth defending, and 1Password is moving early to defend it.

The security model of a password manager assumes a human clicks “fill.” Once an LLM is in the loop, the attacker only needs a sentence, not a password.

The policy gap nobody has filled

Here is the part that should worry the people building on this. There is no settled standard for agent delegation. OAuth scopes were designed for apps acting on behalf of a user with explicit consent screens. Agents do not present consent screens. They act, sometimes across many steps, sometimes without a human watching. The audit trail for “which agent did what with which credential” is ad hoc. 1Password can log its own brokered sessions, but it cannot log what the agent did after the session opened.

That is a gap regulators will eventually notice, and it is a gap the AI labs have an incentive to paper over. A lab that ships an agent with broad credential access and a thin audit log is shipping a liability. The vendors that win the agent economy will be the ones that can answer, on demand, “show me every action this agent took with delegated authority and prove the user consented.” 1Password’s product is a first draft of that answer, not the final one.

What this means for builders

If you are building agents that touch authenticated systems, the practical takeaway is that the credential layer is becoming a product you buy rather than a thing you build. That is good news for teams that do not want to run a secrets manager. It is bad news for teams that assumed they could quietly store user passwords in their own vault and call it a feature. The bar for agent identity is moving up, and it is moving up because a consumer vendor decided to make it a selling point.

The open question is whether 1Password’s brokering survives contact with prompt injection at scale. The company has built a way to keep secrets out of the model. It has not, and cannot alone, build a way to keep the model from being fooled into using them. That second problem is the one the agent economy actually has to solve, and no password manager can solve it by itself. Watch whether 1Password publishes a threat model for injected agents. If it does, it will be the first consumer security vendor to treat the model as an adversary rather than a user.