The Password Replacement and Why Your Agent Needs One Too

The password is on its way out. That's not a marketing line. OMB M-22-09 told U.S. civilian federal agencies to deploy phishing-resistant MFA by the end of fiscal year 2024. Every major identity provider now ships passkey-first sign-in. Apple, Google, and Microsoft default new accounts to passkeys when the platform supports it. The orgs I work with have all started this migration, and most of them are somewhere between a third and two-thirds of the way through.

While that migration is happening, those same orgs are also onboarding AI agents into customer support flows, code review, ticket triage, sales prospecting, finance close, and more or less every other workflow that has structured inputs and outputs. The two programs have not been talking to each other. They need to.

This essay is about why, and what an AI-aware identity strategy actually looks like.

What's actually new about passkeys#

The thing that makes a passkey different from every other "MFA" is one property: origin binding. The signed assertion the authenticator produces is bound to the domain the browser is talking to. A reverse-proxy phishing kit at login-examp1e.com will produce a signature for that domain. The real login.example.com rejects it.

That's the trick. There is no shared secret to steal, no OTP to forward, no push notification to fatigue someone into approving. The signature is wrong against the wrong origin, and the relying party refuses it.

If you've never seen the WebAuthn ceremony up close, register a passkey on the lab. The whole flow runs in about ten seconds and you can watch the credential ID and public key come back from the browser.

The headline number from the rollout has been: zero successful at-scale phishing of FIDO2 passkeys in the wild. Not "fewer." Not "harder." None. The infosec community has been chasing that property for twenty years.

Where the migration usually stalls#

Almost every passkey rollout I've watched goes through the same gradient:

Passkey plus password fallback. Easy to deploy, fast wins, zero help-desk pushback. The password still exists, which means it can still be phished, which means the headline win is mostly cosmetic.
Passwordless primary, recovery via secondary device. Real reduction in attack surface. Harder helpdesk story, especially around lost-device recovery.
Phishing-resistant only, no exceptions. AAL3, OMB M-22-09 territory. No SMS recovery, no "lost device, just call us" path.

Most orgs stop at step 1 and call it done. Then an attacker calls the helpdesk, says they lost their device, and walks out with a freshly enrolled passkey on the attacker's phone. That was the MGM and Caesars pattern in 2023, and variations of it show up on every identity-driven incident I've reviewed since.

The control that closes this isn't the technology. It's removing the soft-fallback paths that defeat the technology. If a phone call to the helpdesk can re-enroll a passkey, the program has not actually shipped phishing-resistant authentication. It has shipped a phishing-resistant factor on top of a phishing-prone recovery flow.

And then there's the agent#

Here's where almost every identity program I see today has a blind spot.

You've spent eighteen months convincing the CFO to fund the passkey rollout. Phishing is finally a controlled risk. Then an engineering team ships an AI agent with an OpenAI API key in a config file, a long-lived GitHub PAT for code review, and a Stripe live key for payment automation, all sitting in the same container. The audit log says "user did X" when in reality the agent did X under a service account that the user owns.

What did the program actually achieve?

The agent has become the weakest credential in the environment. Steal the container, get keys to everything. The beautiful passkey rollout protects the front door of a house with all the windows wide open. Worse, because the agent acts under a human's session in many SaaS platforms today, the access path is genuinely indistinguishable from the human's actions in most audit trails.

This is not a hypothetical. Every consulting engagement I've been part of in the last twelve months has surfaced at least one of these. Long-lived secrets in repos. Service principals with Application.ReadWrite.All. OAuth apps that nobody can attribute to a current employee. The agent identity problem is not coming. It's already shipped.

The same primitives, applied to workloads#

The good news is the building blocks for fixing this exist. They are the same primitives that finally made human passwords obsolete, just translated into the workload-identity world.

