The terms, defined.

In traditional systems usage, execution authority is the permission for a user, process, or account to run code or commands: the execute bit, privilege levels, application allowlisting.

In the infrastructure category (Execution Authority Infrastructure), it is the fourth security layer after authentication, authorization, and audit: cryptographic proof that a specific human approved a specific action at the moment it executes, independent of session state.

The two senses answer different questions. The first asks what a principal may run. The second asks who approved this action, right now, with what proof. PSEA (Post-Session Execution Assurance) is the open architectural model for the second sense.

Execution Authority Infrastructure produces evidence about the act, not the session. The proof is generated by the specific human on a device they control, bound to the exact action, and verifiable by any party against a published public key.

Authentication answers who logged in. Execution Authority Infrastructure answers who is doing this. Yuthent is an Execution Authority Infrastructure company; the core authorization method is patent pending with the USPTO.

PSEA defines the model. It holds that authority must be proven at the moment a sensitive action executes, and never inherited from a past authentication event.

PSEA is published as an individual IETF Internet-Draft, draft-yossif-psea. It is not adopted by an IETF working group and does not represent IETF consensus. Yuthent is an implementation of the PSEA model.

Payment authorization proves a credential holder consented to a charge. Task authorization proves the human approved the task itself: what the agent was mandated to do, within what amount ceiling, against which counterparties, until when.

In Yuthent the task authorization is a hardware-bound signature over the mandate parameters, made in a sealed Authoritative-tier ceremony. Yuthent produces and verifies the signature and the payload hash; your verify step checks each agent action against the signed mandate, and a dispute over an agent-initiated action terminates at that artifact.

Execution-time authority treats authority as temporal, not persistent. A login establishes a session. Execution-time authority requires a fresh, per-action proof for the actions that have to be provable, closing the gap between the moment a human authenticated and the moment an action executes.

Passive: a device-signed attestation with no biometric, used to confirm the enrolled device is still trusted.

Silent: one biometric establishes a short, policy-bounded session for routine actions, with batch sync and offline support.

Explicit: a fresh biometric and a server-verifiable signed proof for each individual action.

Authoritative: a fresh biometric per action, with full server verification and a tamper-evident audit trail, for the highest-stakes actions.

The integrator's backend policy selects the tier per action. The tier is a contract between the SDK, the server, and the auditor on what evidence the action must produce.