1Password Lets AI Agents Log In Without Seeing Your Passwords

1Password has launched 1Password for Agents, a platform that lets AI agents use logins to complete tasks without receiving the username, password or vault contents. Engadget reported the launch on October 22, 2026.

Access is granted per session. An agent receives permission only for specific approved items, and that permission does not carry over into later sessions. Passwords and one-time MFA (multi-factor authentication) codes are injected through a secure channel that 1Password manages, so the credential material stays outside the AI model itself.

The approval flow works as follows. When an agent reaches a password check, it uses a special key to verify its identity with 1Password. 1Password then notifies the user which agent needs access and why. If the user approves, 1Password fills in the required information. The agent never reads the secret, and the user sees the request before anything is released.

1Password pitches the product for consumer-style errands such as booking restaurants, buying gifts and planning vacations. The use case it describes is an agent navigating authenticated websites on a user's behalf, which is a different problem from an agent calling a documented API with a static key.

Aashish Tripathi is the company's chief product officer.

The launch follows a series of product announcements on 1Password's blog this year. In March, the company described Unified Access as bringing together discovery, security and auditability to manage access across people and agents. In April, it said it was developing an agent identity architecture intended to simplify and strengthen the security of AI agents. In June, it introduced Credential Broker, which it said extends the product from storing credentials and secrets to brokering them at runtime, meaning releasing them on demand while a task runs. In July, it introduced Privileged Access, which it said eliminates standing privileges, or permanent access rights, for human and AI agent identities through just-in-time access. The October launch sits on top of that sequence, and it is the first of those pieces presented as a product for agents in a general sense.

In my view, the design choice worth weighing is the separation between the model and the secret. Most early approaches to agent authentication have handed the agent a token or password in its context or environment, which makes the credential reachable by anything that can manipulate the agent's inputs or outputs. Keeping the secret in a channel the model never reads narrows that exposure considerably, though it does not remove it. The agent still holds a session in which it can act against an approved item, and the approval step depends on a human reading an accurate notification. Per-session scoping limits how long a compromised session can do damage, but the boundary of what an agent may do inside a website, once logged in, is set by the site and the approval the user gives.

The broader context here is that agents are moving from answering questions to performing transactions, and transactions require authentication. For security teams, the practical question is less whether an agent can log in and more how that login is scoped, logged and revoked. Session-bound, item-specific, non-persistent access with user approval is a recognizable pattern from privileged access management, now applied to non-human actors that act at machine speed on a user's behalf.

If the model works as described, an agent can complete a logged-in task without the user handing over a master password or pasting a one-time code into a chat window. That is a small ergonomic change with a larger security implication: the credential lifecycle stays in one place, with one audit trail, rather than being copied into prompts, scripts or agent memory. Whether that holds across the range of websites and enterprise systems agents will meet is the part the next several months of deployment will test.