When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality

1.1. Vulnerability: A Correct Gate Can Protect the Wrong Amount of the System

A security system can authenticate a requester correctly, evaluate policy correctly, bind authority to an exact Candidate Act, verify freshness and revocation, and enforce that decision at one carefully protected gate. Those properties are valuable. They do not by themselves prove that the protected consequence is unreachable by another route.¶

The security object considered in this document is therefore not only a request or API call. It is the defined Protected Consequence and the complete set of technically viable routes, inside an explicit Effectuation Domain, that can first make that consequence effective.¶

                        checked path
Candidate Act  -------> +-------------------+ -------+
                        | Protected Gate     |        |
                        | / Finality Sink    |        v
                        +-------------------+   +-------------+
                                                | CONSEQUENCE |
                                                +-------------+
                                                       ^
                                                       |
Alternate API / queue / admin / device / DMA ----------+
                 no equivalent finality check

In the figure, the checked path can be perfectly implemented. The bypass exists because the consequence, not the gate, is the true security target. A prevention claim therefore depends on coverage of consequence-producing paths, not merely correctness of one enforcement point.¶

1.2. Existing Solutions Already Address Important Parts

The strongest existing architectural precedent is the reference-monitor concept. NIST describes a reference validation mechanism as always invoked (complete mediation), tamper resistant, and sufficiently analyzable to be verifiable; NIST SP 800-160 further treats non-bypassability as a criterion for trustworthy system control [NIST-RM].¶

OAuth security guidance requires Resource Servers to restrict and check token audience, resources, and actions for requests they receive [RFC9700].¶

API gateways, service meshes, cloud policy systems, service perimeters, operating-system controls, IOMMU/device controls, and hardware isolation mechanisms can mediate selected execution or access paths. RATS can establish evidence and Attestation Results about the trust state of components that participate in those paths. WIMSE is addressing identity and security context across multi-service and asynchronous workload chains.¶

These mechanisms are not treated as deficient. They provide mature controls at their defined boundaries, and a deployment that already makes one of those boundaries complete and non-bypassable for the consequence can already satisfy the core property in this document.¶

1.3. Why the Residual Gap Can Remain

The residual problem exists only where the scope of enforcement is narrower than the set of ways the consequence can actually occur. The issue is not that the existing control failed to do what it was designed to do; the issue is that its enforcement boundary may not coincide with the full consequence boundary.¶

• A Resource Server can correctly validate every request it receives, yet a later queue, worker, database, device, payment rail, or downstream workload can remain separately reachable.¶
• A gateway, service mesh, or service perimeter can correctly govern configured traffic while local administrative, recovery, storage, management-plane, or hardware paths remain capable of producing the same effect.¶
• A RATS appraisal can correctly establish trust in a component while another unmodeled component or route remains capable of producing the consequence; attestation establishes evidence about state, not automatic consequence-wide path coverage.¶
• A TEE, DPU, SmartNIC, IOMMU, or other protected mechanism can provide strong enforcement when it lies on every relevant route, but isolation or trust in that component alone does not prove that all effectuation paths traverse it.¶
• A topology can be complete when reviewed and later become incomplete after a routing, service, firmware, device, API, queue, recovery, or management-plane change.¶

Accordingly, this document does not ask whether a policy decision was correct. It asks whether every route capable of creating the defined consequence intersects equivalent load-bearing enforcement before the consequence becomes effective. If an existing mechanism already provides that complete, non-bypassable mediation for the defined consequence, the residual gap does not exist for that deployment.¶

1.4. What This Architecture Introduces

The proposed contribution is deliberately narrower than a claim to have invented complete mediation. It applies complete-mediation reasoning to an explicitly defined consequence and expresses the result as an execution-finality property that can span distributed software and hardware paths.¶

• Define the Protected Consequence K rather than relying only on the name of an API or service.¶
• Define the Effectuation Domain D inside which the prevention claim is made.¶
• Model the relevant system as a generation-indexed directed Effectuation Graph G_g = (V_g, E_g).¶
• Identify the source set S_g from which a Candidate Act or attacker-controlled operation can enter an effectuation path.¶
• Identify the consequence node e_K, the first transition at which K becomes effective.¶
• Define a Finality Cut Set F_g whose valid enforcement points separate every admissible source from e_K.¶
• Require each enforcement point in F_g to apply an equivalent load-bearing finality predicate to the concrete Candidate Act.¶
• Bind the coverage claim to a protected Path-Set Generation g so a topology-changing event cannot silently inherit an older proof.¶
• Distinguish a verified prevention profile from partial-coverage mitigation or detection.¶

5.1. Path-Specific Authorization Is Not Consequence-Wide Coverage

A protocol can prove that one request was correctly authorized without proving that all equivalent effectuation routes are governed. This document treats those as separate security properties.¶

5.2. Complete Mediation and the Reference-Monitor Precedent

The reference-monitor model is direct prior security architecture for the requirement that security-relevant accesses be mediated. NIST defines the reference validation mechanism as always invoked, tamperproof, and verifiable [NIST-RM].¶

This document does not rename complete mediation as a new invention. The narrower question is how to state and test mediation when the protected object is a consequence reached through heterogeneous distributed software and hardware paths, rather than a single subject-object access boundary.¶

5.3. Detection Is Not Prevention

Logging, anomaly detection, SIEM, audit trails, and post-event reconciliation can reveal that a bypass occurred. They remain important controls. Unless they prevent the protected effect before it becomes effective, they provide detection, accountability, or recovery rather than the same prevention property.¶

6.1. Adversary Capabilities

The adversary MAY control or influence the requester, AI agent, application process, ordinary network path, request sequencing, exposed alternate APIs, asynchronous job submission, ordinary caches, and any credential legitimately available to those components. The adversary MAY attempt to route the same intended effect through a different API, service, queue, storage interface, administrative surface, device path, recovery mechanism, or management plane.¶

