How AI agents can log in without seeing your passwords

Someone asked me this a few days ago:

Is there a 1Password-like solution for AI agents? Something that lets the agent use the passwords and passkeys I saved, so it can log in to my bank or an airline and manage stuff for me. Is that what 1Password Developer Environments is for?

The short answer is no, Environments is the wrong product. The one you want is called Agentic Autofill, and 1Password is not the only company working on this.

The longer answer is this post. I’ll explain what the problem really is, how the different solutions deal with it, and where each one stops working. Banks and passkeys come at the end, because that part of the question has a less comfortable answer.

The problem is the model reading the secret

When we say “give the agent my password”, in practice we mean “put the password somewhere the language model can read it”.

That’s what we want to avoid.

Anything a model reads can end up somewhere else. It can be echoed back in a reply, written to a log, or captured in a screenshot the agent takes to understand the page. It also gets sent to the provider as part of the conversation. And if a web page contains hidden instructions, a prompt injection can tell the model to type the password into a form on another site.

So the agent should be able to log in, but the model should never hold the secret. Every solution below is a different way of getting there.

I count four patterns in use today. Let’s go from worst to best.

Pattern 1: paste the credentials in the prompt

This is what most people do the first time. You write “log in with user [email protected] and password hunter2” or you put the values in a .env file the agent can read.

It works. It’s also the worst option, because the password is now in the model context, in the conversation history, probably in a log file, and in whatever the agent decides to do next.

Don’t do this for anything you care about. A throwaway test account on your own staging server, fine.

Pattern 2: let the agent use your logged-in browser

This is what agentic browsers do. ChatGPT Atlas, Perplexity Comet, and Claude in Chrome all run inside a browser profile where you are already signed in to your accounts.

The agent never types a password, because it uses the cookies of the sessions you already have.

That sounds safer, and in one way it is, since no secret gets typed anywhere. But if a page manages to inject instructions, the agent can act on any site where you have a session. That includes your email, your calendar, and your bank if you left that tab open.

The vendors know this. ChatGPT agent pauses when it hits a login page, asks you to take over the browser, and stops taking screenshots while you type. Atlas has a “logged out” mode where the agent starts with a clean profile, and a “watch mode” that forces you to keep the tab visible on sensitive sites. Useful, but none of it solves the credential question. It’s the vendor saying “we know this is risky, please watch”.

If you use this pattern, my advice is to give the agent its own browser profile with only the accounts it needs, and nothing else.

Pattern 3: the password manager fills the form, the model sees a placeholder

This is the answer to the original question.

The agent knows that a login is needed and which saved item to use. It does not know the value. When it reaches the login form, it asks the password manager to fill it. The password manager checks with you, fills the fields directly in the page, submits, and hands control back.

The model only ever sees something like “login for lufthansa.com, username flavio”, and never the password or the one-time code.

Two password managers ship this today.

1Password Agentic Autofill

1Password calls it Agentic Autofill, and the first consumer integration is 1Password for Claude, launched in July 2026 for Claude in Chrome.

Here is the flow when Claude needs to sign in during a task:

1. Claude reaches a login page and asks 1Password for a credential that matches the site.
2. 1Password shows you a prompt on your device: which item, for which site, requested by which agent. You approve with Touch ID, swap to a different account, or deny.
3. The 1Password extension fills the username, password, and one-time code directly into the page and submits the form. While this happens, Claude is paused. It does not read the page.
4. 1Password checks that the submission went through and that no secret is left in a field. If the login failed, it wipes the filled values before Claude looks again.

What Claude gets back is a status, success or failure. Before the fill it also gets an overview of the items you approved: title, username, and the websites saved on the item. That’s the same information you see in 1Password’s own inline suggestions, enough to pick the right account and nothing more.

There is also something called Agentic Mode. As soon as a compatible agent takes control of a tab, the 1Password extension locks itself down in that tab. The inline suggestions disappear, the popup is hidden, and only the items you approved for the current task are reachable. This kicks in even if you never set up the Claude integration. It’s 1Password protecting itself from agents in general.

Approval is per session and per item. When the task ends, the access ends, and nothing carries over to the next task.

A developer-facing version exists too. Since October 2025, Agentic Autofill has been in early access with Browserbase, the cloud browser platform. There the 1Password extension runs inside the headless browser, and your desktop app and Browserbase talk over an end-to-end encrypted channel. Same approval prompt on your machine, but the browser is in the cloud.

