Why Yuthent
Every control you run checks who got in. None of them checks who decided.
Three controls each answer their own question correctly. None of them answers the one you are asked afterwards: who approved this action.
The problem
The controls you run answer their own question correctly.
Each of these is a property of how the systems work, not a failure in how you configured them.
The check happened earlier
Identity is settled once, when the session opens, and every action afterwards inherits that settlement. The action that runs an hour later was not part of what anyone checked.
The record shows activity
An entry shows an action completed under a valid credential. That is a statement about activity. It is not a statement that a person decided it.
The witness is the actor
The system that carries out the action also writes the record of its approval. The record and the act have the same author.
The session identifies. The signature authorizes.
Why now
One credential. More and more hands.
- Built for one person at one keyboard.
- Then a session: hours of actions, scripts and integrations, inheriting one login.
- Now automated agents act inside those sessions. The actors multiplied. The check didn’t move.
Regulation drew the line: oversight of consequential actions by a person, evidenced, not asserted (DORA Article 9, EU AI Act Article 14). The anchor that survives is a decision a person signed, bound to the action it authorizes.
The objections
Every objection here is fair. None of them closes the gap.
None of the answers asks you to remove a control you already run.
We already have passkeys.
Keep them. A passkey is the right tool for login and nothing here replaces it. It binds nothing to the amount, the payee, or the command that runs an hour later inside that session. 88% of basic web-application attacks use valid stolen credentials (Verizon 2025 DBIR). A passkey proves it is your device. Yuthent proves it is your decision.
This sounds like friction our users will hate.
Applied to everything it would be. Most actions should not be gated and are not; your policy decides which few are, and everything else runs untouched. Where a person has signed standing bounds in advance, actions inside those bounds proceed without interrupting anyone.
What does this cost us to integrate?
Your action keeps its own code path. The SDK goes into your app, a check goes in front of the route you already have, and your backend verifies before it executes. A first engagement scopes one high-stakes flow and ships a working integration; cost and timeline are scoped in the first call.
Due diligence
The three a reviewer checks later.
Isn't an audit log enough for compliance?
DORA Article 9 and EU AI Act Article 14 are both asking for an artifact rather than a policy document. Yuthent produces the artifact. Whether it satisfies your obligation is weighed by your auditor, your regulator or your court, and that judgement stays where it belongs.
Do you store biometric data?
No, and we could not if we wanted to. Verification runs entirely on-device inside StrongBox, TEE or Secure Enclave using OS-native APIs. Our servers receive device-signed proofs and server acknowledgements. There is no central biometric database to breach, to leak, or to subpoena.
What if you go out of business?
The proofs are signed with keys on your users' devices and verified against public keys you hold. Verification is a cryptographic operation against data in your own ledger. It does not require us to be reachable, or to exist.
See it on your own flow.
Your app, your call, our SDK.