Origin binding for humans → workload attestation for agents. The agent doesn't say it's running on a trusted node, it proves it. TPM quote, AWS Nitro attestation, GitHub Actions OIDC, Azure managed identity, GCP workload identity federation. A relying party can validate the attestation before issuing any credential.
No shared secrets for humans → federated short-lived tokens for agents. The major cloud platforms now issue OIDC tokens to running workloads that the relying party verifies against a JWKS endpoint. No long-lived API key ever has to land in the container. (Paste one of those tokens into the JWT inspector and watch what it flags.)
Hardware-bound for humans → non-extractable workload keys for agents. SPIFFE/SPIRE issues short-lived X.509 SVIDs to attested workloads with stable identifiers like spiffe://prod/agent/code-reviewer/v3. The private key never leaves the host enclave.
User-to-agent delegation. OAuth 2.0 Token Exchange (RFC 8693) lets a user's session token be downgraded into a narrower agent token: scope limited to what the agent needs, audience limited to the specific upstream API, TTL limited to minutes, and an act claim recording that "the agent acting on behalf of the user." The audit log finally has a story.

Almost no orgs have wired all four together yet. A few have wired two of them. The standards are settled. The implementation is still ahead of most identity teams.

Where the platform vendors fit in (and where they don't)#

The platform vendors are racing to claim the agent identity layer. Microsoft has shipped agent management surfaces in Microsoft 365 and Copilot Studio. AWS, Google, and the major identity vendors are moving in similar directions. The selling proposition is unified governance: one place to inventory agents, see their permissions, review their access, and retire them.

This is a real and useful direction. It is also worth being clear-eyed about a structural pattern. The most fully-featured agent governance surfaces tend to manage the vendor's own agents well, and third-party agents partially or not at all. An identity portal that sees Microsoft-built agents as first-class citizens and OpenAI- or Anthropic-backed agents as opaque blobs is not the same as an identity portal that governs all agents in the environment. For an org that has standardized on a single IAM provider and runs the majority of its identity surface there, the gap between "we govern our own AI" and "we govern all AI in the environment" matters a lot. It is the difference between a control and a marketing screenshot.

This is not a vendor takedown. It is an honest read of where the agent governance market is in 2026. The vendor with the largest IAM footprint has the most leverage to shape what "agent governance" means, and the most reason to define it in a way that favors their own ecosystem. Buyers should architect for agent identity diversity even if they buy from a single primary vendor.

What to actually do#

The action set splits cleanly between the human side and the agent side.

For the human side of the program:

Get to passkey-only for admin, break-glass, and high-privilege accounts. No fallback.
Audit the helpdesk recovery flow. If a phone call can re-enroll a passkey, the program has not yet shipped what it thinks it has shipped.
Inventory every long-lived secret your org has issued. There are more of them than you think.

For the agent side:

Stop putting long-lived keys in agent config files. Use OIDC federation against the platform the agent runs on.
Identify the agent in the audit log separately from the user it acts for. RFC 8693 act claims, or the platform-specific equivalent.
Bound scope per task. The agent doing code review does not need repo:write on every repo.
Plan for revocation that does not require the user to rotate their passkey or reset their account.
Pick an identity strategy that treats third-party agents as first-class, not as opaque guests inside a vendor portal.

I wrote a deeper companion piece on this — the agent-identity model, the orgs racing to define it, and what gets missed in the rush — over here: The Agent Identity Front. Some of the framing in that piece is direction-of-travel rather than current state, and I name names where it helps.

Closing#

The lesson I keep coming back to is that human identity and agent identity are no longer separate problems. The same session that runs your passkey-protected human eventually invokes a tool, a connector, a Copilot, a custom agent. Whatever credential the agent presents at that next hop is now part of the trust chain that started with the passkey. If the chain ends in a long-lived API key in a YAML file, the passkey has done less than the deck claimed.

If your org is in the middle of a passwordless rollout, take the agent identity question off the IAM team's wishlist and put it on the same roadmap. If you build agents, the Identity Lab walks through the WebAuthn ceremony, the JWT failure modes, and the workload-identity primitives this essay covers, with code you can read in an afternoon. The primitives are the easy part. The hard part is shipping them before the agents outpace the program.