Here is a question worth being able to answer for every agent you ship: what is the single worst thing it can do, and who has to approve that thing before it happens?

Most agent safety conversations skip straight to frameworks and policies. But the frameworks are converging — LangGraph, the OpenAI Agents SDK, and the Vercel AI SDK all gate a tool call behind human approval in a few lines now, so the API ergonomics are a wash. The decision that actually matters is not how you pause. It's where the authority to approve lives — and whether the agent can forge it.

There are four practical answers. They form a ladder, and you climb it action by action, not app by app.

1. No gate: the agent just acts#

The right default more often than founders admit. If the worst single action an agent can take is cheap and reversible — draft a message, label a ticket, summarize a document, read from an API — a human approval step is pure friction. Autonomy is correct here. The mistake is applying it one rung too high, to an action that moves money or mutates production.

Use when: the blast radius of the worst case is trivial and undoable.

2. Software step-up: pause in the framework#

Your agent framework interrupts the tool call and waits for a human to approve. needsApproval: true on a Vercel AI SDK tool; an interrupt persisted in a LangGraph checkpointer; a RunState pause in the OpenAI Agents SDK. It's fast, it's programmable, and — critically — you can gate on a predicate that inspects the arguments, so routine calls run and only the dangerous ones pause. That's how you avoid approval fatigue.

The limit is structural: the approval and the agent live in the same trust domain. A runtime that an attacker fully owns, or a prompt injection that can manufacture the "approved" state, can walk through this gate. For the vast majority of consequential-but-bounded actions — a modest refund, a routine deploy behind other controls — that residual risk is fine. For company-ending actions, it isn't.

Use when: the action is consequential but bounded, and you want speed plus programmable rules. Persist the pause — an in-memory approval that dies on redeploy is a footgun for exactly the irreversible tools you bothered to gate.

3. Hardware key: verified authorization#

This is the rung that changed last week. YubiKey 5.8, shipped July 21, extends passkeys from authentication to verified authorization: a hardware-backed signature on one specific action, delivered over the emerging WebAuthn signing extension. The signing key never enters the agent's runtime, so a compromised agent can prepare a bad action but cannot authorize it. And because it rides standard WebAuthn, it gates any web-requestable action — a payment, a privileged-access grant, a production config change, a legal signature — not just crypto.

Use when: a single wrong non-crypto action is catastrophic, and "a compromised runtime could bypass the gate" is unacceptable.

4. Crypto hardware signer: the trusted display#

For on-chain transactions specifically, Ledger's Agent Stack does the same move with one addition that matters for crypto: a trusted display. The device shows the exact transaction — amount, destination, action — on its own screen before you confirm. What You See Is What You Sign. A compromised agent can't render one transaction on your monitor and sign another, because the screen that matters is the one it can't touch.

Use when: the action is a blockchain transaction and the loss is irreversible.

The rule that picks the rung#

Blast radius decides the gate: cheap and reversible → autonomy or software step-up; catastrophic and irreversible → move the signature into hardware the agent physically cannot cross.

Notice this is a per-action decision, not a per-app one. The same agent can read your treasury autonomously, refund a customer behind a software approval, and require a physical key press to move funds off-platform — three different rungs, one agent, chosen by what each action can destroy.

The industry now has a clean answer to the agent-authority question, and it is a layered one. Run a policy engine that auto-approves the routine and pauses only on risk. Then put a hardware veto on the narrow set of actions that can end the company. The policy layer bounds your volume and speed; the hardware layer bounds your worst case. You need both, and — for the first time — neither one is a bespoke cryptography project.