Agents act.
Humans authorize.
We produce the proof.
Map your high-stakes agent actions to a tier that needs a human. When an agent hits one, Yuthent pushes a signed approval request to the authorizing human's enrolled device; a biometric press produces a proof bound to those exact parameters. The agent carries the proof; your server verifies it against a published key. No proof, no action.
How do you authorize AI agent actions?
You decide which agent actions need a human. For those, the server pushes an approval request to the authorizing human's enrolled device, and a biometric press produces an Authoritative-tier proof bound to the exact parameters. The agent includes it; your server verifies it. An agent inside a valid session still cannot produce that proof, it can request, only the human can authorize.
Session trust does not survive autonomy.
Autonomous agents now move money, schedule care, modify infrastructure, negotiate contracts, and file regulatory reports on behalf of humans. The question which human authorized this specific action, at this specific moment, with this specific intent becomes a legal, regulatory, and operational problem of the first order.
Today, agent platforms answer with session-level trust: the human authenticated once, the agent operates inside the session, and every downstream action inherits the authorization. This is the same architectural error that produced session-based fraud for twenty years. Autonomy magnifies the blast radius.
The agent can request. Only the human can authorize.
No agent-specific magic, the same execution-authority mechanism, pointed at the agent threat. Six moving parts, all shipped.
Signed push to the enrolled human
When an agent hits an action your policy flags, the server pushes a signed ACTION_APPROVAL_REQUEST to the authorizing human's enrolled device (FCM on Android, APNs on iOS). The screen shows the exact action the agent will execute. No registered device, no approval: the request fails closed.
Bound to the exact action
A biometric press produces an Authoritative-tier proof over the real parameters. Change the amount, the recipient, or the command and the payload hash no longer verifies. A push for one action cannot approve another.
Your policy sets the line
You map action risk to a tier. Routine actions pass on the agent's session; anything above the line needs a fresh human proof. You own the threshold, per action type, amount, counterparty, or scope.
Or the human signed the boundary once
For work that cannot wait on a person, the human signs a mandate on their own device instead: which action types, up to what ceiling, how many in a day, until when. Inside those bounds the agent proceeds and nobody is interrupted. The authority was granted in advance, by signature, which is the design rather than a gap in it.
No mandate, no execution
If no mandate covers the agent, or the one it names has been revoked, the call fails rather than falling back to whatever its OAuth token or service account still carries. Revocation lands on the next call, not at the next token refresh.
Verifiable downstream
The agent carries the proof into your call. Your server checks the ES256 signature against the public key published at /.well-known and refuses the call if it does not verify, with no Yuthent round-trip needed to make that decision. What lands in the hash-chained ledger afterwards is the record of a call that passed.
Execution-time proof. Per action. Per human.
Your policy classifies the action
Below the threshold you configured, the agent proceeds inside its session, routine reads, low-value calls, internal operations. No human interruption.
Threshold crossed
An outbound payment above a configured amount. A new counterparty. An irreversible or regulated action. Whatever your policy marks as needing a human.
Push to the human's device
The server routes a signed approval request to the authorizing human's enrolled phone. The screen shows the action parameters exactly as the agent will execute them. Any change invalidates the payload hash.
A biometric produces the proof
A press of the sensor unlocks the hardware key and produces an Authoritative-tier proof bound to those exact parameters. No press, no proof. No proof, no action.
The agent submits; you verify; only then does it execute
The agent includes the proof in the downstream call. Your verifier checks the signature against the published public key. It verifies and the action runs. It does not and the call stops at your gate. Either outcome lands in the hash-chained ledger.
We don't issue agent identities. We authorize the action.
Everyone is building the delegation layer, which human authorized which agent, via OAuth, on-behalf-of, and agent-grant drafts. That layer is software-level and necessary, and you keep it. Yuthent is the execution layer beneath it: did this specific action get human approval, right now, in hardware.
A runtime agent gateway can call Yuthent as the decision point for the high-risk subset: pause the action, request a signed human approval, release or block on the result. We compose with your agent stack, we do not replace it.
You decide. We prove.
Authority over an action comes from three places, and all three are yours: the mandate the person signed, the policy engine you already run, and whatever scores risk in your stack. Swap any of them for the tool you actually use, a bank's fraud engine, an EDR, your own service. Yuthent is in none of the three. An AI agent holds none of it either; it operates inside a boundary a verified human signed.
The person it belongs to
A standing mandate they filled in and signed with a biometric on their own device. Limits, targets, categories, their terms, not an administrator's.
Your policy engine
Whatever already holds your rule book. Thresholds, windows, change-control gates. Your rules, running where they run today.
Your risk system
Whatever scores risk in your stack. Above your own threshold, the action needs a human instead of a silent pass.
The decision · yours
Every agent action is checked field by field, at execution.
Not screened by a model. Compared, field by field, against terms a verified human signed.
Inside the signed terms
Every field matches the mandate. The action settles without interrupting anyone.
Beyond what was signed
Over the ceiling, an unpermitted action type, or an unlisted counterparty. The call stops and goes to the human for a fresh approval.
No mandate to spend
Absent, revoked, or past the expiry. The action does not run.
Yuthent is in none of those three.
We do not set your limits, score your risk, or decide your actions. Replace any of the three with a different vendor tomorrow and nothing here changes. Your engines decide; Yuthent produces the evidence that a verified human stood behind the decision, and the signed record names the engine that made the call, not us.
You decide. We prove.
A token proves a grant. Hardware proves the decision.
The agent-authorization approaches converging today (OAuth on-behalf-of, delegated grants, DID-signed agent tokens) all live at the delegation layer: which human granted which agent which scope, once, in software. That layer is useful, and you keep it. But a software token issued in advance cannot prove that a specific human approved this specific action at the moment it fired.
Yuthent signs the act, not the grant. A fresh biometric on the enrolled person's hardware, Secure Enclave or StrongBox, produces a non-repudiable proof bound to the canonical action, verifiable against a published key. It composes with your delegation layer; it is the piece none of them hold.
The standards agenda is moving the same direction: NIST's AI Agent Standards Initiative, launched in February 2026, names security and identity research among its pillars, and its agent identity and authorization concept work covers non-repudiation explicitly.
Where a named human is on the hook.
The gate earns its cost where a signature is legally load-bearing, regulated, high-blast-radius actions where a software log is not enough and a specific person is accountable when it goes wrong.
Agentic finance
A managed-account agent handles routine rebalancing on its own session. A transfer above the ceiling does not settle, a new beneficiary does not get paid, and a venue change does not take effect until the accountable human signs for it. When that transaction is later challenged, the investigation holds a signed, parameter-bound record of exactly what the human approved.
Financial transactionsPayment authorization vs task authorizationAgentic healthcare
A clinical agent handles routine lab orders and template-compliant documentation. A controlled substance does not transmit, a high-risk intervention does not proceed, and a record does not leave the standing scope until the named prescriber signs for it.
HealthcareAgentic infrastructure
An operations agent handles routine deploys. A production database operation does not run, a security policy does not change, and a secret is not read until the accountable operator signs for it. Anything inside your blast-radius policy stops at the same gate.
CybersecurityAgentic enterprise
A workflow agent drafts under template. A deviation does not go out, a counterparty outside the approved list is not contracted, and nothing that would bind the company legally leaves the building until the named signatory signs for it.
Workforce & enterpriseAgent authorization, answered.
How do you authorize AI agent actions?
You decide which agent actions need a human. For those, the server pushes a signed approval request to the human's enrolled device; a biometric press produces an Authoritative-tier proof bound to the exact parameters. The agent includes it, and your server verifies it against a published public key. An agent inside a valid session still cannot produce that proof, it can request, only the human can authorize.
Does the agent get its own Yuthent identity?
No. Yuthent does not issue agent identities; that is the delegation layer (OAuth, on-behalf-of, agent grants), and you keep it. Yuthent is the execution layer beneath it: the action does not run unless it carries authority the named human signed, either a fresh press for that action or a standing mandate whose bounds it falls inside.
Can prompt injection or a compromised model forge the approval?
No. The proof requires a fresh biometric on the enrolled human's hardware. The signing key never enters the prompt, the model, or a tool output. A compromised agent can be told to request anything, but it cannot produce the human's signature.
How does the human receive the request?
The server pushes a signed ACTION_APPROVAL_REQUEST to the enrolled device (FCM on Android, APNs on iOS) carrying the exact action parameters. A biometric press produces the proof. If no device token is registered or delivery fails, the request fails closed rather than proceeding.
When an agent-initiated transaction is disputed, what evidence exists?
A mandate-bound proof. The human signs the mandate on their enrolled device: amount ceiling, counterparty scope, expiry, hashed into a sealed Authoritative-tier payload. The objection is timing: the human approved at T0, the agent executed at T1. Mandate binding answers it: your backend verifies every T1 action against the T0 mandate. An action outside the signed parameters does not proceed on that mandate: it stops and returns to the human for a fresh approval, and an expired or revoked mandate fails outright. What the investigator holds is an ES256 artifact, independently verifiable against a published key, bound to the action parameters. Yuthent produces the evidence. Your dispute process consumes it.
Does it replace OAuth or my agent framework?
No, it composes. OAuth identifies the session; the Yuthent proof authorizes the specific action. Runtime agent gateways can call Yuthent as the decision point for the high-risk subset, pause the action, request a signed human approval, release or block on the result.
Building agent infrastructure?
If you are building agent infrastructure, agent products, or agent-integrated enterprise systems, we want to meet. A first deployment ships a working integration on one critical flow, with cryptographic evidence auditable on day one.