The adversary need not compromise the primary enforcement point. A valid bypass exists whenever the attacker can cause the protected consequence through a technically viable route that is outside equivalent enforcement under the declared threat model.¶

6.2. Threat Severity and Applicability

Severity is consequence-dependent rather than universally critical. The issue deserves high attention where bypass can create irreversible, high-value, safety-relevant, privacy-sensitive, sovereign, or operational effects. Examples include financial settlement, critical cloud-control changes, sensitive-data or model-weight release, AI-agent actions affecting external systems, protected network egress, device or operating-system actions, industrial actuation, and mission-critical commands.¶

6.3. Baseline Consequence-Path Profile

In the baseline profile, the requester, application logic, ordinary network, and untrusted caches are not trusted. The configured members of the Finality Cut Set, their load-bearing state, the protected Path-Set Generation, and the protected commit mechanism are trusted to follow the protocol.¶

6.4. High-Assurance Consequence-Path Profile

A higher-assurance deployment MAY additionally assume compromise of the general-purpose host operating system, agent runtime, orchestration plane, local policy cache, service-mesh sidecar, or privileged software capable of invoking alternate storage, device, or network paths. In that profile, the Finality Cut Set and Path-Set Generation MUST be anchored in protection domains that those compromised components cannot rewrite or bypass.¶

Possible enforcement substrates include device firmware, protected storage or transaction controllers, a DPU or SmartNIC, an IOMMU-enforced boundary, a TEE or secure monitor, a hardware security processor, or another independently enforceable boundary appropriate to the system.¶

6.5. Trusted Roots and Limits

The base model assumes that at least one configured root for coverage state and every enforcement point required for the claimed cut remain trustworthy. Compromise of all enforcement roots, physical subversion outside the hardware threat model, a lying topology authority without independent verification, or an effect that can be caused outside the declared Effectuation Domain are outside the base prevention claim.¶

8.1. Prevention Profile

Within the declared Effectuation Domain D, the architecture can claim prevention of the governed alternate-path bypass class only if the path model is complete enough for that claim, every effectuation path intersects valid equivalent enforcement, the enforcement is non-bypassable under the stated threat model, and changes that can alter path coverage cannot silently preserve the prior completeness state.¶

Protected Consequence K
        +
Bounded Effectuation Domain D
        +
Complete-enough effectuation graph G_g
        +
Valid Finality Cut Set F_g
        +
Equivalent load-bearing enforcement on every path
        +
Protected Path-Set Generation g
        +
Fail-closed response to unknown or changed coverage
        =
Prevention of the governed alternate-path bypass class

8.2. Partial-Coverage Mitigation Profile

If only documented APIs are enumerated, path discovery is advisory, debug/recovery/admin/device paths remain ungoverned, enforcement can be disabled by an attacker inside the threat model, or a bypass is only detected after effect, the system provides mitigation, detection, or audit rather than the same prevention guarantee.¶

8.3. Coverage Unknown

A deployment SHOULD have an explicit COVERAGE_UNKNOWN state. When the current path-set generation cannot be established, a topology change is unclassified, or required enforcement membership cannot be verified, high-assurance operations MUST NOT silently inherit the previous prevention claim. They SHOULD remain non-effective or transition to a clearly labeled lower-assurance policy.¶

9.1. Reference Monitors and Complete Mediation

Complete mediation is foundational prior art. NIST states that a reference validation mechanism is always invoked, tamperproof, and sufficiently analyzable to be verifiable, and NIST SP 800-160 discusses non-bypassability for trustworthy system control [NIST-RM].¶

The proposed delta is not the always-invoked property itself. It is a consequence-oriented representation for applying that property to distributed effectuation graphs and binding the resulting coverage assertion to topology generation.¶

9.2. OAuth and Resource Servers

RFC 9700 requires Resource Servers to verify, for requests they receive, that access tokens are intended for the relevant Resource Server, resource, and action [RFC9700].¶

Where the Resource Server itself is the complete non-bypassable consequence boundary, it can satisfy the Finality Sink role and no extra component is required. The residual question arises when the Resource Server hands work to a queue, database, device, payment rail, or downstream system that has additional effect-capable ingress paths.¶

9.3. Gateways, Service Meshes, and Cloud Perimeters

Gateways, service meshes, and service perimeters can provide strong centralized or distributed enforcement for the paths they control. The consequence-path question is whether local calls, administrative planes, recovery tooling, unprotected services, direct storage access, or device paths can create the same effect outside that coverage.¶

9.4. Externalized Authorization and Policy Engines

Amazon Verified Permissions evaluates whether a principal may perform an action on a resource in a given context using Cedar policies [AWS-AVP].¶

Such a policy decision point can participate in finality enforcement. The path-completeness property remains a deployment question: every effect-capable route must actually invoke equivalent enforcement before the consequence occurs.¶

9.5. RATS and Attestation

RATS distinguishes Evidence, Attestation Results, Reference Values, appraisal policy, and Relying Party decisions [RFC9334].¶

Attestation can establish trust in a cut member or in topology/configuration evidence. Trust in a component does not by itself enumerate every route to a later consequence; conversely, a RATS-based deployment may already provide enough authenticated topology evidence for a concrete path-completeness profile.¶

9.6. Protected Hardware and Confidential Computing

TEEs, secure monitors, DPUs, SmartNICs, storage controllers, IOMMUs, and confidential-computing mechanisms can provide protected locations for cut enforcement or topology state. Hardware isolation is therefore a possible substrate for the property, not a replacement for path modeling.¶

9.7. What Is New in This Document

The proposed contribution is the combination of four ideas into one testable execution-finality invariant: consequence-centered scope, a graph-based Finality Cut Set across heterogeneous paths, coverage bound to a protected Path-Set Generation, and an explicit prevention-versus-mitigation classification.¶

The document does not claim that no existing product or standard already implements an equivalent property. Reviewers are specifically invited to identify systems that already provide the same invariant for a defined consequence and threat model.¶

