The Hook Is Not the Boundary

Boundary completeness in pre-execution authorization

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.

Boundary completeness is a FERZ-defined property in the runtime authorization framework. The term is introduced in the FERZ, Inc. Technical Note The Hook Is Not the Boundary: Boundary Completeness in Pre-Execution Authorization, concept DOI 10.5281/zenodo.22180242.

---

The category error

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.

The distinction between monitoring and authorization is now reasonably well understood: monitoring creates evidence of what occurred, and execution-time authorization creates evidence of what was permitted before occurrence. A second distinction is less well understood. Moving a control earlier in time is necessary. It is not the same as placing the control in the path.

An evaluation can occur before an action and still not govern it: the action may reach its effect by an uncovered route, release may not depend on the result, or the record may not permit reconstruction.

Treating a timing property as an architectural classification is the category error this analysis names.

This is not an observability concept and it is not an identity concept. Identity and access management authorizes principals to reach resources; it does not authorize a specific proposed AI action before execution. A policy engine returns a decision; it does not by itself establish that nothing can execute without one. Runtime application security prevents exploitation; it does not enforce authorization. Boundary completeness is a property of the enforcement path, not of the monitoring layer above it.

The generic pre-execution hook pattern

A pattern has become common across agent frameworks, appearing as a pre-tool callback, a before-execution hook, a decorator, or a policy plugin. Its shape is stable across those variants. An agent forms an action request naming a function and its parameters. Before the function runs, a callback fires synchronously. An evaluator receives the request together with some declared context and returns a result, typically permit or refuse. A record of the result is written. If the result permits, the function runs.

This is a real advance. Such a control can refuse an action before it takes effect, apply written rules rather than learned judgment, and return a refusal legible to the calling system.

On its own, the pattern establishes four things: temporal interception, a synchronous decision point, a refusal channel, and a written record of the result. Whether the evaluation is deterministic is a separate property of the evaluator, its declared inputs, and the state on which it relies.

Why interception is not closure

Seven properties are frequently offered as establishing that a pre-execution control is an authorization boundary: evaluation before execution, deterministic evaluation, a callback at the framework level, a signed receipt, a fail-closed default, a route for human escalation, and per-call policy compliance. Each is worth having. None establishes the boundary, and their conjunction does not either.

The reason is structural. A callback is a component inside a runtime. Its position in time is a property of the callback; its position in the path is a property of the runtime.

Five general observations follow, none of them an allegation about any particular implementation.

• Coverage. A runtime may not invoke the callback for every effect-bearing action. An integration should not be presumed complete merely because a callback is available at one interface. Coverage must be demonstrated over the declared execution topology.
• Disablement. A runtime may permit the callback to be disabled, skipped, or reconfigured. Where that is supported, closure is a deployment-time property rather than a design property.
• Alternate routes. A caller may hold credentials that reach the effect by a route that does not traverse the callback at all.
• Release. Release may not depend on the result. A control that returns a value the caller is expected to honor is different from a control on which the effect is conditioned.
• Records. The record written may not be sufficient to reconstruct the determination. A record establishing only that an evaluation happened is a record of a governance activity, not evidence of what was authorized.

Closure therefore requires that the paths, the state, the release, the failure behavior, and the authority transitions all sit inside the authorization dependency.

Six conditions, grouped under the integrity properties

The conditions below are grouped under the three properties of the Authorization Boundary Integrity Model: Output Integrity, that an unauthorized action cannot execute; Input Integrity, that a verdict rests only on evidence whose admissible origin is established and that satisfies the applicable decision-time admissibility conditions; and Replay Integrity, that a verdict can be independently reconstructed from bound inputs, policy and version state, authority chain, and proposed action.

The orthogonality of those three properties is load-bearing. Satisfying one implies nothing about the others. The conditions are grouped rather than ranked.

Boundary completeness introduces no additional test framework. Its six conditions are scoped applications of the three integrity properties, evaluated using the normative vocabulary of the Five Tests Standard. It does not combine the three property conclusions into an aggregate conformance result, establish Five Tests Standard conformance, or characterize authorization infrastructure outside the declared scope.

