1Password for Agents Signs In Without Sharing Passwords

1Password introduced 1Password for Agents on October 22, a system that lets an AI agent sign into your accounts without ever handling the password itself. The agent completes the login; the credential never reaches it.

That closes the gap every agent builder has been papering over. Until now, giving an agent a task behind a login meant giving it the credential — and a credential, once handed over, is permanent access to everything behind that account.

How the handoff works

When an agent reaches a sign-in form, it presents a unique digital key to verify its identity to 1Password. The app then notifies you with which account's credentials it needs and why. If you approve, 1Password fills in the login information rather than handing it to the agent. The agent continues its task, signed in, having never seen the password.

Approvals are granted on your own device, which 1Password compares to two-factor authentication — the point being that a human on a trusted device is behind each permission, not a policy file the agent could reason its way around.

The framing from 1Password chief product officer Aashish Tripathi is explicit about what it replaces: "Agents are starting to do real work on our behalf. The old model where you hand over a credential and hope for the best doesn't work." He adds that an agent "should be able to do the job it's been asked to do without getting permanent access to everything behind the account."

Which agents it covers today

The system is built to work across agents rather than inside one. At launch it supports Meta Muse, ChatGPT Work, Dots, Claude Duet, Grok Bot and Town.

1Password says more partners are working on support, naming Browserbase, Browser Use, Dana, Instinct, Kernel, Perplexity, Ramp, Tomo and Wajo, with further integrations to come.

That list is the most informative part of the announcement. It spans consumer assistants, work agents and the browser-automation infrastructure layer — which is where credentials actually leak in practice, because a headless browser driving a login has to get the secret from somewhere.

What it does and doesn't solve

Note the boundary precisely: approval is per sign-in request, not per session or per action. You are authorising the agent to get in, and nothing in the described mechanism constrains what it does after the session is established. Credential delegation and action authorisation are separate problems, and this addresses the first one.

It is also opt-in per request by design — the feature does not give agents free rein across connected accounts. For a workflow that touches twenty services, that is twenty notifications, and whether that stays workable at volume is the open question this launch does not answer.

For anyone building agent workflows, the practical change is architectural. If your agent currently reads secrets from an environment variable or a vault at runtime, that pattern now has a documented alternative on at least six agent platforms: the agent proves identity, a human approves once per sign-in, and the secret stays on the credential manager's side of the line.

Worth watching: whether the per-sign-in approval model holds up for unattended overnight runs, the exact workload the current wave of always-on agents is built around.