Architectural analysis reveals that temporal interception hooks fail to ensure true authorization boundaries in autonomous runtimes, indicating the necessity of verifiable boundary completeness.
Autonomous systems increasingly evaluate a proposed action before it executes. A callback fires, a policy is applied, a result is returned, and a record is written. This note argues that the arrangement establishes temporal interception and does not, on its own, establish an authorization boundary. In this note, hook is a generic term for a framework- or application-level interception point, such as a pre-tool callback, before-execution handler, decorator, middleware function, or policy plugin, that is invoked after an action is proposed and before the associated function or effect is released. The term identifies the invocation point. It does not imply execution-path closure, control over release, or the existence of a runtime authorization boundary. Pre-execution is a timing property. It states when an evaluation occurred relative to an effect. It does not state what the evaluation governed, what could have proceeded without it, or what record it left behind. Treating a timing property as an architectural classification is the category error the note names. The corrective is a scoped property. Boundary completeness is the scoped property of an authorization architecture in which, for a declared execution-path scope, every covered execution path, verdict-determinative state element, release transition, failure condition, and authority transition remains inside the authorization dependency, and every resulting verdict is represented in an authorization artifact sufficient for an independent third party to reconstruct that verdict without access to the governed system. Synchronous policy evaluation before a proposed action establishes temporal interception. It does not establish a runtime authorization boundary unless boundary completeness holds over the declared scope. The note states six conditions, grouped as scoped applications of the three integrity properties of the Authorization Boundary Integrity Model and evaluated using the normative vocabulary of the Five Tests Standard. Each condition is stated with a falsifiable test. Under Output Integrity. Execution-path closure; artifact-conditioned release; fail-closed invariance. Under Input Integrity. Governed-state completeness, including the requirement that the artifact identify the applicable decision-time admissibility conditions and record that the boundary evaluated them before emitting the verdict. Under Replay Integrity. Independent reconstruction under a declared State-Replay or Protocol-Replay mode. Spanning Output and Replay Integrity. Governed override, in which ABSTAIN blocks execution and the boundary materially consumes authority-bound input before any verdict releases the action. Three further sections apply the conditions. One separates signature semantics from reconstructability: a signature binds a byte sequence to a signing key and establishes nothing about whether the attested content is sufficient to reconstruct the determination. One treats stateful and composed authorization, covering accumulated limits, determinations cached at issuance, and sequences of individually permitted actions. One examines failure behavior and human authority, including the architectural consequence of an operator-selectable path that permits execution when authorization is unavailable. Scope of the claim. Boundary completeness is a scoped necessary-condition formulation. It is a necessary filter on architectures that already assert pre-execution authorization, and it answers one question: whether a control that evaluates before execution can properly be called a boundary. It does not claim that the enumerated properties are sufficient to establish complete authorization in every architecture, does not combine the three integrity conclusions into an aggregate conformance result, does not establish Five Tests Standard conformance, and does not characterize authorization infrastructure outside the declared scope. Each condition carries three possible evidence outcomes: affirmative evidence, a confirmed failure witness that defeats the condition, or an unresolved omission that leaves it not established. Method. The note is a synthesis and application. No underlying requirement is introduced here. Every load-bearing proposition is an application of published work in the FERZ corpus, cited where it is used, and the contribution is the consolidation of that corpus into a single criterion stated at the interface level, so that it can be evaluated without access to any particular implementation. The note names no vendor, product, or specification, and discloses no mechanism internals. Intended readers. Architects of agent and automation runtimes; assurance, audit, and risk functions evaluating vendor authorization claims; and bodies drafting control categories for pre-execution controls. Recommended citation. Meyman, E. (2026). The Hook Is Not the Boundary: Boundary Completeness in Pre-Execution Authorization. FERZ, Inc. Technical Note, Version 1.0. CC BY 4.0. DOI: 10.5281/zenodo.22180242
No takes yet. Share an insight, caveat, or question.
Edward Meyman (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: