This article explains an independently published technical result: Enforcement Integrity in Pre-Execution Authorization, FERZ, Inc. Technical Note v1.0, published on Zenodo at https://doi.org/10.5281/zenodo.23438040.
1. The assumption the corpus carried
Consider a deployment in which an AI agent reaches every tool through a gateway. Every covered action traverses the gateway. The gateway evaluates each action before release, releases only on ALLOW, fails closed when it cannot evaluate, and produces an authorization artifact supporting independent reconstruction. The deployment exhibits the traversal, release-conditioning, fail-closed, and reconstruction properties required of a runtime authorization boundary.
Now suppose the gateway reads its effective policy from a configuration store the agent can write. Those four properties may continue to hold, but they do not establish that the mechanism remains outside the agent's control. FERZ's existing boundary-completeness requirements already demand evidence of policy lineage and governing authority. The remaining question is different: what establishes that the agent cannot alter the enforcement mechanism or its governing dependencies in the first place?
That question had no specified answer. The FERZ corpus has been precise about the four properties: a boundary must be in the path of every covered action, release must depend on its verdict, and failure must produce no ALLOW [Hook]; a verdict must be reconstructable by someone outside the system [ABIM]. It has also required, as part of boundary completeness, evidence of the governing policy's lineage and the applicable authority state [Hook], which is what gives an evaluator a basis for examining where a rule came from. What it had not specified is the control relationship itself, assessed as a property in its own right: the evidence that establishes that the governed system cannot alter the mechanism, its dependencies, or the conditions under which it governs release. That relationship had been assumed.
The assumption was not hidden. Execution-Time Authorization names the governed agent as the primary threat actor and records as an open direction that software-level non-bypassability rests on assumptions about the integrity of the execution environment [ETA]. The Hook Is Not the Boundary observes that a callback is not the boundary where the runtime can omit, disable, bypass, or reconfigure it, and develops closure; the control relationship is not its subject [Hook]. The ABIM Evidence Requirements require every Output Integrity assessment to begin with a declared scope and a trust-assumption record, and do not say what a trust assumption about the mechanism must contain [ABIM-ER].
The lineage is older than the corpus. The reference monitor of 1972 had three requirements: it must always be invoked, it must be tamperproof, and it must be small enough to be analyzed and tested. The first became complete mediation and then boundary completeness. The second was inherited as an assumption. A technical note published this month, Enforcement Integrity in Pre-Execution Authorization, gives that assumption specified content: a definition, four obligations, an assurance record, and a rule for what happens to the evidence when the deployment changes [EI]. This article explains what the note establishes and why it matters to anyone evaluating a claim that an AI system is governed.
2. Why the four properties do not settle it
Two configurations show that the gap is real and that it is not the same gap as bypass. Both keep the gateway of Section 1 exactly as described. The only thing that changes is what the agent writes into the configuration store.
In the first, the agent writes a rule permitting a class of actions the policy prohibits. Subsequent requests traverse the gateway, the gateway issues ALLOW under the written rule, and the prohibited effect occurs. Complete mediation held throughout. The artifacts reconstruct each verdict computation faithfully, and what they reconstruct is a verdict rendered under a rule the authority never issued. A reviewer checking only traversal, release conditioning, fail-closed behavior, and computational reconstruction could miss the control failure. The authorization artifact's policy-lineage evidence provides a separate basis for examining the unauthorized origin. But neither computational reconstruction nor lineage visibility establishes that the agent lacked the capability to modify the mechanism. That is the additional assurance question enforcement independence addresses.
In the second, the agent writes a rule that restricts rather than permits: it appends a prohibition the authority never authored. No unauthorized covered effect is released. Yet the agent has acquired a veto the authority never delegated and has used it to block actions the authority permitted, among them, possibly, actions the authority required, such as a notification, a record, or a handoff. The verdicts whose justification depends on the appended rule were issued by no authority. Policy is authored under authority and has no standing otherwise [AvA].
The second configuration is the one that shows the shape of the problem. A test that looks only for unauthorized releases will never find it, because there are none. What has failed is not the boundary's coverage of execution paths. It is the relationship between the governed system and the mechanism that governs it. The rest of this article is about that relationship: how the note defines it, how it is assessed, and what the assessment is worth once the deployment changes.
3. Enforcement independence, defined
The note names the property and states it in one sentence:
Enforcement independence is the property that the governed system cannot exercise unauthorized control over the mechanism that enforces pre-execution authorization, its dependencies, or the conditions under which it governs release, and that the authority model reserves the protected elements of that mechanism to authority the governed system cannot supply or substitute, relative to a declared configuration, scope, authority model, and capability model.
Three definitions carry the property, and their order matters because it is what keeps the definition from being circular. Each can be read against the gateway of Section 1.
Effective control is reachability. An actor has effective control over a change to the mechanism's control state when the capabilities available to it, directly or through another actor whose action it can obtain, permit it to cause or select that change, or to change the conditions under which the boundary governs release. Reachability says nothing about permission. It is a fact about what the actor can reach. The agent with write access to the configuration store has effective control over the gateway's policy whether or not anyone intended it to.
Whether an exercise of effective control is authorized is answered by the declared authority rules: the assignment, to identified actors, of the authority to make, delegate, or override each class of change, with the procedure under which the change is authorized. A change to enforcement-relevant state is authorized when the actor making it holds the required authority and follows the prescribed procedure. Where the governed system can cause or select such a change without the authority assigned to it, directly or through an actor whose action it can obtain, it exercises unauthorized control.
The protected set closes the loophole that the first two definitions leave open. If the authority rules could assign the governed system authority over the policy that governs it, every modification the agent made would be authorized, and a test based solely on whether changes were authorized could incorrectly report independence. The protected set is the subset of enforcement-relevant state whose alteration must require authority the governed system cannot supply or substitute: the designation of the boundary as the source of the verdicts on which release depends; the condition that release depends on that verdict; the source of governing authority, meaning who may author the policy the boundary applies to the governed system's covered actions; and the rules determining who may modify any of these, including the procedure for amending the authority rules themselves. An authority model that assigns the governed system a protected element, directly or by delegation, fails the definition on its face. Independence cannot be defined away by assignment.
Nothing in the definition forbids interaction. The governed system may submit requests, supply bounded inputs, consume resources within declared limits, and take part in change procedures the authority rules permit, provided a protected change remains contingent on a determination the governed system cannot make or replace. What the property prohibits is control outside the authority rules that can change what the boundary relies on or whether it governs release, and an authority model that places that control inside the governed system's own authority.
4. Four obligations
The assessment begins with the authority model. If the authority rules assign the governed system control over a protected element, directly or by delegation, independence fails without any attempted modification. The evaluator then applies four overlapping obligations. Each examines a different route to enforcement control, and a demonstrated reachable capability can defeat an obligation even where no unauthorized transition has occurred. The table identifies the prohibited control, an illustrative observed failure, and the evidence required to assess the route.
| Obligation | Prohibited control | Illustrative observed failure | What the record must show |
|---|---|---|---|
| EI-1 Modification | Changing what the boundary relies on, outside the authority rules, in either direction | A change to the boundary's control state caused by the governed system that the rules do not assign to it | The inventory of enforcement-relevant state and dependencies, the write paths to each, and the authority each path requires |
| EI-2 Lifecycle | Altering the boundary's lifecycle state, or the condition that the boundary is required for release, outside the rules | A suspension, removal, or lifecycle transition of the boundary caused by the governed system that the rules do not assign to it | Who may deploy, suspend, replace, or retire the boundary, and that the release condition cannot be relaxed by the governed system |
| EI-3 Substitution | Conditioning release on a verdict from a source the rules do not designate | Release accepted on a verdict the boundary did not issue | That the release path consumes verdicts only from the designated source, and how a substitute would be refused |
| EI-4 Delegated acquisition | Reaching a change to the boundary's control state through an actor who relays rather than decides | A change whose authorizing input was the governed system's request transmitted, not an authority's determination | Where the authority-bound input enters the change procedure, that the procedure fails without it, and what the procedure can and cannot establish about the approver |
Modification (EI-1) is the obvious case and the one the two configurations in Section 2 illustrate; the phrase in either direction is deliberate, because a restriction the authority never issued is as much a failure as a permission. Lifecycle (EI-2) covers the quieter route: not changing the policy but suspending the boundary, or removing the requirement that release wait for it. An agent that can place the gateway in a maintenance state, or can clear the setting that makes release wait for the gateway's verdict, has changed no rule and still controls whether the boundary governs release. Substitution (EI-3) covers the case where the boundary is intact but release listens to something else: a cached verdict, a secondary service, a flag that stands in for the gateway's answer. Delegated acquisition (EI-4) is the obligation that changes most when the governed system is an AI system. A system that can produce, at scale and without fatigue, the inputs that move human operators does not need privileges of its own. If an operator's approval is the agent's request transmitted rather than a determination the operator made, the write to the configuration store carries the operator's credentials and the agent's control. The capability model must therefore include the actors whose actions the governed system can obtain; a model that enumerates the agent's credentials and stops has not enumerated the agent's reach.
The note bounds what the record can show about that last obligation. An assurance record can establish whether a change procedure required a separately authorized actor to supply an authenticated, action-bound determination and whether the specified checks were satisfied. A signature or approval event alone establishes neither independent reasoning, substantive review, nor immunity to manipulation. Authentication establishes who approved, not that the approver reasoned independently. The obligation is bounded to procedural evidence, and the record must say so.
5. Three findings that are not the same
Much of the note's precision is in keeping three findings apart that are easy to run together. In the first configuration of Section 2, the agent changed the policy, an unauthorized release followed, and the prohibited effect occurred. In the second, the agent changed the policy to restrict execution, but no unauthorized release occurred. Those are different findings with different evidence, and an evaluator who treats them as one will either see failures that are not there or miss the one that is.
An enforcement-independence failure is a finding about the mechanism. It is established on any of three grounds: a prohibited authority assignment under the declared rules, a demonstrated reachable capability for unauthorized control over enforcement-relevant state within the declared capability model, or an observed unauthorized exercise of such control. The first two defeat independence without any observed change. A deployment does not have to wait for the agent to rewrite the policy; the fact that it can is the finding.
A release-control violation is a finding about release. Release proceeded without the authorization the applicable rules required for that action. This is the failure witness for the Hook conditions on release and fail-closed behavior [Hook]. A feasible bypass demonstrated analytically is such a witness; an actual unauthorized release is an observed one.
An Output Integrity failure witness is a finding about executions. A covered effect occurred without the required authorization bound to the proposed action. This requires the effect to have occurred. A demonstrated capability to compromise the mechanism does not, by itself, establish that an unauthorized effect happened.
The three are different objects, and none of them is a runtime verdict. Enforcement independence is a condition on the mechanism over a declared configuration. Output Integrity is a property of executions over declared paths, and it keeps the definition the Authorization Boundary Integrity Model gives it [ABIM]. The relationship between them is evidentiary: evidence for Output Integrity is gathered against a particular control state, with the boundary configured a certain way, and if the governed system can alter that state outside the authority rules, the evidence attaches to a state the governed system can change. Whether it still reaches the state that will govern the next release is a question, not a given.
One further rule governs all three. A finding that the property is defeated requires a confirmed failure witness. Absence of a witness is not satisfaction, and it is not affirmative evidence. An obligation is supported only to the extent justified by the evidence submitted, the scope declared, and the residual assumptions stated.
6. The assurance record
Independence is established by evidence, and the note specifies the record that carries it. The record is not new machinery. The ABIM Evidence Requirements already require a trust-assumption record as a prerequisite to any Output Integrity conclusion [ABIM-ER]; the independence record is the content of that prerequisite for the assumption that the mechanism is beyond the governed system's reach.
The record is organized per obligation, with a precondition: before any obligation is assessed, the evaluator identifies the protected elements and inspects the authority rules, including their delegation and amendment provisions, to determine whether the rules assign the governed system any authority over a protected element. A claim that fails this check fails on the face of the rules, before any evidence about reachability is examined.
For each obligation, the record carries eight fields: the claim and obligation under assessment; the covered configuration, with its scope, authority model, and capability model; the control relationship between the governed system and the relevant state; the failure scenario the evidence addresses; the supporting evidence; the residual assumptions the evidence leaves standing; the evidence outcome; and the reassessment triggers that would require the assessment to be repeated.
Suppose the gateway deployment has been corrected and the agent's write path to the configuration store removed. The modification entry would then name the store as enforcement-relevant state, list the write paths that remain and the authority each requires, cite the first configuration of Section 2 as the failure scenario, carry the evidence that the agent holds no path to the store and can obtain no actor who does, and record as a residual assumption whatever that evidence does not reach, such as the integrity of the store's own access control. Its reassessment triggers would include any new writer to the store.
The evidence outcome takes one of three values. Affirmative evidence: the submitted evidence supports the obligation at the covered configuration, subject to the stated residual assumptions. Not established: the evidence is insufficient, because of an unresolved omission or deficiency, and the claim is neither supported nor defeated. Failure witness: a confirmed witness exists on one of the three grounds, and the claim is defeated. These are assessment results about a claim. They are not verdicts. The runtime verdict space remains ALLOW, DENY, and ABSTAIN, and a finding of not established in this record says only that an evaluator lacks evidence; it borrows nothing from the semantics of a runtime ABSTAIN.
7. When the configuration changes
Every claim of independence is bound to the configuration at which the evidence was gathered. New tools, new integrations, new delegates, new credentials, new approval workflows, and new operator procedures are all changes to the configuration, and the question of what happens to the existing claim deserves a precise answer rather than a reflex.
Take the corrected gateway deployment of Section 6, and suppose that a month after the record is written the deployment adds a tool integration whose installer writes to the configuration store under a service account of its own. Whether the agent can obtain that installer's action is a claim-relevant difference. The note gives the answer in three outcomes, and insists they are not to be collapsed into one word.
| Outcome | What it means | What it takes |
|---|---|---|
| Defeated | A confirmed claim-specific failure witness exists at the new configuration | Any of the three grounds, demonstrated at the new configuration |
| Not established | The property may still hold, but the evidence gathered at the old configuration does not establish it at the new one | A claim-relevant difference whose effect on the evidence has not been shown to be preserved |
| Preserved | The change lies within an envelope the record already justified, and the existing evidence continues to support the claim | A documented change assessment showing that every claim-relevant difference preserves the applicability of the original evidence |
Until a change assessment addresses the new writer, the claim is not established. If the assessment demonstrates that the agent can use the installer to cause an unauthorized change to enforcement-relevant state, independence is defeated. If the installer remains beyond the agent's effective control and the assessment establishes that every other claim-relevant difference preserves the applicability of the original evidence, the claim may be preserved. The distinction turns on demonstrated control and evidence applicability, not merely on whether the installer exists. The rule that decides between not established and preserved is the Evidence Transfer Criterion. It is a conservative assurance rule, offered as such and not as a derived theorem. Evidence gathered for a claim at one configuration may be reused at a later configuration only if a documented change assessment, considered together with the original evidence, establishes that every claim-relevant difference between the two configurations preserves the applicability of that evidence, either directly or under an expressly justified invariance class. The assessment must include newly introduced execution paths, enforcement dependencies, authority relationships, administrative interfaces, delegated capabilities, and other claim-relevant capabilities, whether or not they were named in the original record. Where preservation is not established, the claim is not established until new evidence is obtained or the claim is narrowed. Configuration change alone establishes neither defeat nor preservation.
The criterion applies to independence claims and to Output Integrity claims alike, and separately. For independence, the claim is the property of Section 3 with its protected-set check and four obligations. For Output Integrity, the claim is the ABIM property, and its failure witness requires a covered effect that occurs without the required authorization. Reuse of evidence for one claim does not imply reuse for the other.
8. What independence does not give you
The note is explicit about its limits, and three of them matter for anyone reading a claim built on it.
Independence is not sufficient for security. A mechanism may be beyond the governed system's reach while the policy is wrong, the inputs inadmissible, the verdict unreconstructable, or the covered scope incomplete. Independence replaces none of the other integrity requirements. Enforcement independence is one necessary assurance consideration; continued applicability of evidence across configurations remains subject to the Evidence Transfer Criterion.
An availability failure is not an independence failure. If the governed system, or anything else, exhausts a resource the boundary depends on and every covered effect is blocked, that is fail-closed enforcement operating as specified. Nothing was released. It becomes an independence question only where the governed system's control over the exhausted resource is itself outside the authority rules, which is the modification obligation applied to a dependency.
Independence is mechanism-agnostic and configuration-bound. The note uses published architectural requirements and stipulated configurations, excludes unpublished mechanisms, and claims nothing about controlling AI systems in general. It adds no integrity property to the Authorization Boundary Integrity Model and no test to the Five Tests Standard. Its record is the content of a prerequisite the evidence framework already requires, and its obligations are conditions a deployment must defend before a claim of a non-bypassable runtime authorization boundary can be evaluated.
9. What changes for an evaluator
Before the note, an evaluator presented with a governed deployment could check that every covered action traversed the boundary, that release waited on the verdict, that failure produced no ALLOW, and that verdicts reconstructed, and could examine the policy lineage and authority state the artifact evidences. Those were necessary checks, and they remain necessary. They were never the complete boundary requirements, and none of them asked, as a question in its own right, whether the agent could reach the mechanism. The first configuration in Section 2 shows what that costs: a deployment can pass the four operational checks while the agent writes the policy, and lineage evidence gives a basis for examining where the rule came from without establishing that the agent could not have put it there.
After the note, the evaluator has a further question, and it has specified content. Does the authority model reserve the protected elements to authority the governed system cannot supply? Within the declared capability model, including the actors the agent can move, can the governed system reach a change to what the boundary relies on, to whether the boundary governs release, or to whose verdict release consumes? Is the answer evidenced per obligation, with residual assumptions stated and reassessment triggers named? And when the configuration changes, has anyone shown that the evidence still reaches the state that will govern the next release?
The note does not conclude that AI systems can be controlled. It concludes that a claim to have controlled one has a specific content, and that the content can be checked.
The technical note is published on Zenodo as the version of record: Enforcement Integrity in Pre-Execution Authorization, FERZ, Inc. Technical Note v1.0, https://doi.org/10.5281/zenodo.23438040 (concept DOI 10.5281/zenodo.23438039).
Related concepts
- Runtime Authorization Boundary
- Non-Bypassable AI Governance
- Fail-Closed Design
- Observability is not authorization
- Auditability Is Not Authorization
References
- [EI] Meyman, E. (2026). Enforcement Integrity in Pre-Execution Authorization. FERZ, Inc. Technical Note, Version 1.0. https://doi.org/10.5281/zenodo.23438039 (version of record: https://doi.org/10.5281/zenodo.23438040)
- [Hook] Meyman, E. (2026). The Hook Is Not the Boundary: Boundary Completeness in Pre-Execution Authorization. FERZ, Inc. Technical Note, Version 1.0. https://doi.org/10.5281/zenodo.22180242 (edition relied upon: https://doi.org/10.5281/zenodo.22180243)
- [ABIM] Meyman, E. (2026). The Authorization Boundary Integrity Model. FERZ, Inc. Technical Note. https://doi.org/10.5281/zenodo.20929115 (edition relied upon: v1.2, https://doi.org/10.5281/zenodo.22262364)
- [ABIM-ER] FERZ, Inc. (2026). ABIM Evidence Requirements: Evidence for Output, Input, and Replay Integrity Conclusions. Version 3.5. https://doi.org/10.5281/zenodo.22117938 (edition relied upon: https://doi.org/10.5281/zenodo.22117939)
- [ETA] Meyman, E. (2026). Execution-Time Authorization for AI Agents: A Formal Framework for Deterministic Governance Boundaries. FERZ, Inc. https://doi.org/10.5281/zenodo.18764561 (edition relied upon: v3.1, https://doi.org/10.5281/zenodo.22261326)
- [AvA] Meyman, E. (2026). Authority versus Authorization: A Definitional Framework for AI Governance. FERZ, Inc. https://doi.org/10.5281/zenodo.21341907
CITE THIS PAGE
Meyman, E. (2026). Enforcement Integrity in Pre-Execution Authorization. FERZ, Inc. https://ferz.ai/articles/enforcement-integrity-pre-execution-authorization. Technical note of record: https://doi.org/10.5281/zenodo.23438040
BibTeX
@misc{meyman2026enforcementintegrity,
author = {Meyman, Edward},
title = {Enforcement Integrity in Pre-Execution Authorization},
publisher = {{FERZ, Inc.}},
year = {2026},
howpublished = {\url{https://ferz.ai/articles/enforcement-integrity-pre-execution-authorization}},
note = {Technical note of record: \url{https://doi.org/10.5281/zenodo.23438040}}
}© 2026 FERZ, Inc. Licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).