Each condition has three possible evidence outcomes. Affirmative evidence supports the condition within the declared scope. A confirmed failure witness defeats it. An unresolved omission or untested dependency leaves it not established. Absence of supporting evidence is not itself a confirmed failure.

Under Output Integrity

1. Execution-path closure. Every covered action traverses the runtime authorization boundary. A callback is not the boundary where the runtime can omit it, disable it, bypass it, or route around it. Enumerate the execution paths within the declared scope and show that no path reaches an effect without traversal. The enumeration is the evidence.

2. Artifact-conditioned release. Execution depends on a valid ALLOW verdict represented in an authorization artifact. Returning a Boolean result and writing a record afterward does not satisfy this condition, because in that arrangement the record is a byproduct of release rather than its precondition.

3. Fail-closed invariance. Missing evidence, unavailable policy, evaluation failure, malformed state, unmapped actions, and incomplete artifacts each prevent ALLOW. Fail-closed design is definitional rather than tier-dependent. An operator-selectable path that permits execution when authorization is unavailable is a bypass by configuration, and recording its use does not repair it.

Under Input Integrity

4. Governed-state completeness. The authorization artifact binds every verdict-determinative input in canonical form, together with the applicable policy snapshot and its lineage, the evaluator identity and version, the canonicalization specification and its version, the authority state relied upon, time, and any accumulated or sequence-dependent state that influenced the verdict. The artifact must additionally identify the applicable decision-time admissibility conditions, trace them to governing policy and authority, and record that the boundary evaluated them before emitting the verdict.

Provenance establishes origin. Origin is necessary but not sufficient for admissibility, which asks whether evidence with that origin may participate in this verdict under the declared policy and authority conditions. Neither provenance nor admissibility establishes that the evidence is true.

Binding the decision state is a shared substrate for Input Integrity assessment and independent reconstruction. It does not itself establish Input Integrity.

Under Replay Integrity

5. Independent reconstruction. A qualified third party reconstructs the verdict from the authorization artifact and its authenticated bound materials under a declared State-Replay or Protocol-Replay mode, without access to the governed system or the original authorization service. Every required dependency must resolve to its decision-time version, authenticate against the record, remain retrievable, and be independently usable outside the vendor's control.

A canonicalization requirement without a specified canonicalization does not support independent recomputation. Where an artifact commits to a hash over canonical form but no profile fixes key ordering, encoding, whitespace, numeric representation, and timestamp form, the commitment is verifiable only by an implementation that happens to share the original's serialization behavior.

Spanning Output Integrity and Replay Integrity

6. Governed override. In an authority-reserved or otherwise unresolved case, ABSTAIN blocks execution. Execution may resume only where the boundary materially consumes authority-bound input, emits the resulting verdict, and represents that verdict in an authorization artifact sufficient for independent reconstruction of that verdict under the declared replay mode.

Absent an authorized override, the verdict remains ABSTAIN and execution remains blocked. DENY and unresolved ABSTAIN are both non-executable states, and they are not semantically equivalent: DENY records a confirmed prohibition, while ABSTAIN records an unresolved or authority-required determination. The absence of permission never becomes tacit permission.

An escalation implemented at the application layer does not satisfy this condition, because in that arrangement the release decision is made by a component the boundary does not govern.

Summary

Condition	ABIM relationship	Decisive failure witness
1. Execution-path closure	Output	A path within the declared scope that reaches an effect without traversing the boundary
2. Artifact-conditioned release	Output	An execution that proceeds where the artifact is absent, incomplete, or fails validation
3. Fail-closed invariance	Output	Any failure class that yields ALLOW, including a configured path permitting execution when authorization is unavailable
4. Governed-state completeness	Input; decision-state binding also supports Replay	A materially used evidence set shown to have failed an applicable admissibility condition
5. Independent reconstruction	Replay	A reconstruction that fails the expected result for the declared mode; a bound component that fails to authenticate; a verdict evaluated under state different from the bound state; or material dependence on live or undeclared state
6. Governed override	Output and Replay	An execution released on human input the boundary did not consume, with no verdict representing the override

