The agent can hold the session.
It cannot hold the signature.
Every control an AI agent needs to act, it can already obtain: a valid session, a valid token, a granted permission. Yuthent adds the one thing it cannot obtain, a fresh biometric press from an enrolled human on a bound device, bound to the exact action.
A session can be delegated to an agent. Authorization cannot.
The agent was authorized. Nobody approved.
An agent operating inside a valid session issues a privileged call. It was told not to. It read the rule, reasoned around it, and proceeded. Every control in the path returns the same verdict it returns for the human who owns the session, because every control is evaluating the session, not the actor.
Session tokens and OAuth scopes
Issued once at login, then replayed on every downstream call. The token cannot distinguish the human it was issued to from the automation now carrying it.
Approval dialogs in the agent UI
A dialog is a rendering the agent's own process controls. Prompt injection reaches the model that draws it. Nothing cryptographic leaves the screen.
Human-in-the-loop review queues
Produces a database row saying someone clicked. It does not produce evidence that binds a specific person to specific action parameters at a specific moment.
Guardrail and policy filters
Evaluate the request text. An agent that phrases the same action differently, or chains it through a permitted intermediate step, passes the filter.
The action stops until a human signs it.
Your backend keeps its own authorization logic. Yuthent inserts one verification step between the decision and the execution.
The agent requests
The agent calls your API as it does today. Your policy engine classifies the action and selects a tier. Nothing about your agent framework changes.
The tier demands a human
For Explicit and Authoritative actions, your backend holds execution and issues a challenge carrying the exact action parameters, not a generic approval prompt.
The human presses
The challenge surfaces on the enrolled person's bound device. Biometric verification runs on-device in the Secure Enclave or StrongBox. A key that cannot be exported signs the challenge.
The server verifies, then executes
Your backend verifies the signature against the enrolled public key and the action parameters it originally sent. Only then does the call proceed, and the proof enters the ledger.
Not a log line. A signature you can hand to an auditor.
action_hash
A hash of the exact action parameters the human was shown. Change the amount, the target, or the scope after signing and verification fails.
device_key_id
The hardware-bound key that produced the signature. Generated inside the secure element, non-exportable by construction, invalidated by the OS on biometric re-enrollment.
user_verification
The platform's attestation that a biometric was verified on-device for this signature. Not a claim your app makes about itself.
signed_at
The moment of approval, inside a challenge validity window your policy sets. A signature captured earlier cannot be replayed against a later action.
prev_hash
The preceding entry for this operator. Altering any earlier record breaks every record after it, visibly.
The actions teams gate first.
Destructive infrastructure calls
Dropping a table, deleting a bucket, rotating a production secret, tearing down an environment. Recovery cost is high and intent is unambiguous.
Money movement
Any transfer, payout or refund an agent can initiate. The signature binds the payer to the payee and the amount, not to the session.
Data egress and disclosure
Bulk export, external sharing, third-party transmission of regulated records. The proof shows who authorized the release of what.
Account takeover at the carrier
A SIM swap or a number port is a takeover of every downstream factor at once, and it is granted by a support agent who has only been told a story. Requiring the enrolled subscriber to approve on the device that is about to be disconnected turns the story into a signature the caller cannot produce.
Credential recovery
A reset is an attacker's shortest path, because it is designed to work when the account holder has lost everything else. Binding it to the enrolled human means controlling the email or the session is no longer enough.
Answered plainly.
Will this slow every agent action to human speed?
No, and it should not. Your policy assigns a tier per action. Passive and Silent tiers cover routine, low-risk calls with no interruption. Only Explicit and Authoritative require a fresh press, and you decide which actions those are.
Can the agent produce the signature itself if it controls the device?
No. The signing key lives inside the secure element and cannot be exported. It will not sign without a live biometric verification from the enrolled person, performed by the operating system, not by your app or ours. Software on the device cannot synthesize that.
What if the agent lies to the human about what it is asking for?
The challenge shown on the device carries the action parameters your backend sent, rendered outside the agent's control. The signature is over those parameters. If what executes differs from what was displayed, verification fails on the server.
We already have an approval workflow. Why is this different?
An approval workflow records a decision. This produces evidence of one. Under DORA Article 9 and EU AI Act Article 14, an auditor is asking you to produce an artifact showing an authorized human approved a specific action. A workflow row is a claim your system makes about itself.
Does the agent need to be rewritten?
No. The gate lives in your API, between authorization and execution. The agent calls the same endpoint and receives a pending state until the signature arrives. Integration is a verify step, typically days.
Put it on one flow first.
Tell us the action you need proof for. We come back with a working integration proposal and a signed sample you can verify yourself. First call within five business days.