Human authority for agentic AI
Delegation with a cryptographic ceiling.
A person seals a bound, or a single action, on their own device. The agent operates inside it and cannot widen, extend or reissue it.
The problem
Standing credentials have no ceiling.
An agent is given an API key, a service account, or a long-lived token so it can operate without interruption. That grant carries no limit that survives contact with the agent: no amount cap it enforces, no expiry it respects, no scope it cannot reason its way around.
No ceiling
An API key or a service account carries no amount it will not move. The scope that permits a five-dollar refund permits a five-million-dollar one.
Illustration, not a figure
No expiry
A long-lived token is valid until someone rotates it. Nothing in it says when the grant should have ended.
No record of its own
When it acts outside what anyone intended, nothing in the credential says it did. The log has the same author as the act.
What a mandate binds
Seven fields, sealed once.
The fields the code checks on each call your system sends. Each is inside what the device sealed.
Action types
The mandate lists the action types it covers. A call of any other type comes back as a step-up demand.
Per-action ceiling
One amount limit, checked on each call. An amount over it, or a call that names no amount at all, comes back as a step-up demand.
Daily total, when the mandate declares one
A mandate may declare a daily total. When it does, each authorized amount is added to that day’s count and a call that would pass it comes back as a step-up demand. A mandate that declares none keeps no total.
Counterparty allowlists
Payees, subscriptions or suppliers, listed by hash when the bounds are sealed. A counterparty off the list, or none named where a list applies, comes back as a step-up demand.
The named agent scope
The person names the scope the mandate covers. A call asserted under a different scope is not covered by it.
Validity window
A start and an end, sealed with the rest. Outside the window the mandate is not consulted at all: the call fails as if no mandate existed.
The subject device
A delegation mandate is bound to one enrolled device and covers that device’s person alone. A new enrolment does not inherit it, and the server refuses a mandate whose sealed bounds differ from what that device signed.
How it works
The person seals the bounds once. Your system asks before it acts.
The person seals the bounds
Action types, ceiling, counterparties, agent scope and window are sealed on the enrolled device and signed there with a key held in Android StrongBox or the TEE, or in the iOS Secure Enclave. The server recomputes what was sealed and refuses a mandate whose bounds differ.
Before acting, your system asks
Your system submits the action it is about to run: its type, amount, counterparty and your own reference. One check against the sealed bounds returns one of three answers. It proceeds. It comes back as a step-up demand with the level the ceremony must reach, and your system sends it to the person. Or it fails: no mandate covers it, it was revoked, or its window has passed.
The signed decision, verified at your gate
A proceeding call returns a decision signed by Yuthent, naming the action, the amount, the counterparty and your reference. Your endpoint verifies it before it acts, and the verify step fails closed on any check. With your reference, the decision is bound to that one action; a retry returns the same decision.
The boundary of the guarantee
Yuthent decides. Your gate enforces.
What the mandate proves, where it stops, and what is still open. Stated here, not hidden.
Your gate enforces
The decision is designed as a precondition: your endpoint verifies it before it acts. A second API path that reaches the same operation without that check bypasses it. What is not required is not controlled.
A signature proves the key and the data
It proves this device’s key signed exactly these bounds, or exactly this decision. It does not prove intent or understanding, and it does not make a wrong decision right.
Per action, always. Per day, only when declared
The ceiling is checked on each call. A daily total exists when the mandate declares one. Without it, calls under the ceiling add up to no total this system counts.
Revocation reaches the next call
Status is read live on every decision, with no cache. Revocation takes effect on the next call, not the one already decided. A tenant owner or admin, or the issuing actor, revokes; today that is not something the person does from their own phone.
Issuance and the biometric
Issuing a mandate is a sealed, signed ceremony on the enrolled device. Requiring a fresh biometric at issuance by construction is a pending change, so this page does not claim it.
The software behind the call
The record proves that an action matched the scope the person sealed. It says nothing about which software sent the call, and this page does not claim it does.
Where it applies
The same bounds, on five kinds of action.
Each is the mechanism above with different fields sealed.
A production deploy
The right to ship is a listed action type inside a window, not a standing token in the pipeline.
A permissions change
Granting a role is an action type the mandate must list; a change of any other type comes back as a step-up demand.
A sensitive export
The export runs against the bounds sealed for it and leaves a signed, chained record naming the mandate and the device.
A payment approval
A payee allowlist and a per-action ceiling, sealed once; a payee off the list comes back as a step-up demand.
A refund by a service agent
The agent’s scope is named, the ceiling is per refund, and a daily total applies when the mandate declares one.
First-call questions
Answered plainly.
What stops the agent from asking for a new mandate when it hits the ceiling?
A mandate is not a token the agent can mint. Issuing one is itself a sealed, signed ceremony on the enrolled device: the server recomputes what the device sealed and refuses a mandate whose bounds differ from it. An agent asking for more authority produces a ceremony for a person, which is the intended behaviour.
What if the agent is compromised?
It can act inside the sealed bounds: the listed action types, the per-action ceiling, the counterparty lists, the window, and a daily total when the mandate declares one. Every authorized action leaves a signed, chained record naming the mandate and the device. Revocation is read on the next call, with no cache.
Which agent did it?
The record does not answer that, and this page does not claim it. It answers a different question: each human decision keeps its own signed record, bound to the action it authorized, so what a person sealed and what ran under it stay separable.
Keep reading
See it on your own flow.
Your app, your call, our SDK.