Each row states what would defeat the condition, not what would confirm it. The absence of a failure witness leaves a condition not established rather than satisfied.

Scope

Each condition is evaluated over a declared execution-path scope. A conformance claim that does not disclose its scope is not evaluable, and scope disclosure is therefore part of the claim rather than context for it. A conforming disclosure states the authorization object, action vocabulary, execution topology, decision state, evidence closure, replay mode, and temporal boundary.

Signed records and authorization artifacts

A signature binds a byte sequence to a signing key. It establishes that the holder of that key attested, and that the bytes have not been altered since. Attribution of the signature to a named party is a further step, depending on trusted resolution of the key to that party. It establishes nothing about whether the attested content is sufficient to reconstruct the determination it describes.

Signature and reconstructability are frequently treated as the same guarantee. They are not equivalent. Integrity protection contributes to reliable reconstruction, and it does not establish evidentiary completeness. A signed record of six fields is a signed record of six fields. If the policy state, evaluator version, and canonicalization profile relied upon are not among them, the signature attests to an incomplete account with high integrity.

A governance artifact records that a governance activity occurred. Governance evidence is a package sufficient for an independent third party to reproduce the verdict. Logs record what a system claims occurred. Authorization evidence enables independent reconstruction of the verdict from the bound inputs and governing state. Immutability is not replayability: storing a record immutably proves that something was recorded, and does not make the verdict reproducible.

Stateful and composed authorization

Two failures share a structure and differ only in timescale. In both, a quantity that determines the verdict lives outside the artifact.

Accumulated state. Rate limits, daily caps, rolling windows, and quota rules are written as though they were policy. They behave as hidden temporal state. A rule of the form "no more than N per day" makes the verdict depend on a running total that is not part of the action request and not part of the credential that declares the threshold.

Declared-input completeness fails: the same action, policy, and declared limits can produce different verdicts because an undeclared counter, accumulation window, or sequence state differs. This does not make the evaluator nondeterministic if that state is among its actual inputs. It makes the authorization claim incomplete, and it defeats replay when the state is absent from the authorization artifact.

The remedy is not to abandon aggregate rules, which are among the most useful rules there are. The remedy is Condition 4: the accumulated quantity relied upon is a verdict-determinative input and belongs in the governed state.

Determination cached in advance. Where a policy evaluation is computed when a credential is issued and its outcome is carried inside that credential, a verdict rendered later that consults the cached outcome rests on a determination made earlier, under a policy state the later record does not pin.

Eligibility asks whether a party is of a kind that may generally act. Authorization asks whether this specific proposed action may proceed now. A cached eligibility outcome answers the first question and is frequently read as answering the second. Where the policy has changed, the authority has changed, or the credential has been amended since issuance, the two answers may diverge and nothing in the record shows which one was used.

Composition. Independent evaluation of each action permits sequences of individually permitted actions to reach an outcome that no single action would have been permitted to reach. Structuring a transfer across several small transfers is the canonical case, and it generalizes to any aggregate effect assembled from permitted parts. Where the second evaluation cannot see what the first authorized, the sequence is unevaluated even though each step was evaluated.

Failure and human authority

Fail-open deserves examination as an architectural claim rather than as an operational convenience. The usual justification is development and migration: teams need to integrate the control before the policy library is complete. The practical need is real. The architectural consequence is that a deployment flag can open the boundary, which means the closure of the boundary is a property of the configuration rather than of the design, and any claim of non-bypassability has to be made about a specific deployment with that flag in a specific state.

On the human side, the arrangement matters more than the presence of a person. The common arrangement places a person somewhere in a flow that proceeds by default, able to intervene. The record that arrangement produces shows something weak: that a human could have objected and did not.

The alternative inverts the default. When governing policy cannot resolve a case, the verdict is ABSTAIN, and ABSTAIN blocks. Authority returns to a designated human, whose affirmative, attributable, recorded input is consumed by the boundary. Execution may proceed only if the boundary then emits ALLOW and represents that verdict in an authorization artifact sufficient for independent reconstruction.