12.1. Formal Graph Components

For each Path-Set Generation g, the deployment models the bounded effectuation domain as a directed graph G_g = (V_g, E_g). Vertices represent security-relevant effectuation states, interfaces, controllers, queues, storage objects, devices, commit points, or other nodes whose presence or absence can change whether the protected consequence is reachable. Directed edges represent technically viable transitions under the declared threat model.¶

G_g = (V_g, E_g)

S_g ⊆ V_g       = applicable source vertices

K              = protected consequence class

κ_g ⊆ V_g      = one or more consequence vertices / first-effect
                 transitions that instantiate K

P_g(K,D)       = all technically viable directed paths
                 from any s ∈ S_g to any κ ∈ κ_g
                 inside declared domain D

12.2. Path-Set Definition

P_g(K,D) :=
    { p |
        p is a directed path in G_g,
        start(p) ∈ S_g,
        end(p) ∈ κ_g,
        p is technically viable under threat model T,
        p remains inside declared effectuation domain D
    }

The model is consequence-oriented rather than API-oriented. Two different APIs, queues, DMA paths, recovery paths, firmware interfaces, or physical controllers belong to the same path analysis when they can instantiate the same protected consequence K.¶

12.3. Consequence Equivalence

The completeness claim depends on defining which effects count as the same protected consequence. Let ≡_K denote the deployment-defined effect-equivalence relation.¶

e1 ≡_K e2
    iff
the deployment treats e1 and e2 as equivalent
for the security property being protected.

Example:
    write balance=0 through API-A
        ≡_K
    write balance=0 through admin console
        ≡_K
    direct database mutation producing balance=0

If consequence equivalence is underspecified, a system can appear complete merely because an alternate path is labeled as a different operation even though it produces the same protected effect.¶

12.4. Effectuation-Domain Closure

The declared domain D must be closed over every transition that can materially contribute to the protected consequence under the threat model. The model need not contain irrelevant implementation detail, but omission of a load-bearing transition invalidates the completeness claim.¶

ClosedFor(K,D,T) :=
    FOR EVERY technically viable transition τ
    that can participate in a path to K under threat model T:

        τ is represented in G_g
        OR
        τ is outside D by an explicit, justified boundary assumption.

12.5. Expanded Effectuation Graph

Applicable sources S_g

  Agent/API       Admin API       Queue Producer       Recovery Tool
      |               |                 |                   |
      v               v                 v                   v
   Gateway --------> Service --------> Worker ----------> Storage
      |                                  |                  |
      |                                  v                  |
      |                              Device Path            |
      |                                  |                  |
      +--------------------------+-------+------------------+
                                 |
                                 v
                         Consequence vertices κ_g
                                 |
                                 v
                         Protected consequence K

Completeness is about every viable route to K, not only the normal API.

13.1. Vertex-Cut Definition

F_g ⊆ V_g

F_g is a valid Finality Cut Set for (K,D,g)
iff:

    FOR ALL p ∈ P_g(K,D):
        p ∩ F_g ≠ ∅

Every technically viable source-to-consequence path must intersect at least one valid enforcement vertex. The cut can contain one chokepoint or many distributed enforcement points.¶

13.2. Edge-Cut Variant

Some implementations are naturally modeled by protected transitions rather than protected vertices. Let Q_g be a set of enforced edges.¶

Q_g ⊆ E_g

EdgeCutCoverage(K,D,g,Q_g) :=
    FOR ALL p ∈ P_g(K,D):
        edges(p) ∩ Q_g ≠ ∅

A profile MAY use vertex cuts, edge cuts, or a mixed representation, provided the chosen model preserves the same non-bypassability property.¶

13.3. Bypass Witness

BypassWitness(K,D,g,F_g) :=
    any path p such that:

        p ∈ P_g(K,D)
        AND
        p ∩ F_g = ∅

Returning a concrete witness path is operationally useful because it identifies the route that invalidates the completeness claim rather than merely returning a Boolean failure.¶

13.4. Minimum Cut Is Not Required

A minimum cut can be useful for optimization or review, but security does not require the smallest cut. A larger cut can be preferable when it aligns with independent trust domains, existing safety/security boundaries, or availability requirements.¶

Security condition:
    cut covers all paths

Optimization objective (optional):
    minimize cost(F_g)

These are different problems.

13.5. Valid Cut Versus Uncovered Witness Path

Covered paths:

 S1 ---> A ---> [F1] ---> K
  \
   +--> B ---> C ---> [F2] ---> K

Uncovered path:

 S2 ---> X ---> Y -----------------> K
              ^                     ^
              |                     |
          no member of F_g intersects path

Witness path = S2 -> X -> Y -> K
Coverage result = FAIL

The complete formal definitions for reachability, coverage records, distributed cuts, generation transitions, and the bounded prevention theorem appear in <xref target="formal-invariant"/>.¶

14.1. Cut-Set Prevention Theorem (Within the Declared Model)

Assume: (1) G_g faithfully contains every effectuation path inside D that the threat model permits the adversary to use; (2) F_g is a valid separating cut, so removing F_g makes k unreachable from S_g; (3) each member of F_g is non-bypassable and enforces an equivalent finality predicate; and (4) the attacker cannot compromise all required cut members or protected topology state. Then no modeled path from S_g can make K effective without first crossing valid finality enforcement.¶

Proof sketch: suppose a modeled path p from S_g reaches k without valid finality enforcement. If p contains no member of F_g, then k remains reachable in G_g minus F_g, contradicting CutCoverage. If p crosses F_g but avoids the predicate, the non-bypassability/enforcement assumption is false. Therefore an attack that succeeds must violate at least one declared assumption: graph completeness, cut coverage, enforcement correctness, topology freshness, or trusted-root integrity. The theorem is intentionally bounded to D and g; it is not a proof about unmodeled external systems.¶

