Independent Inventor TLS tells you the channel is authentic. OAuth tells you the caller holds a valid grant. HTTPS tells you the origin is who it claims to be. EMV tells you a payment cryptogram is transaction-specific. None of these mechanisms answer a question that autonomous, machine- speed systems now raise on every turn: is _this specific act_, generated by _this_ model, agent, or workload, at _this_ moment, actually authorized to become externally effective? Large language model agents, autonomous cloud workloads, and machine- to-machine network functions increasingly compute, decide, and act inside a single event loop, at latencies where no human, log reviewer, or downstream audit process can intervene before an API call fires, a payment settles, a file leaves the enterprise boundary, or a physical actuator moves. Transport, authentication, and authorization protocols were designed for a world in which the gap between "this request was generated" and "this request had a chance to be reviewed" was measured in human-relevant time. That gap has collapsed to milliseconds. Existing protocol layers were never built to close it, because the question they answer -- identity, channel integrity, delegated scope -- is a necessary but categorically different question from whether _this act, right now, should be allowed to leave computation and become consequence_. This document specifies an architectural pattern, execution finality, that treats every machine-generated operation as a Candidate Act held in a Non-Effective State until a Protected Enforcement Domain validates act-specific authority -- purpose, destination, jurisdiction, freshness, revocation state, policy epoch, and runtime integrity -- and issues a narrowly scoped, non-bearer Execution Handle bound to that act and to a specific Finality Sink, the first boundary at which the act would otherwise become externally effective. The document formalizes the vocabulary, a cold-path/hot- path split for latency-sensitive deployment, a structured threat model with adversary-facing pseudocode, an incremental migration path for coexistence with TLS, HTTPS, OAuth, and EMV rather than replacement of them, and worked examples spanning AI agents, payments, telecommunications, cloud infrastructure, satellite command, industrial control, and robotics. The central claim is narrow and falsifiable: _computation does not itself confer authority for consequence_, and no general, cross- domain Internet layer currently makes that separation a structural property of the release path rather than an application-specific convention. This document is intended to solicit IETF community review of whether that gap is real, whether it is already covered by existing or in-progress work, and if not, which venue should take it up. This document describes a patent-pending architectural concept. Any intellectual-property rights or disclosure obligations relating to implementation are outside the technical scope of this document and are subject to applicable IETF IPR procedures, including BCP 79.