Policy gate vs signed proof
A policy gate records that an action was allowed. A login check records that someone authenticated earlier. A risk score records a probability. A signed proof records that a specific human approved this action, verifiable after the fact against a published public key. This page compares the approaches by mechanism.
Four approaches, four kinds of evidence
Policy gate
How it works
A rules engine at the execution boundary decides approve, refuse, or escalate, and records the decision.
What it proves
That the action satisfied a policy, or that an approval step was shown.
The limit
The record is produced by the platform. It does not prove which human approved, or that a human approved at all.
Login-time identity
How it works
The user authenticates once, at the start, with a password, passkey, or biometric. A session credential carries that authority forward.
What it proves
That someone authenticated at login.
The limit
Authority inherits to every downstream action. A hijacked session or an agent inside the session acts with the original authority.
Behavioral risk scoring
How it works
Device, network, and behavioral signals produce a probability that the activity is fraudulent.
What it proves
A likelihood, expressed as a score and a threshold.
The limit
Probabilistic, and degrades against agent-driven activity that has no human behavioral pattern. A score is not evidence of who approved.
Cryptographic per-action proof
How it works
The specific human signs a description of the exact action on their own device, with a hardware-bound key, gated by a fresh biometric, at execution time.
What it proves
That this human approved this action now, verifiable independently against a published public key.
The limit
Requires an enrolled device and a per-action signing step on the actions you choose to protect.
The wedge
The first three approaches treat human approval as a policy event, a login event, or a probability. None of them produce a cryptographic, hardware-bound, non-repudiable artifact that binds a specific human to the specific action, verifiable offline and after the fact, by your backend, a regulator, or a court.
Yuthent produces that artifact. It composes with the others: keep the policy gate, the login, and the risk model, and add the signed proof on the actions that have to be provable. Yuthent is Execution Authority Infrastructure, and every engagement starts with a scoped first deployment.
Common questions
What is the difference between a policy gate and a signed proof?
A policy gate records that an action was allowed by a rule, and the record is the platform's own. A signed proof records that a specific human approved this specific action, produced by the human's device with a key the platform does not hold, verifiable by a third party against a published public key. One is a decision log. The other is independent evidence.
Do these approaches compete?
Mostly they compose. A policy gate decides what is allowed. A login check establishes who started the session. A risk score flags anomalies. Yuthent adds the missing layer: the act does not run without authority a human signed, for that act or for the boundary it falls inside. It runs alongside the others, not in place of them.
Which approach satisfies regulatory dynamic linking and human oversight?
A cryptographic per-action signature bound to the action is the approach that maps to PSD2 SCA dynamic linking, DEA EPCS non-repudiation, and EU AI Act Article 14 human oversight, because each of those asks for evidence about the specific act, not the session or a probability.