A person cannot be handed to someone else.
Everything we use to represent one can.
A password. A code. A device. A session. Every one of them stands in for a person, and every one of them can be handed over, borrowed, or inherited by software.
Yuthent proves the one thing that cannot be handed over:
The fourth security layer·after authentication, authorization, audit
A cryptographic receipt for every sensitive action, bound to the specific human and signed on their device. Attackers can’t forge it. AI agents can’t act without it.
Not a break-in. Three completely different actors, one system, and a verdict that cannot tell them apart.
Nobody broke in. All three were already logged in.
Three actors with nothing in common: one entitled, one autonomous, one hostile. Every control in the stack returns the same answer for all of them.
Approved the payment.
Present. Deliberate. Entitled to do it.
Deleted the database.
Told never to. Read the rule. Proceeded.
Domain admin in 40 minutes.
One phone call. No malware. MFA passed.
What the system sees
EXECUTE
identical for all three
Every check passed. Nothing linked a trusted person to this action, at that moment.
Sources: April 2026 public post-mortem of an agent-initiated database deletion; Mandiant M-Trends 2026 (help-desk call to domain admin in under 40 minutes, no malware); adversary-in-the-middle kits relay one-time codes inside the validity window; Verizon DBIR.
of web-app breaches use valid, stolen credentials. The session is real; the human is not.
Verizon 2025 DBIR
in business email compromise losses across 21,442 incidents, every one inside a valid session.
FBI IC3, 2024
of organizations cannot tell a human action from an AI agent's. The blind spot, measured.
CSA / Aembit, 2026
A scoped 90-day pilot costs less than one incident.
Three questions. No system answers any of them.
The stack proves identity at login and permission at policy. Between the last check and the executed action, every answer is a claim the system makes about itself.
The lifecycle of one critical action
Login
✓ identity proven
Session
identity inherited
Policy check
✓ permission proven
?
no proof exists
Action fires
money moves · drug dispensed
Audit log
the system’s own testimony
Whose key signed this?
Today: Assumed at enrollment, never verified. Two people can be enrolled on one device and the platform returns the same yes.
AssumptionWas a human even present?
Today: The session says so. OTP re-checks the session, not the person, and when the actor is an agent there is no one to ask.
InferenceWas it what they approved?
Today: Nothing checks. A person approves an intent; the system executes parameters. Nothing binds the two together.
UncheckedWhat you hand the regulator today
14:22:07 transfer.approve user=a91f status=AUTHORIZED
A line the system wrote about itself. Not evidence, testimony.
The requirement, and the artifact that answers it.
Your auditor is not asking whether you have a policy. They are asking you to produce evidence that an authorized human approved a specific action. Process — trained overseers, halt buttons, audit logs — does not produce an artifact. This does.
DORA · Art 9(4)(d)
Strong authentication and cryptographic key protection
Signing keys generated and held in the Secure Enclave or StrongBox. Non-exportable by construction.
DORA · RTS Art 12(2)(d)
Tamper-proof records of privileged activity
An append-only, hash-chained ledger. Altering one entry breaks every entry after it, visibly.
DORA · RTS Art 21
Just-in-time privileged access
Authorization per action rather than per session, at the Explicit and Authoritative tiers.
PCI-DSS v4.0.1 · Req 8.5.1
Authentication not susceptible to replay
A server-verified monotonic counter signed into the payload. A captured proof cannot be replayed.
EU AI Act · Art 14(4)(d,e)
Affirmative human override for high-risk AI
A fresh biometric signature per action, bound in hardware to the exact payload the human was shown.
EU AI Act · Art 14(5)
Four-eyes confirmation for biometric systems
Dual signature at the Authoritative tier: the device proof plus a synchronous server co-signature.
Reg (EU) 2022/2554 (DORA) and Commission Delegated Reg (EU) 2024/1774; PCI-DSS v4.0.1; Reg (EU) 2024/1689 (EU AI Act) as amended by the Digital Omnibus — high-risk obligations apply from 2 December 2027. Mapping is ours; it is not a certification, and your auditor’s scope governs.
One artifact closes all three questions: a cryptographic proof of human authority, produced per action.
A fresh biometric, signed in hardware, bound to the exact action.
No images, templates, or match data ever leave the device. It sends a hardware-signed, action-bound proof, and your server confirms a real human approved the exact action, without ever seeing the biometric.
Enroll once
Bind a person to a hardware trust anchor, attestation-gated. You bring the identity: your IdP, KYC, or in person.
Prove per action
At the action, a fresh biometric signs the exact payload inside the device security chip. Only the signature leaves the device.
Verify and ledger
Your server verifies the signed proof and writes it to a tamper-evident, hash-chained ledger.
What the proof guarantees
Hardware-bound
A compromised app can never sign for the user.
The key lives in the Secure Enclave or StrongBox and never leaves it.
Bound to this action
A proof can never be moved to a different action, or used twice.
The signature covers the real amount, recipient, and command, plus a server-verified counter.
See what you sign
The person verifies the real thing, not a reference number.
Real names and limits are shown and signed on the device. Only a hash reaches us.
Declaration
A tap cannot be faked. Malware taps buttons; it cannot know what a person meant.
On the top tier the user states their intent among real options and decoys, checked server-side.
Tamper-evident ledger
Nobody can rewrite what happened afterwards, including us.
Every proof is time-ordered and hash-chained. Change one entry and the chain breaks.
Offline-first
A bad network never blocks a legitimate approval.
Approval happens on the device. Only the top tier calls the server synchronously.
Agent mandate
An agent borrows a person’s authority and never owns its own.
A human signs the scope. Every agent action is checked against that signed boundary at execution.
Fraud-ready
You keep the decision. We only produce the evidence behind it.
Signals feed your policy engine, with alerts and webhooks into your existing pipeline.
How much proof each action demands — you choose, per action
Passive
Device-signed attestation, no biometric. Confirms the enrolled device is still within trust policy.
Silent
One biometric opens a short session; routine actions are cached within policy bounds. Offline-capable.
Explicit
Fresh biometric per action. Device-signed, server-verifiable proof. Offline-capable.
Authoritative
Fresh biometric plus synchronous server co-signature, hash-chained to the ledger. The action blocks until verified.
You map each action type to a tier. The tier is a contract between the SDK, your server, and your auditor — and it is enforced server-side, not by the client.
A passkey proves it’s your device. Yuthent proves it’s your decision.
A passkey signs an opaque login challenge. Yuthent binds a fresh biometric to each action’s real payload — the actual amount, target, and command — signed in hardware at the moment it runs. Every proof is independently verifiable (ES256 JWS) and chained into an append-only, tamper-evident ledger.
We prove it was them. We never learn what they look like.
Every biometric system you have evaluated asked you to trust it with the biometric. This one never receives it. The comparison happens inside the user’s own hardware and only the signature leaves — which is why there is nothing here to breach, leak, or subpoena.
The biometric itself
No image, no template, no match data. It is never transmitted, so it is never received.
The comparison
The face or fingerprint match runs inside the OS secure hardware, using native platform APIs. We do not implement it and we do not see its inputs.
The signing key
Generated inside the Secure Enclave or StrongBox and non-exportable by construction. It cannot be extracted, copied, or escrowed — not by an attacker, and not by us.
The tamper-evident ledger stores the payload hash, never the cleartext.
There is no central biometric database. Nothing to breach, nothing to leak, nothing to hand over.
On-device matching keeps special-category data out of scope by design rather than by policy — the GDPR Article 9 posture is documented and a DPIA package is delivered at onboarding.
Three layers secure the session. Yuthent secures the action.
Authentication, authorization, and audit all trust the session once it exists, who logged in, what they can reach, and what already happened. Execution Authority is the fourth layer that closes the gap, alongside the stack you already run.
The moment of action falls in the gap between them
Authentication
Okta · Entra · MFA
Verifies who signed in, once, at login.
Authorization
CyberArk · RBAC
Grants what the session may reach.
Audit
SIEM · UEBA
Records the action, after it executed.
Execution Authority
Yuthent · PSEA
Proves a specific human approved this action, at the moment it fires.
Four outcomes. One integration.
Block account takeover.
Stolen passwords, hijacked sessions, remote-control malware. The attacker cannot produce the cryptographic proof, so the action fails, even from inside a valid session.
Hold agents to a signed mandate.
The person whose authority it is signs a typed mandate — limits, targets, categories — with a biometric on their own device. Every agent action is then checked field by field against those signed terms, at execution. An agent never holds authority of its own; it borrows a boundary a human signed. Prompt injection cannot widen a mandate it cannot sign.
Name who decided and who approved.
Every sensitive action leaves a signed record: which of your engines made the call, which enrolled human authorized it, and the exact payload they were shown. Built to survive audit, dispute, and adversarial review. “I didn’t do that” stops being deniable.
Works in your stack.
One verify layer inside your existing APIs. ES256, independently verifiable by your backend, a regulator, or a court. Offline-capable for low- and medium-risk actions.
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.
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
Pushed to the enrolled device as a structured selection with decoys. There is no “Approve” button — the correct selection plus a live biometric is the authorization.
Past the signed ceiling
Over a signed limit, or a target outside the signed allowlist. Refused by the signer’s own terms — not by a model, and not by us.
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.
A deterministic input, not another score.
A valid hardware-bound proof is ground truth, so your engine consumes it as its highest-confidence signal. Additive, never a rip-and-replace.
Hold an action for an outside verdict.
Pause anything pending a decision from a supervisor, a helpdesk, or your own engine. The action stays pending until that decision returns.
Streams where you already look.
Every proof, refusal, and trust signal streams by webhook into your SIEM, UEBA, or PAM. Triage and the policy editor live in the control plane.
Put it on the flow that's bleeding.
Privileged access and admin escalation
Production access, config pushes, destructive operations. Zero-trust at the action, and insider denial closed.
AI agent actions
Deploys, data exports, fund movement. Checked against a signed mandate; no human authority, no execution.
Payroll, bulk export, attestations
Business email compromise and insider exfiltration, closed at the moment of action.
Wire and high-value payments
Authorize the transfer with proof the human approved this amount and this beneficiary. PSD2 SCA dynamic linking. APP-scam defense.
Account changes and SIM swap
Step-up that an attacker holding the session still cannot pass.
Controlled-substance prescribing
DEA EPCS non-repudiation. The prescriber of record, proven per script.
Which one of these is yours?
Name the flow you cannot currently prove a human authorized. We will scope it, tell you honestly whether we are the right answer, and show you what the evidence looks like on your own data.
A verify layer inside your existing APIs. Days, not quarters.
One SDK call client-side. Verify the ACK inside your existing endpoint, server-side. ES256. Your business logic does not move. Zero architecture change.
// client, one call wraps the sensitive action
const proof = await yuthent.authorize({
action: "prod.database.drop",
tier: "A", // Authoritative
payload: { cluster: "eu-west-1", table: "customers" },
});
// server, verify before you execute
const ok = await yuthent.verify(proof); // ES256 · hash-chained
if (!ok) return reject("no human authority");Independently verifiable against the published public key, by your backend, a regulator, or a court.
And where it runs — your data stays where it has to
Hosted
Shared, isolated infrastructure we operate. The fastest path from pilot to production.
Dedicated single-tenant
Your own deployment, your own keys, in the region your data has to stay in.
On-prem
A sealed, self-contained deployment inside your environment, for air-gap and full data-control mandates.
Your evidence does not depend on us being here.
Every proof is a standard ES256 JWS, verifiable against a published public key by your own backend, your auditor, a regulator, or a court — with no call to Yuthent and no Yuthent software. Export the ledger and it still verifies. That is the difference between evidence you hold and a vendor dashboard you rent.
Put it on one flow and see the evidence.
A scoped 90-day pilot on one real flow of yours. You leave with cryptographic proof for every action in it, and an executive report on the actions that still have none.
What security teams ask first.
How is this different from passkeys, FIDO2, OTP, or MFA?
Passkeys, FIDO2, OTP, and MFA authenticate at login and produce a session token that then authorizes every downstream action with no further check. Yuthent inverts that: the session identifies, the signature authorizes. Every privileged action carries a fresh, hardware-bound, biometric-enforced signature tied to the specific action parameters, not the session.
What are the four P/S/E/A tiers?
Passive is a device attestation, no biometric. Silent opens a short biometric session for routine actions. Explicit requires a fresh biometric per action with a server-verifiable proof. Authoritative adds a synchronous server co-signature and hash-chains the proof to the ledger. Your backend policy selects the tier per action.
Can an AI agent or bot approve an action inside a trusted session?
No. Explicit and Authoritative tiers require a fresh biometric from the enrolled human on the bound device. An agent, bot, or automation operating inside a valid session cannot produce that proof from the device secure element. A session can be delegated to an agent; authorization cannot.
Does Yuthent store or transmit biometric data?
No. All biometric verification runs on-device inside StrongBox, TEE, or Secure Enclave using OS-native APIs. Yuthent servers never see, store, or transmit biometrics, the backend receives device-signed proofs and server ACKs. There is no central biometric database to breach or subpoena.
How does it make insider denial untenable?
The signature comes from a hardware-bound key that cannot be extracted, cannot be used without a live biometric press from the enrolled individual, and cannot be replicated remotely. The hash-chained ledger anchors every action to the prior one by the same operator. Non-repudiation is the architectural default.
Still have one? Ask it directly — or read all the questions.
One flow, scoped and instrumented, with cryptographic evidence you can take to your board.
90 days. One flow. Signed proof you can take to your board.
We run a scoped, paid pilot on one of your real flows. You get cryptographic evidence from day one and an executive authority-gap report at the end. Production licensing scopes from there: fixed annual per deployment, never per-action, never per-MAU.
01 · Scope
We pick the one flow that is costing you the most.
02 · Integrate
One flow, one SDK call. Days, not quarters.
03 · Proof
Cryptographic evidence and a board-ready authority-gap report.
Show us the flow you need to protect.
Tell us the critical flow, the stack you run alongside, and what proof looks like in your environment. First call within five business days.
Proving human authority at the moment of action, not inherited from login.
Yuthent. Proof, not assumption.