AI Agent Authorization
Agents act. Humans authorize. We produce the proof.
An agent can compose a request and send it. Releasing the signature takes the person, on their own phone, with their fingerprint or face.
In Short
How do you authorize AI agent actions?
You decide which agent actions need a person. For those, the approval request goes to their enrolled device, and their fingerprint or face releases a signature bound to that exact action. The agent includes it in the call; your server verifies it before anything runs. An agent inside a valid session can compose the request. Releasing the signature takes the person.
The Split
An agent can ask for anything. Asking is not authorizing.
An agent operating in your systems can compose any request it likes and put it on the wire. What it does not reach is the key that turns a request into an authorization. That key is generated inside the secure hardware of the person's own phone, Android's StrongBox or the TEE or the iOS Secure Enclave, and it is released by their fingerprint or face. Nothing in a prompt, a model or a tool output reaches it, because it is not in the software at all.
That is also what keeps the record readable afterwards. Each human decision keeps its own signed record, bound to the action it authorized, so what a person approved and what ran under it stay separable. It does not tell you which agent acted, and this page does not claim it does.
Where the platform proves it, and where it does not yet
On Android the device's own attestation carries the policy the key was created under, so your server can confirm the key it is trusting cannot be used without a live fingerprint or face. iOS does not give the same proof today and that path is being closed. Until it is, what this page states is where the signature is released, not that the property is proved identically on both platforms.
The Gate
The agent can request. Only the person can authorize.
No agent-specific machinery. The same execution authority the rest of the site describes, pointed at the agent case, and two ways an action can carry it.
A request lands on their phone
When an agent reaches an action your policy flags, the approval request goes to the enrolled person's own device, and the screen shows the action the agent will run. No enrolled device, no approval: the request fails closed rather than proceeding.
Bound to the action it was made for
The approval carries the action it was made for. Change the amount, the recipient or the command afterwards and it no longer matches, and your backend refuses it. A request for one action cannot approve another.
Your policy sets the line
You decide which actions need a person, by action type, amount, counterparty or scope. Everything below the line runs on the agent's own session, untouched. You own the threshold and you move it.
Or the person signed the bounds once
For work that cannot wait, the person signs a mandate on their own device instead: which action types, up to what ceiling, 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 token or service account still carries. Revocation lands on the next call, not at the next token refresh.
Your backend is the gate
The agent carries the approval into your call. Your server verifies it against a key Yuthent publishes, and refuses the call when it does not verify, without calling us to decide. Until your own endpoint requires that check, a second path to the same operation reaches it without one.
How It Works
Four steps, and your server has the last one.
Your policy classifies the action
Below the line you set, the agent proceeds inside its session: routine reads, low-value calls, internal operations, no interruption. Above it — an outbound payment over your threshold, a new counterparty, something irreversible or regulated — a person is asked.
The request reaches the person
It goes to the enrolled device of the person accountable for that action, showing the parameters exactly as the agent will run them. Anything that changes afterwards no longer matches what they approved.
Their fingerprint or face releases the signature
The key sits in the phone's secure hardware, Android's StrongBox or the TEE or the iOS Secure Enclave, and it will not sign until the person releases it. No release, no approval. No approval, no action.
You verify, and only then does it run
The agent includes the approval in the downstream call. Your server verifies it against a key Yuthent publishes. It verifies and the action runs; it does not and the call stops at your gate. Either way the decision keeps its own signed record.
The Authority Model
You decide. We prove.
Everyone is building the delegation layer: which person authorized which agent, through OAuth, on-behalf-of, agent grants. That layer is software and you keep it. Yuthent sits underneath it and answers a different question — did this action carry a person's approval, and can you check it yourself.
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. Yuthent is in none of the three, and an agent holds none of it either — it operates inside a boundary a person 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 call is resolved against the bounds a human signed.
Not screened by a model. Resolved against the bounds the enrolled 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; what Yuthent produces is the record that a person stood behind the decision.
You decide. We prove.
Why Not a Token
A token proves a grant. Hardware proves the decision.
The agent-authorization approaches converging today, OAuth on-behalf-of, delegated grants, signed agent tokens, all live at the delegation layer: which person granted which agent which scope, once, in software. That layer is useful and you keep it. What a token issued in advance does not carry is that a person approved this action at the moment it fired.
Yuthent signs the act rather than the grant. The person's fingerprint or face releases a signature, in the secure hardware of their own phone, bound to the action it was made for and checkable against a key we publish. It composes with your delegation layer, and it is the piece none of them hold.
Where It Matters
Where a person is on the hook.
The gate earns its cost where a signature carries weight: regulated, high-blast-radius actions where a software log is not enough and a specific person answers for it afterwards.
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 person signs for it. When the transaction is questioned later, what the investigation holds is a signed record bound to exactly what that person 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 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 leaves the building until the signatory signs for it.
Workforce & enterpriseQuestions
Agent authorization, answered.
How do you authorize AI agent actions?
You decide which agent actions need a person. For those, the approval request goes to their enrolled device, and their fingerprint or face releases a signature bound to the exact action. The agent includes it, and your server verifies it against a key Yuthent publishes. An agent inside a valid session can compose the request; releasing the signature takes the person.
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 enrolled person signed, either a fresh approval for that action or a standing mandate whose bounds it falls inside.
Can an agent produce the approval on its own?
The signature is released by the person's live fingerprint or face, inside the phone's secure hardware. Nothing in a prompt, a model or a tool output reaches that key. On Android the device's own attestation lets your server confirm the key was created so it cannot be used without that release; iOS does not give the same proof today and that path is being closed, so this page states where the signature is released rather than claiming the property holds identically on both.
Which agent did it?
The record does not answer that, and this page does not claim it does. It answers a different question: each human decision keeps its own signed record, bound to the action it authorized, so what a person approved and what ran under it stay separable.
When an agent-initiated transaction is questioned, what evidence exists?
The mandate the person signed on their own device — action types, ceiling, counterparties, expiry — and the record of what ran under it. The objection is timing: the person approved before, the agent acted after. The mandate answers it, because your backend checks every action against the bounds that were signed. An action outside them does not proceed on that mandate: it stops and returns to the person for a fresh approval, and an expired or revoked mandate fails outright. Yuthent produces the record. Your dispute process consumes it.
Does it replace OAuth or my agent framework?
No, it composes. OAuth settles who holds the session; the Yuthent approval authorizes the specific action. A runtime agent gateway can call Yuthent as the decision point for the high-risk subset: pause the action, request an approval, release or block on the result.
See it on your own flow.
Your app, your call, our SDK.