Stolen sessions authorize nothing. Push-bombing approves nothing. Insider denial proves nothing.
Continuous verification produces a token. Tokens get stolen, replayed, and bombed. Yuthent produces a gate the token cannot open: the privileged command does not execute unless the named operator signed for it, or signed the boundary it falls inside. Session takeover inherits nothing. Fatigue bombing reaches no approval surface. An insider's signature is theirs, forensically and mathematically.
Zero Trust redefined the security posture. Never trust, always verify. In practice, verification reduces to session-level signals feeding into an access decision that produces a session token. The token then authorizes every action inside the session. An attacker who takes over the session through AiTM phishing, cookie theft, OAuth consent phishing, or browser-session compromise inherits the full access the session carried, instantly, with no further friction at any privileged action.
Three operational realities compound the weakness. Session hijacking is now commoditized: off-the-shelf AiTM kits neutralize the FIDO2 and passkey advantage at login because the post-login session remains a bearer token. MFA fatigue and push-bombing defeat step-up challenges by exhausting the user into approving a prompt that looks identical to a legitimate one. Insider actors use legitimate credentials and then rely on credential-theft as a plausible-deniability defense when exfiltration is traced back to their account.
Standard controls acknowledge each problem and do not fully close any of them. FIDO2 prevents phishing at login but produces a session after. Step-up MFA interrupts the user without binding the interrupt to a specific command. PAM constrains standing privilege but does not produce cryptographic evidence that a specific human approved a specific use. The architectural gap is a cryptographic act tied to each sensitive action itself, not to the session that preceded it.
Stop protecting the session. Start proving the action.
Session takeover stops being a path to privilege escalation because the session holds no privilege. The production console action, the secrets read, the infrastructure change, the policy edit, each one you tier Authoritative requires an Authoritative-tier proof produced by the specific operator on their specific hardware, bound to the specific action parameters. A stolen cookie used against a privileged endpoint reaches the gate and stops there. The verifier sees no proof and refuses the action.
MFA fatigue and push-bombing stop being viable attack patterns because there is no generic approve prompt to spam. Every Yuthent approval carries the exact action parameters on the operator's device screen: the command, the target, the scope, the blast radius. An attacker cannot generate an abstract prompt without a corresponding privileged command, and every approval prompt carries the exact parameters of the action it is bound to. The generic approve prompt, the thing fatigue attacks spam, does not exist.
Insider denial stops being a defense because the Yuthent signature is cryptographically inseparable from the insider. The private key lives inside StrongBox, TEE, or Secure Enclave, is un-extractable, requires a live biometric press from the enrolled individual, and cannot be replicated or stolen remotely. A compromised-credential claim fails forensically because the signature could only have been produced by physical possession of the device combined with the enrolled biometric at the exact moment of action. The ledger is non-repudiable by design, not by policy.
The agent can request the privileged action. Only the human can authorize it.
AI agents and automations increasingly hold console access, service credentials, and API scope. The question is not whether they act, it is what they may do alone. Yuthent is not inline in your traffic: your runtime gateway, PAM, or the resource itself calls it as the decision point for the high-risk subset, and it composes with the enforcement you already run.
The operator signs the blast radius once
A mandate is signed on the accountable operator's own device: which command classes the agent may run, how many in a day, until when. Inside those bounds a service restart or a routine rotation proceeds without paging anyone at three in the morning. Non-interruption inside signed bounds is the design, not a hole in it.
Outside it, the operator signs the command
A secrets read, a production change, a policy edit, a bulk export past the ceiling: the call stops and a signed request reaches the accountable operator's device showing the exact command, target, and scope. A prompt-injected or compromised agent can request it and cannot produce the human's signature.
No mandate, no execution
If no mandate covers the agent, or the one it names has expired or been revoked, the call fails rather than falling back to whatever its OAuth token or service account still carries. Revocation takes effect on the next call, not at the next token refresh, which is the difference between an incident contained and an incident logged.
Three modern attack patterns. Where Yuthent closes the gate.
Session Hijacking · AiTM, Cookie Theft, Token Replay
The pattern
Attacker captures a post-login session via an adversary-in-the-middle phishing proxy, a stolen browser cookie, an OAuth consent grant, or a compromised SSO token. The session is now theirs for the lifetime of the token, with full user privilege.
Why current defenses fail
FIDO2 and passkeys prevent credential phishing at login but produce a bearer session after. Session tokens authorize every downstream action with no further challenge. MFA step-up is a one-time interrupt that produces yet another session token. Access logs show the legitimate account performing the actions.
Where Yuthent stops it
The session carries zero action authority. Every privileged operation requires a fresh Authoritative-tier signature produced on the operator's enrolled device. A stolen session reaches the authorization gate and produces nothing. The verifier sees no proof and the action does not execute.
ApprovalToken payload-hash binding · session-level signals do not substitute for action-level proof
MFA Fatigue and Push Bombing
The pattern
Attacker triggers repeated MFA push prompts, often late at night, until the target approves one out of exhaustion, confusion, or habit. The approval produces a valid session for the attacker.
Why current defenses fail
Conventional push approvals are generic: a single 'Approve?' prompt with no binding to a specific command. The user cannot distinguish a legitimate login from a malicious privileged operation. Number-matching mitigates but does not eliminate the attack.
Where Yuthent stops it
No generic approve surface exists. Every Yuthent prompt carries the exact action parameters: the command, the target, the scope. An attacker cannot spam prompts without a corresponding privileged action request. The user sees what they are signing and presses only for operations they initiated. Action-bound payload-hash binding makes the attack pattern mathematically inapplicable.
Every prompt shows exact action parameters · payloadHash binds the signature to the parameters delivered to the device
Insider Threat · Plausible-Deniability Exfiltration
The pattern
An authorized employee with legitimate access executes privileged actions or exfiltrates data. When detected, the employee claims their credentials were compromised. Standard forensics cannot conclusively prove intent.
Why current defenses fail
Access logs show the employee's account performing the action. The compromised-credential defense is difficult to refute without physical evidence, keystroke forensics, or admissions. SIEM and UEBA produce probabilistic indicators, not cryptographic proof of direct personal involvement.
Where Yuthent stops it
At Explicit and Authoritative tier the signature is produced by a hardware-bound key that cannot leave the device, cannot be extracted, and cannot be used without a live biometric press from the enrolled individual. A compromised-credential defense fails because the proof requires physical device possession plus the enrolled biometric at the exact moment of action. The hash-chained ledger anchors every action to the prior action by the same operator. Forensic undeniability is the architectural default.
Hardware-bound key in StrongBox, TEE, or Secure Enclave · biometric enforced at secure element · per-operator hash-chained ledger
What the SDK and control plane produce for your security stack.
Execution-time proof layer beneath every control
Privileged console actions, secrets reads, policy changes, and data exports each produce an Authoritative proof. The proof is verifiable against a published public key and exportable to SIEM. The session becomes an identity signal only, not an authorization artifact.
Action-bound payload hashing defeats fatigue attacks
An approval prompt is bound to the specific action being authorized, never to a generic request. The action parameters are hashed into the signature. A modified parameter invalidates the proof. There is no abstract approve surface for an attacker to exploit.
Continuous five-category trust engine
Device integrity, remote-control exposure (AnyDesk, TeamViewer, accessibility abuse, ADB), overlay presence, behavioral anomaly, and contextual drift are observed continuously. Signals carry severity and aggregate into a score that drives the action gate.
Hardware-bound, un-extractable operator key
EC P-256 keypair generated inside StrongBox, TEE, or Secure Enclave. The key never leaves the device. Biometric enrollment change cryptographically destroys it. A stolen credential is useless without the device and the biometric press.
Hash-chained per-operator audit trail
Every Authoritative-tier action is chained to the prior action by the same operator. Altering one record breaks every record after it. Daily tenant anchors. Forensics-grade evidence suitable for internal investigation, legal discovery, or post-incident review.
Immediate revocation with push propagation
A compromised device revoked through the control plane propagates to the endpoint in real time. The device cannot produce any further valid proof at any tier. Exit requires full re-enrollment.
External-decision callback for UEBA and PAM
Your UEBA or PAM can inject a verdict into Yuthent at verification time. Force step-up, soft-block, or accept, without changing the SDK integration on the operator side. The callback is signed and rate-limited at the control plane.
Webhook stream into SIEM and SOAR
Outbound events for every tiered action, every refusal, every trust-state change, every revocation. Drop into Splunk, Sentinel, Chronicle, or your internal event bus. Real-time attack-pattern detection on the action layer itself.
What each framework will not let you run without.
NIST SP 800-207 Zero Trust Architecture
Maps directly to the per-request authorization model at the heart of the framework. Execution-time proof is the cryptographic primitive the model assumes but most deployments do not produce.
Independent security validation (scheduled)
A gray-box penetration engagement is scheduled during deployment readiness with a 30-day retest on High-plus findings. Privileged-action non-repudiation and the immutable audit trail map to access-control and system-monitoring control categories in common frameworks.
NIS2 and DORA
Operational-resilience frameworks require cryptographic evidence of privileged actions and defensible incident forensics. Yuthent's per-action signatures and hash-chained ledger meet the evidentiary bar these regimes are moving toward.
Cyber insurance · underwriting posture
Underwriters price what they can verify. MFA coverage on privileged actions, session-hijacking exposure, and forensic evidence quality are questionnaire line items. Yuthent turns them into a deterministic control: per-action, hardware-bound human proof that an underwriter or forensic team can verify independently against a published key. It is what the CISO brings to the renewal conversation: a control the assessor verifies rather than a questionnaire answer.
Yuthent sits alongside your IdP (Okta, Entra, Ping), your passkey or MFA layer (Duo, YubiKey, FIDO2), your PAM (CyberArk, Delinea, BeyondTrust), and your EDR. It replaces none of them. It adds an execution-time evidence layer beneath all of them. The webhook stream feeds your SIEM in real time. The external-decision callback lets your UEBA or PAM adjust the gate without changing the operator experience.
First deployments are paid engagements with a named integration scope, a defined threat-model objective, and a cryptographic evidence target. A first deployment typically scopes one high-stakes operator surface: production console access, cloud control-plane operations, or secrets retrieval. The control plane is live from day one. The first proofs you see are your own. The first SIEM webhook your analysts receive comes from a flow you defined.
Answered plainly.
What if the agent or the session is compromised?
We assume it may be. Yuthent proves the authorized human approved the action; a compromised agent or hijacked session can request anything but cannot produce a fresh biometric proof from the operator's hardware. Blocking the compromised agent inline is the job of runtime security (Zenity, Sweet). Yuthent is the human-authority decision point they call for the high-risk subset.
Where does enforcement sit so an insider can't switch it off?
At a point you control, the resource, a gateway, or your PAM, that calls Yuthent for the high-risk subset. Yuthent is the authority service, not an inline choke point the operator can bypass. Think of it as the execution-authority equivalent of an IdP: the enforcement point calls it, and without a valid proof the privileged action does not execute.
Does it replace our IdP, PAM, or SIEM?
No. It sits alongside Okta / Entra / Ping, CyberArk / Delinea / BeyondTrust, and your SIEM, and adds an execution-time evidence layer beneath them. The webhook stream feeds Splunk, Sentinel, or Chronicle; the external-decision callback lets your UEBA or PAM adjust the gate without changing the operator experience.
Does this help with cyber-insurance requirements?
Increasingly, yes. Underwriting questionnaires now ask specifically about MFA coverage on privileged actions, session-hijacking exposure, and the quality of forensic evidence. Yuthent gives those questions a deterministic answer: privileged actions carry a fresh, hardware-bound human proof, and every decision lands in a tamper-evident ledger an assessor can verify independently against a published key. It does not replace your policy's control requirements, it converts several of them from attestations into demonstrable controls.
Does Yuthent see our data?
No. The control plane receives action metadata, the command and target hashed into the signature, a counter, a device attestation, and the proof, never the payload of the action or the data it touches.
Cloud or on-prem?
Hosted multi-tenant on Yuthent's Google Cloud. Because only metadata leaves, hosted is sufficient for most. Dedicated cloud and on-prem are available on request and scoped during a first deployment.
Start a first deployment.
Tell us the flow you want to protect. We will come back with a working integration proposal. First call within five business days.