14.2. Reachability Formulation

For a known finite graph, explicit enumeration of every path is unnecessary. Remove the candidate cut and test whether any consequence vertex remains reachable from any applicable source.¶

G'_g = G_g - F_g

CutCoverage(K,D,g,F_g) :=
    NOT Reach_G'_g(S_g, κ_g)

where:

Reach_G(S,κ) = TRUE
    iff ∃ s ∈ S and ∃ k ∈ κ
    such that a directed path s ->* k exists in G.

14.3. Enforcement Validity

EnforcementPointValid(f,C,g) :=
       IntegrityValid(f,g)
   AND EquivalentFinalityPredicateDefined(f)
   AND ExactActBindingAvailable(f,C)
   AND CurrentPolicyStateAvailable(f)
   AND CurrentRevocationStateAvailable(f)
   AND CurrentTrustStateAvailable(f)
   AND GenerationBound(f,g)
   AND ProtectedCommitControlled(f)

EnforcementValid(F_g,C,g) :=
    FOR EVERY f ∈ F_g that can mediate the realized path:
        EnforcementPointValid(f,C,g)

14.4. Coverage Record

CR_g = Protect(
         K,
         D,
         g,
         Root(G_g),
         Root(F_g),
         ThreatModelId,
         AssuranceProfile,
         ConsequenceEquivalenceId,
         CoverageResult)

CoverageRecordValid(CR_g) :=
       IntegrityValid(CR_g)
   AND CurrentGeneration(CR_g.g)
   AND ThreatModelMatches(CR_g)
   AND ConsequenceDefinitionMatches(CR_g)

The coverage record is evidence of a reviewed graph and cut for a specific generation and threat model. Possession of the record is not itself execution authority.¶

14.5. Runtime Realized-Path Condition

Static cut coverage is necessary but not sufficient. The realized runtime path must cross a currently valid enforcement member or an equivalent protected predicate.¶

RealizedPathValid(C, p, g, F_g) :=
       p ∈ P_g(K,D)
   AND (
          ∃ f ∈ (p ∩ F_g):
              EnforcementPointValid(f,C,g)
       )
   AND ExactActBindingSatisfied(C,p)
   AND GenerationCurrent(g)

14.6. Distributed-Cut Composition

For a distributed cut F_g = {f1, f2, ..., fn}:

DistributedCutSatisfied(C,p,g) :=
    EXISTS nonempty R ⊆ (p ∩ F_g)
    such that:
        ReceiptChainAuthentic(R)
    AND ReceiptsCorrespondToRealizedPath(R,p)
    AND EquivalentPredicateSatisfied(R,C,g)
    AND RequiredThresholdOrRoleRuleSatisfied(R)

A profile can require one valid cut member, multiple independent members, a threshold, or role-separated enforcement. The composition rule must be explicit.¶

14.7. Prevention-Ready Predicate

PreventionReady(K,D,g,F_g,C) :=
       ClosedFor(K,D,T)
   AND CutCoverage(K,D,g,F_g)
   AND CoverageRecordCurrent(g)
   AND CutMembersNonBypassable(F_g)
   AND EnforcementValid(F_g,C,g)
   AND ConsequenceDefinitionCurrent(K)
   AND ThreatModelCurrent(T)

14.8. Strict Consequence-Path Safety Invariant

Effective(K,C)
    =>
PreventionReady(K,D,g,F_g,C)
AND RealizedPathValid(C,p_realized,g,F_g)

Strict prevention:

NOT PreventionReady(K,D,g,F_g,C)
    =>
NOT Effective(K,C)

OR, equivalently for a known finite graph:

Reach_(G_g - F_g)(S_g, κ_g) = TRUE
    =>
coverage claim MUST fail.

14.9. Topology-Transition Validity

TransitionValid(g -> g+1, K, D) :=
       AuthenticatedTopologyChange(g,g+1)
   AND (
          RecomputeCoverage(K,D,g+1)
          OR
          ProveChangeIrrelevantToReachability(K,D,g,g+1)
       )

If:
    NewReachabilityToK(g+1)
    OR CutMembershipChanged(g+1)
    OR TrustBoundaryChanged(g+1)

then:
    CoverageClaim(g) MUST NOT imply CoverageClaim(g+1).

14.10. Non-Monotonicity of Coverage

Coverage is generally non-monotonic with respect to topology growth. Adding one edge can invalidate a previously valid cut; removing an edge can restore coverage. Therefore a coverage claim must be generation-bound rather than treated as a permanent system property.¶

G_g covered
    +
add edge e_bypass
    =
G_(g+1) potentially uncovered

Coverage(G_g,F_g) = TRUE
does NOT imply
Coverage(G_(g+1),F_g) = TRUE

14.11. Bounded Prevention Proof

Assume: (1) D is closed for K under the declared threat model; (2) G_g faithfully represents all load-bearing transitions in D; (3) CutCoverage is true; (4) every cut member that can mediate a realized path is integrity-protected and enforces an equivalent finality predicate; (5) g remains current through protected commit; and (6) no consequence-equivalent path exists outside D.¶

Suppose K becomes effective through a path p without crossing a valid cut member. Because p is a technically viable source-to-consequence path, p belongs to P_g(K,D). CutCoverage requires every such p to intersect F_g. Therefore p both must and must not intersect F_g, a contradiction. The prevention claim consequently holds only while the assumptions remain true. The proof does not establish graph fidelity, threat-model correctness, or consequence-definition completeness; those are explicit premises.¶

14.12. Proof Intuition Diagram

Original graph:

 S ----> A ----> [F] ----> B ----> K
  \                ^
   \               |
    +----> C ------+

Remove valid cut F:

 S ----> A             B ----> K
  \
   +----> C

Can S still reach K?

  NO  -> cut covers all represented paths
  YES -> witness path exists; coverage fails

15.1. Topology Digest and Generation Binding

