AI agents have started doing real things: booking a trip, filling in a form, opening a dashboard and pulling a number. The problem is that almost everything interesting sits behind a login. And until now, for an agent to log in on your behalf, you had to do something quite unsettling: show it your password. That is, put your key in the very place where the model lives, with its memory and its logs.

This week 1Password and Anthropic announced a way to avoid exactly that. And since just yesterday I wrapped up my Grok roundup with that line about “being in control: knowing what leaves and what stays,” this is the perfect chance to tell the other side of the coin: how it starts getting solved properly.

The problem, in one sentence #

For an agent to act on your behalf it needs your credentials. But handing them to the model means your password —and worse, your one-time code— passes through its context, may linger in its memory, and can end up in the logs of whoever runs the model. Even with no bad intent, that’s attack surface that didn’t exist before. The good question isn’t “do I trust this AI?” but “why does it need to see my password at all?”.

The idea: permission to use, not permission to see #

Here’s the elegant part, and 1Password’s CTO, Nancy Wang, puts it better than I can:

“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.”

It sounds like wordplay, but it’s a real change of architecture. The key is separating two things that had always travelled together: permission to use a credential and knowledge of that credential. You grant the first; the agent never gets the second.

How it works under the hood #

The 1Password extension sits in the middle as a broker for credentials. Step by step:

1. Claude asks for a task, not a password. The model says “I need to sign in to this site.” It doesn’t request the key; it requests permission to do something.
2. You approve with biometrics, item by item. Each request is approved or denied with a single gesture (Touch ID). The dialog and the value never pass through the model.
3. 1Password injects the credential through its own channel. It writes username, password and the one-time code straight into the site’s fields, over a channel it controls. The password and the OTP “stay outside the model, its memory and Anthropic’s systems.” The model only gets a “went fine” or “failed.” 1Password calls it zero-exposure: zero exposure of the secret.
4. The moment the agent takes the browser, the vault locks down. Only the items approved for that task remain visible. The rest of the vault is unreachable while the agent is in control.
5. The permission expires with the session. It doesn’t carry over to other sessions and leaves no standing access behind. When it’s over, it’s over.
6. And it cleans up if something smells off. After every autofill it scans the page and, if the form doesn’t submit properly, it wipes the values it just typed. So if you land on a fake site, your freshly entered password doesn’t stay there.

A practical nuance: within a single task it can chain several logins across different sites without asking you every two minutes. You don’t lose the convenience; what changes is who sees the secret.

Why this isn’t “the same old autofill” #

The system keychain has been auto-filling passwords for years. What’s genuinely new here isn’t the autofill, but having redesigned it with an agent in mind —an odd kind of actor: not quite you, not quite a malicious website. That’s why pieces appear that classic autofill never had: the vault that locks down when the agent takes the wheel, the permission that expires with the session, and the wiping of injected values on a failed submit. These are defenses built for when a program, not a person, is at the wheel.

A personal note #

This one hits close for a reason: the assistant I code with is designed to work exactly like this. Claude Code —the one I write much of my work with— includes a piece for requesting credentials without seeing them: instead of knowing your key, it can ask your password manager to resolve a login or a payment, which you approve in the manager’s interface, so the real values never pass through the model. It’s not that I have it set up in my day-to-day —in fact I don’t use it yet—, but the principle is identical to what 1Password has just brought to the browser. When the same idea shows up in two separate places at once, it’s usually a good sign it’s heading where it should.

What I take away #

That someone is solving the problem from the right side. The fashionable move would have been “give the AI full access and trust it”; instead, the proposal is to grant just the right permission, for just the right task, for just the right amount of time, without showing it the secret. It’s the good old principle of least privilege, applied to a new kind of actor.

It’s not magic and it doesn’t fix every risk of an agent loose in your browser —you still have to be careful where you let it act. But it moves the line to the right place: the question stops being “do I give the AI my passwords?” and becomes “what do I let it do, and for how long?”. That second question, at least, I do know how to answer.