One arrangement shows that a human was present. The other shows that a specific authorized person supplied attributable, authority-bound input before effect, and that the boundary consumed that input and emitted the operative verdict on the record.

Implications for standards

Standards that classify pre-execution controls as authorization should require declared-scope disclosure and evaluate execution-path, state, release, failure, reconstruction, and authority closure.

A classification that requires only synchronous evaluation and record-writing admits controls that intercept without closing. Such a classification does not distinguish authorization from timely observation, and a conformance statement made under it carries correspondingly little information for the party relying on it.

Two drafting consequences follow. Scope disclosure should be mandatory rather than encouraged: a control that closes the boundary for one class of effects and not another is a useful control, and describing it accurately requires stating which class. And reconstruction should be specified separately from record-keeping: a requirement for a tamper-evident record is satisfied by an integrity-protected log, while a requirement that a third party be able to reconstruct the verdict is a different requirement with different content.

Conclusion

A pre-execution callback may be a genuine enforcement component. It is not, by virtue of its position in time, an authorization boundary.

A pre-execution control does not establish authorization governance unless the complete release dependency is present over a declared scope: the paths are closed, verdict-determinative state is bound, release depends on the artifact, failure conditions cannot produce ALLOW, the verdict is independently reconstructable, and authority transitions run through the boundary rather than around it. The scope must be declared, because a claim without a declared scope cannot be checked.

---

Frequently asked questions

What is boundary completeness?

Boundary completeness is the scoped property of an authorization architecture in which 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 independently reconstructable authorization artifact.

Does a pre-execution policy hook constitute runtime authorization?

Not by itself. A hook establishes temporal interception: the evaluation happens before the effect. Authorization additionally requires that no covered path reaches an effect without traversing the boundary, that release depends on the artifact, that failure cannot produce ALLOW, and that the verdict is independently reconstructable.

Is a signed decision record an authorization artifact?

Not necessarily. A signature establishes that a key holder attested and that the bytes are unaltered. It does not establish that the attested content is sufficient to reconstruct the determination. An artifact must bind the policy state, evaluator version, canonicalization profile, and verdict-determinative inputs relied upon.

How is this different from identity and access management?

Identity and access management authorizes principals to reach resources. Boundary completeness concerns whether a specific proposed action can execute without a verdict, and whether that verdict can be reconstructed by a third party. The subject is the action, not the principal, and the property is enforcement, not identification.

Does boundary completeness establish Five Tests Standard conformance?

No. It is a scoped necessary-condition formulation applied to architectures that already assert pre-execution authorization. It does not aggregate the integrity properties into a conformance result, does not establish Five Tests Standard conformance, and does not characterize authorization infrastructure outside the declared scope.

---

References

1. The Hook Is Not the Boundary: Boundary Completeness in Pre-Execution Authorization. FERZ, Inc. Technical Note, Version 1.0, 2026. Concept DOI: 10.5281/zenodo.22180242. This edition: 10.5281/zenodo.22180243
2. Authorization Boundary Integrity Model. FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.20929115
3. Five Tests Standard (5TS). FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.21040295
4. On the Impossibility of Observability-Based Authorization. FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.19647542
5. The Override Asymmetry. FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.19772248
6. The Closed-World Bargain. FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.21643658
7. Standing Eligibility versus Runtime Authorization. FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.21941656
8. A Taxonomy of AI Governance Approaches. FERZ, Inc., 2026. Concept DOI: 10.5281/zenodo.18275969

Full corpus: Research and papers · FERZ community on Zenodo

Related

• Runtime authorization boundary
• Execution-time authorization
• Fail-closed design
• ABSTAIN verdict
• Observability is not authorization
• FERZ is not AI observability

How to cite this page

FERZ, Inc. (2026). The Hook Is Not the Boundary: Boundary Completeness in Pre-Execution Authorization. ferz.ai. https://ferz.ai/articles/the-hook-is-not-the-boundary

For the citable technical note, cite concept DOI 10.5281/zenodo.22180242.