TG_g = Protect(
          generation = g,
          graph_root = Root(G_g),
          cut_root = Root(F_g),
          consequence_id = K,
          domain_id = D,
          threat_model_id = T,
          equivalence_id = Eq_K)

CurrentCoverage(CR_g, TG_now) :=
       CR_g.g == TG_now.g
   AND CR_g.graph_root == TG_now.graph_root
   AND CR_g.cut_root == TG_now.cut_root
   AND CR_g.consequence_id == TG_now.consequence_id
   AND CR_g.threat_model_id == TG_now.threat_model_id

15.2. Security-Relevant Topology Change Classification

PathAffecting(change,K,D) :=
       AddsSource(change)
    OR AddsEdge(change)
    OR AddsConsequenceEquivalentSink(change)
    OR RedirectsEdge(change)
    OR RemovesCutMember(change)
    OR WeakensCutMember(change)
    OR ChangesTrustBoundary(change)
    OR EnablesDebugRecoveryPath(change)
    OR ChangesDMAOrDeviceReachability(change)
    OR ChangesThreatModelAssumption(change)

15.3. Proof of Irrelevance

Not every topology change requires full recomputation if an authoritative proof shows the change cannot alter reachability to K or cut validity.¶

Irrelevant(change,K,D,g,g+1) :=
       AuthenticatedChange(change)
   AND NoNewSourceToKReachability(change)
   AND NoCutMemberRemovedOrWeakened(change)
   AND NoConsequenceDefinitionChange(change)
   AND NoThreatModelChange(change)

CoverageClaim(g)
AND Irrelevant(...)
    =>
CoverageClaim(g+1) MAY be carried forward

15.4. Topology Drift Across Generations

g17: COVERED

 S ---> [F] ---> K


g18: new bypass edge introduced

 S ---> [F] ---> K
  \______________> K

coverage becomes UNKNOWN / INVALID


g19: second cut member added

 S ---> [F1] ---> K
  \----> [F2] ---> K

coverage restored after recomputation

17.1. Define the Protected Consequence

The deployment identifies the first technically meaningful event that constitutes the consequence. The definition SHOULD be expressed in terms of effect, not merely an upstream message, when those differ.¶

17.2. Bound the Effectuation Domain

The deployment identifies the systems, trust domains, APIs, queues, storage systems, device paths, management planes, and hardware interfaces included in the claim. Anything outside D is explicitly outside the prevention proof unless separately constrained.¶

17.3. Establish the Path Set

The deployment builds or obtains an authenticated representation of the effectuation graph. Sources can include configuration manifests, service registries, workflow definitions, routing tables, infrastructure-as-code, hardware topology state, IOMMU/device configuration, firmware inventories, formal models, or manually reviewed bounded designs.¶

17.4. Establish the Finality Cut

The deployment selects enforcement vertices F_g and verifies that removing them disconnects all admissible sources from k. A concrete system MAY use a single common sink or several path-specific enforcement points.¶

17.5. Bind Coverage to a Protected Generation

The coverage result is bound to g and SHOULD identify K, D, the relevant graph or authenticated root, cut membership, assurance profile, and any expiration or revalidation conditions. The binding can be local protected state or portable evidence; this document does not define a wire format.¶

17.6. Finalize the Candidate Act

At runtime, a Candidate Act remains non-effective until it reaches a valid cut member. The cut member verifies that the coverage generation remains current, reconstructs or observes the concrete act, evaluates the load-bearing finality predicate, and couples success to protected commit. If current coverage cannot be established, the high-assurance path fails closed.¶

17.7. Runtime Enforcement Architecture

                  +----------------------+
Candidate Act --->         | Coverage Generation  |
                           | g + Cut F_g           |
                           +----------+-----------+
                                      |
                                      v
API ----------\              +-------------------+
Queue ---------\             | VALID CUT MEMBER  |
Admin ---------->------------| exact act         |----> K
Device --------/             | current g         |
Recovery -----/              | policy/revocation |
                             | finality predicate |
                             +-------------------+

18.1. Normalize the Protected Consequence

function normalize_consequence(effect_spec, equivalence_policy):
    K = canonical_security_consequence(effect_spec)

    equivalents = equivalence_policy.expand(K)

    if equivalents is EMPTY:
        equivalents = {K}

    return ConsequenceClass(
        id = H(canonical(equivalents)),
        members = equivalents,
        equivalence_policy_id = equivalence_policy.id)

18.2. Build the Effectuation Graph

function build_effectuation_graph(K, D, topology_sources, threat_model):
    G = DirectedGraph()

    for source in topology_sources:
        snapshot = authenticated_topology_snapshot(source)

        if !snapshot.integrity_valid:
            fail("untrusted topology source")

        for vertex in snapshot.vertices:
            if relevant_to_domain(vertex, D, K, threat_model):
                G.add_vertex(vertex)

        for edge in snapshot.edges:
            if technically_viable(edge, threat_model):
                G.add_edge(edge.from, edge.to, metadata=edge.metadata)

    add_declared_sources(G, threat_model)
    add_consequence_vertices(G, K)

    if !domain_closure_review_passes(G, K, D, threat_model):
        return CoverageFailure("effectuation domain not closed")

    return G

18.3. Discover Applicable Source Vertices

function applicable_sources(G, threat_model):
    S = set()

    for v in G.vertices:
        if attacker_or_authorized_actor_can_initiate_from(
                v, threat_model):
            S.add(v)

        if privileged_recovery_or_admin_origin(v, threat_model):
            S.add(v)

        if device_or_dma_origin_can_reach_effect(v, threat_model):
            S.add(v)

    return S

18.4. Discover Candidate Cut Members

function candidate_cut_members(G, K, enforcement_inventory):
    F = set()

    for e in enforcement_inventory:
        if !e.protected:
            continue

        if !controls_effectuation_transition(e, K):
            continue

        if !equivalent_finality_predicate_defined(e, K):
            continue

        F.add(graph_vertex_or_edge_for(e))

    return F

