Palo Alto Networks is putting around $500 million into Console, the Thrive-backed startup whose entire reason to exist is giving AI agents their own identities and their own secrets. I read the coverage twice. What’s being bought is a very good safe, and underneath the price tag sits an assumption nobody argued about first: that every agent needs something to put inside it.

Mine doesn’t. The browser agent I use all day has never been handed a password of mine, and there’s nowhere in it to put one.

What it actually sees when it opens Gmail

Say I’ve got mail.google.com open in a tab and I ask the side panel to draft replies to the four threads from a vendor. What the agent receives is the rendered DOM, the accessibility tree, the visible text, the URL, and my instruction. Then it dispatches clicks and keystrokes into that page like a very fast, slightly literal-minded person borrowing my mouse.

Notice what isn’t in that list. No token. No cookie value. The session cookie Google set when I logged in myself is marked HttpOnly, which means page JavaScript cannot read it at all, and Chrome attaches it to outgoing requests without ever showing it to anything running in the page. So the agent is authenticated in the only sense that matters, and simultaneously has no idea what that session cookie looks like.

That’s not a policy we wrote. It’s how the browser was built, and browser agents like Dassi inherit it for free.

The 1Password question

People ask whether the agent can unlock 1Password or Bitwarden and fill in a login form for them. It can’t open your vault, and building that would be the worst feature we could possibly ship.

It doesn’t need to. When a login form shows up, Chrome’s password manager (or whichever one you already use) autofills it the way it always does, and the agent clicks Sign in. The password stays saved in the vault, your password manager does the filling, and nobody ever has to paste it into the agent’s settings.

Nothing to leak beats stored safely

Simon Willison’s lethal trifecta is the clearest framing anyone has given this: an agent gets dangerous when it has access to private data, exposure to untrusted content, and a way to communicate externally. A browser agent has the first two by definition. It reads your logged-in pages, and every page it reads is content someone else wrote, which means some fraction of them will eventually contain white-on-white text instructing the agent to do something you didn’t ask for.

Now hand that same agent a vault key. The blast radius stops being “one weird action in one tab I’m watching” and becomes “the master credential for every account I own, held in the memory of a process that just read a hostile web page.” A prompt injection that previously cost me a badly worded email now costs me my bank. And credential theft doesn’t expire when I close the laptop, which is the part that should scare people who currently think of vault integration as a convenience feature rather than a permanent transfer of everything.

Vaults are wonderful. I use one. But the security argument for a vaulted agent is always some version of “the secret is encrypted at rest, the scope is minimal, the audit log is complete,” and every one of those claims is a promise about implementation quality that has to hold forever, across every future version, against attackers who only need to be right once. The argument for a session-scoped agent is a claim about what exists: there is no long-lived secret in the process, so there is nothing for a bad prompt to smuggle out. One of those is a control. The other is an absence. Absences don’t have CVEs.

We wrote about the same shape of thing when Cyera paid $1B on the premise that agents need identities. The identity already exists. You made it when you typed your password in yourself.

Then a site wants your phone, and you notice immediately

This isn’t free. Because the agent borrows a session rather than holding a credential, it inherits every limit of that session, including the steps only I can complete.

Salesforce logs me out after a couple of hours of inactivity. When that happens mid-task, the agent goes back through the front door the way I would: Chrome autofills my saved login, it clicks Sign in, and the task carries on. What it can’t get past is anything that needs me. Banks are the obvious case. Anything with a 2FA prompt or step-up auth on a sensitive action will simply stop, and I have to go tap my phone.

So when it fails, it fails by stopping at that 2FA prompt, and I fix it in ten seconds. Compare that to a vaulted agent’s failure mode, which is that it succeeds at something I never sanctioned. I’ll take the halting one. It’s a mild damn annoyance instead of an incident report, and this is roughly the same reason your agent can’t see your logins from the cloud unless it’s running where you already are.

Console will do fine. Server-side agents hitting APIs at 3am genuinely need machine identity, and someone had to build the plumbing for it. But a lot of that $500M is being spent to reconstruct, in a vault, a thing your browser has been doing correctly since 1994. There’s a version of the agent security conversation five years from now where somebody points at all of it and asks why we didn’t just use the tab.