Individual Submission S. Das
Internet-Draft Independent
Intended status: Informational 16 September 2026
Expires: 20 March 2027
When the Gate Can Be Bypassed: Consequence-Path Completeness for
Execution Finality
draft-das-consequence-path-completeness-00
Abstract
A perfectly correct authorization or security gate does not prevent a
protected consequence if the same effect remains technically
reachable through another path. High-consequence systems commonly
place authentication, authorization, policy, attestation, or
execution-finality checks at identified API, gateway, Resource
Server, operating-system, service-perimeter, or hardware boundaries.
The vulnerability examined here is therefore a coverage failure: the
protected gate can be sound while the effect can go around it. This
deserves high attention where the bypass can produce irreversible,
financial, safety-relevant, privacy-sensitive, sovereign, or mission-
critical consequences.
Existing security architecture already addresses important parts of
this problem. The reference-monitor concept requires complete
mediation, tamper resistance, and verifiability; OAuth Resource
Servers validate authorization for requests they receive; gateways,
service meshes, cloud policy systems, and service perimeters mediate
configured flows; RATS provides trust evidence for components; and
confidential-computing or hardware isolation can provide protected
enforcement locations. If any existing mechanism actually mediates
every route capable of producing the defined consequence under the
stated threat model, that deployment already satisfies the core
property described here and no additional component is required
merely for duplication.
The residual problem arises when enforcement coverage is narrower
than the consequence: for example, when an approved API hands work to
a queue or database with other ingress paths, a service perimeter
covers selected services while another interface remains effect-
capable, or a software gate coexists with administrative, recovery,
device, DMA, storage, or management-plane routes. This document
introduces a consequence-oriented execution-finality formulation: a
Protected Consequence K, an Effectuation Domain D, a generation-
indexed directed Effectuation Graph G_g, an Effectuation Path Set
P_g(K,D), a Finality Cut Set F, and a protected Path-Set Generation
g. Prevention is claimed only when removal of the valid enforcement
Das Expires 20 March 2027 [Page 1]
Internet-Draft Consequence-Path Completeness September 2026
set F disconnects every admissible source from the consequence node,
every member of F enforces an equivalent load-bearing finality
predicate, and topology changes cannot silently inherit an older
completeness claim.
Where path discovery is incomplete, enforcement is bypassable,
topology state is stale, or only selected interfaces are covered, the
mechanism is mitigation or detection rather than the same prevention
guarantee. The model is relevant to AI-agent tool execution, cloud
authorization, service meshes, financial and database commits,
operating-system and device actions, confidential computing,
accelerator/DPU/SmartNIC infrastructure, and industrial control.
Microsoft Azure Policy, Amazon Verified Permissions/Cedar, Google
Cloud VPC Service Controls, NVIDIA attestation, and Arm CCA are cited
only as complementary industrial comparison or integration points,
not as assertions of vulnerability, deficiency, non-conformance,
affiliation, or endorsement.
The proposed delta is not invention of complete mediation. It is an
explicit, testable mapping of complete-mediation reasoning to a
protected consequence across heterogeneous distributed software and
hardware paths, with coverage bound to a topology generation and to
effectuation-time finality. Criticism, corrections, counterexamples,
prior-art pointers, evidence of equivalent existing mechanisms, and
cases where path completeness cannot be established at acceptable
cost are explicitly invited.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Das Expires 20 March 2027 [Page 2]
Internet-Draft Consequence-Path Completeness September 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Vulnerability: A Correct Gate Can Protect the Wrong Amount
of the System . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Existing Solutions Already Address Important Parts . . . 7
1.3. Why the Residual Gap Can Remain . . . . . . . . . . . . . 8
1.4. What This Architecture Introduces . . . . . . . . . . . . 8
2. Conventions and Requirements Language . . . . . . . . . . . . 9
3. Direct Question: What Threat Does This Architecture Solve? . 9
4. Motivating Scenario: The Path Around the Gate . . . . . . . . 10
5. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Path-Specific Authorization Is Not Consequence-Wide
Coverage . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Complete Mediation and the Reference-Monitor Precedent . 11
5.3. Detection Is Not Prevention . . . . . . . . . . . . . . . 11
6. Threat Model and Assurance Scope . . . . . . . . . . . . . . 11
6.1. Adversary Capabilities . . . . . . . . . . . . . . . . . 11
6.2. Threat Severity and Applicability . . . . . . . . . . . . 11
6.3. Baseline Consequence-Path Profile . . . . . . . . . . . . 12
6.4. High-Assurance Consequence-Path Profile . . . . . . . . . 12
6.5. Trusted Roots and Limits . . . . . . . . . . . . . . . . 12
7. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 12
8. Prevention and Mitigation Property . . . . . . . . . . . . . 13
8.1. Prevention Profile . . . . . . . . . . . . . . . . . . . 13
8.2. Partial-Coverage Mitigation Profile . . . . . . . . . . . 13
8.3. Coverage Unknown . . . . . . . . . . . . . . . . . . . . 14
9. Existing Mechanisms and the Proposed Delta . . . . . . . . . 14
9.1. Reference Monitors and Complete Mediation . . . . . . . . 14
9.2. OAuth and Resource Servers . . . . . . . . . . . . . . . 14
9.3. Gateways, Service Meshes, and Cloud Perimeters . . . . . 14
9.4. Externalized Authorization and Policy Engines . . . . . . 15
9.5. RATS and Attestation . . . . . . . . . . . . . . . . . . 15
9.6. Protected Hardware and Confidential Computing . . . . . . 15
9.7. What Is New in This Document . . . . . . . . . . . . . . 15
10. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Consequence and Effectuation-Domain Model . . . . . . . . . . 17
12. Effectuation Graph and Path Set . . . . . . . . . . . . . . . 17
12.1. Formal Graph Components . . . . . . . . . . . . . . . . 18
Das Expires 20 March 2027 [Page 3]
Internet-Draft Consequence-Path Completeness September 2026
12.2. Path-Set Definition . . . . . . . . . . . . . . . . . . 18
12.3. Consequence Equivalence . . . . . . . . . . . . . . . . 18
12.4. Effectuation-Domain Closure . . . . . . . . . . . . . . 19
12.5. Expanded Effectuation Graph . . . . . . . . . . . . . . 19
13. Finality Cut Set . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Vertex-Cut Definition . . . . . . . . . . . . . . . . . 20
13.2. Edge-Cut Variant . . . . . . . . . . . . . . . . . . . . 21
13.3. Bypass Witness . . . . . . . . . . . . . . . . . . . . . 21
13.4. Minimum Cut Is Not Required . . . . . . . . . . . . . . 21
13.5. Valid Cut Versus Uncovered Witness Path . . . . . . . . 22
14. Formal Safety Invariant . . . . . . . . . . . . . . . . . . . 22
14.1. Cut-Set Prevention Theorem (Within the Declared
Model) . . . . . . . . . . . . . . . . . . . . . . . . 23
14.2. Reachability Formulation . . . . . . . . . . . . . . . . 23
14.3. Enforcement Validity . . . . . . . . . . . . . . . . . . 24
14.4. Coverage Record . . . . . . . . . . . . . . . . . . . . 24
14.5. Runtime Realized-Path Condition . . . . . . . . . . . . 25
14.6. Distributed-Cut Composition . . . . . . . . . . . . . . 25
14.7. Prevention-Ready Predicate . . . . . . . . . . . . . . . 25
14.8. Strict Consequence-Path Safety Invariant . . . . . . . . 25
14.9. Topology-Transition Validity . . . . . . . . . . . . . . 26
14.10. Non-Monotonicity of Coverage . . . . . . . . . . . . . . 26
14.11. Bounded Prevention Proof . . . . . . . . . . . . . . . . 27
14.12. Proof Intuition Diagram . . . . . . . . . . . . . . . . 27
15. Path-Set Generation and Topology Continuity . . . . . . . . . 28
15.1. Topology Digest and Generation Binding . . . . . . . . . 28
15.2. Security-Relevant Topology Change Classification . . . . 29
15.3. Proof of Irrelevance . . . . . . . . . . . . . . . . . . 29
15.4. Topology Drift Across Generations . . . . . . . . . . . 30
16. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 30
17. Solution Architecture . . . . . . . . . . . . . . . . . . . . 31
17.1. Define the Protected Consequence . . . . . . . . . . . . 31
17.2. Bound the Effectuation Domain . . . . . . . . . . . . . 32
17.3. Establish the Path Set . . . . . . . . . . . . . . . . . 32
17.4. Establish the Finality Cut . . . . . . . . . . . . . . . 32
17.5. Bind Coverage to a Protected Generation . . . . . . . . 32
17.6. Finalize the Candidate Act . . . . . . . . . . . . . . . 32
17.7. Runtime Enforcement Architecture . . . . . . . . . . . . 32
18. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 33
18.1. Normalize the Protected Consequence . . . . . . . . . . 33
18.2. Build the Effectuation Graph . . . . . . . . . . . . . . 33
18.3. Discover Applicable Source Vertices . . . . . . . . . . 34
18.4. Discover Candidate Cut Members . . . . . . . . . . . . . 34
18.5. Validate Cut Coverage by Reachability . . . . . . . . . 35
18.6. Extract a Human-Reviewable Bypass Witness . . . . . . . 35
18.7. Establish and Protect a Coverage Record . . . . . . . . 36
18.8. Authorize a Candidate against Current Coverage . . . . . 36
18.9. Validate the Realized Runtime Path . . . . . . . . . . . 37
Das Expires 20 March 2027 [Page 4]
Internet-Draft Consequence-Path Completeness September 2026
18.10. Protected Runtime Finalization . . . . . . . . . . . . . 38
18.11. Handle a Topology Change . . . . . . . . . . . . . . . . 39
18.12. Prove a Change Irrelevant to Consequence Reachability . 40
18.13. Evaluate a Distributed Cut . . . . . . . . . . . . . . . 41
18.14. Runtime Consequence-Path Coverage Check . . . . . . . . 41
18.15. Crash-Safe Recovery . . . . . . . . . . . . . . . . . . 42
19. Dynamic Path Introduction . . . . . . . . . . . . . . . . . . 43
20. Equivalent Distributed Enforcement . . . . . . . . . . . . . 43
21. Alternate and Hidden Path Classes . . . . . . . . . . . . . . 44
21.1. Alternate API Paths . . . . . . . . . . . . . . . . . . 44
21.2. Queues and Asynchronous Workers . . . . . . . . . . . . 44
21.3. Direct Storage Mutation . . . . . . . . . . . . . . . . 44
21.4. Administrative and Privileged Interfaces . . . . . . . . 45
21.5. Debug and Recovery Paths . . . . . . . . . . . . . . . . 45
21.6. Device, DMA, and Accelerator Paths . . . . . . . . . . . 45
21.7. Network and Management Planes . . . . . . . . . . . . . 45
21.8. Representative Path Class Matrix . . . . . . . . . . . . 45
22. Attack Analysis . . . . . . . . . . . . . . . . . . . . . . . 45
22.1. Protected API plus legacy API . . . . . . . . . . . . . 46
22.2. Queue injection . . . . . . . . . . . . . . . . . . . . 46
22.3. Direct database write . . . . . . . . . . . . . . . . . 46
22.4. Topology drift . . . . . . . . . . . . . . . . . . . . . 46
22.5. Cut member disabled . . . . . . . . . . . . . . . . . . 46
22.6. False topology evidence . . . . . . . . . . . . . . . . 46
23. Deployment Patterns . . . . . . . . . . . . . . . . . . . . . 46
23.1. Resource Server as Complete Boundary . . . . . . . . . . 46
23.2. Gateway or Service-Mesh Cut . . . . . . . . . . . . . . 47
23.3. Storage or Transaction Commit Boundary . . . . . . . . . 47
23.4. Device or Operating-System Boundary . . . . . . . . . . 47
23.5. DPU or SmartNIC Boundary . . . . . . . . . . . . . . . . 47
23.6. Distributed Cut . . . . . . . . . . . . . . . . . . . . 47
24. High-Assurance Hardware Enforcement . . . . . . . . . . . . . 47
25. Performance and Availability . . . . . . . . . . . . . . . . 49
26. Relationship to OAuth . . . . . . . . . . . . . . . . . . . . 49
27. Relationship to WIMSE . . . . . . . . . . . . . . . . . . . . 49
28. Relationship to RATS . . . . . . . . . . . . . . . . . . . . 50
29. Complementary Industrial Alignment . . . . . . . . . . . . . 50
30. Required Classes of Test Vectors . . . . . . . . . . . . . . 51
31. Questions to the IETF Community . . . . . . . . . . . . . . . 52
32. Potential IETF Discussion Venues and Scope Boundaries . . . . 53
32.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . 53
32.2. WIMSE . . . . . . . . . . . . . . . . . . . . . . . . . 53
32.3. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 53
32.4. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 54
32.5. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 54
32.6. No Presumed Home . . . . . . . . . . . . . . . . . . . . 54
33. Relationship to Other Execution-Finality Internet-Drafts . . 54
34. Public Implementations and Companion Engineering Material . . 55
Das Expires 20 March 2027 [Page 5]
Internet-Draft Consequence-Path Completeness September 2026
35. Security Considerations . . . . . . . . . . . . . . . . . . . 56
35.1. Incomplete Path Inventory . . . . . . . . . . . . . . . 56
35.2. Consequence Under-Specification and Effect
Equivalence . . . . . . . . . . . . . . . . . . . . . . 56
35.3. Topology-Authority Compromise . . . . . . . . . . . . . 56
35.4. Compromised Host . . . . . . . . . . . . . . . . . . . . 56
35.5. Alternate API . . . . . . . . . . . . . . . . . . . . . 57
35.6. Queue and Worker Bypass . . . . . . . . . . . . . . . . 57
35.7. Direct Storage or Device Access . . . . . . . . . . . . 57
35.8. DMA and IOMMU Boundary Errors . . . . . . . . . . . . . 57
35.9. Debug and Recovery Interfaces . . . . . . . . . . . . . 57
35.10. Break-Glass Controls . . . . . . . . . . . . . . . . . . 57
35.11. Topology Drift . . . . . . . . . . . . . . . . . . . . . 57
35.12. Stale Path-Set Generation . . . . . . . . . . . . . . . 58
35.13. Enforcement-Point Compromise . . . . . . . . . . . . . . 58
35.14. Distributed-Cut Inconsistency . . . . . . . . . . . . . 58
35.15. Crash Consistency . . . . . . . . . . . . . . . . . . . 58
35.16. Fail-Open Behavior . . . . . . . . . . . . . . . . . . . 58
35.17. Denial of Service . . . . . . . . . . . . . . . . . . . 58
35.18. Audit Is Not Prevention . . . . . . . . . . . . . . . . 58
36. Privacy Considerations . . . . . . . . . . . . . . . . . . . 59
37. Criticism, Corrections, and Review Invited . . . . . . . . . 59
38. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
39. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 59
40. Normative References . . . . . . . . . . . . . . . . . . . . 60
41. Informative References . . . . . . . . . . . . . . . . . . . 60
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction
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.
Das Expires 20 March 2027 [Page 6]
Internet-Draft Consequence-Path Completeness September 2026
checked path
Candidate Act -------> +-------------------+ -------+
| Protected Gate | |
| / Finality Sink | v
+-------------------+ +-------------+
| CONSEQUENCE |
+-------------+
^
|
Alternate API / queue / admin / device / DMA ----------+
no equivalent finality check
Figure 1: The path around a correct gate
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.
Das Expires 20 March 2027 [Page 7]
Internet-Draft Consequence-Path Completeness September 2026
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.
Das Expires 20 March 2027 [Page 8]
Internet-Draft Consequence-Path Completeness September 2026
* 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.
2. Conventions and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Direct Question: What Threat Does This Architecture Solve?
The threat is an authorization-bypass condition in which the
protected consequence remains technically reachable through a path
that does not preserve the security invariant enforced on the
intended path. The attacker does not necessarily forge a token,
defeat cryptography, or compromise the protected gate. The attacker
succeeds by selecting, creating, discovering, or retaining another
route to the same effect.
Das Expires 20 March 2027 [Page 9]
Internet-Draft Consequence-Path Completeness September 2026
Question:
If path A is checked correctly, but path B can create the same
consequence without an equivalent check, what was actually prevented?
Required answer for a prevention claim:
Path B must not exist inside the declared effectuation domain,
or it must cross an enforcement point with an equivalent finality
invariant before the protected consequence becomes effective.
This question is particularly important where a system has multiple
APIs, queues, administrative surfaces, storage paths, device
interfaces, hardware fabrics, control planes, or recovery mechanisms
that converge on the same state-changing or externally visible
consequence.
4. Motivating Scenario: The Path Around the Gate
Consider a protected cloud operation that modifies a high-value
resource. The normal application route passes through an
authorization service and Finality Sink. The resource can also be
modified by an administrative API, a recovery worker, or a direct
database/control-plane path.
Normal path:
Agent -> API -> Policy -> Finality Sink -> Resource mutation
Alternate path:
Agent/Operator -> Recovery worker -> Direct mutation
If the alternate path can create the same protected consequence K and
preserves no equivalent finality predicate, the normal path's correctness
is insufficient for a consequence-wide prevention claim.
Figure 2: Motivating alternate-path bypass
The same pattern can appear in payments, data release, AI tool
execution, GPU or accelerator egress, storage mutation, device
actuation, or network control. The exact components differ; the
structural question is whether the set of effect-producing paths is
completely mediated.
5. Problem Space
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.
Das Expires 20 March 2027 [Page 10]
Internet-Draft Consequence-Path Completeness September 2026
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. Threat Model and Assurance Scope
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.
Das Expires 20 March 2027 [Page 11]
Internet-Draft Consequence-Path Completeness September 2026
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.
7. Design Goals and Non-Goals
The design goal is to make the anti-bypass claim explicit, bounded,
and testable. A deployment should be able to state which consequence
is protected, what domain is covered, which paths can create that
consequence, which enforcement points cut those paths, what topology
generation was validated, and what event invalidates the claim.
This document does not define a universal network-discovery protocol,
universal program-analysis algorithm, mandatory graph encoding, new
OAuth grant type, new attestation format, new service-mesh protocol,
or universal hardware interface. It does not require one physical
Finality Sink. Distributed equivalent enforcement is permitted.
Das Expires 20 March 2027 [Page 12]
Internet-Draft Consequence-Path Completeness September 2026
The document also does not claim that exhaustive path discovery is
computable from arbitrary software. A concrete profile may rely on
authenticated configuration manifests, formal models, service
registries, device routing state, topology evidence, build-time
inventories, constrained architecture, or other mechanisms
appropriate to the bounded domain.
8. Prevention and Mitigation Property
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.
Das Expires 20 March 2027 [Page 13]
Internet-Draft Consequence-Path Completeness September 2026
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. Existing Mechanisms and the Proposed Delta
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.
Das Expires 20 March 2027 [Page 14]
Internet-Draft Consequence-Path Completeness September 2026
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.
10. Terminology
*Protected Consequence:* The external, persistent, financial,
physical, disclosure, administrative, or other effect whose
prevention property is being defined.
Das Expires 20 March 2027 [Page 15]
Internet-Draft Consequence-Path Completeness September 2026
*Effectuation Domain:* The explicitly bounded technical domain within
which path completeness is claimed.
*Effectuation Graph:* A directed graph representing effect-capable
transitions inside an Effectuation Domain for a specific protected
consequence and Path-Set Generation.
*Effectuation Path:* A technically viable directed path from an
applicable source to the point at which the Protected Consequence
first becomes effective.
*Effectuation Path Set:* The set of Effectuation Paths recognized for
the Protected Consequence within the defined domain and generation.
*Finality Cut Set:* A set of protected enforcement points whose
removal disconnects all modeled admissible sources from the
consequence node, with each member enforcing an equivalent load-
bearing finality predicate.
*Equivalent Finality Enforcement:* An enforcement mechanism that may
use different components or token formats but enforces the same
security-relevant finality predicate before effectuation.
*Path-Set Generation:* A protected generation or version identifying
the topology/configuration assumptions under which consequence-path
coverage was established.
*Coverage Proof:* Protected evidence or an authoritative statement
that a particular consequence/domain/generation satisfies the
declared cut-set and enforcement requirements. The term does not
require zero-knowledge proof or a specific cryptographic format.
*Coverage Unknown:* A state in which the system cannot establish that
the current path set remains covered by equivalent finality
enforcement.
*Candidate Act:* A proposed consequence-bearing operation that may be
computed, queued, or authorized but has not yet been permitted to
make the protected consequence effective.
*Finality Sink:* A protected functional boundary that verifies the
load-bearing finality predicate before a Candidate Act first acquires
external effect. In this document, multiple sinks can collectively
form the Finality Cut Set.
Das Expires 20 March 2027 [Page 16]
Internet-Draft Consequence-Path Completeness September 2026
11. Consequence and Effectuation-Domain Model
A completeness claim is meaningful only if K and D are explicit. If
K is defined too narrowly, an attacker may produce an equivalent
real-world effect outside the model. If D is defined too broadly,
the claim may become untestable. A concrete profile SHOULD identify
the exact state transition, disclosure, commit, transmission,
actuation, or other event that constitutes K.
Example consequence declaration:
K = "account balance for account-B is reduced by USD 100"
D = payment service + queue + ledger writer + admin API
Not sufficient:
K = "POST /transfer was accepted"
when another component can alter the same balance without using that API.
12. Effectuation Graph and Path Set
For Path-Set Generation g, model the bounded effectuation domain as a
directed graph:
G_g = (V_g, E_g)
S_g = set of applicable source vertices
k = consequence vertex or first effect transition for K
P_g(K,D) = { p | p is a technically viable directed path
from some s in S_g to k within D }
A link-level enforcement point MAY be represented by splitting an edge
into a logical enforcement vertex, so the model can use one vertex-cut
formulation for software and hardware enforcement.
The graph need not represent every implementation detail. It MUST
represent every load-bearing transition whose presence or absence can
change whether the protected consequence is reachable without
equivalent enforcement under the stated threat model.
Implementations are not required to enumerate all paths explicitly.
For a known finite graph, cut coverage can be tested using
reachability after removing the enforcement vertices, which is often
more practical than enumerating every path.
Das Expires 20 March 2027 [Page 17]
Internet-Draft Consequence-Path Completeness September 2026
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.
Das Expires 20 March 2027 [Page 18]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 19]
Internet-Draft Consequence-Path Completeness September 2026
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.
Figure 3: Expanded consequence-oriented effectuation graph
13. Finality Cut Set
Let F_g be the set of valid finality-enforcement vertices for
generation g. F_g is a valid consequence cut only if every path from
an applicable source to the consequence intersects F_g and every
intersected member enforces the required finality predicate for the
concrete Candidate Act.
API path --------------------\
Queue / worker ----------------\
Admin path ----------------------> [ FINALITY CUT SET F_g ] ---> K
Device / DMA -------------------/
Recovery path -----------------/
Every effectuation path intersects at least one valid enforcement
member. F_g need not be a minimum cut; correctness, not minimality,
is the requirement.
Figure 4: Consequence-oriented Finality Cut Set
13.1. Vertex-Cut Definition
Das Expires 20 March 2027 [Page 20]
Internet-Draft Consequence-Path Completeness September 2026
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.
Das Expires 20 March 2027 [Page 21]
Internet-Draft Consequence-Path Completeness September 2026
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
Figure 5: Valid cut versus uncovered witness path
The complete formal definitions for reachability, coverage records,
distributed cuts, generation transitions, and the bounded prevention
theorem appear in .
14. Formal Safety Invariant
Define Reach_G(X,y) as true when y is reachable in directed graph G
from any vertex in source set X. Define G_g minus F_g as the graph
obtained by removing valid enforcement vertices in F_g and their
incident edges.
Das Expires 20 March 2027 [Page 22]
Internet-Draft Consequence-Path Completeness September 2026
CutCoverage(K,D,g,F_g) :=
NOT Reach_(G_g - F_g)(S_g, k)
EnforcementValid(F_g,C,g) :=
FOR ALL f in F_g that mediates the realized path:
Protected(f,g)
AND FinalityPredicate_f(C, State_f, g) = TRUE
PreventionReady(K,D,g,F_g) :=
CutCoverage(K,D,g,F_g)
AND CoverageStateCurrent(g)
AND CutMembersNonBypassable(F_g)
AND EquivalentPredicateDefined(F_g)
Safety invariant:
Effective(K,C) =>
PreventionReady(K,D,g,F_g)
AND the realized effectuation path crossed at least one
valid member of F_g before K became effective.
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.
Das Expires 20 March 2027 [Page 23]
Internet-Draft Consequence-Path Completeness September 2026
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)
Das Expires 20 March 2027 [Page 24]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 25]
Internet-Draft Consequence-Path Completeness September 2026
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.
Das Expires 20 March 2027 [Page 26]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 27]
Internet-Draft Consequence-Path Completeness September 2026
Figure 6: Proof intuition: remove the cut and test reachability
15. Path-Set Generation and Topology Continuity
A completeness conclusion is a statement about a particular graph.
It MUST NOT silently survive a change that can alter effectuation
reachability.
Generation G17:
A ----\
B -----> [ F17 ] -----> K COMPLETE
C ----/
Topology / API / firmware / routing change
|
v
Generation G18:
A ----\
B -----> [ F17 ] -----> K
C ----/
D ---------------------> K BYPASS
Result: Coverage(G17) does not imply Coverage(G18).
Figure 7: A new path invalidates an old completeness claim
If P_g(K,D) != P_(g+1)(K,D) in a security-relevant way:
CoverageClaim(K,D,g) -/-> CoverageClaim(K,D,g+1)
The deployment MUST:
(a) re-establish coverage for g+1; or
(b) prove the change irrelevant to K; or
(c) enter COVERAGE_UNKNOWN / mitigation-only state.
A Path-Set Generation can be represented by a monotonic epoch,
authenticated topology digest, signed configuration version,
hardware-protected generation, or equivalent mechanism. This
document does not mandate one representation.
15.1. Topology Digest and Generation Binding
Das Expires 20 March 2027 [Page 28]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 29]
Internet-Draft Consequence-Path Completeness September 2026
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
Figure 8: Topology drift across three generations
16. State Machine
Das Expires 20 March 2027 [Page 30]
Internet-Draft Consequence-Path Completeness September 2026
+----------------+
| DEFINE K AND D |
+-------+--------+
|
v
+----------------+
| ESTABLISH G_g |
+-------+--------+
|
v
+----------------+
| VALID CUT F_g? |---- no ----> COVERAGE_UNKNOWN /
+---+--------+---+ MITIGATION ONLY
| ^
yes |
v | topology/path change
+----------------+
| FINALITY READY |
+-------+--------+
|
Candidate Act
|
v
+----------------+
| VERIFY AT CUT |---- fail ---> NON-EFFECTIVE
+-------+--------+
|
pass
v
+----------------+
| PROTECTED |
| COMMIT |
+-------+--------+
|
v
EFFECTIVE
Figure 9: Coverage and finality state machine
17. Solution Architecture
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.
Das Expires 20 March 2027 [Page 31]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 32]
Internet-Draft Consequence-Path Completeness September 2026
+----------------------+
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 |
+-------------------+
Figure 10: Runtime consequence-path enforcement
18. Illustrative Pseudocode
The following pseudocode is non-normative. It separates graph
construction, consequence normalization, source discovery, cut
discovery/validation, bypass-witness extraction, coverage record
issuance, runtime authorization, runtime finalization, topology-
change invalidation, distributed-cut evaluation, path-coverage
testing, and crash-safe recovery.
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
Das Expires 20 March 2027 [Page 33]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 34]
Internet-Draft Consequence-Path Completeness September 2026
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)
}
Das Expires 20 March 2027 [Page 35]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 36]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 37]
Internet-Draft Consequence-Path Completeness September 2026
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:
Das Expires 20 March 2027 [Page 38]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 39]
Internet-Draft Consequence-Path Completeness September 2026
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)
Das Expires 20 March 2027 [Page 40]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 41]
Internet-Draft Consequence-Path Completeness September 2026
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
Das Expires 20 March 2027 [Page 42]
Internet-Draft Consequence-Path Completeness September 2026
19. Dynamic Path Introduction
New paths can appear without changing the high-level application API.
Examples include a new queue consumer, new privileged endpoint,
firmware update, newly enabled DMA mapping, service-mesh bypass,
debug port, disaster-recovery tool, storage replication path,
management-plane route, or alternate network interface.
A concrete deployment SHOULD define which configuration events are
path-affecting and MUST advance or invalidate the Path-Set Generation
when such an event can change reachability to K. If the
classification cannot be made safely, the conservative result for a
high-assurance operation is COVERAGE_UNKNOWN.
Before firmware/configuration change:
Client -> API -> [F] -> Device -> K
After change:
Client -> API -> [F] -> Device -> K
\
Firmware hook ------+-------------> K
The public API is unchanged, but effectuation reachability changed.
Generation MUST advance or coverage becomes stale.
Figure 11: A hidden path introduced without changing the public API
20. Equivalent Distributed Enforcement
A single physical chokepoint is not required. Different paths can
cross different enforcement points, provided every path is cut and
the enforcement semantics are equivalent for the load-bearing
properties of K.
Path A ---> [F1] ---\
\
Path B ---> [F2] -------> K
/
Path C ---> [F3] --------/
F1, F2, and F3 may be different components.
The requirement is consequence-wide separation plus equivalent
load-bearing finality semantics, not one appliance.
Figure 12: Distributed Finality Cut Set
Das Expires 20 March 2027 [Page 43]
Internet-Draft Consequence-Path Completeness September 2026
Where several enforcement points jointly determine whether a path is
safe, the profile MUST define how their state is composed and what
happens under disagreement, partition, stale generation, or partial
failure.
Path P1:
S -> [F_authz] -> [F_safety] -> K
Path P2:
S -> [F_authz] -> [F_device] -> K
Possible rule:
Authz receipt REQUIRED
AND
(Safety receipt OR Device-enforcement receipt) REQUIRED
A single global chokepoint is unnecessary if every path
satisfies the declared distributed composition rule.
Figure 13: Distributed cut with role-separated enforcement
21. Alternate and Hidden Path Classes
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.
Das Expires 20 March 2027 [Page 44]
Internet-Draft Consequence-Path Completeness September 2026
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.
Figure 14: Representative alternate path classes
22. Attack Analysis
Das Expires 20 March 2027 [Page 45]
Internet-Draft Consequence-Path Completeness September 2026
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. Deployment Patterns
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.
Das Expires 20 March 2027 [Page 46]
Internet-Draft Consequence-Path Completeness September 2026
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.
24. High-Assurance Hardware Enforcement
When the host operating system or orchestration plane is within the
adversary model, a software-only gateway on that host cannot by
itself establish non-bypassability. The finality cut must be placed
in a protection domain the compromised host cannot rewrite, disable,
route around, or reset.
Das Expires 20 March 2027 [Page 47]
Internet-Draft Consequence-Path Completeness September 2026
Compromisable plane
+---------------------------------------------+
| Agent | App | OS | Orchestrator | Sidecar |
+----------------------+----------------------+
|
v
+-----------------------------+
| PROTECTED FINALITY CUT |
| DPU / secure service / TEE |
| device / storage controller |
| protected transaction svc |
+-------------+---------------+
|
v
PROTECTED EFFECT
Figure 15: High-assurance enforcement below a compromisable plane
Arm CCA provides hardware-enforced isolation through Realms and RME,
while NVIDIA documents attestation for GPUs and NVSwitch devices;
these are examples of protected trust substrates that may host or
supply inputs to a high-assurance cut, not claims that either
technology implements this document [ARM-CCA] [NVIDIA-ATTEST].
Compromisable plane
+---------------------------------------------------+
| Agent | API | OS | Queue | Admin | Recovery Tool |
+-----------------------+---------------------------+
|
+-----------+-----------+
| |
v v
software path direct path
| |
+-----------+-----------+
|
v
+----------------------+
| PROTECTED CUT / AFB |
| exact act |
| generation |
| current policy |
| non-bypassable commit|
+----------+-----------+
|
v
K
Das Expires 20 March 2027 [Page 48]
Internet-Draft Consequence-Path Completeness September 2026
Figure 16: Cut placement below multiple compromisable software paths
25. Performance and Availability
The graph and cut calculation are primarily control-plane operations.
Runtime enforcement SHOULD avoid recomputing the full topology for
every Candidate Act. A typical implementation can verify a protected
generation, local cut membership, exact-act binding, and finality
predicate on the hot path while topology discovery, graph
construction, and cut validation occur on configuration changes or
bounded refresh intervals.
For a known finite graph, path completeness need not require
enumerating every path. Removing F_g and running a reachability
search from S_g to k is sufficient to test the cut property in the
model. Incremental reachability or dependency tracking can further
reduce the cost of revalidation after localized changes.
Fail-closed coverage can create availability pressure. A deployment
MAY define lower-assurance bounded-staleness or mitigation profiles
for lower-consequence operations, but MUST NOT describe them as
equivalent to a current high-assurance prevention claim.
26. Relationship to OAuth
OAuth is directly relevant because access tokens and Resource Servers
define a widely deployed authorization boundary. RFC 9700 requires
per-request audience/resource/action restriction at Resource Servers
[RFC9700].
The OAuth WG is active and its current charter includes complex
delegation for automated agents [OAUTH-CHARTER].
This document does not alter OAuth token semantics. It asks a
deployment question: is the Resource Server the actual complete
consequence boundary, or does the authorized request later enter a
system with additional effect-capable paths? If the former, OAuth
enforcement may already satisfy the cut property. If the latter, the
downstream consequence domain must be modeled separately.
27. Relationship to WIMSE
WIMSE is active and focuses on workload identity and least-privilege
authorization across multi-service environments, including multi-hop,
long-lived, and asynchronous transactions [WIMSE-CHARTER].
Das Expires 20 March 2027 [Page 49]
Internet-Draft Consequence-Path Completeness September 2026
Consequence-path completeness is complementary: identity/security
context can follow the workload chain while the path model asks
whether every route to the final protected effect intersects
equivalent enforcement. The draft does not propose new workload-
identity formats.
28. Relationship to RATS
RATS defines roles and artifacts including Evidence, Attestation
Results, Endorsements, Reference Values, and appraisal policies
[RFC9334].
A RATS deployment can provide evidence that a cut member or topology
collector is in an expected state. This document does not treat
attestation as consequence authorization by itself. It uses
attestation, where appropriate, to strengthen confidence in
enforcement and topology inputs.
29. Complementary Industrial Alignment
Microsoft Azure Policy documents a deny effect that can prevent non-
compliant Resource Manager requests before they are sent to the
Resource Provider [AZURE-POLICY].
Amazon Verified Permissions externalizes fine-grained authorization
decisions for principal, action, resource, and context using Cedar
policies [AWS-AVP].
Google Cloud VPC Service Controls provides service perimeters and
explicitly recommends protecting applicable services because leaving
APIs unprotected increases potential exfiltration vectors
[GOOGLE-VPCSC].
NVIDIA documents attestation evidence collection for GPUs and
NVSwitch devices, and Arm CCA provides hardware-enforced
confidential-computing isolation [NVIDIA-ATTEST] [ARM-CCA].
These examples demonstrate industrial attention to preventive policy
enforcement, service coverage, trust evidence, and protected compute.
They are cited as comparison or potential integration points only.
This document does not assert that any named product is insecure,
incomplete, vulnerable, non-conforming, or required to implement this
architecture. A particular deployment may already satisfy some or
all of the proposed invariant.
Das Expires 20 March 2027 [Page 50]
Internet-Draft Consequence-Path Completeness September 2026
30. Required Classes of Test Vectors
A concrete profile or implementation SHOULD test at least the
following classes:
* single path, valid cut member, current generation: effect
succeeds;
* two paths, both crossing equivalent cut members: effect succeeds
on either after valid finality;
* alternate API path that does not cross F_g: coverage establishment
fails and prevention is not claimed;
* new path introduced after coverage generation: prior coverage
record is rejected or moved to COVERAGE_UNKNOWN;
* queue producer bypass: direct job injection is rejected or the
queue/worker commit is separately mediated;
* direct storage mutation attempt: blocked by storage/transaction
cut or explicitly shown outside the assurance domain;
* cut member compromised or disabled inside the declared threat
model: prevention profile fails closed;
* stale topology evidence: coverage record rejected;
* distributed cut with one valid path-specific enforcement member:
succeeds;
* distributed cut disagreement or missing required receipt: fails
closed;
* debug/recovery path enabled without generation change: treated as
a test failure;
* effect created outside declared D: reported as outside the formal
prevention claim, not falsely counted as covered.
For graph-oriented implementations, test vectors SHOULD include both
positive and negative reachability cases and SHOULD preserve at least
one concrete witness path for every expected coverage failure.
Das Expires 20 March 2027 [Page 51]
Internet-Draft Consequence-Path Completeness September 2026
31. Questions to the IETF Community
Criticism, corrections, counterexamples, operational experience,
prior-art pointers, evidence of existing equivalent mechanisms, and
recommendations to narrow or merge the work are explicitly invited.
Negative answers are useful outcomes.
1. Does the classical reference-monitor/complete-mediation model
already express the proposed property fully, making a separate
consequence-path abstraction unnecessary?
2. Does any existing IETF protocol define an interoperable way to
establish that every path capable of producing a specified
consequence is mediated by an equivalent authorization/finality
invariant?
3. In OAuth deployments, when is the Resource Server itself a
complete consequence boundary, and when does a later queue,
database, device, payment rail, or downstream workload become
the real effectuation boundary?
4. Is a Finality Cut Set a useful abstraction for distributed
enforcement, or should the document use existing reference-
monitor terminology only?
5. How should an implementation define the Effectuation Domain
tightly enough that a prevention claim is testable rather than
aspirational?
6. Can path-set completeness be established without automated path
enumeration using configuration manifests, topology evidence,
formal models, service inventories, hardware routing state, or
operational certification?
7. Which events should advance the Path-Set Generation: API
registration, routing changes, firmware updates, queue changes,
administrative-interface changes, device-topology changes, or
other events?
8. How should emergency, break-glass, recovery, and maintenance
paths be represented without making the completeness claim
meaningless?
9. How should equivalently strong distributed enforcement be
demonstrated when paths do not converge on one physical Finality
Sink?
Das Expires 20 March 2027 [Page 52]
Internet-Draft Consequence-Path Completeness September 2026
10. Which real systems already provide the full property? Reviewers
are invited to identify the system and the precise consequence
boundary it protects.
11. Which deployment classes are inherently only mitigation because
complete path coverage cannot be established?
12. What performance or operational costs would make revalidation
after topology-generation changes impractical?
13. Is the problem better treated as a BCP or security-architecture
document than as a new wire protocol?
14. Is OAuth, WIMSE, RATS, DISPATCH, SAAG, or another venue the
appropriate place for further discussion?
15. What counterexample would falsify or materially narrow the
proposed model?
32. Potential IETF Discussion Venues and Scope Boundaries
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.
Das Expires 20 March 2027 [Page 53]
Internet-Draft Consequence-Path Completeness September 2026
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.
33. Relationship to Other Execution-Finality Internet-Drafts
The broader execution-finality family addresses different failure
surfaces. This document is intended to isolate path completeness
rather than repeat those drafts.
* The protocol-layer draft defines the broad Candidate Act ->
protected validation -> scoped authority -> Finality Sink
architecture.
* The agentic draft applies execution finality to AI tool dispatch.
* The hardware-rooted draft places enforcement at protected
boundaries for high-consequence infrastructure.
* The RATS/attestation-bound draft connects trusted workload state
to exact consequential authority.
* The state/policy-continuity draft asks whether the decision basis
remains applicable between approval and effectuation.
* The finality-bound-revocation draft asks whether authority
withdrawn before effectuation can survive to protected commit.
Das Expires 20 March 2027 [Page 54]
Internet-Draft Consequence-Path Completeness September 2026
* The purpose-execution-finality draft addresses purpose/capability
laundering and cross-domain data reuse.
* The AI-interoperability draft applies bounded finality to third-
party AI/device interoperability.
* This document asks whether the protected consequence can avoid all
of those checks through another effectuation path.
State continuity: Is the authorization basis still applicable?
Revocation finality: Has authority been withdrawn before effectuation?
Consequence completeness: Can the effect avoid those checks entirely
through another path?
Current and companion documents referenced in this comparison include
[DAS-PROTOCOL], [DAS-AGENTIC], [DAS-HARDWARE], [DAS-RATS],
[DAS-STATE], [DAS-REVOCATION], [DAS-PURPOSE], and [DAS-INTEROP].
34. Public Implementations and Companion Engineering Material
The following public repositories provide related engineering
material. They are cited as companion implementations of execution-
finality concepts, not as proof that arbitrary deployments already
satisfy the path-set-generation model in this document.
* Execution-Finality Architecture for Machine-Generated Acts:
architectural background including anti-bypass and Finality Sink
concepts.
* Hardened Challenge-Bound Execution Finality for AI
Interoperability: runnable exact-effect binding, current
policy/epoch/revocation checks, fresh sink challenge, replay
protection, and atomic/single-use finality at selected sinks.
* Secure and Privacy-Preserving AI Interoperability for Third-Party
Tools: predecessor implementation of Candidate Act, Non-Effective
State, protected validation, scoped capability, and Finality Sink
concepts.
* Execution Finality for GPUs, AI Accelerators, and Confidential
Workloads: runnable bounded HTTP transfer profile plus broader
accelerator/confidential-compute architecture.
None of these references is represented here as a universal automatic
path-discovery implementation. A future path-completeness profile
would require explicit topology/path-set integration and
corresponding test vectors.
Das Expires 20 March 2027 [Page 55]
Internet-Draft Consequence-Path Completeness September 2026
The companion public engineering materials are [GH-ARCH],
[GH-HARDENED], [GH-INTEROP], and [GH-GPU].
35. Security Considerations
The security claim depends simultaneously on graph fidelity, cut
coverage, finality-enforcement integrity, and topology-generation
freshness. A strong finality predicate at one gate provides no
consequence-wide prevention if the graph omits an effect-capable
route; a perfect graph provides no protection if a cut member can be
bypassed or disabled under the threat model.
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.
Das Expires 20 March 2027 [Page 56]
Internet-Draft Consequence-Path Completeness September 2026
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.
Das Expires 20 March 2027 [Page 57]
Internet-Draft Consequence-Path Completeness September 2026
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.
Das Expires 20 March 2027 [Page 58]
Internet-Draft Consequence-Path Completeness September 2026
36. Privacy Considerations
Path and topology inventories can reveal sensitive architecture,
service relationships, administrative interfaces, device assignments,
trust boundaries, recovery mechanisms, and operational timing. A
portable Coverage Proof SHOULD disclose only the information required
for the relying enforcement decision.
Implementations can use scoped topology digests, authenticated roots,
selective disclosure, local protected verification, or domain-
specific commitments rather than publishing full internal graphs.
Stable topology identifiers can themselves become correlators and
should be scoped where possible.
37. Criticism, Corrections, and Review Invited
This document is intentionally presented for adversarial technical
review. Reviewers are invited to identify incorrect assumptions,
existing standards or products that already provide the full
property, cases where reference-monitor terminology makes the new
abstraction unnecessary, effectuation paths omitted from the model,
impossible or impractical topology requirements, performance costs,
privacy costs, or terminology that conflicts with established IETF
usage.
Concrete counterexamples are especially useful. Evidence that an
existing Resource Server, service perimeter, reference monitor,
hardware boundary, or distributed architecture already guarantees the
same consequence-wide invariant should be used to narrow, merge, or
correct this proposal rather than ignored.
38. IANA Considerations
This document has no IANA actions.
39. Conclusion
A correct authorization decision is not a consequence-wide prevention
guarantee when the protected effect has another route around the
decision point. The classical reference-monitor principle already
teaches that security-relevant access must be completely mediated.
This document applies that principle to a bounded consequence across
distributed software and hardware effectuation paths and makes the
coverage claim generation-specific.
Das Expires 20 March 2027 [Page 59]
Internet-Draft Consequence-Path Completeness September 2026
CORRECT GATE
+
WRONG COVERAGE
=
BYPASS REMAINS POSSIBLE
For prevention inside D:
every path to K
-> intersects valid finality enforcement
-> under current path-set generation
-> before K becomes effective
If an existing architecture already provides those properties, it
already satisfies the core invariant. Where coverage is incomplete
or unprovable, the appropriate claim is mitigation or detection. The
purpose of this draft is to make that distinction explicit, testable,
and open to standards review.
A practical implementation should be able to answer not merely
"coverage failed" but "which source-to-consequence witness path
bypassed the declared cut, under which topology generation, and which
change invalidated the prior coverage claim." That diagnostic
property is central to making consequence-path completeness
reviewable rather than aspirational.
40. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, May 2017,
.
41. Informative References
[ARM-CCA] Arm, "Arm Confidential Compute Architecture", 2026,
.
[AWS-AVP] Amazon Web Services, "Amazon Verified Permissions
Documentation", 2026,
.
Das Expires 20 March 2027 [Page 60]
Internet-Draft Consequence-Path Completeness September 2026
[AZURE-POLICY]
Microsoft, "Azure Policy definitions: deny effect", 2026,
.
[DAS-AGENTIC]
Das, S., "Tool Selection Is Not Execution: Finality for
Agentic Tool Dispatch in High-Risk AI Systems", Work in
Progress, Internet-Draft, draft-das-agentic-execution-
finality-02, August 2026,
.
[DAS-HARDWARE]
Das, S., "Computation Is Not Authority: Hardware-Enforced
Execution-Finality for Agentic AI, MCP Tool Calls, and
Industrial Agents", Work in Progress, Internet-Draft,
draft-das-hardware-enforced-execution-finality-02, August
2026, .
[DAS-INTEROP]
Das, S., "Secure and Privacy-Preserving AI
Interoperability under Article 6(7) of the European
Digital Markets Act: An Execution-Finality Architecture",
Work in Progress, Internet-Draft, draft-das-execution-
finality-ai-interoperability-04, September 2026,
.
[DAS-PROTOCOL]
Das, S., "The Missing Execution-Finality Protocol Layer of
the Internet", Work in Progress, Internet-Draft, draft-
das-execution-finality-protocol-layer-00, August 2026,
.
[DAS-PURPOSE]
Das, S., "Data-Purpose Laundering Prevention: Execution-
Finality for Preventing Cross-Domain Data Reuse", Work in
Progress, Internet-Draft, draft-das-purpose-execution-
finality-03, September 2026,
.
[DAS-RATS] Das, S., "Attestation-Bound Execution Finality for GPU, AI
Accelerator, DPU, SmartNIC, and Confidential-Computing
Infrastructure", Work in Progress, Internet-Draft, draft-
Das Expires 20 March 2027 [Page 61]
Internet-Draft Consequence-Path Completeness September 2026
das-rats-attestation-bnd-execution-finality-04, September
2026, .
[DAS-REVOCATION]
Das, S., "Revoked but Still Executable: Closing the
Authorization-to-Effect Gap with Finality-Bound
Revocation", Work in Progress, Internet-Draft, draft-das-
finality-bound-revocation-00, September 2026,
.
[DAS-STATE]
Das, S., "When Valid Authorization Becomes Stale: State
and Policy Continuity at the Execution-Finality Boundary",
Work in Progress, Internet-Draft, draft-das-state-policy-
continuity-finality-00, September 2026,
.
[DISPATCH-CHARTER]
IETF, "Dispatch Working Group Charter", July 2026,
.
[GH-ARCH] Das, S., "Execution-Finality Architecture for Machine-
Generated Acts", 2026, .
[GH-GPU] Das, S., "Execution Finality for GPUs, AI Accelerators,
and Confidential Workloads", 2026,
.
[GH-HARDENED]
Das, S., "Hardened Challenge-Bound Execution Finality for
AI Interoperability", 2026, .
[GH-INTEROP]
Das, S., "Secure and Privacy-Preserving AI
Interoperability for Third-Party Tools", 2026,
.
Das Expires 20 March 2027 [Page 62]
Internet-Draft Consequence-Path Completeness September 2026
[GOOGLE-VPCSC]
Google Cloud, "Design and architect service perimeters —
VPC Service Controls", 2026,
.
[NIST-RM] National Institute of Standards and Technology,
"Engineering Trustworthy Secure Systems, NIST SP 800-160
Vol. 1 Rev. 1", November 2022,
.
[NVIDIA-ATTEST]
NVIDIA, "NVIDIA Attestation SDK — GPU and Switch
Attestation", 2026, .
[OAUTH-CHARTER]
IETF, "Web Authorization Protocol (OAuth) Working Group
Charter", June 2026,
.
[RFC9334] IETF, "Remote ATtestation procedureS (RATS) Architecture",
RFC 9334, January 2023,
.
[RFC9700] IETF, "Best Current Practice for OAuth 2.0 Security",
RFC 9700, January 2025,
.
[RFC9711] IETF, "The Entity Attestation Token (EAT)", RFC 9711,
April 2025, .
[SAAG] IETF, "Security Area Open Meeting (SAAG)", 2026,
.
[WIMSE-CHARTER]
IETF, "Workload Identity in Multi System Environments
Working Group Charter", March 2026,
.
Author's Address
Das Expires 20 March 2027 [Page 63]
Internet-Draft Consequence-Path Completeness September 2026
Sangam Das
Independent
Balasore
Odisha
India
Phone: +91-9861363532
Email: info@sangamdas.com
Das Expires 20 March 2027 [Page 64]