18.5. Validate Cut Coverage by Reachability

function validate_cut_coverage(G, S, K_vertices, F):
    G_reduced = remove_cut(G, F)

    result = multi_source_reachability(
        graph=G_reduced,
        sources=S,
        targets=K_vertices)

    if result.reachable:
        return CoverageFailure(
            reason="unmediated consequence path",
            witness=result.path)

    return COVERAGE_VALID

18.6. Extract a Human-Reviewable Bypass Witness

function explain_bypass(witness_path):
    return {
        source = witness_path.first,
        consequence = witness_path.last,
        hops = witness_path.vertices_and_edges,
        missing_cut_intersection =
            true,
        trust_boundary_crossings =
            identify_trust_boundary_crossings(witness_path),
        privileged_or_hidden_edges =
            classify_hidden_edges(witness_path)
    }

18.7. Establish and Protect a Coverage Record

function establish_coverage(K, D, topology_sources,
                            enforcement_inventory,
                            threat_model,
                            assurance_profile):

    G = build_effectuation_graph(
        K, D, topology_sources, threat_model)

    if G is CoverageFailure:
        return G

    S = applicable_sources(G, threat_model)
    K_vertices = consequence_vertices(G, K)

    F = candidate_cut_members(
        G, K, enforcement_inventory)

    if F is EMPTY:
        return CoverageFailure("no valid finality cut")

    coverage = validate_cut_coverage(
        G, S, K_vertices, F)

    if coverage != COVERAGE_VALID:
        return coverage

    for f in F:
        if !enforcement_integrity_valid(
                f, assurance_profile):
            return CoverageFailure(
                "cut member integrity insufficient", f)

    g = protected_next_path_set_generation(D)

    return protect_coverage_record(
        consequence = K,
        domain = D,
        generation = g,
        graph_root = authenticated_graph_root(G),
        cut_root = authenticated_cut_root(F),
        threat_model_id = threat_model.id,
        assurance_profile = assurance_profile,
        equivalence_id = K.equivalence_policy_id)

18.8. Authorize a Candidate against Current Coverage

function authorize_candidate(candidate_spec, coverage):
    if !coverage_record_integrity_valid(coverage):
        reject("invalid coverage record")

    if current_path_set_generation(coverage.domain)
       != coverage.generation:
        reject_or_mark_coverage_unknown(
            "coverage generation changed")

    C = canonicalize_effect(candidate_spec)

    if !consequence_matches_coverage(
            C, coverage.consequence):
        reject("candidate outside coverage consequence")

    decision = policy_evaluate(
        C,
        current_policy_state())

    if decision != ALLOW:
        reject("candidate not authorized")

    return CandidateAct(
        effect_digest = H(C),
        coverage_generation = coverage.generation,
        execution_authority =
            issue_single_use_act_bound_authority(
                H(C),
                coverage.generation,
                decision.constraints))

18.9. Validate the Realized Runtime Path

function validate_realized_path(
        candidate,
        realized_path,
        coverage,
        enforcement_receipts):

    if !path_matches_current_topology_generation(
            realized_path,
            coverage.generation):
        return REVALIDATE_COVERAGE

    intersections = intersect(
        realized_path,
        coverage.cut_members)

    if intersections is EMPTY:
        reject("runtime path bypasses finality cut")

    if !receipts_correspond_to_realized_path(
            enforcement_receipts,
            realized_path):
        reject("receipt/path mismatch")

    if !distributed_or_single_cut_predicate_satisfied(
            candidate,
            intersections,
            enforcement_receipts):
        reject("cut predicate unsatisfied")

    return VALID

18.10. Protected Runtime Finalization

function finalize(candidate,
                  observed_effect_request,
                  realized_path,
                  coverage,
                  enforcement_receipts):

    begin_protected_finality_section()

    if !coverage_record_integrity_valid(coverage):
        reject("invalid coverage record")

    g_now = current_path_set_generation(
        coverage.domain)

    if g_now != coverage.generation:
        if !prove_change_irrelevant_to_consequence(
                coverage.consequence,
                coverage.generation,
                g_now):
            reject_or_mark_coverage_unknown(
                "topology generation changed")

    if H(canonical(observed_effect_request))
       != candidate.effect_digest:
        reject("exact-act mismatch")

    if validate_realized_path(
            candidate,
            realized_path,
            coverage,
            enforcement_receipts) != VALID:
        reject()

    if !finality_predicate(
            candidate,
            current_policy_state(),
            current_revocation_state(),
            current_trust_state(),
            g_now):
        reject("finality predicate failed")

    atomic {
        assert current_path_set_generation(
                   coverage.domain) == g_now

        assert realized_path_still_bound_to_commit(
                   realized_path)

        assert no_new_unmediated_path_affects_commit(
                   coverage.consequence,
                   g_now)

        consume_once(
            candidate.execution_authority)

        commit_protected_effect(
            observed_effect_request)
    }

18.11. Handle a Topology Change

function register_effectuation_change(
        change,
        affected_domains):

    for D in affected_domains:
        if !change_can_affect_effect_paths(change, D):
            continue

        old_g = current_path_set_generation(D)

        new_g = advance_protected_path_set_generation(D)

        mark_coverage_unknown(
            D,
            from_generation=old_g,
            to_generation=new_g)

        invalidate_pending_candidates_bound_to(
            D, old_g)

        schedule_or_require_revalidation(D)

18.12. Prove a Change Irrelevant to Consequence Reachability

function prove_change_irrelevant_to_consequence(
        K, g_old, g_new):

    delta = authenticated_topology_delta(
        g_old, g_new)

    if delta.changes_threat_model:
        return FALSE

    if delta.changes_consequence_definition:
        return FALSE

    if delta.adds_source_or_consequence_vertex:
        return FALSE

    if delta.removes_or_weakens_cut_member:
        return FALSE

    if creates_new_reachability_to_consequence(
            delta, K):
        return FALSE

    return authoritative_irrelevance_proof_valid(
        delta, K)