Limits, as of when I write this:

• It fills Login items: username, password, TOTP. It also handles “Sign in with Google” style buttons.
• Passkeys are not supported. More on why below.
• On 1Password Business, an admin has to turn on the “Allow AI agents to autofill for users” policy first.
• Every fill needs a human tap. There is no “run overnight” mode, and that is deliberate.

Back to the original question: 1Password Developer Environments is a different product. It stores .env style secrets (API keys, database URLs) and hands them to your scripts through a mounted file or op run. It’s great for giving a coding agent the API keys a project needs, and I wrote about using it with Cursor. It has nothing to do with logging in to websites.

A third 1Password product gets mixed up in this conversation too: Credential Broker, in public preview since July 2026 for Business accounts. It sits on top of Environments and answers a different question: how does a machine prove who it is before it gets secrets?

The workload (a GitHub Actions job, a Kubernetes pod, an agent runtime) presents an OIDC token. 1Password checks the token’s claims against a trust policy an admin defined, such as “only jobs from this repository, on this branch”. If they match, the workload receives the secrets from the connected Environment for the duration of the job, and the delivery is logged with the workload’s identity. No long-lived service account token sits in the CI config.

So Agentic Autofill is for an agent logging in to a website on your behalf, with you approving each time. Credential Broker is for an unattended workload fetching API keys, where the workload’s identity is the approval. If you run agents in CI or on a server rather than in your browser, the broker is the one you want. It has more in common with the OAuth pattern I describe below than with filling passwords into forms.

Bitwarden Agent Access SDK

Bitwarden took a different route. In March 2026 they published the Agent Access SDK, an open protocol for the same problem.

The shape is similar:

1. You pair an agent with your Bitwarden client once, through a small CLI.
2. When the agent needs a credential, it sends an encrypted request for one specific item.
3. The request lands on your device. You approve or deny it in the CLI.
4. If approved, that one credential travels back through the encrypted tunnel and is injected into the agent’s process as environment variables. The tunnel closes. Next time, the whole thing repeats.

The encryption uses the Noise protocol, and the relay in between routes ciphertext without being able to read it. Bitwarden says this is meant as an open standard other password managers could adopt, and that right now it’s an early alpha for developers exploring the pattern, not something to put in production.

The difference from 1Password is where the secret ends up. 1Password fills the web page itself. Bitwarden hands the value to a process you control. That works for any tool, not only browsers, but it also means the process receiving the variable has to be one that doesn’t pass it on to the model.

Don’t confuse it with Bitwarden’s MCP server. That one lets an AI assistant read and manage your vault through the bw CLI. Handy for “generate a password and save it”, but the values do go through the model, and Bitwarden themselves recommend using it only with a local, self-hosted LLM. So it is not the tool for logging in to websites. If you are new to MCP, my free MCP course explains what a server like that exposes.

Doing it yourself with Browser Use

If you are building the agent rather than using a product, the same placeholder idea is built into Browser Use, the open-source browser agent library.

You pass secrets in a sensitive_data dictionary and refer to them by name in the task, so the model sees only the names. When the model decides to type x_pass into a field, the library swaps in the real value at the DOM level, after the LLM call.

from browser_use import Agent, Browser, ChatOpenAI

agent = Agent(
  task='Log in to lufthansa.com with x_user and x_pass, then open My bookings',
  sensitive_data={
    'https://*.lufthansa.com': {
      'x_user': '[email protected]',
      'x_pass': 'the-real-password',
    },
  },
  browser=Browser(allowed_domains=['*.lufthansa.com']),
  use_vision=False,
  llm=ChatOpenAI(model='gpt-4.1-mini'),
)

The credentials are keyed by domain, so they can only be filled on lufthansa.com. Without that, a prompt injection could steer the agent to another site and type your password there.

allowed_domains stops the browser from navigating anywhere else at all. The library warns you if you set sensitive_data without it.

use_vision=False stops screenshots from going to the model. A screenshot of a filled password field is a password in the model context.

For TOTP, you pass the shared secret under a key ending in bu_2fa_code, and the library generates a fresh code when the agent needs one.

The model never sees the values. But your script has them in plaintext, so you still need to load them from somewhere safe. That’s where op run from 1Password or the Bitwarden SDK come in, one layer feeding the other.

