Mission: Impossible and The Matrix are telling the same story about the same failure mode. They just dress it differently. Ethan Hunt's mask doesn't disguise him — it overwrites him, projecting a completely different, system-verified identity directly onto his own face, so whatever's checking faces on the other side checks the wrong one and waves it through. Agent Smith does the identical thing one layer down the stack: he's a computer virus that copies his own code onto other programs and human minds inside the Matrix, overwriting their identity until the "duplicate" is running with his authority instead of theirs. One's a rubber mask, one's a self-replicating exploit, and they're describing the exact same attack — don't break into the host. Become it.

Twenty-five years later we've got the problem running in reverse: we're the ones deploying the agents now, and it's our agent that has to prove it's actually us, without quietly turning into an overwrite of us along the way.

Here's the question I keep coming back to: how do we let an agent exercise my authority, on systems that were designed exclusively for humans, without ever handing the agent my underlying credentials?

I'm not saying anything new by asking it. I am saying this needs a genuinely new open protocol, and even that won't solve the problem entirely. Nobody's written the red pill for this one yet.

The problem, oversimplified

If you need an agent to access anything behind a login, it needs some form of credential. Often, that credential is your actual username and password.

The most naive approach, and the most insecure, is to just hand the agent your username and password directly. Nobody serious does that on purpose, but plenty of setups amount to it by accident. It's the enterprise version of WarGames: hand the machine the launch codes and hope it only wants to play a nice game of chess.

The approach most people actually take instead is to store the username and password as secrets and make them available to the agent, usually as environment variables. That feels safer. It isn't, not really. Any agent with shell access can print its environment variables, and there they are, sitting in a log somewhere, exposed. Call it the Mission: Impossible mask trick, minus the studio budget — the agent isn't you, it's overwriting you, convincingly enough that nothing behind the desk asks twice, right up until somebody peels back the latex and finds a plaintext log file where your identity used to be.

So we've built an entire generation of "agentic" tooling on top of a credential-handling pattern that was never designed to survive an agent that can read its own environment and, occasionally, narrate what it finds.

What's actually needed

There needs to be genuinely new infrastructure for getting agents access to information behind logins, without ever exposing the underlying credential to the agent itself. Not a workaround. Not a slightly-more-obscured environment variable. A different architecture, where the agent proves it's acting on your behalf without ever holding the thing that proves you are you.

The auth.md protocol out of WorkOS goes part of the way there, and it's the most serious attempt I've seen at treating this as an infrastructure problem instead of an implementation detail.

The catch is that it only works if the web app on the other end opts in. And I can see plenty of reasons why a lot of them won't. Opting in means engineering effort, a new integration surface, and a security review, for a use case that half your product team still isn't sure is a fad. Meanwhile the naive approach ships today, works fine in the demo, and only becomes somebody's incident report later.

Every enterprise racing to bolt agents onto systems that were never built to be delegated to is making this same trade, usually without naming it. The credential problem doesn't announce itself in the sales deck. It shows up in the postmortem, once, and everyone acts surprised — a little like WOPR asking if anyone wants to play Global Thermonuclear War, except this time it's asking to read your CRM. By then the question isn't whether the agent can prove it's you. It's whether anyone would have noticed if it had already been overwriting you for months.