18.13. Evaluate a Distributed Cut

function evaluate_distributed_cut(
        candidate,
        realized_path,
        cut_rule,
        receipts):

    valid = []

    for receipt in receipts:
        if !verify_receipt_integrity(receipt):
            continue

        if !receipt_binds_candidate(
                receipt, candidate.effect_digest):
            continue

        if !receipt_binds_generation(
                receipt,
                current_path_set_generation()):
            continue

        if !receipt_point_on_realized_path(
                receipt, realized_path):
            continue

        valid.append(receipt)

    if !cut_rule.satisfied_by(valid):
        reject("distributed cut rule not satisfied")

    return ALLOW_FINAL_COMMIT

18.14. Runtime Consequence-Path Coverage Check

function verify_runtime_consequence_path(
        consequence,
        current_graph,
        current_cut):

    S = applicable_sources(
        current_graph,
        current_threat_model())

    K_vertices = consequence_vertices(
        current_graph,
        consequence)

    result = validate_cut_coverage(
        current_graph,
        S,
        K_vertices,
        current_cut)

    if result is CoverageFailure:
        freeze_or_restrict_protected_effect(consequence)
        emit_bypass_witness(result.witness)
        return COVERAGE_INVALID

    return COVERAGE_VALID

18.15. Crash-Safe Recovery

function recover(candidate_id):
    state = protected_commit_state(candidate_id)

    if state == EFFECTIVE:
        return DO_NOT_REPLAY

    if state == COMMITTING:
        outcome = resolve_atomic_commit(candidate_id)

        if outcome == EFFECT_COMMITTED:
            return DO_NOT_REPLAY

        return REVALIDATE_CURRENT_TOPOLOGY_AND_FINALITY

    if state == PENDING:
        return REVALIDATE_CURRENT_TOPOLOGY_AND_FINALITY

    return FAIL_CLOSED

21.1. Alternate API Paths

A second API, legacy endpoint, SDK, RPC, shell command, browser automation interface, or local service can produce the same effect while bypassing the protected API.¶

21.2. Queues and Asynchronous Workers

Authorization can occur at enqueue time while a later worker commits the effect. Other producers or worker-side administrative paths may reach the same commit. The queue/worker chain must therefore be inside the effectuation model when it is load-bearing.¶

21.3. Direct Storage Mutation

An application-layer gate does not provide consequence-wide prevention if a database administrator, replication mechanism, stored procedure, maintenance tool, or direct storage interface can create the same state transition without equivalent enforcement.¶

21.4. Administrative and Privileged Interfaces

Administrative APIs and privileged consoles are often intentionally powerful. They must either be included in the cut model, explicitly excluded from the assurance claim, or governed by an equivalent higher-assurance procedure.¶

21.5. Debug and Recovery Paths

Debug, test, maintenance, migration, restore, disaster-recovery, and break-glass mechanisms can become bypasses if they retain direct effect authority during normal operation.¶

21.6. Device, DMA, and Accelerator Paths

A software gate can be bypassed if a device, DMA engine, peer accelerator, firmware path, or hardware agent can cause the same memory, storage, egress, or actuation effect outside the modeled enforcement path.¶

21.7. Network and Management Planes

Data-plane enforcement can be undermined by management-plane, out-of-band, alternate-interface, or control-plane routes that can create the same consequence.¶

21.8. Representative Path Class Matrix

                 Can reach K?
                 |
Normal API ------+---- yes ----> must cross cut
Admin API -------+---- yes ----> must cross cut
Queue worker ----+---- yes ----> must cross cut
Direct storage --+---- yes ----> must cross cut
DMA/device path -+---- yes ----> must cross cut
Recovery path ---+---- yes ----> must cross cut
Debug path ------+---- yes ----> must cross cut
Audit-only path -+---- no -----> not an effectuation path

Classification depends on technical capability, not naming.

22.1. Protected API plus legacy API

The attacker submits an operation through a legacy endpoint that reaches the same commit. If the legacy route is absent from G_g, the model was incomplete; if present but does not cross F_g, CutCoverage fails and the system must not claim prevention.¶

22.2. Queue injection

The checked API enqueues a job, but another principal can inject an equivalent job directly into the queue. The queue producer is an additional source/path that must cross equivalent enforcement before worker commit.¶

22.3. Direct database write

The application path is finality-protected, but a privileged process writes the protected record directly. A high-assurance claim requires the database/storage commit boundary or equivalent privileged path to be included in F_g or explicitly outside D.¶

22.4. Topology drift

Coverage was established at g=17. A deployment change adds a second service route at g=18. If g is checked at finalization, the old coverage record becomes unusable until the change is proved irrelevant or coverage is re-established.¶

22.5. Cut member disabled

An attacker with control inside the threat model disables a sidecar or gateway and keeps the path operational. The non-bypassability assumption fails; prevention cannot be claimed for that profile.¶

22.6. False topology evidence

A compromised topology source omits a path. Higher-assurance deployments require protected/attested topology sources, independent validation, formal configuration constraints, or other controls; otherwise the assurance level must reflect the risk.¶

23.1. Resource Server as Complete Boundary

Where the Resource Server itself performs the irreversible or externally effective operation and no alternate effect path exists under the threat model, it can be the sole cut member.¶

23.2. Gateway or Service-Mesh Cut

A gateway or mesh can form some or all of F_g when all relevant service routes traverse it and local or privileged bypasses are either blocked or equivalently mediated.¶

23.3. Storage or Transaction Commit Boundary

For database or ledger consequences, placing finality at the commit service or protected storage controller can reduce the number of upstream paths that need separate trust.¶

23.4. Device or Operating-System Boundary

For device actions, a secure service, kernel mediator, protected firmware interface, or hardware controller can form the consequence cut when software above it is not trusted.¶

