Mandates
Powered by oneface — advanced biometrics↗Fourteen patent claims filed · revocable at any moment · enforced at the rail, not in the prompt · an anchored receipt on every action
Proof that a human authorised this agent
Mandates is the patent-pending technology that lets any AI protocol act in the name of a human — against another machine, or in the real world.A mandate proves human intent, signed at the moment it is given.Powered by oneface — advanced biometrics↗Fourteen patent claims filed · revocable at any moment · enforced at the rail, not in the prompt · an anchored receipt on every action
What it is
An authorisation signed by a living person
A mandate is the authorisation a live human signs that says: this machine may do this, up to this limit, in this scope, until this date. It is granted once, by a person proven alive at that second, and it lives where the agent cannot reach it.If the ceiling lives in the instruction, anything that can rewrite the instruction can rewrite the ceiling. So the rail refuses what falls outside the mandate, however convincingly it is asked — and the refusal is the trail working, not an error.The proof behind it
A mandate is worth exactly what the proof of who granted it is worth. Anchor it in a password, a token, a code by message or a biometric someone else is holding, and it inherits the weakness of each.A mandate is only as strong as the proof behind it
PasswordAuthorises whoever knows the secretWhich is the holder, the person they shared it with, and whoever bought the breach. The mandate cannot tell those three apart, because the credential cannot.
Token or deviceAuthorises whoever has the handsetA stolen phone is a valid grant. So is a SIM swapped an hour ago. The grant is strong; the thing it is anchored to walked out of the building.
Stored templateAuthorises whoever resembles a recordA comparison, not a presence. It answers “this looks like the enrolment” — never “a living person was here just now”. Two different questions, and only one of them holds up in a dispute.
Living tissueAuthorises a personRead in that second, proved without leaving the device, and discarded. The only one of the four where the answer to “was somebody actually there?” is yes.
The attack is not the one legacy biometrics was built forNobody is holding a printed photograph up to a lens any more. The risk is synthetic video injected straight into the camera stream, which a system designed to reject paper does not see coming.So the reading is bound to the device’s secure hardware, every request carries a challenge that expires in seconds, and a proof issued for a sign-in cannot be replayed to approve a payment.Read the threat model ↗
The question every buyer asks, answeredWhat happens to my mandates if the vendor is acquired, subpoenaed or breached? A mandate anchored in a custodied template is exactly as durable as the company holding the template.We hold no template, so we can be neither the origin of the failure nor the bottleneck of the proof. Verification does not depend on our cooperation — including if we stop existing.The trust model ↗
The question every developer asks
OAuth is still the right tool for signing in, and nothing here replaces it. What is missing is a different thing entirely.OAuth proves an app has access. It does not prove a person agreed.
DelegationBetween systems, not from a proven personA token says an app has permission on an account. It does not say a living human was present when that permission was given — or that the human still exists.
UnitNo economic ceiling existsAn OAuth scope is “can read your calendar”. There is no “may spend up to forty dollars a month”. Agent consent needs a number, and the grammar has nowhere to put one.
ProofNothing left for the counterpartyOAuth is bilateral: the server knows it issued the token. The seller on the other side verifies nothing independently. An anchored receipt is what closes that gap.
ConsentA click, and anything can clickThe consent screen is satisfied by a click, and a click is exactly what software is best at. This is where reading living tissue comes in.
Sidaxis does not replace OAuth — it sits underneath it. Keep OAuth for sign-in, and bring in a mandate at the moment an agent is about to act. Every identity provider stays a potential customer, not a competitor.How it maps ↗
Scope
A mandate is a single signed thing. Remove any one of the five and it stops being enforceable — which is why it is not a menu of options.Five fields, one object
granted_by
Who authorised itA human, proven alive by oneface at the moment of the grant — not an account that clicked a button, and not a session that was already open.
granted_to
Who may actThe agent, named. A different agent presenting the same mandate is refused, so a compromised integration cannot inherit someone else’s authority.
scope
What it may doThe operations permitted, in terms the rail enforces without interpreting language. Purpose lives in the receipt, not here — a rail that has to understand intent can be argued with.
ceiling
Up to how muchAn amount, a count, a counterparty set. Enforced at the layer that moves the value, so the agent can believe anything at all and still be refused.
until
Until whenAn absolute expiry, so an abandoned agent lapses instead of lingering — and a revocation reference the granter can use immediately, without the agent’s cooperation.
Revocation is free and immediateOne call, and every branch under that mandate stops at the same instant. We never charge to revoke.
Every action under it leaves an anchored receiptChecked, refused or completed — each one anchors under the mandate reference and can be verified without an account.
Workflow
Five steps, in order, every time. The person is at the start and the receipt is at the end — and only the receipt leaves the layer.From a human decision to a receipt anyone can check
Human intentA person decides, on their own device.
Nothing starts without them. The decision is the event, not the click that follows it.Proof of a live humanLiving tissue, proven at that second, nothing stored.
It runs on the person’s own device. A generated video, a printed face and a replayed recording all arrive without a living body behind them.Mandate issuedScope, ceiling and expiry, written down.
The five fields are filled in and signed. From here the agent has authority it cannot widen, in a place it cannot rewrite.Agent actsInside the mandate, checked before every action.
Every action calls the check first and gets allowed true or false with the reason. A refusal is the rail working, and it is not billed.Receipt anchoredAny counterparty can check it, with no account.
The receipt is the only part that leaves the layer, and it is immutable. It returns the seal, never the value behind it.Core applications
The same five fields, with different content. Revoke the mandate and every branch stops at once.What a mandate can authorise
Agentic loginA session no bot can open.
01CAPTCHA and anti-botThe site cannot tell an authorised agent from a scraper, so it blocks both. A legitimate user’s agent dies at the same wall as the scraper.
Password and SMS codeThe agent should not hold the password, and the code needs the person right then. Half of all automations end in “I could not access your account”.
And once in, it is in without limitsIf the user hands over the credential, the agent becomes the user — no scope, no ceiling, no expiry, no trail.
What it authorisesThe site does not have to guess whether the caller is a bot or a human. It receives a mandate that says who authorised the session, what that session may do and until when. Revoke it and the session dies at once.
How the mandate is filled inscope: ["access"]
ceiling: { count: 1, period: once }
until: "2026-09-21T00:00:00Z"
require: proof_of_live_human
ceiling: { count: 1, period: once }
until: "2026-09-21T00:00:00Z"
require: proof_of_live_human
For the site ownerRight now you lose business by blocking agents and take risk by letting them in. Accepting an agent with proven authorisation is the option the agentic commerce protocols already assume exists, and nobody shipped.
Free foreverThe login session and the login mandate are free, unlimited, forever. The first identification of that person is still paid. Recognising them afterwards is free.
Continue with onefaceOne button, two uses: a human signs in, an agent signs in with a mandate. You install it once and serve both.Agentic login docsThe receipt proves: That a living person opened this session, at that second, and under which mandate.
Agentic purchaseOne basket, inside the ceiling.
02What it authorisesAn agent completes one purchase for a named person, at a named merchant, up to an amount that person set before the agent ever ran. Over the amount, or at a different merchant, the check refuses and nothing settles.
How the mandate is filled inscope: ["payment"]
ceiling: { amount: 250, currency: USD, period: once }
counterparties: ["merchant_9x"]
until: "2026-10-14T00:00:00Z"
ceiling: { amount: 250, currency: USD, period: once }
counterparties: ["merchant_9x"]
until: "2026-10-14T00:00:00Z"
The receipt proves: Who authorised this basket, and that the amount was inside what they allowed.
Agentic paymentsRecurring, until revoked.
03What it authorisesThe same mandate pays every month without asking again. The ceiling resets with the period, and the month a bill arrives higher than the ceiling is the month the agent is refused instead of surprising anyone.
How the mandate is filled inscope: ["payment"]
ceiling: { amount: 40, currency: USD, period: month }
until: "2027-09-14T00:00:00Z"
require: proof_of_live_human
ceiling: { amount: 40, currency: USD, period: month }
until: "2027-09-14T00:00:00Z"
require: proof_of_live_human
The receipt proves: That every charge in the series ran under one authorisation, and which one.
Agentic tasksEach step under the same scope.
04What it authorisesA long-running agent takes many steps toward one goal. Every step calls the check first, so a plan that drifts outside the scope stops at the step that drifted — not after the fact, in a log someone reads on Monday.
How the mandate is filled inscope: ["access"]
ceiling: { count: 20, period: day }
until: "2026-12-31T00:00:00Z"
ceiling: { count: 20, period: day }
until: "2026-12-31T00:00:00Z"
The receipt proves: Which steps were inside the scope, and where the agent was refused.
SignatureA person signed, not a session.
05What it authorisesOne document, one signer, one mandate that expires the same day. Attribution is the part that holds up later, which is why the signature is undeniable rather than merely recorded in someone’s system.
How the mandate is filled inscope: ["signature"]
ceiling: { count: 1 }
until: "2026-09-15T18:00:00Z"
require: proof_of_live_human
ceiling: { count: 1 }
until: "2026-09-15T18:00:00Z"
require: proof_of_live_human
The receipt proves: That a live human authorised this signature, and which document it covered.
Data shareOne answer, not the document.
06What it authorisesThe asking party receives the answer and never the document, so there is nothing for them to store, lose or be breached over. The mandate names who may ask and how long the answer stays valid.
How the mandate is filled inscope: ["data_release"]
ceiling: { count: 1, period: once }
counterparties: ["acme_co"]
until: "2026-09-14T23:59:00Z"
ceiling: { count: 1, period: once }
counterparties: ["acme_co"]
until: "2026-09-14T23:59:00Z"
The receipt proves: That the person released this answer, to that counterparty, once.
ID proofOver a threshold, not the date.
07What it authorisesOver eighteen, resident here, licensed for that. The answer is the threshold, not the birth date and not a scan of the card — and a company that never received the date cannot leak it.
How the mandate is filled inscope: ["data_release"]
ceiling: { count: 1, period: once }
until: "2026-09-14T23:59:00Z"
require: proof_of_live_human
ceiling: { count: 1, period: once }
until: "2026-09-14T23:59:00Z"
require: proof_of_live_human
The receipt proves: That the threshold was met, without recording the value behind it.
AccessA door released once.
08What it authorisesA door, a gate, a turnstile or a room releases once and closes behind the person. The mandate expires the same evening, so a credential that leaks the next day opens nothing.
How the mandate is filled inscope: ["access"]
ceiling: { count: 1, period: once }
until: "2026-09-14T20:00:00Z"
require: proof_of_live_human
ceiling: { count: 1, period: once }
until: "2026-09-14T20:00:00Z"
require: proof_of_live_human
The receipt proves: Who entered, under whose authorisation, at what second.
Revoke
One call revokes the mandate, and every application above stops at the same instant — the session, the purchase, the recurring payment, the task loop, the signature, the answer, the threshold and the door. Nothing needs to be chased down, because nothing was ever granted anywhere else.Revoke in the referenceA check after revocation returns allowed: false with mandate_revoked.
Agentic checkout
Every agentic checkout needs an answer to one question: who authorised this?
An agentic checkout has three parts — discovering the product, authorising whoever is buying, and settling the money. The first and the third already have owners, and good ones. The middle one is the mandate, and it is the part nobody has shipped.
Step oneDiscoveryThe agent finds the product. Catalogues, marketplaces and shopping protocols already do this well.
→Step two · SidaxisAuthorisationDoes this purchase fall inside a mandate a verified human granted? Allowed or refused, with the reason. No money touched.
→Step threeSettlementThe PSP, the issuer or the marketplace moves the money, holding the receipt that says who allowed it.
Before the PSP call, never in place of itOne synchronous endpoint answers whether an action fits a mandate — scope, ceiling, validity — and the executor settles or stops. That is the whole of agentic checkout on our side, and it never touches money.The check endpoint and its webhooks ↗
Why that boundary is the businessBecause we do not settle, any PSP, marketplace or issuer is a customer instead of a competitor. Give an agent a wallet, not your keys — and give the wallet a ceiling somebody has to be alive to raise.
Build
The first decision you make. Both modes issue the same mandate and return the same receipt.Two ways in
HeadlessYou build the screen, we answer behind itFull control of the experience. You render your own frontend and call the API behind it — REST and MCP on the same account and the same keys.Headless quickstart
Your UI, your copy, your flow
Same keys for REST and MCP
HostedWe render the mandate screen for youCreate a session, get a URL, redirect the user, receive the result by webhook. Integration needs nothing but your API key.Hosted quickstart
No frontend work at all
White-label included: logo, colours, domain and copy
In codeAPI reference ↗
Eight lines, and the agent has authority it cannot widen
Call it over REST, or expose it as an MCP tool so the agent can request a grant without anyone writing an integration. Either way the ceiling is evaluated where the value moves, not where the reasoning happens.Liveness required at the grant, not at the call
Every action anchors under that mandate reference
Revoked in one call, effective on the next request
mcp.sidaxis.com · grant_mandate
{
"granted_to": "agent_7f2c",
"scope": ["payment"],
"ceiling": { "amount": 200, "period": "month" },
"until": "2027-03-01",
"require": "proof_of_live_human"
}
→ mandate_9f41c7b2 · receipt 0x7c3d…a41fThe agent may ask for more. The rail answers the same way every time.Every action under a mandate leaves a receipt anyone can check.Anchored, so it cannot be rewritten afterwards. Public, so your counterparty confirms it without an account, a login or a word from us.