Pattern 4: skip the login page, use OAuth

Everything above assumes the agent has to go through a web login form. Sometimes it doesn’t.

If the service has an API with OAuth, you log in once, consent to a scope, and the agent gets a token limited to that scope. No password ever exists on the agent side, and you can revoke the token without changing your password.

There is a small industry of “token vaults” for this now. Arcade, Nango, and Auth0’s Token Vault all store per-user OAuth tokens, refresh them, and inject them into tool calls so the model never sees them. If you are building agents that touch Google Workspace, GitHub, Slack, or similar, this is the layer to use, and it beats driving a browser.

The catch for the original question is that your bank and your airline don’t give you an OAuth API for your personal account. There is no scope to consent to. The login form is the only door, and that’s the reason the browser-fill pattern exists at all.

Why passkeys don’t work with agents yet

The question mentioned passkeys, and every product above says they are not supported. Passkeys require a person to approve the login on a device.

A passkey login is a WebAuthn ceremony. The site sends a challenge, the authenticator on your device signs it with a private key, and the site verifies the signature. Before signing, the authenticator requires user presence: a fingerprint, a face, a PIN, a tap on a security key. The whole point is that a human touched the device right now.

An agent cannot produce that gesture. It can ask you to touch the sensor, and that’s what happens today: the agent pauses, you unlock the passkey, the agent continues. But then it’s you logging in, not the agent, and it rules out unattended runs on passkey-only sites.

The workaround people use is to set up a browser profile by hand, complete the passkey login yourself, and let the agent reuse the resulting cookies. That’s pattern 2 with a narrower profile, and it works until the session expires.

Longer term, the direction is delegation instead of impersonation. You authenticate with a passkey, you consent to a scoped mandate, and the agent receives a short-lived token that says “acting on behalf of Flavio, for this task, until this time”. Visa and Mastercard are building this for agent payments, and the OAuth token-exchange work at the IETF describes the same idea. You won’t be able to set it up for your bank this year.

About banks and airlines specifically

I’d treat the two differently.

An airline account is mostly low-stakes. You check a booking, pick a seat, add a frequent flyer number. If 1Password for Claude fills the login and you approve each fill, I think that’s a reasonable use of an agent, with one condition: anything that spends money should pause for you. I wrote about how to make an agent stop before irreversible actions, and buying a ticket is exactly that kind of step.

A bank is different. Banks use passkeys, hardware tokens, app confirmations, and device binding precisely so that nobody can automate them, and most of them forbid it in their terms. The tools above solve the credential part. They don’t solve the rest, and I wouldn’t try. Read your balance through the bank’s own export, or through an aggregator with a proper API if you have one.

How I would use this

I keep my passwords and TOTP codes in 1Password already, so Agentic Autofill is the option I would try first.

The first thing I would do is open a separate Chrome profile just for Claude, sign in to nothing, and let 1Password be the only way into any account. That takes care of the logged-in browser problem before it starts.

Then I would approve fills for the boring accounts: the domain registrar dashboard where I check renewals, the analytics for my sites, the newsletter tool where I want a monthly export. These are the tasks I already delegate to agents today with API keys stored in 1Password Environments. Agentic Autofill would extend that to services that only have a web UI.

For the agents I build myself, the ones that run inside a script with Browser Use or a plain Playwright session, I would keep the credentials in a 1Password vault, load them at runtime with op run, and pass them as sensitive_data scoped to the one domain they belong to. The vault keeps the plaintext off disk, and the placeholder keeps it away from the model.

Credential Broker would fit the one place where I already have a secret sitting in CI. This site has a GitHub Actions workflow that hits a Cloudflare deploy hook every morning to publish scheduled posts, and the hook URL lives in a GitHub secret. With the broker, the job would prove it is that workflow in this repository and fetch the URL from an Environment at runtime. It’s a Business feature, so for a one-person setup it’s more than I need, but that’s the shape of it.

I wouldn’t use any of this with a passkey-only account because it can’t run unattended. I would also keep it away from my bank and any account where a wrong click can move money or delete data, unless the agent stops for confirmation. Shared and work accounts need the administrator to enable the feature first.

If you want the background on why this isolation matters, my free Security Fundamentals course covers trust boundaries. The password manager can pass a secret to the site without showing it to the model.

Want me to talk about your product? You can sponsor this site.