For a decade the passkey answered one question well: is this really you? You touched the key, the site got a signature proving you held the device, and the session opened. Everything you did after that rode on the trust established in that single moment at the door.
That model has a hidden assumption baked into it: the thing acting inside the session is the human who unlocked it. Autonomous agents quietly deleted that assumption. The session is still authenticated. The actor is now software — software that can be prompt-injected, jailbroken, or simply confident and wrong. A login says a human proved they were here. It says nothing about who is pressing the buttons ninety minutes later.
YubiKey 5.8, released July 21, 2026, is Yubico's answer to that gap. It extends the hardware key from authentication — proving who you are at login — to what the company calls verified authorization: a hardware-backed signature on one specific action. The passkey stops being a door and starts being a veto.
The one-sentence version#
An agent can draft the payment. A human presses the key before it clears.
That is the whole idea, and it is worth saying plainly because it inverts where the guardrail lives. Today, most agent safety sits inside the runtime: a spend cap in the code, an allowlist in a config, a policy in a service the agent calls. All of those live in systems an attacker who owns the agent might also reach. A hardware signature does not. The signing key never leaves the physical device, so the approval is bound to something the agent's software has no path to.
The guardrail that actually holds is the one the agent physically cannot cross.
What makes it work: CTAP 2.3 and the WebAuthn signing extension#
The mechanism is not a proprietary trick. YubiKey 5.8 adds support for CTAP 2.3 — the Client to Authenticator Protocol layer that governs how keys, browsers, and apps talk — plus preview access to the emerging WebAuthn signing extension. That extension lets a security key produce a digital signature over arbitrary data, not just a login assertion, through the same WebAuthn API developers already use for passkeys.
The practical consequence for a builder: a hardware-backed signature on an action becomes a standard browser API call instead of a custom cryptographic integration. You are not standing up an HSM and a signing service. You are asking the platform you already use for passkeys to sign one more thing — the action itself.
Where a founder actually uses it#
Yubico frames the use cases around the moments where being wrong is expensive and irreversible. Require a YubiKey-backed signature before an agent:
- submits a payment — the mandate problem, solved at the point of settlement rather than trusted upstream;
- provisions privileged access — no agent grants itself or another principal admin without a human press;
- changes a production configuration — the 3 a.m. "the agent edited the load balancer" story gets a physical stop;
- approves a legally binding document — a signature that a court would recognize, bound to a person, not a session.
Notice what is not on that list: reading balances, drafting the change, proposing the transaction, summarizing the contract. All of that stays fully autonomous. The key enters the loop only at the boundary between prepare and commit — which is exactly where you want a human, and nowhere else.
Why now, and what it means#
This is the same structural move Ledger made for crypto: keep the signature on a device the agent can't reach, let the agent do everything up to that line. What YubiKey 5.8 changes is the domain. Ledger's signer is crypto-specific. Verified authorization over WebAuthn is general — any action a web app can request can be gated behind a physical press, using rails that already run in every major browser.
For founders, the takeaway is not "buy hardware keys." It is that the industry is converging on a specific answer to the agent-safety question: software policy is the right default for speed and volume, and a hardware signature is the right default when a single wrong action is catastrophic. Most teams will end up running both — a policy engine that auto-approves the routine, and a physical veto on the handful of actions that can end a company.
The interesting part is that the veto is finally becoming boring infrastructure. When the strongest human-in-the-loop primitive is a standard WebAuthn call, "put a human on the dangerous action" stops being an architecture project and becomes a feature flag.
Next: the design question this raises is which gate to put on which action. We compared the real options — hardware key vs. crypto signer vs. software step-up — and the one rule that decides between them. And if you're wiring approval in code today, here are three SDKs that gate a tool call behind human sign-off, side by side.