23.5. DPU or SmartNIC Boundary

Where the consequence is network or I/O egress and all relevant traffic is forced through a protected DPU/SmartNIC path, that component can participate in F_g.¶

23.6. Distributed Cut

Large systems can use several cut members if their collective coverage and equivalent semantics are demonstrable.¶

32.1. OAuth

OAuth is active and now explicitly includes complex delegation for automated agents in its work program [OAUTH-CHARTER].¶

OAuth is relevant when a Resource Server or delegated-agent flow is one of the enforcement boundaries. The document should not presume that OAuth owns non-HTTP device, storage, or hardware path coverage.¶

32.2. WIMSE

WIMSE is active and addresses workload identity and authorization across multi-service environments [WIMSE-CHARTER].¶

It is relevant where the effectuation graph crosses multiple workloads or asynchronous services.¶

32.3. RATS

RATS is relevant where path-completeness evidence depends on trusted component state, topology evidence, attestation results, or protected enforcement components. The document does not propose to replace the RATS architecture.¶

32.4. DISPATCH

DISPATCH is an active standing venue for feedback and routing of proposed new work spanning ART, SEC, and non-transport WIT topics [DISPATCH-CHARTER].¶

Because consequence-path completeness cuts across authorization, workload identity, attestation, and systems security, DISPATCH may be useful if no single existing WG owns the problem.¶

32.5. SAAG

SAAG is an active Security Area open forum for security and privacy discussion; it is not a Working Group and does not adopt or publish documents [SAAG].¶

32.6. No Presumed Home

This document does not claim that any named group should adopt the work. The preferred sequence is technical criticism, overlap analysis, discussion in specialist groups, and routing only if a distinct interoperable work item remains justified.¶

35.1. Incomplete Path Inventory

The most important failure mode is omission of a technically viable path. Implementations SHOULD identify the evidence basis for graph completeness and SHOULD label the assurance level accordingly. An inventory derived only from documented APIs must not be treated as proof against hidden privileged or hardware paths unless the platform model supports that conclusion.¶

35.2. Consequence Under-Specification and Effect Equivalence

A mathematically complete cut for the wrong consequence does not provide the intended security property. If K is defined as one API event while another state transition, disclosure route, actuator command, or storage mutation produces an equivalent real-world consequence, that alternate effect must be incorporated into the model or explicitly excluded from the assurance claim. Implementations SHOULD document how technically distinct effects are classified as security-equivalent for the protected consequence.¶

35.3. Topology-Authority Compromise

A cut calculation proves only properties of the graph it is given. If an attacker can cause the authoritative topology representation to omit an effect-capable path, the graph can appear complete while the deployed system is bypassable. Higher-assurance profiles SHOULD authenticate topology inputs and MAY require independent evidence, attested configuration, formal deployment constraints, or separation of duties where one topology source is not sufficiently trustworthy.¶

35.4. Compromised Host

If the host OS is within the adversary model, host-resident enforcement and topology state can be modified or bypassed. High-assurance deployments must place required cut enforcement and generation state outside that trust boundary.¶

35.5. Alternate API

Legacy, undocumented, internal, local, or administrative APIs that can produce K are members of P_g(K,D) even if they are not intended for ordinary callers.¶

35.6. Queue and Worker Bypass

A queue can decouple the authorization point from commit. All producers capable of creating effectful work, and the worker-side commit path, require modeling.¶

35.7. Direct Storage or Device Access

Direct database writes, device commands, DMA, firmware actions, and storage-controller paths can bypass application enforcement. They must be blocked, included in F_g, or excluded from the prevention domain with an explicit limitation.¶

35.8. DMA and IOMMU Boundary Errors

A high-assurance hardware design can fail if the IOMMU or device assignment permits an unmodeled DMA path. Device topology and protection configuration can therefore be load-bearing topology state.¶

35.9. Debug and Recovery Interfaces

Maintenance and recovery paths often intentionally bypass normal policy. Their enablement must either advance g, be restricted to a separate assurance mode, or be included in equivalent finality enforcement.¶

35.10. Break-Glass Controls

Emergency access can be compatible with the model if it is represented as an explicit path with its own stronger authorization/finality rule. An undocumented bypass cannot simultaneously be treated as break-glass and omitted from the completeness claim.¶

35.11. Topology Drift

Service discovery, routing, firmware, deployment, orchestration, API registration, and device configuration can change the graph. Security-relevant drift must invalidate or advance the Path-Set Generation.¶

35.12. Stale Path-Set Generation

An authentic old coverage record is not evidence for a new topology. Protected monotonic generations, authenticated roots, or equivalent freshness rules are required according to the threat model.¶

35.13. Enforcement-Point Compromise

Compromise of a required cut member can turn a modeled path into a bypass. Higher-assurance deployments may use hardware isolation, multiple independent cut members, threshold decisions, or narrower trusted computing bases.¶

35.14. Distributed-Cut Inconsistency

Path-specific cut members can disagree about policy, revocation, topology generation, or act canonicalization. A concrete profile must define equivalence and fail behavior under disagreement.¶

35.15. Crash Consistency

A crash between generation verification, authority consumption, and effect commit must not create a bypass or allow replay. Transactional state, protected journals, compare-and-swap, or equivalent techniques may be required.¶

35.16. Fail-Open Behavior

Coverage or enforcement failure MUST NOT silently become authorization for operations whose profile requires prevention. Lower-assurance availability modes must be explicit and distinguishable.¶

35.17. Denial of Service

An attacker may intentionally trigger topology changes, make coverage evidence unavailable, or disable a cut member to force fail-closed behavior. Availability engineering can reduce this risk but must not silently convert unknown coverage into prevention-ready state.¶

35.18. Audit Is Not Prevention

Logging an alternate path after K occurs does not satisfy the prevention invariant. Audit can support detection, forensics, and assurance but is a different property.¶