Individual Submission S. Das
Internet-Draft Independent Inventor
Intended status: Informational 22 October 2026
Expires: 25 April 2027
Protected Execution Finality for Sandboxed AI Agents, Credential
Mediation, Process Lineage, and Network Egress
draft-das-sandbox-credential-egress-finality-00
Abstract
This informational document describes future-oriented execution-
finality profiles for sandboxed autonomous AI agents, protected host
services, credential brokers, external connectors, process-lineage
restrictions, proxy-mediated network egress, native resources, and
downstream effectuation interfaces. It examines sandbox versus
authority separation, protected credential use, destination binding
after DNS resolution, operation-specific validation, influence
tracking, bypass-path completeness, replay restrictions, recovery and
independent sink verification. It distinguishes possession of
sandbox or proxy permissions from authority for a particular actual
resource effect. Source-derived procedures, tests and algorithms are
presented as implementation examples, not as evidence that identified
vendors implement this proposed architecture.
Industry Relevance: Recent public developments in autonomous AI-agent
security and execution governance include Microsoft Execution
Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030
(Action-Bound, Fail-Closed Approval Protocol), and Project
Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel
AI-Agent Security Architecture; NVIDIA OpenShell Reference
Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK,
and Responses API; and Anthropic Claude Managed Agents, Claude Code
Sandboxing, and Claude Code Auto Mode. These initiatives illustrate
industry attention to agent isolation, independent policy
enforcement, action-bound authorization, delegated authority,
credential isolation, network-egress security, hardware-assisted
containment, runtime supervision, and fail-closed controls. This
draft describes related proposed execution-finality mechanisms
without asserting that these initiatives implement them.
Das Expires 25 April 2027 [Page 1]
Internet-Draft Sandbox Credential Egress Finality October 2026
Relevance to the IETF: the mechanisms described here require common,
interoperable objects and verification semantics across independently
built components, including operation descriptors, act-bound non-
bearer capabilities, finality-sink verification results, validation
evidence, and authority, revocation, and containment generations.
The document relates to existing IETF work on OAuth, GNAP, RATS,
WIMSE, and SCITT, and asks the community whether and where this
effectuation-boundary problem should be addressed.
This document is intentionally long and is not repetitive: each
profile specifies a distinct mechanism with its own algorithms,
failure cases, and enforcement points, and the security properties
depend on how these mechanisms combine. A reduced excerpt would hide
the conditions under which they fail closed, so this document and its
two companion drafts, among which the profiles are divided, are meant
to be evaluated as a whole.
This draft builds on earlier Internet-Drafts by the same author, in
particular draft-das-agent-execution-finality, and adds mechanism
families not described there; the Introduction states precisely what
was disclosed earlier and what is disclosed here.
IPR: The technical content of this draft set is based upon the
author's international application PCT/IB2026/055615, which forms the
foundation of this disclosure and comprises approximately 300
distinct, non-repetitive embodiments and enforcement points. A
separate patent application specific to the material in this draft
set has also been filed. Related Indian applications: 202531130665,
202631000572, 202631001586, 202631002990, 202631124028, and
202631125689. Related international applications: PCT/IB2025/058316,
PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/
IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/
IB2026/056941. These identify related technical disclosures; not all
described mechanisms are necessarily patent-claimed or granted, and
patent scope and priority depend on applicable law and examination.
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/.
Das Expires 25 April 2027 [Page 2]
Internet-Draft Sandbox Credential Egress Finality October 2026
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 25 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 39
1.1. This Document Is Intentionally Long . . . . . . . . . . . 40
1.2. Document Set and Cross-References . . . . . . . . . . . . 41
1.3. Profile Map . . . . . . . . . . . . . . . . . . . . . . . 42
1.4. Relationship to Earlier Internet-Drafts . . . . . . . . . 45
1.4.1. What the Earlier Drafts Disclosed . . . . . . . . . . 45
1.4.2. What This Draft Set Discloses . . . . . . . . . . . . 47
2. IPR and Related Patent Disclosures . . . . . . . . . . . . . 50
2.1. Related Indian Patent Disclosures and Claimed Priority . 50
2.2. Related International Patent Applications and WIPO
Publications . . . . . . . . . . . . . . . . . . . . . . 50
2.3. Scope and Priority Qualifications . . . . . . . . . . . . 51
3. Problem Statement and Security Objectives . . . . . . . . . . 51
3.1. General Problem . . . . . . . . . . . . . . . . . . . . . 51
3.2. Specific Problems . . . . . . . . . . . . . . . . . . . . 52
3.3. Primary Focus of This Draft . . . . . . . . . . . . . . . 56
3.4. Security Objectives . . . . . . . . . . . . . . . . . . . 57
4. Relevance to the IETF . . . . . . . . . . . . . . . . . . . . 57
4.1. Why This Is IETF Work . . . . . . . . . . . . . . . . . . 57
4.2. Relationship to Existing IETF Work . . . . . . . . . . . 58
4.3. What the Community Is Asked to Evaluate . . . . . . . . . 58
5. Industry Alignment and Technical Relevance . . . . . . . . . 59
6. Scope and Terminology . . . . . . . . . . . . . . . . . . . . 59
6.1. Technology-Neutral Architectural Definitions . . . . . . 60
6.2. General Interpretation . . . . . . . . . . . . . . . . . 65
6.3. Execution Environments and Sandbox Architectures . . . . 66
6.4. Operations, Effects, and Effectuation Boundaries . . . . 70
6.5. Protected Domains and Execution Authority . . . . . . . . 75
Das Expires 25 April 2027 [Page 3]
Internet-Draft Sandbox Credential Egress Finality October 2026
6.6. Algorithmic and Runtime Verification . . . . . . . . . . 80
7. Source-Derived Technical Implementation Profiles . . . . . . 82
7.1. Implementation Profile S-1 . . . . . . . . . . . . . . . 83
7.1.1. S-1.1 - Technical Field . . . . . . . . . . . . . . . 83
7.1.2. S-1.2 - Technical Problem . . . . . . . . . . . . . . 83
7.1.3. S-1.3 - Technical Objective . . . . . . . . . . . . . 84
7.1.4. S-1.4 - System Architecture . . . . . . . . . . . . . 85
7.1.5. Component A - Physical or Virtualized Computing
Host . . . . . . . . . . . . . . . . . . . . . . . . 85
7.1.6. Component B - Virtualization Manager . . . . . . . . 85
7.1.7. Component C - Agent Virtual Machine . . . . . . . . . 85
7.1.8. Component D - Candidate Act Interceptor . . . . . . . 85
7.1.9. Component E - Non-Effective Operation Holder . . . . 85
7.1.10. Component F - Protected Enforcement Domain . . . . . 85
7.1.11. Component G - Protected Validation Evidence Store . . 85
7.1.12. Component H - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 86
7.1.13. Component I - Finality Sink . . . . . . . . . . . . . 86
7.1.14. Component J - Effect-Capable Resource . . . . . . . . 86
7.1.15. S-1.5 - Reference Deployment Arrangement . . . . . . 86
7.1.16. Agent VM → Controlled Operation Interface → Candidate
Act Holding State → PED . . . . . . . . . . . . . . . 86
7.1.17. Validation → Protected Evidence and Capability →
Finality Sink Verification → Effect-Capable Resource 87
7.1.18. S-1.6 - Virtual-Machine Configuration and
Isolation . . . . . . . . . . . . . . . . . . . . . . 87
7.1.19. S-1.6.1 - Guest-to-host trust assumption . . . . . . 88
7.1.20. S-1.6.2 - Isolation limitation . . . . . . . . . . . 88
7.1.21. S-1.7 - Candidate Act Generation and Interception . . 88
7.1.22. S-1.7.1 - Interception before consequential effect . 89
7.1.23. S-1.8 - Non-Effective State Implementation . . . . . 89
7.1.24. S-1.8.1 - Immutable operation snapshot . . . . . . . 90
7.1.25. S-1.9 - Candidate Act Descriptor . . . . . . . . . . 91
7.1.26. Field . . . . . . . . . . . . . . . . . . . . . . . . 91
7.1.27. Technical purpose . . . . . . . . . . . . . . . . . . 91
7.1.28. S-1.10 - Protected Enforcement Domain Operation . . . 92
7.1.29. S-1.10.1 - Protected authority-state acquisition . . 92
7.1.30. S-1.10.2 - State-consistency verification . . . . . . 93
7.1.31. S-1.11 - Protected Validation Evidence . . . . . . . 93
7.1.32. S-1.11.1 - Evidence generation alternatives . . . . . 94
7.1.33. S-1.11.2 - Required evidence ordering . . . . . . . . 94
7.1.34. S-1.12 - Scoped Non-Bearer Finality Capability . . . 95
7.1.35. S-1.12.1 - Software implementation . . . . . . . . . 95
7.1.36. S-1.12.2 - Cryptographic implementation . . . . . . . 96
7.1.37. S-1.12.3 - Hardware implementation . . . . . . . . . 96
7.1.38. S-1.13 - Finality Sink Implementation . . . . . . . . 96
7.1.39. S-1.13.1 - Independent operation correspondence . . . 97
7.1.40. S-1.13.2 - Finality Sink verification predicates . . 97
Das Expires 25 April 2027 [Page 4]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.41. S-1.14 - Sink-Local Protected State . . . . . . . . . 97
7.1.42. S-1.14.1 - Single-use consumption . . . . . . . . . . 98
7.1.43. S-1.14.2 - Concurrent verification . . . . . . . . . 98
7.1.44. S-1.15 - Principal Successful Execution Workflow . . 99
7.1.45. Step S1 - Agent initialization . . . . . . . . . . . 99
7.1.46. Step S2 - Tool execution request . . . . . . . . . . 99
7.1.47. Step S3 - Boundary interception . . . . . . . . . . . 99
7.1.48. Step S4 - Candidate Act creation . . . . . . . . . . 99
7.1.49. Step S5 - Non-effective staging . . . . . . . . . . . 99
7.1.50. Step S6 - Descriptor canonicalization . . . . . . . . 99
7.1.51. Step S7 - Protected-domain submission . . . . . . . . 99
7.1.52. Step S8 - Authority-state retrieval . . . . . . . . . 99
7.1.53. Step S9 - Authorization evaluation . . . . . . . . . 100
7.1.54. Step S10 - Validation evidence commitment . . . . . . 100
7.1.55. Step S11 - Capability activation . . . . . . . . . . 100
7.1.56. Step S12 - Finality Sink presentation . . . . . . . . 100
7.1.57. Step S13 - Actual pending operation reconstruction . 100
7.1.58. Step S14 - Capability and evidence verification . . . 100
7.1.59. Step S15 - Atomic authorization-state transition . . 100
7.1.60. Step S16 - Effectuation . . . . . . . . . . . . . . . 100
7.1.61. Step S17 - Completion observation . . . . . . . . . . 100
7.1.62. Step S18 - State reconciliation . . . . . . . . . . . 101
7.1.63. S-1.16 - Reference Enforcement Algorithm . . . . . . 101
7.1.64. Algorithm S1-A - Candidate Act Admission . . . . . . 101
7.1.65. Algorithm S1-B - PED Authorization . . . . . . . . . 101
7.1.66. Algorithm S1-C - Finality Sink Verification . . . . . 102
7.1.67. S-1.17 - Worked Technical Example: Agent-Originated
Payment-Beneficiary Modification . . . . . . . . . . 102
7.1.68. S-1.17.1 - Authorized variation . . . . . . . . . . . 103
7.1.69. S-1.18 - Failure and Adversarial Cases . . . . . . . 103
7.1.70. Case F1 - Guest operating-system compromise . . . . . 104
7.1.71. Case F2 - Agent instruction injection . . . . . . . . 104
7.1.72. Case F3 - Operation substitution . . . . . . . . . . 104
7.1.73. Case F4 - Capability replay . . . . . . . . . . . . . 104
7.1.74. Case F5 - Stale authority generation . . . . . . . . 105
7.1.75. Case F6 - PED unavailable . . . . . . . . . . . . . . 105
7.1.76. Case F7 - Finality Sink unavailable . . . . . . . . . 105
7.1.77. Case F8 - Network redirection . . . . . . . . . . . . 105
7.1.78. Case F9 - Concurrent replay attempts . . . . . . . . 106
7.1.79. Case F10 - Snapshot rollback . . . . . . . . . . . . 106
7.1.80. Case F11 - Alternate network adapter . . . . . . . . 106
7.1.81. Case F12 - Host compromise . . . . . . . . . . . . . 106
7.1.82. Case F13 - External execution with uncertain
result . . . . . . . . . . . . . . . . . . . . . . . 107
7.1.83. Case F14 - Canonicalization discrepancy . . . . . . . 107
7.1.84. S-1.19 - Virtual-Machine Migration and Resume . . . . 107
7.1.85. S-1.20 - Software-Only, Hardware-Assisted, and Hybrid
Variations . . . . . . . . . . . . . . . . . . . . . 108
Das Expires 25 April 2027 [Page 5]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.86. S-1.20.1 - Software-only variation . . . . . . . . . 108
7.1.87. S-1.20.2 - TEE-assisted variation . . . . . . . . . . 108
7.1.88. S-1.20.3 - HSM-assisted variation . . . . . . . . . . 108
7.1.89. S-1.20.4 - SmartNIC/DPU variation . . . . . . . . . . 109
7.1.90. S-1.20.5 - Hypervisor enforcement variation . . . . . 109
7.1.91. S-1.20.6 - Distributed PED and sink variation . . . . 109
7.1.92. S-1.20.7 - Integrated PED and sink variation . . . . 110
7.1.93. S-1.21 - Optional ALF, AIF, and RBD Integration . . . 110
7.1.94. S-1.21.1 - ALF verification . . . . . . . . . . . . . 110
7.1.95. S-1.21.2 - AIF verification . . . . . . . . . . . . . 110
7.1.96. S-1.21.3 - RBD verification . . . . . . . . . . . . . 110
7.1.97. S-1.21.4 - Optionality . . . . . . . . . . . . . . . 111
7.1.98. S-1.22 - Implementation Data Structures . . . . . . . 111
7.1.99. A. VMContextRecord . . . . . . . . . . . . . . . . . 111
7.1.100. B. CandidateActRecord . . . . . . . . . . . . . . . 111
7.1.101. C. ValidationEvidenceRecord . . . . . . . . . . . . 112
7.1.102. D. FinalityCapabilityRecord . . . . . . . . . . . . 112
7.1.103. E. SinkStateRecord . . . . . . . . . . . . . . . . 112
7.1.104. F. EffectPathRegistry . . . . . . . . . . . . . . . 113
7.1.105. S-1.23 - Verification and Test Procedures . . . . . 113
7.1.106. Test T1 - Authorized operation . . . . . . . . . . . 113
7.1.107. Test T2 - Missing capability . . . . . . . . . . . . 113
7.1.108. Test T3 - Replay . . . . . . . . . . . . . . . . . . 113
7.1.109. Test T4 - Descriptor mismatch . . . . . . . . . . . 114
7.1.110. Test T5 - Authority revocation . . . . . . . . . . . 114
7.1.111. Test T6 - Alternate egress . . . . . . . . . . . . . 114
7.1.112. Test T7 - Guest privilege escalation . . . . . . . . 114
7.1.113. Test T8 - Concurrent capability use . . . . . . . . 114
7.1.114. Test T9 - Snapshot restoration . . . . . . . . . . . 114
7.1.115. Test T10 - PED outage . . . . . . . . . . . . . . . 115
7.1.116. Test T11 - Sink outage . . . . . . . . . . . . . . . 115
7.1.117. Test T12 - Host compromise assumption . . . . . . . 115
7.1.118. Test T13 - Canonicalization ambiguity . . . . . . . 115
7.1.119. Test T14 - Uncertain external result . . . . . . . . 115
7.1.120. S-1.24 - Technical Effect and Relationship to Other
Embodiments . . . . . . . . . . . . . . . . . . . . . 115
7.1.121. S-1.25 - Enablement Boundaries and Implementation
Requirements . . . . . . . . . . . . . . . . . . . . 116
7.1.122. S-1.26 - Summary of the Representative Embodiment . 117
7.2. Implementation Profile S-2 . . . . . . . . . . . . . . . 118
7.2.1. S-2.1 - Technical Field . . . . . . . . . . . . . . . 118
7.2.2. S-2.2 - Technical Problem . . . . . . . . . . . . . . 118
7.2.3. S-2.3 - Technical Objectives . . . . . . . . . . . . 119
7.2.4. PART I - SYSTEM ARCHITECTURE . . . . . . . . . . . . 120
7.2.5. S-2.4 - Principal Components . . . . . . . . . . . . 120
7.2.6. Component A - Physical or Virtualized Host . . . . . 120
7.2.7. Component B - Micro-VM Manager . . . . . . . . . . . 120
7.2.8. Component C - Ephemeral Agent Micro-VM . . . . . . . 121
Das Expires 25 April 2027 [Page 6]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.9. Component D - Execution-Generation Controller . . . . 121
7.2.10. Component E - Controlled Micro-VM Communication
Interface . . . . . . . . . . . . . . . . . . . . . . 121
7.2.11. Component F - Candidate Act Capture and Staging
Controller . . . . . . . . . . . . . . . . . . . . . 121
7.2.12. Component G - Protected Enforcement Domain . . . . . 121
7.2.13. Component H - Protected Validation Evidence
Controller . . . . . . . . . . . . . . . . . . . . . 122
7.2.14. Component I - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 122
7.2.15. Component J - Finality Sink . . . . . . . . . . . . . 122
7.2.16. Component K - Outstanding Operation Registry . . . . 122
7.2.17. Component L - Lifecycle Reconciliation Controller . . 122
7.2.18. S-2.5 - Reference Micro-VM Deployment . . . . . . . . 122
7.2.19. S-2.5.1 - Logical arrangement . . . . . . . . . . . . 123
7.2.20. Agent Orchestrator . . . . . . . . . . . . . . . . . 123
7.2.21. Micro-VM Manager and Execution-Generation
Controller . . . . . . . . . . . . . . . . . . . . . 123
7.2.22. Ephemeral Agent Micro-VM . . . . . . . . . . . . . . 123
7.2.23. Controlled Virtual Device / Communication Channel . . 123
7.2.24. Candidate Act Capture and Non-Effective Staging . . . 123
7.2.25. PED - Protected Validation and Evidence Commitment . 123
7.2.26. Scoped Non-Bearer Finality Enablement . . . . . . . . 123
7.2.27. Finality Sink - Actual Pending Operation
Verification . . . . . . . . . . . . . . . . . . . . 124
7.2.28. External Effect-Capable Resource . . . . . . . . . . 124
7.2.29. PART II - MICRO-VM IDENTITY AND LIFECYCLE . . . . . . 124
7.2.30. S-2.6 - Micro-VM Instance Identity . . . . . . . . . 124
7.2.31. S-2.6.1 - Authenticated context binding . . . . . . . 124
7.2.32. S-2.6.2 - Instance identifier reuse . . . . . . . . . 125
7.2.33. S-2.7 - Lifecycle State Machine . . . . . . . . . . . 125
7.2.34. S-2.7.1 - Lifecycle event binding . . . . . . . . . . 126
7.2.35. S-2.8 - Micro-VM Creation Workflow . . . . . . . . . 126
7.2.36. Step C1 - Task selection . . . . . . . . . . . . . . 126
7.2.37. Step C2 - Isolation-profile selection . . . . . . . . 126
7.2.38. Step C3 - Instance creation . . . . . . . . . . . . . 126
7.2.39. Step C4 - Execution-generation allocation . . . . . . 127
7.2.40. Step C5 - Controlled interface assignment . . . . . . 127
7.2.41. Step C6 - Authority-context association . . . . . . . 127
7.2.42. Step C7 - Guest startup . . . . . . . . . . . . . . . 127
7.2.43. Step C8 - Readiness verification . . . . . . . . . . 127
7.2.44. Step C9 - Active-state transition . . . . . . . . . . 127
7.2.45. PART III - VIRTUAL DEVICE AND EFFECTUATION-PATH
ENFORCEMENT . . . . . . . . . . . . . . . . . . . . . 127
7.2.46. S-2.9 - Reduced Virtual-Device Configuration . . . . 127
7.2.47. S-2.10 - Micro-VM Effectuation Path Registry . . . . 128
7.2.48. Path class . . . . . . . . . . . . . . . . . . . . . 128
7.2.49. Example interface . . . . . . . . . . . . . . . . . . 128
Das Expires 25 April 2027 [Page 7]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.50. Controlled effect . . . . . . . . . . . . . . . . . . 128
7.2.51. S-2.10.1 - Path-completeness condition . . . . . . . 128
7.2.52. S-2.11 - Controlled Micro-VM Communication Channel . 129
7.2.53. S-2.11.1 - Channel authentication . . . . . . . . . . 129
7.2.54. S-2.11.2 - Channel closure . . . . . . . . . . . . . 130
7.2.55. PART IV - PROTECTED OPERATION STAGING . . . . . . . . 130
7.2.56. S-2.12 - Candidate Act Capture . . . . . . . . . . . 130
7.2.57. S-2.13 - Non-Effective Holding Mechanism . . . . . . 131
7.2.58. S-2.13.1 - Durable staging . . . . . . . . . . . . . 131
7.2.59. S-2.14 - Candidate Act Descriptor . . . . . . . . . . 131
7.2.60. S-2.14.1 - Canonicalization . . . . . . . . . . . . . 132
7.2.61. PART V - PED AND CIED OPERATION . . . . . . . . . . . 132
7.2.62. S-2.15 - Protected Enforcement Domain . . . . . . . . 132
7.2.63. S-2.15.1 - Authority-state binding . . . . . . . . . 133
7.2.64. S-2.16 - Protected Validation Evidence . . . . . . . 133
7.2.65. S-2.17 - CIED Variation . . . . . . . . . . . . . . . 134
7.2.66. PART VI - LIFECYCLE-BOUND FINALITY AUTHORITY . . . . 135
7.2.67. S-2.18 - Scoped Non-Bearer Capability . . . . . . . . 135
7.2.68. S-2.18.1 - Instance-bound capability . . . . . . . . 135
7.2.69. S-2.18.2 - Task-bound capability . . . . . . . . . . 135
7.2.70. S-2.18.3 - Distinction . . . . . . . . . . . . . . . 136
7.2.71. PART VII - FINALITY SINK VERIFICATION . . . . . . . . 136
7.2.72. S-2.19 - Finality Sink . . . . . . . . . . . . . . . 136
7.2.73. S-2.20 - Actual Pending Operation Reconstruction . . 136
7.2.74. S-2.20.1 - Operation transformation . . . . . . . . . 137
7.2.75. S-2.21 - Sink-Local Protected State . . . . . . . . . 137
7.2.76. S-2.21.1 - Verification sequence . . . . . . . . . . 138
7.2.77. PART VIII - OUTSTANDING OPERATION CONTINUITY . . . . 138
7.2.78. S-2.22 - Outstanding Operation Registry . . . . . . . 138
7.2.79. S-2.23 - Operation State Machine . . . . . . . . . . 139
7.2.80. PROPOSED → STAGED → VALIDATED → AUTHORIZED → RESERVED →
DISPATCHED → COMPLETED . . . . . . . . . . . . . . . 139
7.2.81. S-2.24 - Micro-VM Termination Workflow . . . . . . . 140
7.2.82. Step T1 - Termination initiation . . . . . . . . . . 140
7.2.83. Step T2 - New-operation restriction . . . . . . . . . 140
7.2.84. Step T3 - Outstanding-operation enumeration . . . . . 140
7.2.85. Step T4 - Operation classification . . . . . . . . . 140
7.2.86. Step T5 - Cancellation or continuation
determination . . . . . . . . . . . . . . . . . . . . 140
7.2.87. Step T6 - Authority-generation transition . . . . . . 140
7.2.88. Step T7 - Pending-operation update . . . . . . . . . 140
7.2.89. Step T8 - Continued-operation preservation . . . . . 140
7.2.90. Step T9 - Guest destruction . . . . . . . . . . . . . 140
7.2.91. Step T10 - Post-termination reconciliation . . . . . 141
7.2.92. S-2.25 - Replacement Micro-VM Workflow . . . . . . . 141
7.2.93. S-2.25.1 - Replacement consistency check . . . . . . 141
7.2.94. S-2.25.2 - Replacement authority . . . . . . . . . . 141
7.2.95. PART IX - SNAPSHOT RESTORATION AND ROLLBACK . . . . . 142
Das Expires 25 April 2027 [Page 8]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.96. S-2.26 - Snapshot Security . . . . . . . . . . . . . 142
7.2.97. S-2.27 - Snapshot Restoration Workflow . . . . . . . 142
7.2.98. S-2.27.1 - Protected state independence . . . . . . . 143
7.2.99. PART X - REFERENCE ALGORITHMS . . . . . . . . . . . . 143
7.2.100. S-2.29 - Algorithm B: Candidate Act Staging . . . . 144
7.2.101. S-2.31 - Algorithm D: Finality Sink Operation . . . 146
7.2.102. S-2.32 - Algorithm E: Micro-VM Termination . . . . . 147
7.2.103. PART XI - WORKED TECHNICAL EXAMPLES . . . . . . . . 148
7.2.104. PART XII - FAILURE AND ADVERSARIAL SCENARIOS . . . . 150
7.2.105. S-2.36 - Failure F1: Micro-VM Identifier Reuse . . . 150
7.2.106. S-2.37 - Failure F2: Snapshot Replay . . . . . . . . 150
7.2.107. S-2.38 - Failure F3: Guest Privilege Escalation . . 151
7.2.108. S-2.41 - Failure F6: PED Unavailable . . . . . . . . 151
7.2.109. S-2.45 - Failure F10: Host Compromise . . . . . . . 151
7.2.110. S-2.46 - Failure F11: Premature Guest Destruction . 152
7.2.111. PART XIII - SOFTWARE, HARDWARE, AND HYBRID
VARIATIONS . . . . . . . . . . . . . . . . . . . . . 152
7.2.112. S-2.48 - Software-Based Micro-VM Implementation . . 152
7.2.113. S-2.49 - Hardware-Assisted Virtualization
Implementation . . . . . . . . . . . . . . . . . . . 152
7.2.114. S-2.52 - SmartNIC/DPU Finality Implementation . . . 153
7.2.115. S-2.53 - Distributed Micro-VM Implementation . . . . 153
7.2.116. S-2.54 - Integrated Protected Controller
Implementation . . . . . . . . . . . . . . . . . . . 154
7.2.117. PART XIV - REPRESENTATIVE TECHNICAL DATA
STRUCTURES . . . . . . . . . . . . . . . . . . . . . 154
7.2.118. S-2.55 - MicroVMContextRecord . . . . . . . . . . . 154
7.2.119. S-2.56 - CandidateActRecord . . . . . . . . . . . . 154
7.2.120. S-2.57 - ProtectedValidationEvidenceRecord . . . . . 154
7.2.121. S-2.58 - ScopedFinalityCapabilityRecord . . . . . . 155
7.2.122. S-2.59 - OutstandingOperationRecord . . . . . . . . 155
7.2.123. S-2.60 - LifecycleReconciliationRecord . . . . . . . 155
7.2.124. PART XV - implementer VERIFICATION AND IMPLEMENTATION
TESTS . . . . . . . . . . . . . . . . . . . . . . . . 155
7.2.125. S-2.61 - Representative Test Matrix . . . . . . . . 155
7.2.126. Test Condition . . . . . . . . . . . . . . . . . . . 155
7.2.127. Expected technical behavior . . . . . . . . . . . . 156
7.2.128. PART XVII - Enforcement-Point Mapping and Technical
Correspondence FAMILIES . . . . . . . . . . . . . . . 156
7.2.129. S-2.63 - Enforcement Point Support and Scope . . . . 156
7.2.130. S-2.64 - Relationship to Other Sandbox
Embodiments . . . . . . . . . . . . . . . . . . . . . 157
7.2.131. S-2.65 - Enablement Requirements . . . . . . . . . . 157
7.2.132. S-2.66 - Technical Summary . . . . . . . . . . . . . 159
7.3. Implementation Profile S-3 . . . . . . . . . . . . . . . 159
7.3.1. S-3.1 - Technical Field . . . . . . . . . . . . . . . 160
7.3.2. S-3.2 - Technical Problem . . . . . . . . . . . . . . 160
7.3.3. S-3.3 - Technical Objectives . . . . . . . . . . . . 162
Das Expires 25 April 2027 [Page 9]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.4. PART I - PRINCIPAL ARCHITECTURE . . . . . . . . . . . 162
7.3.5. S-3.4 - Principal System Components . . . . . . . . . 162
7.3.6. Component A - Container Host . . . . . . . . . . . . 162
7.3.7. Component B - Container Runtime and Isolation
Controller . . . . . . . . . . . . . . . . . . . . . 162
7.3.8. Component C - Agent Container . . . . . . . . . . . . 163
7.3.9. Component D - Container Context Authenticator . . . . 163
7.3.10. Component E - Operation Interceptor . . . . . . . . . 163
7.3.11. Component F - Non-Effective Operation Holder . . . . 163
7.3.12. Component G - Protected Enforcement Domain . . . . . 163
7.3.13. Component H - Protected Evidence Controller . . . . . 163
7.3.14. Component I - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 163
7.3.15. Component J - Finality Sink . . . . . . . . . . . . . 163
7.3.16. Component K - Host-Side Tool Connector . . . . . . . 164
7.3.17. Component L - Credential Broker . . . . . . . . . . . 164
7.3.18. Component M - Network Egress Mediator . . . . . . . . 164
7.3.19. Component N - Protected Operation Registry . . . . . 164
7.3.20. Component O - Optional Runtime Observation
Mechanism . . . . . . . . . . . . . . . . . . . . . . 164
7.3.21. S-3.5 - Representative Deployment Arrangement . . . . 164
7.3.22. Agent Container → Controlled Tool or Network Interface
→ Candidate Act Staging → . . . . . . . . . . . . . . 165
7.3.23. PED Validation → Protected Evidence → Scoped Finality
Capability → Finality Sink Verification → External
Resource . . . . . . . . . . . . . . . . . . . . . . 165
7.3.24. PART II - CONTAINER ISOLATION . . . . . . . . . . . . 165
7.3.25. S-3.6 - Operating-System Namespace Isolation . . . . 165
7.3.26. S-3.6.1 - Host context and container context . . . . 166
7.3.27. S-3.7 - Control-Group Resource Restrictions . . . . . 166
7.3.28. S-3.7.1 - Resource exhaustion . . . . . . . . . . . . 167
7.3.29. S-3.8 - Linux Capabilities and Privilege
Restrictions . . . . . . . . . . . . . . . . . . . . 167
7.3.30. S-3.9 - Seccomp System-Call Restrictions . . . . . . 168
7.3.31. S-3.9.1 - Seccomp notification variation . . . . . . 168
7.3.32. S-3.10 - Linux Security Modules . . . . . . . . . . . 168
7.3.33. S-3.10.1 - Relationship to finality . . . . . . . . . 169
7.3.34. S-3.11 - eBPF-Based Observation and Enforcement . . . 169
7.3.35. S-3.11.1 - Observational eBPF . . . . . . . . . . . . 170
7.3.36. S-3.11.2 - Enforcement-capable eBPF . . . . . . . . . 170
7.3.37. S-3.11.3 - Observation-to-authority separation . . . 170
7.3.38. PART III - CONTAINER CONTEXT AND OPERATION
IDENTITY . . . . . . . . . . . . . . . . . . . . . . 170
7.3.39. S-3.12 - Container Execution Context . . . . . . . . 170
7.3.40. S-3.13 - Authenticated Origin Binding . . . . . . . . 171
7.3.41. S-3.14 - Container Generation . . . . . . . . . . . . 171
7.3.42. PART IV - HOST-SIDE TOOL DISPATCH AND CONNECTOR
MEDIATION . . . . . . . . . . . . . . . . . . . . . . 172
Das Expires 25 April 2027 [Page 10]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.43. S-3.15 - Controlled Tool Interface . . . . . . . . . 172
7.3.44. S-3.15.1 - Tool request representation . . . . . . . 172
7.3.45. S-3.16 - Host-Side Connector . . . . . . . . . . . . 173
7.3.46. S-3.16.1 - Connector authority limitation . . . . . . 173
7.3.47. S-3.16.2 - Connector transformation . . . . . . . . . 173
7.3.48. S-3.17 - Tool-Dispatch Candidate Act . . . . . . . . 174
7.3.49. PART V - NON-EFFECTIVE STAGING . . . . . . . . . . . 175
7.3.50. S-3.18 - Candidate Act Holding . . . . . . . . . . . 175
7.3.51. S-3.18.1 - Shared-memory safety . . . . . . . . . . . 175
7.3.52. S-3.19 - Canonical Operation Descriptor . . . . . . . 176
7.3.53. PART VI - PROTECTED AUTHORIZATION . . . . . . . . . . 176
7.3.54. S-3.20 - Protected Enforcement Domain . . . . . . . . 176
7.3.55. S-3.20.1 - Authorization predicates . . . . . . . . . 176
7.3.56. S-3.21 - Protected Validation Evidence . . . . . . . 177
7.3.57. S-3.22 - Scoped Non-Bearer Finality Capability . . . 178
7.3.58. S-3.22.1 - Container-independent capability
custody . . . . . . . . . . . . . . . . . . . . . . . 178
7.3.59. PART VII - FINALITY SINK ENFORCEMENT . . . . . . . . 179
7.3.60. S-3.23 - Host-Side Tool Finality Sink . . . . . . . . 179
7.3.61. S-3.23.1 - Required verification . . . . . . . . . . 179
7.3.62. S-3.24 - Sink-Local Protected State . . . . . . . . . 179
7.3.63. PART VIII - NETWORK EGRESS FINALITY . . . . . . . . . 180
7.3.64. S-3.25 - Container Network Architecture . . . . . . . 180
7.3.65. S-3.26 - Network Candidate Act Descriptor . . . . . . 180
7.3.66. S-3.26.1 - Destination identity . . . . . . . . . . . 181
7.3.67. S-3.27 - Network Effectuation Workflow . . . . . . . 182
7.3.68. S-3.27.1 - Encrypted application traffic . . . . . . 182
7.3.69. PART IX - CREDENTIAL ISOLATION AND RELEASE . . . . . 183
7.3.70. S-3.28 - Credential Broker . . . . . . . . . . . . . 183
7.3.71. S-3.28.1 - Credential-use distinction . . . . . . . . 183
7.3.72. S-3.29 - Surrogate Credential Variation . . . . . . . 184
7.3.73. S-3.29.1 - Post-transformation verification . . . . . 184
7.3.74. S-3.29.2 - Credential non-disclosure . . . . . . . . 184
7.3.75. PART X - FILE, STORAGE, AND IPC EFFECTUATION . . . . 185
7.3.76. S-3.30 - File-System Effectuation . . . . . . . . . . 185
7.3.77. S-3.30.1 - File object correspondence . . . . . . . . 185
7.3.78. S-3.31 - Unix-Domain Sockets and IPC . . . . . . . . 185
7.3.79. S-3.31.1 - File-descriptor passing . . . . . . . . . 186
7.3.80. S-3.32 - Database and Persistent Resource Commit . . 186
7.3.81. PART XI - CONTAINER LIFECYCLE AND ASYNCHRONOUS
OPERATIONS . . . . . . . . . . . . . . . . . . . . . 187
7.3.82. S-3.33 - Container Lifecycle States . . . . . . . . . 187
7.3.83. S-3.34 - Container Termination . . . . . . . . . . . 187
7.3.84. S-3.35 - Container Restart and Generation Change . . 187
7.3.85. S-3.36 - Asynchronous Tool Worker . . . . . . . . . . 188
7.3.86. PART XII - SUCCESSFUL EXECUTION WORKFLOW . . . . . . 188
7.3.87. S-3.37 - Principal 20-Step Workflow . . . . . . . . . 188
7.3.88. Step S3-01 - Container creation . . . . . . . . . . . 188
Das Expires 25 April 2027 [Page 11]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.89. Step S3-02 - Isolation configuration . . . . . . . . 188
7.3.90. Step S3-03 - Enforcement-path configuration . . . . . 189
7.3.91. Step S3-04 - Execution identity assignment . . . . . 189
7.3.92. Step S3-05 - Agent execution . . . . . . . . . . . . 189
7.3.93. Step S3-06 - Consequential operation proposal . . . . 189
7.3.94. Step S3-07 - Boundary interception . . . . . . . . . 189
7.3.95. Step S3-08 - Authenticated origin determination . . . 189
7.3.96. Step S3-09 - Candidate Act creation . . . . . . . . . 189
7.3.97. Step S3-10 - Non-effective staging . . . . . . . . . 189
7.3.98. Step S3-11 - Descriptor construction . . . . . . . . 189
7.3.99. Step S3-12 - PED submission . . . . . . . . . . . . . 189
7.3.100. Step S3-13 - Protected predicate evaluation . . . . 190
7.3.101. Step S3-14 - Protected evidence commitment . . . . . 190
7.3.102. Step S3-15 - Scoped finality authorization . . . . . 190
7.3.103. Step S3-16 - Sink-side actual-operation
reconstruction . . . . . . . . . . . . . . . . . . . 190
7.3.104. Step S3-17 - Finality verification . . . . . . . . . 190
7.3.105. Step S3-18 - Protected authorization-state
transition . . . . . . . . . . . . . . . . . . . . . 190
7.3.106. Step S3-19 - Consequential effectuation . . . . . . 190
7.3.107. Step S3-20 - Completion and reconciliation . . . . . 190
7.3.108. PART XIII - REFERENCE PSEUDOCODE . . . . . . . . . . 191
7.3.109. S-3.38 - Algorithm A: Container Registration . . . . 191
7.3.110. S-3.39 - Algorithm B: Tool Request Interception . . 191
7.3.111. S-3.41 - Algorithm D: Finality Sink Verification . . 193
7.3.112. S-3.43 - Algorithm F: Credential-Brokered
Dispatch . . . . . . . . . . . . . . . . . . . . . . 195
7.3.113. PART XIV - WORKED EXAMPLES . . . . . . . . . . . . . 196
7.3.114. S-3.46 - Example C: Host Credential Substitution . . 198
7.3.115. PART XV - FAILURE AND ADVERSARIAL SCENARIOS . . . . 199
7.3.116. S-3.48 - Representative Failure Conditions . . . . . 199
7.3.117. F1 - Privileged Container Configuration . . . . . . 199
7.3.118. F2 - Namespace Bypass . . . . . . . . . . . . . . . 199
7.3.119. F3 - Inherited File Descriptor . . . . . . . . . . . 199
7.3.120. F4 - Host-Side Connector Abuse . . . . . . . . . . . 200
7.3.121. F5 - Credential Disclosure . . . . . . . . . . . . . 200
7.3.122. F6 - DNS Rebinding or Redirected Destination . . . . 200
7.3.123. F7 - eBPF Observation Loss . . . . . . . . . . . . . 200
7.3.124. F8 - Kernel Compromise . . . . . . . . . . . . . . . 200
7.3.125. F9 - Operation Substitution . . . . . . . . . . . . 201
7.3.126. F10 - Capability Replay . . . . . . . . . . . . . . 201
7.3.127. F11 - Container Restart . . . . . . . . . . . . . . 201
7.3.128. F12 - Asynchronous Worker Delay . . . . . . . . . . 201
7.3.129. F13 - Shared-Memory Modification . . . . . . . . . . 201
7.3.130. F14 - Policy-Generation Mismatch . . . . . . . . . . 201
7.3.131. F15 - Connector Crash After Possible External
Effect . . . . . . . . . . . . . . . . . . . . . . . 201
7.3.132. F16 - Host Networking Bypass . . . . . . . . . . . . 202
Das Expires 25 April 2027 [Page 12]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.133. F17 - Symlink or Mount Substitution . . . . . . . . 202
7.3.134. F18 - Container Identity Spoofing . . . . . . . . . 202
7.3.135. PART XVI - SOFTWARE, HARDWARE, AND HYBRID
IMPLEMENTATIONS . . . . . . . . . . . . . . . . . . . 202
7.3.136. S-3.49 - Software-Only Container Implementation . . 202
7.3.137. S-3.50 - LSM-Based Enforcement Implementation . . . 202
7.3.138. S-3.51 - eBPF-Assisted Implementation . . . . . . . 203
7.3.139. S-3.52 - Hypervisor-Hosted Container
Implementation . . . . . . . . . . . . . . . . . . . 203
7.3.140. S-3.53 - TEE-Assisted Container Implementation . . . 203
7.3.141. S-3.54 - HSM-Assisted Credential and Finality
Implementation . . . . . . . . . . . . . . . . . . . 204
7.3.142. S-3.55 - SmartNIC/DPU Enforcement Implementation . . 204
7.3.143. S-3.56 - Distributed Host-Connector
Implementation . . . . . . . . . . . . . . . . . . . 205
7.3.144. PART XVII - DATA STRUCTURES . . . . . . . . . . . . 205
7.3.145. S-3.57 - ContainerContextRecord . . . . . . . . . . 205
7.3.146. S-3.58 - ToolCandidateActRecord . . . . . . . . . . 205
7.3.147. S-3.59 - ProtectedValidationEvidenceRecord . . . . . 206
7.3.148. S-3.60 - ScopedFinalityCapabilityRecord . . . . . . 206
7.3.149. S-3.61 - SinkLocalStateRecord . . . . . . . . . . . 206
7.3.150. S-3.62 - ContainerEffectPathRecord . . . . . . . . . 207
7.3.151. S-3.63 - CredentialBrokerRecord . . . . . . . . . . 207
7.3.152. S-3.64 - OutstandingOperationRecord . . . . . . . . 207
7.3.153. PART XVIII - implementer VERIFICATION TESTS . . . . 208
7.3.154. S-3.65 - Proposed Engineering Test Matrix . . . . . 208
7.3.155. Test Test condition . . . . . . . . . . . . . . . . 208
7.3.156. Expected result . . . . . . . . . . . . . . . . . . 208
7.3.157. PART XX - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 209
7.3.158. S-3.75 - Representative Enforcement Point Support . 209
7.3.159. PART XXI - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 210
7.3.160. S-3.76 - Implementation Checklist . . . . . . . . . 210
7.3.161. S-3.77 - Technical Effect . . . . . . . . . . . . . 211
7.3.162. S-3.78 - Technical Summary . . . . . . . . . . . . . 211
7.4. Implementation Profile S-4 . . . . . . . . . . . . . . . 212
7.4.1. S-4.1 - Technical Field . . . . . . . . . . . . . . . 212
7.4.2. S-4.2 - Technical Problem . . . . . . . . . . . . . . 213
7.4.3. S-4.3 - Technical Objectives . . . . . . . . . . . . 214
7.4.4. PART I - SYSTEM ARCHITECTURE . . . . . . . . . . . . 215
7.4.5. S-4.4 - Principal Components . . . . . . . . . . . . 215
7.4.6. Component A - Computing Host . . . . . . . . . . . . 215
7.4.7. Component B - Host Operating System . . . . . . . . . 215
7.4.8. Component C - Agent Process . . . . . . . . . . . . . 215
7.4.9. Component D - Process Isolation Controller . . . . . 215
7.4.10. Component E - Process Context Registry . . . . . . . 215
7.4.11. Component F - Process-Lineage Controller . . . . . . 215
Das Expires 25 April 2027 [Page 13]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.12. Component G - Resource and Handle Mediation
Controller . . . . . . . . . . . . . . . . . . . . . 216
7.4.13. Component H - Controlled IPC and Tool Interface . . . 216
7.4.14. Component I - Candidate Act Interceptor . . . . . . . 216
7.4.15. Component J - Non-Effective Operation Holder . . . . 216
7.4.16. Component K - Protected Enforcement Domain . . . . . 216
7.4.17. Component L - Protected Validation Evidence
Controller . . . . . . . . . . . . . . . . . . . . . 216
7.4.18. Component M - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 216
7.4.19. Component N - Finality Sink . . . . . . . . . . . . . 216
7.4.20. Component O - Privileged Resource Broker . . . . . . 216
7.4.21. Component P - Protected Operation Registry . . . . . 217
7.4.22. S-4.5 - Representative Process-Isolated
Architecture . . . . . . . . . . . . . . . . . . . . 217
7.4.23. PART II - PROCESS ISOLATION AND AUTHORITY CONTEXT . . 218
7.4.24. S-4.6 - Restricted Agent Process . . . . . . . . . . 218
7.4.25. S-4.7 - Process Execution Identity . . . . . . . . . 219
7.4.26. S-4.7.1 - Process identifier reuse . . . . . . . . . 220
7.4.27. S-4.8 - Process Isolation Without Containers . . . . 220
7.4.28. PART III - CROSS-PLATFORM PROCESS ISOLATION . . . . . 221
7.4.29. S-4.9 - Linux Process-Isolation Variation . . . . . . 221
7.4.30. S-4.9.1 - Capability reduction . . . . . . . . . . . 221
7.4.31. S-4.9.2 - Seccomp enforcement . . . . . . . . . . . . 221
7.4.32. S-4.9.3 - LSM policy . . . . . . . . . . . . . . . . 222
7.4.33. S-4.9.4 - Direct process implementation . . . . . . . 222
7.4.34. S-4.10 - Windows Process-Isolation Variation . . . . 222
7.4.35. S-4.10.1 - Access-token interpretation . . . . . . . 222
7.4.36. S-4.10.2 - Object handles . . . . . . . . . . . . . . 223
7.4.37. S-4.10.3 - Protected service . . . . . . . . . . . . 223
7.4.38. S-4.11 - macOS Process-Isolation Variation . . . . . 223
7.4.39. S-4.11.1 - Entitlement distinction . . . . . . . . . 224
7.4.40. S-4.11.2 - XPC-based mediation . . . . . . . . . . . 224
7.4.41. S-4.12 - Other Operating Systems and Embedded
Platforms . . . . . . . . . . . . . . . . . . . . . . 224
7.4.42. PART IV - PROCESS LINEAGE AND DELEGATION . . . . . . 225
7.4.43. S-4.13 - Process-Lineage Representation . . . . . . . 225
7.4.44. S-4.13.1 - Lineage is not authority . . . . . . . . . 226
7.4.45. S-4.13.2 - Protected lineage attribution . . . . . . 226
7.4.46. S-4.14 - Child Process Creation . . . . . . . . . . . 226
7.4.47. S-4.15 - Process-Tree Termination . . . . . . . . . . 226
7.4.48. PART V - FILE DESCRIPTORS, OBJECT HANDLES, AND RESOURCE
AUTHORITY . . . . . . . . . . . . . . . . . . . . . . 227
7.4.49. S-4.16 - Effect-Capable Handle . . . . . . . . . . . 227
7.4.50. S-4.17 - Handle-Inheritance Control . . . . . . . . . 227
7.4.51. S-4.17.1 - Restricted handle sets . . . . . . . . . . 228
7.4.52. S-4.18 - Handle Duplication and Transfer . . . . . . 228
7.4.53. S-4.18.1 - Existing-handle limitation . . . . . . . . 229
Das Expires 25 April 2027 [Page 14]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.54. S-4.19 - Shared Memory . . . . . . . . . . . . . . . 229
7.4.55. PART VI - CONTROLLED IPC AND PRIVILEGED BROKER . . . 229
7.4.56. S-4.20 - Protected Broker Interface . . . . . . . . . 229
7.4.57. S-4.21 - Authenticated Process Context . . . . . . . 230
7.4.58. S-4.22 - Broker Resource Authorization . . . . . . . 230
7.4.59. PART VII - CANDIDATE ACT AND NON-EFFECTIVE STAGING . 231
7.4.60. S-4.23 - Candidate Act Creation . . . . . . . . . . . 231
7.4.61. S-4.24 - Non-Effective State . . . . . . . . . . . . 231
7.4.62. S-4.25 - Candidate Act Descriptor . . . . . . . . . . 232
7.4.63. PART VIII - PROTECTED ENFORCEMENT DOMAIN . . . . . . 232
7.4.64. S-4.26 - PED Implementation . . . . . . . . . . . . . 232
7.4.65. S-4.27 - Authority Predicate Evaluation . . . . . . . 233
7.4.66. S-4.28 - Protected Validation Evidence . . . . . . . 234
7.4.67. S-4.29 - Scoped Non-Bearer Finality Capability . . . 234
7.4.68. PART IX - FINALITY SINK AND ACTUAL OPERATION
VERIFICATION . . . . . . . . . . . . . . . . . . . . 235
7.4.69. S-4.30 - Finality Sink Placement . . . . . . . . . . 235
7.4.70. S-4.31 - Actual Pending Operation Reconstruction . . 236
7.4.71. S-4.32 - Sink-Local State . . . . . . . . . . . . . . 236
7.4.72. PART X - COMPLETE SUCCESSFUL EXECUTION WORKFLOW . . . 237
7.4.73. S-4.33 - Principal 22-Step Workflow . . . . . . . . . 237
7.4.74. Step S4-01 - Process creation . . . . . . . . . . . . 237
7.4.75. Step S4-02 - Isolation configuration . . . . . . . . 237
7.4.76. Step S4-03 - Process-generation assignment . . . . . 237
7.4.77. Step S4-04 - Effect-path verification . . . . . . . . 237
7.4.78. Step S4-05 - Agent computation . . . . . . . . . . . 237
7.4.79. Step S4-06 - Operation proposal . . . . . . . . . . . 237
7.4.80. Step S4-07 - Controlled IPC submission . . . . . . . 237
7.4.81. Step S4-08 - Source authentication . . . . . . . . . 237
7.4.82. Step S4-09 - Candidate Act creation . . . . . . . . . 238
7.4.83. Step S4-10 - Non-effective staging . . . . . . . . . 238
7.4.84. Step S4-11 - Descriptor construction . . . . . . . . 238
7.4.85. Step S4-12 - PED submission . . . . . . . . . . . . . 238
7.4.86. Step S4-13 - Protected authority-state acquisition . 238
7.4.87. Step S4-14 - Predicate validation . . . . . . . . . . 238
7.4.88. Step S4-15 - Protected evidence commitment . . . . . 238
7.4.89. Step S4-16 - Capability establishment . . . . . . . . 238
7.4.90. Step S4-17 - Actual-operation reconstruction . . . . 238
7.4.91. Step S4-18 - Finality verification . . . . . . . . . 238
7.4.92. Step S4-19 - Protected state reservation . . . . . . 239
7.4.93. Step S4-20 - Effectuation . . . . . . . . . . . . . . 239
7.4.94. Step S4-21 - Completion observation . . . . . . . . . 239
7.4.95. Step S4-22 - Outcome reconciliation . . . . . . . . . 239
7.4.96. PART XI - IMPLEMENTATION ALGORITHMS . . . . . . . . . 239
7.4.97. S-4.36 - Algorithm C: Process-Lineage
Authorization . . . . . . . . . . . . . . . . . . . . 241
7.4.98. S-4.37 - Algorithm D: PED Validation . . . . . . . . 241
7.4.99. S-4.38 - Algorithm E: Finality Sink Verification . . 242
Das Expires 25 April 2027 [Page 15]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.100. PART XII - WORKED TECHNICAL EXAMPLES . . . . . . . . 244
7.4.101. S-4.43 - Example D: Privileged Credential Broker . . 246
7.4.102. PART XIII - FAILURE AND ADVERSARIAL CASES . . . . . 248
7.4.103. S-4.45 - Representative Failure Cases . . . . . . . 248
7.4.104. F1 - Process Identifier Reuse . . . . . . . . . . . 248
7.4.105. F2 - Inherited Privileged Handle . . . . . . . . . . 248
7.4.106. F3 - Handle Duplication . . . . . . . . . . . . . . 248
7.4.107. F4 - Unauthorized IPC . . . . . . . . . . . . . . . 248
7.4.108. F5 - Parent Process Termination . . . . . . . . . . 248
7.4.109. F6 - Process-Token Substitution . . . . . . . . . . 249
7.4.110. F7 - Mutable Shared-Memory Request . . . . . . . . . 249
7.4.111. F8 - Resource-Path Substitution . . . . . . . . . . 249
7.4.112. F9 - Authority Revocation . . . . . . . . . . . . . 249
7.4.113. F10 - Capability Replay . . . . . . . . . . . . . . 249
7.4.114. F11 - Concurrent Capability Presentation . . . . . . 249
7.4.115. F12 - Broker Process Crash . . . . . . . . . . . . . 249
7.4.116. F13 - PED Unavailability . . . . . . . . . . . . . . 250
7.4.117. F14 - Finality Sink Unavailability . . . . . . . . . 250
7.4.118. F15 - Process Escape or Privilege Escalation . . . . 250
7.4.119. F16 - Unobserved Process Activity . . . . . . . . . 250
7.4.120. F17 - Cross-Task Confusion . . . . . . . . . . . . . 250
7.4.121. F18 - Alternative Network Route . . . . . . . . . . 251
7.4.122. F19 - Reused Broker Session . . . . . . . . . . . . 251
7.4.123. F20 - Kernel Compromise . . . . . . . . . . . . . . 251
7.4.124. PART XIV - HARDWARE, SOFTWARE, AND HYBRID
VARIATIONS . . . . . . . . . . . . . . . . . . . . . 251
7.4.125. S-4.46 - Software-Only Process Enforcement . . . . . 251
7.4.126. S-4.47 - Kernel-Mediated Enforcement . . . . . . . . 251
7.4.127. S-4.48 - TEE-Assisted Enforcement . . . . . . . . . 252
7.4.128. S-4.49 - HSM-Assisted Credential Control . . . . . . 252
7.4.129. S-4.50 - SmartNIC/DPU Network Enforcement . . . . . 252
7.4.130. S-4.51 - Hardware Device-Command Enforcement . . . . 253
7.4.131. S-4.52 - Remote Protected Broker . . . . . . . . . . 253
7.4.132. S-4.53 - Single-Component Enforcement . . . . . . . 253
7.4.133. PART XV - REPRESENTATIVE DATA STRUCTURES . . . . . . 253
7.4.134. S-4.54 - ProcessContextRecord . . . . . . . . . . . 253
7.4.135. S-4.55 - ProcessLineageRecord . . . . . . . . . . . 254
7.4.136. S-4.56 - HandleControlRecord . . . . . . . . . . . . 254
7.4.137. S-4.57 - CandidateActRecord . . . . . . . . . . . . 254
7.4.138. S-4.58 - ProtectedValidationEvidenceRecord . . . . . 254
7.4.139. S-4.59 - ScopedFinalityCapabilityRecord . . . . . . 254
7.4.140. S-4.60 - SinkLocalStateRecord . . . . . . . . . . . 255
7.4.141. S-4.61 - OutstandingOperationRecord . . . . . . . . 255
7.4.142. PART XVI - implementer IMPLEMENTATION AND
VERIFICATION . . . . . . . . . . . . . . . . . . . . 255
7.4.143. S-4.62 - Proposed Engineering Tests . . . . . . . . 255
7.4.144. PART XVIII - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 256
Das Expires 25 April 2027 [Page 16]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.145. S-4.72 - Representative Enforcement Point Support . 256
7.4.146. S-4.73 - Relationship to Other Embodiments . . . . . 257
7.4.147. S-4.74 - implementer Enablement Requirements . . . . 258
7.4.148. S-4.75 - Technical Effect . . . . . . . . . . . . . 258
7.4.149. S-4.76 - Technical Summary . . . . . . . . . . . . . 259
7.5. Implementation Profile C-21 . . . . . . . . . . . . . . . 260
7.5.1. C-21.1 - Technical Field . . . . . . . . . . . . . . 260
7.5.2. C-21.2 - Technical Problem . . . . . . . . . . . . . 261
7.5.3. C-21.3 - Central Technical Principle . . . . . . . . 262
7.5.4. PART I - PRINCIPAL SYSTEM ARCHITECTURE . . . . . . . 263
7.5.5. C-21.4 - Principal Components . . . . . . . . . . . . 263
7.5.6. Component A - Continuing Agent Execution
Environment . . . . . . . . . . . . . . . . . . . . . 263
7.5.7. Component B - Protected Session Controller . . . . . 263
7.5.8. Component C - Initial Permission Envelope
Controller . . . . . . . . . . . . . . . . . . . . . 263
7.5.9. Component D - Consequential Operation Interceptor . . 264
7.5.10. Component E - Candidate Act and Window Classifier . . 264
7.5.11. Component F - Canonical Operation Descriptor
Generator . . . . . . . . . . . . . . . . . . . . . . 264
7.5.12. Component G - Protected Enforcement Domain . . . . . 264
7.5.13. Component H - Protected Session State Registry . . . 264
7.5.14. Component I - Runtime Behavioral Descriptor
Collector . . . . . . . . . . . . . . . . . . . . . . 264
7.5.15. Component J - Behavioral Validation Controller . . . 264
7.5.16. Component K - Protected Micro-Validation
Controller . . . . . . . . . . . . . . . . . . . . . 264
7.5.17. Component L - Micro-Validation Chain Controller . . . 264
7.5.18. Component M - Bounded Window Authorization
Controller . . . . . . . . . . . . . . . . . . . . . 265
7.5.19. Component N - Protected Budget Controller . . . . . . 265
7.5.20. Component O - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 265
7.5.21. Component P - Finality Sink . . . . . . . . . . . . . 265
7.5.22. Component Q - Low-Latency Enforcement Controller . . 265
7.5.23. Component R - Session Recovery and Migration
Controller . . . . . . . . . . . . . . . . . . . . . 265
7.5.24. Component S - Outstanding Operation Registry . . . . 265
7.5.25. C-21.5 - Reference Continuous-Session Architecture . 265
7.5.26. PART II - PROTECTED SESSION IDENTITY . . . . . . . . 267
7.5.27. C-21.6 - Continuing Agent Session . . . . . . . . . . 267
7.5.28. C-21.7 - Protected Session Identity . . . . . . . . . 267
7.5.29. C-21.8 - Session Identity Versus Process Identity . . 268
7.5.30. C-21.9 - Session Lifecycle States . . . . . . . . . . 268
7.5.31. PART III - INITIAL PERMISSION ENVELOPE . . . . . . . 269
7.5.32. C-21.10 - Initial Permission Envelope . . . . . . . . 269
7.5.33. C-21.11 - Permission Envelope Example . . . . . . . . 269
7.5.34. C-21.12 - Initial Envelope Restriction . . . . . . . 270
Das Expires 25 April 2027 [Page 17]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.35. PART IV - SUCCESSIVE CANDIDATE ACTS . . . . . . . . . 270
7.5.36. C-21.13 - Successive Operation Interception . . . . . 270
7.5.37. C-21.14 - Per-Act Authorization Mode . . . . . . . . 270
7.5.38. C-21.15 - Bounded Operation Group . . . . . . . . . . 271
7.5.39. C-21.16 - Finite Effectuation Window . . . . . . . . 271
7.5.40. C-21.17 - Window Descriptor . . . . . . . . . . . . . 272
7.5.41. PART V - BOUNDED WINDOW AUTHORIZATION . . . . . . . . 272
7.5.42. C-21.18 - Window Creation . . . . . . . . . . . . . . 272
7.5.43. C-21.19 - Window Authorization Is Not an Unbounded
Token . . . . . . . . . . . . . . . . . . . . . . . . 273
7.5.44. C-21.20 - Window Invariants . . . . . . . . . . . . . 273
7.5.45. PART VI - MICRO-VALIDATION RECORDS . . . . . . . . . 274
7.5.46. C-21.21 - Micro-Validation Record . . . . . . . . . . 274
7.5.47. C-21.22 - Micro-Validation Chain . . . . . . . . . . 274
7.5.48. C-21.23 - Micro-Chain Construction . . . . . . . . . 275
7.5.49. C-21.24 - Protected Chain State . . . . . . . . . . . 275
7.5.50. C-21.25 - Chain Update Ordering . . . . . . . . . . . 276
7.5.51. C-21.26 - Chain Gaps and Sequence Reuse . . . . . . . 276
7.5.52. PART VII - RUNTIME BEHAVIORAL DESCRIPTORS . . . . . . 277
7.5.53. C-21.27 - Runtime Behavioral Descriptor . . . . . . . 277
7.5.54. C-21.28 - Behavioral Observation . . . . . . . . . . 278
7.5.55. C-21.29 - Approved Algorithmic Logic Fingerprint . . 278
7.5.56. C-21.30 - Behavioral Drift . . . . . . . . . . . . . 279
7.5.57. C-21.31 - Drift Decision . . . . . . . . . . . . . . 279
7.5.58. C-21.32 - Drift-Triggered Restriction . . . . . . . . 279
7.5.59. PART VIII - NARROW SESSION GRANTS AND BUDGETS . . . . 280
7.5.60. C-21.33 - Protected Session Grant . . . . . . . . . . 280
7.5.61. C-21.35 - Atomic Budget Reservation . . . . . . . . . 281
7.5.62. C-21.36 - Actual Consumption Versus Reservation . . . 281
7.5.63. C-21.37 - Byte Budget Enforcement . . . . . . . . . . 282
7.5.64. C-21.38 - Time-Bound Grant . . . . . . . . . . . . . 282
7.5.65. PART IX - LOW-LATENCY PROTECTED ENFORCEMENT . . . . . 282
7.5.66. C-21.39 - Control-Path and Effectuation-Path
Separation . . . . . . . . . . . . . . . . . . . . . 282
7.5.67. C-21.40 - Window Grant Compilation . . . . . . . . . 283
7.5.68. C-21.41 - Compact Sink Verification . . . . . . . . . 284
7.5.69. C-21.42 - Effectuation Without Repeating Full PED
Evaluation . . . . . . . . . . . . . . . . . . . . . 284
7.5.70. C-21.43 - Latency Considerations . . . . . . . . . . 284
7.5.71. C-21.44 - Window Grant Revocation . . . . . . . . . . 285
7.5.72. PART X - SESSION FINALITY STATE . . . . . . . . . . . 285
7.5.73. C-21.45 - Protected Session Finality Record . . . . . 285
7.5.74. C-21.46 - Session State Updates . . . . . . . . . . . 286
7.5.75. C-21.47 - Session Continuation . . . . . . . . . . . 286
7.5.76. PART XI - SNAPSHOT, RESTART, AND ROLLBACK . . . . . . 287
7.5.77. C-21.48 - Snapshot Restoration Threat . . . . . . . . 287
7.5.78. C-21.49 - Protected Continuity State . . . . . . . . 287
7.5.79. C-21.50 - Restart Handling . . . . . . . . . . . . . 288
Das Expires 25 April 2027 [Page 18]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.80. C-21.51 - Snapshot Rollback Detection . . . . . . . . 288
7.5.81. C-21.52 - Migration Handling . . . . . . . . . . . . 288
7.5.82. C-21.53 - Failover . . . . . . . . . . . . . . . . . 289
7.5.83. PART XII - COMPLETE EXECUTION WORKFLOW . . . . . . . 289
7.5.84. C-21.54 - Principal 32-Step Workflow . . . . . . . . 289
7.5.85. Step C21-01 - Session initialization . . . . . . . . 289
7.5.86. Step C21-02 - Protected session registration . . . . 289
7.5.87. Step C21-03 - Initial permission envelope
establishment . . . . . . . . . . . . . . . . . . . . 289
7.5.88. Step C21-04 - Effectuation-path restriction . . . . . 289
7.5.89. Step C21-05 - Behavioral baseline establishment . . . 289
7.5.90. Step C21-06 - Agent computation . . . . . . . . . . . 289
7.5.91. Step C21-07 - Proposed operation generation . . . . . 289
7.5.92. Step C21-08 - Operation interception . . . . . . . . 290
7.5.93. Step C21-09 - Candidate classification . . . . . . . 290
7.5.94. Step C21-10 - Non-effective staging . . . . . . . . . 290
7.5.95. Step C21-11 - Descriptor generation . . . . . . . . . 290
7.5.96. Step C21-12 - Current session lookup . . . . . . . . 290
7.5.97. Step C21-13 - Behavioral observation . . . . . . . . 290
7.5.98. Step C21-14 - RBD evaluation . . . . . . . . . . . . 290
7.5.99. Step C21-15 - Protected authority-state retrieval . . 290
7.5.100. Step C21-16 - Predicate validation . . . . . . . . . 290
7.5.101. Step C21-17 - Grant scope determination . . . . . . 290
7.5.102. Step C21-18 - Budget reservation . . . . . . . . . . 290
7.5.103. Step C21-19 - Validation evidence commitment . . . . 291
7.5.104. Step C21-20 - Micro-validation chain update . . . . 291
7.5.105. Step C21-21 - Scoped finality authorization . . . . 291
7.5.106. Step C21-22 - Grant presentation . . . . . . . . . . 291
7.5.107. Step C21-23 - Actual-operation reconstruction . . . 291
7.5.108. Step C21-24 - Current window verification . . . . . 291
7.5.109. Step C21-25 - Protected consumption transition . . . 291
7.5.110. Step C21-26 - Controlled effectuation . . . . . . . 291
7.5.111. Step C21-27 - Outcome observation . . . . . . . . . 291
7.5.112. Step C21-28 - Protected session-state update . . . . 291
7.5.113. Step C21-29 - Subsequent operation classification . 291
7.5.114. Step C21-30 - Drift or policy-change evaluation . . 292
7.5.115. Step C21-31 - Renewal, restriction, or expiration . 292
7.5.116. Step C21-32 - Session continuation or termination . 292
7.5.117. PART XIII - REFERENCE ALGORITHMS . . . . . . . . . . 292
7.5.118. C-21.60 - Algorithm F: Behavioral Drift Detection . 297
7.5.119. C-21.63 - Algorithm I: Session Snapshot Recovery . . 300
7.5.120. PART XIV - WORKED TECHNICAL EXAMPLES . . . . . . . . 302
7.5.121. C-21.66 - Example B: Micro-Validation Chain . . . . 303
7.5.122. C-21.67 - Example C: Runtime Behavioral Drift . . . 304
7.5.123. C-21.68 - Example D: Low-Latency Network Window . . 304
7.5.124. C-21.69 - Example E: Credential-Use Budget . . . . . 305
7.5.125. C-21.70 - Example F: Snapshot Rollback . . . . . . . 305
7.5.126. C-21.71 - Example G: Agent Migration . . . . . . . . 306
Das Expires 25 April 2027 [Page 19]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.127. C-21.72 - Example H: Concurrent Budget
Consumption . . . . . . . . . . . . . . . . . . . . . 306
7.5.128. C-21.73 - Example I: Lost External Acknowledgment . 307
7.5.129. C-21.74 - Example J: Mid-Window Policy Revocation . 307
7.5.130. PART XV - FAILURE AND ADVERSARIAL SCENARIOS . . . . 307
7.5.131. C-21.75 - Representative Failure Cases . . . . . . . 307
7.5.132. F1 - Unlimited Initial Approval . . . . . . . . . . 307
7.5.133. F2 - Expired Window . . . . . . . . . . . . . . . . 308
7.5.134. F3 - Exhausted Operation Count . . . . . . . . . . . 308
7.5.135. F4 - Byte Budget Overrun . . . . . . . . . . . . . . 308
7.5.136. F5 - Wrong Destination . . . . . . . . . . . . . . . 308
7.5.137. F6 - Wrong Resource . . . . . . . . . . . . . . . . 308
7.5.138. F7 - Wrong Operation Class . . . . . . . . . . . . . 308
7.5.139. F8 - Micro-Record Replay . . . . . . . . . . . . . . 308
7.5.140. F9 - Chain Head Substitution . . . . . . . . . . . . 309
7.5.141. F10 - Sequence Gap . . . . . . . . . . . . . . . . . 309
7.5.142. F11 - Concurrent Sequence Allocation . . . . . . . . 309
7.5.143. F12 - Behavioral Drift . . . . . . . . . . . . . . . 309
7.5.144. F13 - ALF Mismatch . . . . . . . . . . . . . . . . . 309
7.5.145. F14 - Missing RBD Observation . . . . . . . . . . . 309
7.5.146. F15 - Policy Generation Change . . . . . . . . . . . 309
7.5.147. F16 - Revocation Generation Change . . . . . . . . . 310
7.5.148. F17 - Cached Grant Replay . . . . . . . . . . . . . 310
7.5.149. F18 - Grant Used at Wrong Sink . . . . . . . . . . . 310
7.5.150. F19 - Concurrent Budget Double-Spend . . . . . . . . 310
7.5.151. F20 - Budget Refund After Unknown Completion . . . . 310
7.5.152. F21 - Restart With Stale Grant . . . . . . . . . . . 310
7.5.153. F22 - Snapshot Rollback . . . . . . . . . . . . . . 310
7.5.154. F23 - Virtual-Machine Migration . . . . . . . . . . 311
7.5.155. F24 - Failover to Unverified Sink . . . . . . . . . 311
7.5.156. F25 - Protected Registry Unavailable . . . . . . . . 311
7.5.157. F26 - PED Unavailable . . . . . . . . . . . . . . . 311
7.5.158. F27 - Insufficient Clock Trust . . . . . . . . . . . 311
7.5.159. F28 - Connector Operation Substitution . . . . . . . 311
7.5.160. F29 - New Tool Introduction . . . . . . . . . . . . 311
7.5.161. F30 - Window Scope Expansion . . . . . . . . . . . . 312
7.5.162. F31 - Authorization Consumption Crash . . . . . . . 312
7.5.163. F32 - External Duplicate Effect . . . . . . . . . . 312
7.5.164. F33 - Session Terminated With Queued Operations . . 312
7.5.165. F34 - Protected-State Rollback . . . . . . . . . . . 312
7.5.166. F35 - Low-Latency Fast-Path Bypass . . . . . . . . . 312
7.5.167. F36 - Invalid Behavioral Revalidation . . . . . . . 312
7.5.168. PART XVI - IMPLEMENTATION VARIATIONS . . . . . . . . 313
7.5.169. C-21.76 - Per-Act Protected Finality . . . . . . . . 313
7.5.170. C-21.77 - Bounded Multi-Act Finality . . . . . . . . 313
7.5.171. C-21.81 - Micro-VM Continuous Agent . . . . . . . . 313
7.5.172. C-21.82 - Cloud-Hosted Session . . . . . . . . . . . 313
7.5.173. C-21.83 - Low-Latency Network Gateway . . . . . . . 313
Das Expires 25 April 2027 [Page 20]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.174. C-21.84 - Hardware Counter Implementation . . . . . 314
7.5.175. C-21.85 - Protected Database Transaction
Implementation . . . . . . . . . . . . . . . . . . . 314
7.5.176. C-21.86 - Distributed Session Grant
Implementation . . . . . . . . . . . . . . . . . . . 314
7.5.177. C-21.87 - Disconnected Operation Variation . . . . . 314
7.5.178. C-21.88 - Hardware-Accelerated Window
Verification . . . . . . . . . . . . . . . . . . . . 314
7.5.179. C-21.89 - Integrated Single-Node Controller . . . . 315
7.5.180. PART XVII - REPRESENTATIVE DATA STRUCTURES . . . . . 315
7.5.181. C-21.90 - ProtectedSessionRecord . . . . . . . . . . 315
7.5.182. C-21.91 - InitialPermissionEnvelopeRecord . . . . . 315
7.5.183. C-21.92 - SessionCandidateActRecord . . . . . . . . 315
7.5.184. C-21.93 - ProtectedWindowGrantRecord . . . . . . . . 315
7.5.185. C-21.94 - MicroValidationRecord . . . . . . . . . . 316
7.5.186. C-21.95 - ProtectedChainStateRecord . . . . . . . . 316
7.5.187. C-21.96 - RuntimeBehavioralDescriptorRecord . . . . 316
7.5.188. C-21.97 - ProtectedBudgetRecord . . . . . . . . . . 316
7.5.189. C-21.98 - SinkLocalWindowStateRecord . . . . . . . . 316
7.5.190. C-21.99 - SessionRecoveryRecord . . . . . . . . . . 317
7.5.191. PART XVIII - implementer VERIFICATION TESTS . . . . 317
7.5.192. C-21.100 - Representative Engineering Test Matrix . 317
7.5.193. Test Condition . . . . . . . . . . . . . . . . . . . 317
7.5.194. Expected technical result . . . . . . . . . . . . . 317
7.5.195. PART XIX - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 318
7.5.196. C-21.101 - Independent enforcement point(s)
corresponding to source item(s) 21 . . . . . . . . . 318
7.5.197. C-21.102 - Dependent enforcement point(s)
corresponding to source item(s) 22: Micro-Receipt
Chain . . . . . . . . . . . . . . . . . . . . . . . . 319
7.5.198. PART XX - IMPLEMENTATION REQUIREMENTS . . . . . . . 320
7.5.199. C-21.107 - implementer Implementation Checklist . . 320
7.5.200. C-21.108 - Technical Effect . . . . . . . . . . . . 321
7.5.201. C-21.109 - Technical Summary . . . . . . . . . . . . 322
7.6. Implementation Profile C-33 . . . . . . . . . . . . . . . 323
7.6.1. C-33.1 - Technical Field . . . . . . . . . . . . . . 323
7.6.2. C-33.2 - Technical Problem . . . . . . . . . . . . . 324
7.6.3. C-33.3 - Central Technical Principle . . . . . . . . 325
7.6.4. Every enabled relevant path capable of producing the
governed effect must be . . . . . . . . . . . . . . . 325
7.6.5. PART I - PRINCIPAL SYSTEM ARCHITECTURE . . . . . . . 325
7.6.6. C-33.4 - Principal Components . . . . . . . . . . . . 326
7.6.7. Component A - Agent Execution Environment . . . . . . 326
7.6.8. Component B - Effectuation-Path Discovery
Controller . . . . . . . . . . . . . . . . . . . . . 326
7.6.9. Component C - Effectuation-Path Registry . . . . . . 326
7.6.10. Component D - Effectuation-Class Controller . . . . . 326
Das Expires 25 April 2027 [Page 21]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.11. Component E - Path Coverage Verifier . . . . . . . . 326
7.6.12. Component F - Parent Finality Sink Verifier . . . . . 326
7.6.13. Component G - Path Disablement Controller . . . . . . 326
7.6.14. Component H - Dynamic Topology Controller . . . . . . 327
7.6.15. Component I - Protected Enforcement Domain . . . . . 327
7.6.16. Component J - Protected Coverage-State Registry . . . 327
7.6.17. Component K - Candidate Act Interceptor . . . . . . . 327
7.6.18. Component L - Non-Effective Operation Holder . . . . 327
7.6.19. Component M - Protected Validation Evidence
Controller . . . . . . . . . . . . . . . . . . . . . 327
7.6.20. Component N - Scoped Finality Enablement
Controller . . . . . . . . . . . . . . . . . . . . . 327
7.6.21. Component O - Finality Sink . . . . . . . . . . . . . 327
7.6.22. Component P - Coverage Recovery Controller . . . . . 327
7.6.23. C-33.5 - Reference Architecture . . . . . . . . . . . 328
7.6.24. PART II - EFFECTUATION-PATH DEFINITIONS . . . . . . . 329
7.6.25. C-33.6 - Effectuation Path . . . . . . . . . . . . . 329
7.6.26. C-33.7 - Effect-Capable Interface . . . . . . . . . . 329
7.6.27. C-33.8 - Governed Effect Class . . . . . . . . . . . 330
7.6.28. C-33.9 - Path Enablement State . . . . . . . . . . . 330
7.6.29. PART III - EFFECTUATION-PATH REGISTRY . . . . . . . . 331
7.6.30. C-33.10 - Path Registry Record . . . . . . . . . . . 331
7.6.31. C-33.11 - Registry Scope . . . . . . . . . . . . . . 332
7.6.32. C-33.12 - Registry Discovery Sources . . . . . . . . 332
7.6.33. C-33.13 - Trusted Path Observation . . . . . . . . . 333
7.6.34. PART IV - MACHINE-VERIFIABLE COVERAGE MODEL . . . . . 333
7.6.35. C-33.14 - Bounded Effectuation Graph . . . . . . . . 333
7.6.36. C-33.15 - Enabled Relevant Paths . . . . . . . . . . 334
7.6.37. C-33.16 - Coverage Classification . . . . . . . . . . 334
7.6.38. C-33.17 - Coverage Predicate . . . . . . . . . . . . 335
7.6.39. C-33.18 - Effect-Specific Coverage . . . . . . . . . 335
7.6.40. PART V - VERIFIED PARENT FINALITY SINK . . . . . . . 335
7.6.41. C-33.19 - Parent Finality Sink . . . . . . . . . . . 336
7.6.42. C-33.20 - Parent-Sink Dominance . . . . . . . . . . . 336
7.6.43. C-33.21 - Parent-Sink Verification Conditions . . . . 336
7.6.44. C-33.22 - Parent-Sink Dominance Algorithm . . . . . . 337
7.6.45. C-33.23 - Parent-Sink Delegation . . . . . . . . . . 337
7.6.46. PART VI - TECHNICAL DISABLEMENT . . . . . . . . . . . 338
7.6.47. C-33.24 - Disabled Effectuation Path . . . . . . . . 338
7.6.48. C-33.25 - Disablement Verification . . . . . . . . . 338
7.6.49. C-33.26 - Effect Prevention Without Total
Disablement . . . . . . . . . . . . . . . . . . . . . 339
7.6.50. PART VII - HOST, CONTAINER, AND KERNEL COVERAGE . . . 339
7.6.51. C-33.27 - Process-Execution Paths . . . . . . . . . . 339
7.6.52. C-33.28 - Container Coverage . . . . . . . . . . . . 340
7.6.53. C-33.29 - Kernel and System-Call Coverage . . . . . . 340
7.6.54. C-33.30 - Existing Handles and Asynchronous
Interfaces . . . . . . . . . . . . . . . . . . . . . 341
Das Expires 25 April 2027 [Page 22]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.55. PART VIII - PROXY, API GATEWAY, AND CONNECTOR
COVERAGE . . . . . . . . . . . . . . . . . . . . . . 341
7.6.56. C-33.31 - Network Proxy as Finality Sink . . . . . . 341
7.6.57. C-33.32 - API Gateway as Finality Sink . . . . . . . 341
7.6.58. C-33.33 - Connector Gateway Coverage . . . . . . . . 342
7.6.59. C-33.34 - Credential-Path Coverage . . . . . . . . . 342
7.6.60. PART IX - ALTERNATIVE PATHS AND FAILOVER . . . . . . 342
7.6.61. C-33.35 - Alternative Path . . . . . . . . . . . . . 343
7.6.62. C-33.36 - Dynamic Path Activation . . . . . . . . . . 343
7.6.63. C-33.37 - Failover Barrier . . . . . . . . . . . . . 343
7.6.64. C-33.38 - Failover Race Protection . . . . . . . . . 344
7.6.65. PART X - NON-NETWORK EFFECTUATION COVERAGE . . . . . 344
7.6.66. C-33.39 - File-System Mutation . . . . . . . . . . . 344
7.6.67. C-33.40 - Database Commit . . . . . . . . . . . . . . 345
7.6.68. C-33.41 - Persistent Memory Mutation . . . . . . . . 345
7.6.69. C-33.42 - Peripheral and Device Operation . . . . . . 345
7.6.70. C-33.43 - Display and Rendering Release . . . . . . . 346
7.6.71. C-33.44 - DMA Operation . . . . . . . . . . . . . . . 346
7.6.72. PART XI - PROTECTED COVERAGE-STATE COMMITMENT . . . . 346
7.6.73. C-33.45 - Coverage Generation . . . . . . . . . . . . 346
7.6.74. C-33.46 - Protected Coverage Commitment . . . . . . . 347
7.6.75. C-33.47 - Coverage Commitment and Candidate Act . . . 347
7.6.76. C-33.48 - Coverage-Aware Finality Capability . . . . 348
7.6.77. C-33.49 - Material Coverage Change . . . . . . . . . 348
7.6.78. C-33.50 - Coverage Invalidation . . . . . . . . . . . 348
7.6.79. PART XII - PROTECTED VALIDATION AND FINALITY . . . . 349
7.6.80. C-33.51 - Candidate Act Capture . . . . . . . . . . . 349
7.6.81. C-33.52 - PED Coverage Predicate Evaluation . . . . . 349
7.6.82. C-33.53 - Protected Validation Evidence . . . . . . . 350
7.6.83. C-33.54 - Scoped Finality Enablement . . . . . . . . 350
7.6.84. C-33.55 - Finality Sink Verification . . . . . . . . 351
7.6.85. PART XIII - PRINCIPAL EXECUTION WORKFLOW . . . . . . 351
7.6.86. C-33.56 - Complete 30-Step Workflow . . . . . . . . . 351
7.6.87. Step C33-01 - Execution environment initialization . 351
7.6.88. Step C33-02 - Effect-class definition . . . . . . . . 351
7.6.89. Step C33-03 - Interface inventory . . . . . . . . . . 351
7.6.90. Step C33-04 - Path registry construction . . . . . . 351
7.6.91. Step C33-05 - Enabled-path determination . . . . . . 351
7.6.92. Step C33-06 - Sink association . . . . . . . . . . . 352
7.6.93. Step C33-07 - Parent-sink verification . . . . . . . 352
7.6.94. Step C33-08 - Coverage predicate evaluation . . . . . 352
7.6.95. Step C33-09 - Protected coverage commitment . . . . . 352
7.6.96. Step C33-10 - Agent execution . . . . . . . . . . . . 352
7.6.97. Step C33-11 - Proposed operation generation . . . . . 352
7.6.98. Step C33-12 - Candidate Act interception . . . . . . 352
7.6.99. Step C33-13 - Non-effective staging . . . . . . . . . 352
7.6.100. Step C33-14 - Candidate descriptor construction . . 352
7.6.101. Step C33-15 - Effect-class association . . . . . . . 352
Das Expires 25 April 2027 [Page 23]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.102. Step C33-16 - Current registry lookup . . . . . . . 352
7.6.103. Step C33-17 - Coverage revalidation . . . . . . . . 353
7.6.104. Step C33-18 - Protected authority-state retrieval . 353
7.6.105. Step C33-19 - Operation-specific predicate
evaluation . . . . . . . . . . . . . . . . . . . . . 353
7.6.106. Step C33-20 - Protected state operation . . . . . . 353
7.6.107. Step C33-21 - Validation evidence commitment . . . . 353
7.6.108. Step C33-22 - Scoped finality authorization . . . . 353
7.6.109. Step C33-23 - Operation presentation to sink . . . . 353
7.6.110. Step C33-24 - Actual pending operation
reconstruction . . . . . . . . . . . . . . . . . . . 353
7.6.111. Step C33-25 - Coverage-generation verification . . . 353
7.6.112. Step C33-26 - Capability and authority
verification . . . . . . . . . . . . . . . . . . . . 353
7.6.113. Step C33-27 - Protected consumption transition . . . 353
7.6.114. Step C33-28 - Controlled effectuation . . . . . . . 354
7.6.115. Step C33-29 - Completion-state update . . . . . . . 354
7.6.116. Step C33-30 - Dynamic coverage maintenance . . . . . 354
7.6.117. PART XIV - REFERENCE ALGORITHMS . . . . . . . . . . 354
7.6.118. C-33.57 - Algorithm A: Path Registry Construction . 354
7.6.119. C-33.58 - Algorithm B: Coverage Predicate . . . . . 355
7.6.120. C-33.60 - Algorithm D: Parent-Sink Verification . . 356
7.6.121. C-33.63 - Algorithm G: Dynamic Path Activation . . . 360
7.6.122. C-33.64 - Algorithm H: Failover Enforcement . . . . 360
7.6.123. PART XV - WORKED TECHNICAL EXAMPLES . . . . . . . . 362
7.6.124. C-33.66 - Example A: Network Proxy Bypass . . . . . 362
7.6.125. C-33.69 - Example D: API Gateway Failover . . . . . 364
7.6.126. C-33.71 - Example F: Hardware DMA Bypass . . . . . . 364
7.6.127. C-33.73 - Example H: Protected Rendering Release . . 365
7.6.128. PART XVI - FAILURE AND ADVERSARIAL SCENARIOS . . . . 366
7.6.129. C-33.75 - Representative Failure Conditions . . . . 366
7.6.130. F1 - Unregistered Enabled Path . . . . . . . . . . . 366
7.6.131. F2 - Invalid Path Registry Entry . . . . . . . . . . 366
7.6.132. F3 - Unsupported Parent-Sink Assertion . . . . . . . 366
7.6.133. F4 - Direct Socket Bypass . . . . . . . . . . . . . 366
7.6.134. F5 - Privileged Process Bypass . . . . . . . . . . . 367
7.6.135. F6 - Container Host Interface Exposure . . . . . . . 367
7.6.136. F7 - Existing File Descriptor . . . . . . . . . . . 367
7.6.137. F8 - Alternative Network Adapter . . . . . . . . . . 367
7.6.138. F9 - Credential Copy . . . . . . . . . . . . . . . . 367
7.6.139. F10 - Connector Replacement . . . . . . . . . . . . 367
7.6.140. F11 - Backup Service Activation . . . . . . . . . . 367
7.6.141. F12 - Maintenance Mode . . . . . . . . . . . . . . . 368
7.6.142. F13 - Diagnostic Interface . . . . . . . . . . . . . 368
7.6.143. F14 - Device Pass-Through . . . . . . . . . . . . . 368
7.6.144. F15 - DMA Alternate Path . . . . . . . . . . . . . . 368
7.6.145. F16 - API Protocol Translation . . . . . . . . . . . 368
7.6.146. F17 - Parent-Sink Failure . . . . . . . . . . . . . 368
Das Expires 25 April 2027 [Page 24]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.147. F18 - Failover Race . . . . . . . . . . . . . . . . 368
7.6.148. F19 - Coverage Generation Mismatch . . . . . . . . . 369
7.6.149. F20 - Registry Rollback . . . . . . . . . . . . . . 369
7.6.150. F21 - Incomplete Path Discovery . . . . . . . . . . 369
7.6.151. F22 - Telemetry-Only Enforcement . . . . . . . . . . 369
7.6.152. F23 - Remote Resource Commit Misclassification . . . 369
7.6.153. F24 - Asynchronous Worker Bypass . . . . . . . . . . 369
7.6.154. F25 - New Effect-Capable Tool . . . . . . . . . . . 369
7.6.155. F26 - Privilege Escalation . . . . . . . . . . . . . 370
7.6.156. F27 - Kernel Enforcement Program Removal . . . . . . 370
7.6.157. F28 - Unverified Hardware Controller . . . . . . . . 370
7.6.158. F29 - Concurrent Coverage Update . . . . . . . . . . 370
7.6.159. F30 - Finality Sink Substitution . . . . . . . . . . 370
7.6.160. F31 - Non-Network Disclosure Path . . . . . . . . . 370
7.6.161. F32 - Protected Evidence Missing Coverage Binding . 370
7.6.162. F33 - Unresolved Effectuation Path . . . . . . . . . 371
7.6.163. F34 - Stale Path Disablement . . . . . . . . . . . . 371
7.6.164. F35 - External Completion Uncertain . . . . . . . . 371
7.6.165. F36 - Coverage Registry Compromise . . . . . . . . . 371
7.6.166. C-33.80 - Cloud Gateway Implementation . . . . . . . 371
7.6.167. C-33.81 - Credential-Broker Implementation . . . . . 371
7.6.168. C-33.82 - Hardware Network Implementation . . . . . 372
7.6.169. C-33.83 - Storage and Database Implementation . . . 372
7.6.170. C-33.84 - Peripheral-Control Implementation . . . . 372
7.6.171. C-33.85 - Rendering Finality Implementation . . . . 372
7.6.172. C-33.86 - Distributed Parent-Sink Implementation . . 372
7.6.173. C-33.90 - EffectClassRecord . . . . . . . . . . . . 373
7.6.174. C-33.91 - FinalitySinkBindingRecord . . . . . . . . 373
7.6.175. C-33.92 - ParentSinkCoverageRecord . . . . . . . . . 373
7.6.176. C-33.93 - PathDisablementRecord . . . . . . . . . . 373
7.6.177. C-33.94 - ProtectedCoverageStateRecord . . . . . . . 373
7.6.178. C-33.95 - CoverageBoundCandidateActRecord . . . . . 374
7.6.179. C-33.96 - CoverageValidationEvidenceRecord . . . . . 374
7.6.180. C-33.97 - CoverageBoundCapabilityRecord . . . . . . 374
7.6.181. C-33.98 - PathTopologyEventRecord . . . . . . . . . 374
7.6.182. C-33.99 - CoverageRecoveryRecord . . . . . . . . . . 374
7.6.183. PART XIX - implementer VERIFICATION TESTS . . . . . 375
7.6.184. C-33.100 - Representative Engineering Test Matrix . 375
7.6.185. Test Condition . . . . . . . . . . . . . . . . . . . 375
7.6.186. Expected technical result . . . . . . . . . . . . . 375
7.6.187. PART XX - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 376
7.6.188. C-33.101 - Independent enforcement point(s)
corresponding to source item(s) 33 . . . . . . . . . 376
7.6.189. PART XXI - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 378
7.6.190. C-33.107 - Implementation Checklist . . . . . . . . 378
7.6.191. C-33.108 - Technical Effect . . . . . . . . . . . . 379
Das Expires 25 April 2027 [Page 25]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.192. C-33.109 - Technical Summary . . . . . . . . . . . . 380
7.7. Implementation Profile C-42 . . . . . . . . . . . . . . . 381
7.7.1. C-42.1 - Technical Field . . . . . . . . . . . . . . 381
7.7.2. PART I - TECHNICAL PROBLEM AND INVENTIVE MECHANISM . 382
7.7.3. C-42.2 - Technical Problem . . . . . . . . . . . . . 382
7.7.4. C-42.3 - Central Technical Principle . . . . . . . . 383
7.7.5. C-42.4 - Relationship to Protected Execution
Finality . . . . . . . . . . . . . . . . . . . . . . 384
7.7.6. PART II - PRINCIPAL SYSTEM COMPONENTS . . . . . . . . 385
7.7.7. C-42.5 - Agent Execution Environment . . . . . . . . 385
7.7.8. C-42.6 - Protected Execution Identity Controller . . 385
7.7.9. C-42.7 - Runtime Observation Controller . . . . . . . 386
7.7.10. C-42.8 - Process-Lineage Registry . . . . . . . . . . 386
7.7.11. C-42.9 - Taint-State Controller . . . . . . . . . . . 386
7.7.12. C-42.10 - Protected Authority-State Controller . . . 386
7.7.13. C-42.11 - Effectuation Controller . . . . . . . . . . 387
7.7.14. C-42.12 - Outstanding Operation Controller . . . . . 387
7.7.15. C-42.13 - Recovery Controller . . . . . . . . . . . . 387
7.7.16. PART III - PROCESS INSTANCE IDENTIFICATION . . . . . 388
7.7.17. C-42.14 - Process Identity Versus Process
Identifier . . . . . . . . . . . . . . . . . . . . . 388
7.7.18. C-42.15 - Execution Generation . . . . . . . . . . . 388
7.7.19. C-42.16 - Agent and Task Association . . . . . . . . 389
7.7.20. PART IV - FORMAL LINEAGE MODEL . . . . . . . . . . . 389
7.7.21. C-42.17 - Process-Lineage Graph . . . . . . . . . . . 389
7.7.22. C-42.18 - Lineage Edge Record . . . . . . . . . . . . 390
7.7.23. C-42.19 - Source-to-Descendant Propagation . . . . . 390
7.7.24. C-42.20 - Transitive Propagation . . . . . . . . . . 391
7.7.25. C-42.21 - Propagation Policy . . . . . . . . . . . . 391
7.7.26. Relationship . . . . . . . . . . . . . . . . . . . . 391
7.7.27. Representative propagation rule . . . . . . . . . . . 392
7.7.28. PART V - TAINT STATE REPRESENTATION . . . . . . . . . 392
7.7.29. C-42.22 - Taint-State Record . . . . . . . . . . . . 392
7.7.30. C-42.23 - Taint Label Classes . . . . . . . . . . . . 393
7.7.31. C-42.24 - Monotonic Restriction Variation . . . . . . 393
7.7.32. C-42.25 - Trust and Restriction Separation . . . . . 394
7.7.33. PART VI - TRUSTED TAINT ACQUISITION . . . . . . . . . 394
7.7.34. C-42.26 - Collection-Time Observation . . . . . . . . 394
7.7.35. C-42.27 - Taint Before Use . . . . . . . . . . . . . 394
7.7.36. C-42.28 - Asynchronous Observation Limitation . . . . 395
7.7.37. C-42.29 - Controlled Tool Results . . . . . . . . . . 395
7.7.38. PART VII - PROCESS CREATION AND EXECUTABLE
REPLACEMENT . . . . . . . . . . . . . . . . . . . . . 396
7.7.39. C-42.30 - Child Process Creation . . . . . . . . . . 396
7.7.40. C-42.31 - Process Fork . . . . . . . . . . . . . . . 396
7.7.41. C-42.32 - Executable Replacement . . . . . . . . . . 396
7.7.42. C-42.33 - Interpreter and Shell Execution . . . . . . 397
7.7.43. C-42.34 - Process Identifier Reuse . . . . . . . . . 397
Das Expires 25 April 2027 [Page 26]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.44. PART VIII - IPC AND DATA-OBJECT TAINT . . . . . . . . 397
7.7.45. C-42.35 - Interprocess Communication . . . . . . . . 397
7.7.46. C-42.36 - IPC Taint Propagation . . . . . . . . . . . 398
7.7.47. C-42.37 - File-Mediated Propagation . . . . . . . . . 398
7.7.48. C-42.38 - Shared Memory . . . . . . . . . . . . . . . 398
7.7.49. C-42.39 - Descriptor Passing . . . . . . . . . . . . 399
7.7.50. PART IX - DELEGATED AND REMOTE WORKERS . . . . . . . 399
7.7.51. C-42.40 - Delegated Worker . . . . . . . . . . . . . 399
7.7.52. C-42.41 - Protected Delegation Record . . . . . . . . 399
7.7.53. C-42.42 - Remote Worker Handoff . . . . . . . . . . . 400
7.7.54. C-42.43 - Taint Across Administrative Domains . . . . 400
7.7.55. PART X - PROTECTED AUTHORITY TRANSITIONS . . . . . . 401
7.7.56. C-42.44 - Protected Permission State . . . . . . . . 401
7.7.57. C-42.45 - Taint-Triggered Authority Change . . . . . 401
7.7.58. C-42.46 - Protected Authority Generation . . . . . . 402
7.7.59. C-42.47 - Revocation Scope . . . . . . . . . . . . . 402
7.7.60. C-42.48 - Authorized Declassification . . . . . . . . 403
7.7.61. PART XI - AUTHORITY REVOCATION BARRIER . . . . . . . 403
7.7.62. C-42.49 - Revocation Barrier . . . . . . . . . . . . 403
7.7.63. C-42.50 - Revocation Ordering . . . . . . . . . . . . 404
7.7.64. C-42.51 - Enforcement Convergence . . . . . . . . . . 404
7.7.65. PART XII - FINALITY SINK CONTROL . . . . . . . . . . 405
7.7.66. C-42.52 - Candidate Act Capture . . . . . . . . . . . 405
7.7.67. C-42.53 - PED Taint-Aware Validation . . . . . . . . 405
7.7.68. C-42.54 - Protected Validation Evidence . . . . . . . 406
7.7.69. C-42.55 - Scoped Finality Authorization . . . . . . . 406
7.7.70. C-42.56 - Finality Sink Verification . . . . . . . . 407
7.7.71. C-42.57 - Non-Bypassability . . . . . . . . . . . . . 407
7.7.72. PART XIII - OUTSTANDING ASYNCHRONOUS OPERATIONS . . . 408
7.7.73. C-42.58 - Outstanding Operation States . . . . . . . 408
7.7.74. C-42.59 - Revocation of Queued Operations . . . . . . 408
7.7.75. C-42.60 - Dispatched Operations . . . . . . . . . . . 409
7.7.76. C-42.61 - Outstanding Credential Requests . . . . . . 409
7.7.77. C-42.62 - Outstanding Device or Network Commands . . 409
7.7.78. PART XIV - PRINCIPAL 32-STEP WORKFLOW . . . . . . . . 410
7.7.79. C-42.63 - Complete Protected Process-Lineage
Workflow . . . . . . . . . . . . . . . . . . . . . . 410
7.7.80. Step C42-01 - Agent environment initialization . . . 410
7.7.81. Step C42-02 - Process identity registration . . . . . 410
7.7.82. Step C42-03 - Execution-generation assignment . . . . 410
7.7.83. Step C42-04 - Initial authority-state
establishment . . . . . . . . . . . . . . . . . . . . 410
7.7.84. Step C42-05 - Observation-boundary activation . . . . 410
7.7.85. Step C42-06 - Agent computation . . . . . . . . . . . 410
7.7.86. Step C42-07 - Security-relevant event occurrence . . 410
7.7.87. Step C42-08 - Trusted event attribution . . . . . . . 411
7.7.88. Step C42-09 - Source classification . . . . . . . . . 411
7.7.89. Step C42-10 - Protected lineage-event commitment . . 411
Das Expires 25 April 2027 [Page 27]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.90. Step C42-11 - Taint-state calculation . . . . . . . . 411
7.7.91. Step C42-12 - Protected taint-state update . . . . . 411
7.7.92. Step C42-13 - Affected-context computation . . . . . 411
7.7.93. Step C42-14 - Transitive propagation . . . . . . . . 411
7.7.94. Step C42-15 - Authority-policy evaluation . . . . . . 411
7.7.95. Step C42-16 - Authority-generation transition . . . . 411
7.7.96. Step C42-17 - Enforcement-path restriction . . . . . 411
7.7.97. Step C42-18 - Outstanding-operation identification . 412
7.7.98. Step C42-19 - Outstanding-operation restriction . . . 412
7.7.99. Step C42-20 - Agent operation proposal . . . . . . . 412
7.7.100. Step C42-21 - Candidate Act interception . . . . . . 412
7.7.101. Step C42-22 - Non-effective staging . . . . . . . . 412
7.7.102. Step C42-23 - Actual descriptor construction . . . . 412
7.7.103. Step C42-24 - PED current-state lookup . . . . . . . 412
7.7.104. Step C42-25 - Operation-specific validation . . . . 412
7.7.105. Step C42-26 - Protected evidence commitment . . . . 412
7.7.106. Step C42-27 - Scoped finality enablement . . . . . . 412
7.7.107. Step C42-28 - Actual operation presentation . . . . 412
7.7.108. Step C42-29 - Sink-side current-state
verification . . . . . . . . . . . . . . . . . . . . 413
7.7.109. Step C42-30 - Effectuation decision . . . . . . . . 413
7.7.110. Step C42-31 - Protected consumption and outcome
update . . . . . . . . . . . . . . . . . . . . . . . 413
7.7.111. Step C42-32 - Recovery and continuity maintenance . 413
7.7.112. PART XV - REFERENCE IMPLEMENTATION ALGORITHMS . . . 413
7.7.113. C-42.65 - Algorithm B: Trusted Taint Acquisition . . 414
7.7.114. C-42.68 - Algorithm E: IPC Taint Propagation . . . . 417
7.7.115. C-42.71 - Algorithm H: Finality Sink Verification . 421
7.7.116. PART XVI - WORKED TECHNICAL EXAMPLES . . . . . . . . 425
7.7.117. C-42.80 - Example G: Remote Delegated Worker . . . . 428
7.7.118. C-42.81 - Example H: Process-ID Recycling . . . . . 428
7.7.119. C-42.82 - Example I: Required Observation Failure . 429
7.7.120. C-42.83 - Example J: Authorized Declassification . . 429
7.7.121. PART XVII - FAILURE AND ADVERSARIAL CONDITIONS . . . 430
7.7.122. C-42.84 - Representative Failure Cases . . . . . . . 430
7.7.123. F1 - Child Process Escape . . . . . . . . . . . . . 430
7.7.124. F2 - Executable Replacement . . . . . . . . . . . . 430
7.7.125. F3 - Process-ID Reuse . . . . . . . . . . . . . . . 430
7.7.126. F4 - Shell Indirection . . . . . . . . . . . . . . . 430
7.7.127. F5 - IPC Laundering . . . . . . . . . . . . . . . . 430
7.7.128. F6 - File-Based Laundering . . . . . . . . . . . . . 430
7.7.129. F7 - Shared Memory Laundering . . . . . . . . . . . 430
7.7.130. F8 - Descriptor Transfer . . . . . . . . . . . . . . 431
7.7.131. F9 - Untrusted Tool Result . . . . . . . . . . . . . 431
7.7.132. F10 - Unverified Remote Delegation . . . . . . . . . 431
7.7.133. F11 - Process-Lineage Record Tampering . . . . . . . 431
7.7.134. F12 - Forged Parent Identity . . . . . . . . . . . . 431
7.7.135. F13 - Lost Observation . . . . . . . . . . . . . . . 431
Das Expires 25 April 2027 [Page 28]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.136. F14 - Delayed Observation . . . . . . . . . . . . . 431
7.7.137. F15 - Authority Generation Replay . . . . . . . . . 432
7.7.138. F16 - Taint Generation Replay . . . . . . . . . . . 432
7.7.139. F17 - Taint Clearing by Environment Variable . . . . 432
7.7.140. F18 - Credential Broker Bypass . . . . . . . . . . . 432
7.7.141. F19 - Direct Network Bypass . . . . . . . . . . . . 432
7.7.142. F20 - Asynchronous Job Continuation . . . . . . . . 432
7.7.143. F21 - Already Dispatched External Operation . . . . 432
7.7.144. F22 - Concurrent Taint Transition . . . . . . . . . 433
7.7.145. F23 - Concurrent Descendant Creation . . . . . . . . 433
7.7.146. F24 - Registry Unavailability . . . . . . . . . . . 433
7.7.147. F25 - Invalid Declassification . . . . . . . . . . . 433
7.7.148. F26 - Overly Broad Taint Propagation . . . . . . . . 433
7.7.149. F27 - Incomplete IPC Coverage . . . . . . . . . . . 433
7.7.150. F28 - Unknown Process Origin . . . . . . . . . . . . 433
7.7.151. F29 - Wrong Execution Generation . . . . . . . . . . 434
7.7.152. F30 - Wrong Agent Context . . . . . . . . . . . . . 434
7.7.153. F31 - Revocation Delivery Failure . . . . . . . . . 434
7.7.154. F32 - Protected State Rollback . . . . . . . . . . . 434
7.7.155. F33 - Tool Replacement . . . . . . . . . . . . . . . 434
7.7.156. F34 - Partial Effectuation . . . . . . . . . . . . . 434
7.7.157. F35 - Malicious Observation Producer . . . . . . . . 434
7.7.158. F36 - Excessive Lineage Growth . . . . . . . . . . . 435
7.7.159. C-42.88 - macOS Process Implementation . . . . . . . 435
7.7.160. C-42.89 - Container-Isolated Implementation . . . . 435
7.7.161. C-42.92 - TEE-Assisted Taint Registry . . . . . . . 435
7.7.162. C-42.93 - HSM-Assisted Evidence Implementation . . . 436
7.7.163. C-42.97 - Integrated Single-Node PED and Sink . . . 436
7.7.164. PART XIX - TECHNICAL DATA STRUCTURES . . . . . . . . 436
7.7.165. C-42.98 - ProcessInstanceRecord . . . . . . . . . . 436
7.7.166. C-42.99 - LineageEdgeRecord . . . . . . . . . . . . 436
7.7.167. C-42.100 - TaintStateRecord . . . . . . . . . . . . 437
7.7.168. C-42.101 - ObservationEventRecord . . . . . . . . . 437
7.7.169. C-42.102 - ProtectedAuthorityRestrictionRecord . . . 437
7.7.170. C-42.103 - DelegatedWorkerLineageRecord . . . . . . 437
7.7.171. C-42.104 - CandidateActTaintRecord . . . . . . . . . 437
7.7.172. C-42.105 - TaintValidationEvidenceRecord . . . . . . 438
7.7.173. C-42.106 - RevocationBarrierRecord . . . . . . . . . 438
7.7.174. C-42.107 - OutstandingOperationRecord . . . . . . . 438
7.7.175. PART XX - ENGINEERING VERIFICATION . . . . . . . . . 438
7.7.176. C-42.108 - Proposed Verification Test Matrix . . . . 438
7.7.177. Test Condition . . . . . . . . . . . . . . . . . . . 438
7.7.178. Expected behavior . . . . . . . . . . . . . . . . . 439
7.7.179. PART XXI - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 440
7.7.180. C-42.109 - Reconstructed Independent enforcement
point(s) corresponding to source item(s) 42 . . . . . 440
Das Expires 25 April 2027 [Page 29]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.181. C-42.110 - Reconstructed Dependent enforcement
point(s) corresponding to source item(s) 43 . . . . . 441
7.7.182. C-42.111 - Reconstructed Dependent enforcement
point(s) corresponding to source item(s) 44 . . . . . 441
7.7.183. PART XXII - implementer IMPLEMENTATION
REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 441
7.7.184. C-42.112 - Implementation Checklist . . . . . . . . 441
7.7.185. C-42.113 - Technical Effect . . . . . . . . . . . . 442
7.8. Implementation Profile C-45 . . . . . . . . . . . . . . . 444
7.8.1. C-45.1 - Technical Field . . . . . . . . . . . . . . 444
7.8.2. PART I - TECHNICAL PROBLEM . . . . . . . . . . . . . 445
7.8.3. C-45.2 - Preliminary Destination Authorization Is
Insufficient . . . . . . . . . . . . . . . . . . . . 445
7.8.4. C-45.3 - DNS Rebinding Problem . . . . . . . . . . . 446
7.8.5. C-45.4 - Proxy and Connector Transformation
Problem . . . . . . . . . . . . . . . . . . . . . . . 447
7.8.6. C-45.5 - Connection Reuse Problem . . . . . . . . . . 447
7.8.7. C-45.6 - Network Non-Bypassability Problem . . . . . 447
7.8.8. PART II - CENTRAL TECHNICAL PRINCIPLE . . . . . . . . 448
7.8.9. C-45.7 - Computation Is Not Network Authority . . . . 448
7.8.10. C-45.8 - Representative Security Relationship . . . . 448
7.8.11. PART III - PRINCIPAL SYSTEM COMPONENTS . . . . . . . 449
7.8.12. C-45.9 - Agent Execution Environment . . . . . . . . 449
7.8.13. C-45.10 - Network Operation Interceptor . . . . . . . 449
7.8.14. C-45.11 - Candidate Network Egress Holder . . . . . . 450
7.8.15. C-45.12 - Destination Resolution Controller . . . . . 450
7.8.16. C-45.13 - Protected Network Authority Registry . . . 451
7.8.17. C-45.14 - Protected Enforcement Domain . . . . . . . 451
7.8.18. C-45.15 - Protected Validation Evidence Controller . 452
7.8.19. C-45.16 - Scoped Network-Egress Capability
Controller . . . . . . . . . . . . . . . . . . . . . 452
7.8.20. C-45.17 - Network-Egress Finality Sink . . . . . . . 453
7.8.21. C-45.18 - Connection State Controller . . . . . . . . 453
7.8.22. C-45.19 - Alternate Egress Path Controller . . . . . 453
7.8.23. PART IV - NETWORK IDENTITY REPRESENTATIONS . . . . . 454
7.8.24. C-45.20 - Requested Destination Identity . . . . . . 454
7.8.25. C-45.21 - Hostname Canonicalization . . . . . . . . . 454
7.8.26. C-45.22 - DNS Answer Representation . . . . . . . . . 454
7.8.27. C-45.23 - Selected Endpoint . . . . . . . . . . . . . 455
7.8.28. C-45.24 - Effective Transport Endpoint . . . . . . . 456
7.8.29. C-45.25 - Application Service Identity . . . . . . . 456
7.8.30. C-45.26 - Effective Network Operation Descriptor . . 456
7.8.31. PART V - DESTINATION POLICY . . . . . . . . . . . . . 457
7.8.32. C-45.27 - Protected Destination Scope . . . . . . . . 457
7.8.33. C-45.28 - Network-Zone Classification . . . . . . . . 458
7.8.34. C-45.29 - Destination Allow Rules . . . . . . . . . . 458
7.8.35. C-45.30 - Address-Set Versus Selected-Address
Policy . . . . . . . . . . . . . . . . . . . . . . . 459
Das Expires 25 April 2027 [Page 30]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.36. PART VI - PROTECTED DNS RESOLUTION . . . . . . . . . 459
7.8.37. C-45.31 - Controlled Resolution . . . . . . . . . . . 459
7.8.38. C-45.32 - DNS Rebinding Protection . . . . . . . . . 459
7.8.39. C-45.33 - DNS Cache State . . . . . . . . . . . . . . 460
7.8.40. C-45.34 - Resolver Trust Boundary . . . . . . . . . . 460
7.8.41. PART VII - CONNECT AND TRANSPORT BINDING . . . . . . 461
7.8.42. C-45.35 - Connection Establishment . . . . . . . . . 461
7.8.43. C-45.36 - Connection Generation . . . . . . . . . . . 461
7.8.44. C-45.37 - Socket Peer Verification . . . . . . . . . 462
7.8.45. C-45.38 - Connection Binding . . . . . . . . . . . . 462
7.8.46. PART VIII - TLS AND AUTHENTICATED SERVICE IDENTITY . 463
7.8.47. C-45.39 - TLS Identity . . . . . . . . . . . . . . . 463
7.8.48. C-45.40 - Encrypted Payload Visibility . . . . . . . 463
7.8.49. C-45.41 - TLS-Terminating Finality Sink . . . . . . . 463
7.8.50. C-45.42 - End-to-End TLS Variation . . . . . . . . . 464
7.8.51. PART IX - REDIRECTS AND CONNECTION CHANGES . . . . . 464
7.8.52. C-45.43 - HTTP Redirect . . . . . . . . . . . . . . . 464
7.8.53. C-45.44 - Redirect Revalidation . . . . . . . . . . . 465
7.8.54. C-45.45 - Redirect Loop and Resource Limits . . . . . 465
7.8.55. C-45.46 - HTTP/2 Connection Coalescing . . . . . . . 465
7.8.56. C-45.47 - HTTP/3 and QUIC Migration . . . . . . . . . 466
7.8.57. C-45.48 - Reused HTTP Connection . . . . . . . . . . 466
7.8.58. PART X - PROXY AND ROUTING SEMANTICS . . . . . . . . 466
7.8.59. C-45.49 - Forward Proxy . . . . . . . . . . . . . . . 466
7.8.60. C-45.50 - CONNECT Tunnel . . . . . . . . . . . . . . 467
7.8.61. C-45.51 - Transparent Proxy . . . . . . . . . . . . . 467
7.8.62. C-45.52 - Remote DNS Resolution Through Proxy . . . . 468
7.8.63. C-45.53 - Network Address Translation . . . . . . . . 468
7.8.64. C-45.54 - Service Mesh . . . . . . . . . . . . . . . 468
7.8.65. PART XI - NETWORK CREDENTIAL USE . . . . . . . . . . 469
7.8.66. C-45.55 - Credential-Bearing Request . . . . . . . . 469
7.8.67. C-45.56 - Credential-to-Endpoint Binding . . . . . . 469
7.8.68. C-45.57 - Credential Substitution Ordering . . . . . 469
7.8.69. PART XII - PROTECTED VALIDATION AND FINALITY . . . . 470
7.8.70. C-45.58 - Candidate Network Egress Act . . . . . . . 470
7.8.71. C-45.59 - PED Authorization . . . . . . . . . . . . . 471
7.8.72. C-45.60 - Protected Validation Evidence . . . . . . . 471
7.8.73. C-45.61 - Scoped Non-Bearer Network Capability . . . 472
7.8.74. C-45.62 - Finality Sink Effective-Endpoint
Verification . . . . . . . . . . . . . . . . . . . . 472
7.8.75. C-45.63 - Finality Sink Consumption . . . . . . . . . 473
7.8.76. PART XIII - ALTERNATE EGRESS PATHS . . . . . . . . . 473
7.8.77. C-45.64 - Egress Path Registry . . . . . . . . . . . 473
7.8.78. C-45.65 - Direct Socket Restriction . . . . . . . . . 474
7.8.79. C-45.66 - Existing Connection Restriction . . . . . . 474
7.8.80. C-45.67 - Alternate Proxy and Failover . . . . . . . 475
7.8.81. PART XIV - NETWORK OPERATION STATE MACHINE . . . . . 475
7.8.82. C-45.68 - Principal Operation States . . . . . . . . 475
Das Expires 25 April 2027 [Page 31]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.83. C-45.69 - Connection Versus Request Finality . . . . 476
7.8.84. C-45.70 - Authorization State Following Endpoint
Change . . . . . . . . . . . . . . . . . . . . . . . 476
7.8.85. PART XV - COMPLETE PRINCIPAL EXECUTION WORKFLOW . . . 476
7.8.86. C-45.71 - Principal 36-Step Workflow . . . . . . . . 476
7.8.87. Step C45-01 - Agent execution context registration . 476
7.8.88. Step C45-02 - Network authority initialization . . . 477
7.8.89. Step C45-03 - Egress path restriction . . . . . . . . 477
7.8.90. Step C45-04 - Agent request creation . . . . . . . . 477
7.8.91. Step C45-05 - Request interception . . . . . . . . . 477
7.8.92. Step C45-06 - Candidate Act creation . . . . . . . . 477
7.8.93. Step C45-07 - Non-effective staging . . . . . . . . . 477
7.8.94. Step C45-08 - Requested destination parsing . . . . . 477
7.8.95. Step C45-09 - Canonicalization . . . . . . . . . . . 477
7.8.96. Step C45-10 - Preliminary authority classification . 477
7.8.97. Step C45-11 - Controlled destination resolution . . . 477
7.8.98. Step C45-12 - Resolution result recording . . . . . . 477
7.8.99. Step C45-13 - Endpoint selection . . . . . . . . . . 478
7.8.100. Step C45-14 - Network-zone classification . . . . . 478
7.8.101. Step C45-15 - Post-resolution destination
validation . . . . . . . . . . . . . . . . . . . . . 478
7.8.102. Step C45-16 - Effective operation descriptor
construction . . . . . . . . . . . . . . . . . . . . 478
7.8.103. Step C45-17 - PED submission . . . . . . . . . . . . 478
7.8.104. Step C45-18 - Protected authority-state retrieval . 478
7.8.105. Step C45-19 - Authority predicate evaluation . . . . 478
7.8.106. Step C45-20 - Protected authorization-state
operation . . . . . . . . . . . . . . . . . . . . . . 478
7.8.107. Step C45-21 - Validation evidence commitment . . . . 478
7.8.108. Step C45-22 - Scoped capability activation . . . . . 478
7.8.109. Step C45-23 - Connection selection . . . . . . . . . 478
7.8.110. Step C45-24 - Actual endpoint verification . . . . . 479
7.8.111. Step C45-25 - Transformation validation . . . . . . 479
7.8.112. Step C45-26 - Actual pending request
reconstruction . . . . . . . . . . . . . . . . . . . 479
7.8.113. Step C45-27 - Evidence verification . . . . . . . . 479
7.8.114. Step C45-28 - Capability verification . . . . . . . 479
7.8.115. Step C45-29 - Current destination verification . . . 479
7.8.116. Step C45-30 - Current authority verification . . . . 479
7.8.117. Step C45-31 - Protected consumption reservation . . 479
7.8.118. Step C45-32 - Credential application . . . . . . . . 479
7.8.119. Step C45-33 - Governed transmission . . . . . . . . 479
7.8.120. Step C45-34 - Completion observation . . . . . . . . 480
7.8.121. Step C45-35 - Protected outcome reconciliation . . . 480
7.8.122. Step C45-36 - Connection and authorization
maintenance . . . . . . . . . . . . . . . . . . . . . 480
7.8.123. PART XVI - REFERENCE ALGORITHMS . . . . . . . . . . 480
7.8.124. C-45.73 - Algorithm B: Controlled DNS Resolution . . 481
Das Expires 25 April 2027 [Page 32]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.125. C-45.75 - Algorithm D: PED Network Authorization . . 482
7.8.126. C-45.82 - Algorithm K: Proxy-Target Verification . . 489
7.8.127. C-45.83 - Algorithm L: Network Outcome Recovery . . 490
7.8.128. PART XVII - WORKED TECHNICAL EXAMPLES . . . . . . . 491
7.8.129. C-45.85 - Example B: Multiple DNS Addresses . . . . 492
7.8.130. C-45.87 - Example D: Forward Proxy With Remote
DNS . . . . . . . . . . . . . . . . . . . . . . . . . 492
7.8.131. C-45.89 - Example F: HTTP/2 Connection Reuse . . . . 493
7.8.132. C-45.90 - Example G: QUIC Network-Path Change . . . 494
7.8.133. C-45.91 - Example H: Direct Socket Bypass . . . . . 494
7.8.134. C-45.92 - Example I: Connection Revocation . . . . . 494
7.8.135. C-45.93 - Example J: Proxy Failover . . . . . . . . 495
7.8.136. C-45.94 - Example K: TLS Service Identity
Mismatch . . . . . . . . . . . . . . . . . . . . . . 495
7.8.137. PART XVIII - FAILURE AND ADVERSARIAL SCENARIOS . . . 496
7.8.138. C-45.96 - Representative Failure Conditions . . . . 496
7.8.139. F1 - DNS Rebinding . . . . . . . . . . . . . . . . . 496
7.8.140. F2 - DNS Answer Substitution . . . . . . . . . . . . 496
7.8.141. F3 - Multiple-Address Selection . . . . . . . . . . 496
7.8.142. F4 - IPv6 Bypass . . . . . . . . . . . . . . . . . . 496
7.8.143. F5 - Loopback Destination . . . . . . . . . . . . . 496
7.8.144. F6 - Link-Local Destination . . . . . . . . . . . . 497
7.8.145. F7 - Private-Network Pivot . . . . . . . . . . . . . 497
7.8.146. F8 - Cloud Metadata Access . . . . . . . . . . . . . 497
7.8.147. F9 - Hostname Parser Ambiguity . . . . . . . . . . . 497
7.8.148. F10 - URL Authority Confusion . . . . . . . . . . . 497
7.8.149. F11 - Redirect Destination Change . . . . . . . . . 497
7.8.150. F12 - Redirect Method Transformation . . . . . . . . 497
7.8.151. F13 - Excessive Redirect Chain . . . . . . . . . . . 498
7.8.152. F14 - Proxy Remote-Resolution Bypass . . . . . . . . 498
7.8.153. F15 - Proxy Identity Substitution . . . . . . . . . 498
7.8.154. F16 - CONNECT Tunnel Scope Expansion . . . . . . . . 498
7.8.155. F17 - Direct Socket Escape . . . . . . . . . . . . . 498
7.8.156. F18 - Existing Socket Reuse . . . . . . . . . . . . 498
7.8.157. F19 - HTTP/2 Origin Coalescing . . . . . . . . . . . 498
7.8.158. F20 - QUIC Path Migration . . . . . . . . . . . . . 499
7.8.159. F21 - TLS Identity Failure . . . . . . . . . . . . . 499
7.8.160. F22 - SNI Substitution . . . . . . . . . . . . . . . 499
7.8.161. F23 - HTTP Host Mismatch . . . . . . . . . . . . . . 499
7.8.162. F24 - Encrypted Payload Invisibility . . . . . . . . 499
7.8.163. F25 - Request Body Substitution . . . . . . . . . . 499
7.8.164. F26 - Credential Scope Mismatch . . . . . . . . . . 499
7.8.165. F27 - Capability Replay . . . . . . . . . . . . . . 500
7.8.166. F28 - Capability Used at Wrong Sink . . . . . . . . 500
7.8.167. F29 - Stale Authority Generation . . . . . . . . . . 500
7.8.168. F30 - Network Interface Failover . . . . . . . . . . 500
7.8.169. F31 - VPN or Tunnel Bypass . . . . . . . . . . . . . 500
7.8.170. F32 - Host Connector Bypass . . . . . . . . . . . . 500
Das Expires 25 April 2027 [Page 33]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.171. F33 - Redirect Through Another Connector . . . . . . 500
7.8.172. F34 - DNS Cache Rollback . . . . . . . . . . . . . . 501
7.8.173. F35 - Connection Identifier Reuse . . . . . . . . . 501
7.8.174. F36 - Resolver Failure . . . . . . . . . . . . . . . 501
7.8.175. F37 - PED Unavailability . . . . . . . . . . . . . . 501
7.8.176. F38 - Finality Sink Unavailability . . . . . . . . . 501
7.8.177. F39 - Protected State Rollback . . . . . . . . . . . 501
7.8.178. F40 - Concurrent Request Double-Spend . . . . . . . 501
7.8.179. F41 - Transmitted Request With Lost Response . . . . 502
7.8.180. F42 - Application Service Change . . . . . . . . . . 502
7.8.181. PART XIX - IMPLEMENTATION VARIATIONS . . . . . . . . 502
7.8.182. C-45.97 - Host-Side Protected Proxy . . . . . . . . 502
7.8.183. C-45.98 - Container Network Namespace . . . . . . . 502
7.8.184. C-45.99 - Virtual-Machine Network Enforcement . . . 502
7.8.185. C-45.100 - Kernel-Mediated Network Finality . . . . 503
7.8.186. C-45.101 - SmartNIC/DPU Network Sink . . . . . . . . 503
7.8.187. C-45.102 - API Gateway Finality . . . . . . . . . . 503
7.8.188. C-45.103 - Credential-Broker Integration . . . . . . 503
7.8.189. C-45.104 - Browser-Agent Egress . . . . . . . . . . 503
7.8.190. C-45.107 - HTTP/2 or HTTP/3 Application
Enforcement . . . . . . . . . . . . . . . . . . . . . 504
7.8.191. C-45.108 - TEE-Assisted Network Authority . . . . . 504
7.8.192. C-45.109 - Integrated Protected Network
Controller . . . . . . . . . . . . . . . . . . . . . 504
7.8.193. C-45.110 - Distributed Network Enforcement . . . . . 504
7.8.194. PART XX - REPRESENTATIVE DATA STRUCTURES . . . . . . 504
7.8.195. C-45.111 - CandidateNetworkEgressRecord . . . . . . 505
7.8.196. C-45.112 - DNSResolutionRecord . . . . . . . . . . . 505
7.8.197. C-45.113 - EffectiveEndpointRecord . . . . . . . . . 505
7.8.198. C-45.114 - NetworkAuthorityRecord . . . . . . . . . 505
7.8.199. C-45.115 - ConnectionBindingRecord . . . . . . . . . 505
7.8.200. C-45.116 - NetworkValidationEvidenceRecord . . . . . 506
7.8.201. C-45.117 - NetworkFinalityCapabilityRecord . . . . . 506
7.8.202. C-45.118 - ProxyTargetRecord . . . . . . . . . . . . 506
7.8.203. C-45.119 - RedirectStateRecord . . . . . . . . . . . 506
7.8.204. C-45.120 - EgressPathCoverageRecord . . . . . . . . 507
7.8.205. C-45.121 - NetworkOperationRecoveryRecord . . . . . 507
7.8.206. PART XXI - implementer VERIFICATION TESTS . . . . . 507
7.8.207. C-45.122 - Proposed Engineering Test Matrix . . . . 507
7.8.208. Test Technical condition . . . . . . . . . . . . . . 507
7.8.209. Expected result . . . . . . . . . . . . . . . . . . 507
7.8.210. PART XXII - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 508
7.8.211. C-45.123 - Reconstructed Independent enforcement
point(s) corresponding to source item(s) 45 . . . . . 509
7.8.212. C-45.124 - Reconstructed Dependent enforcement
point(s) corresponding to source item(s) 46 . . . . . 510
Das Expires 25 April 2027 [Page 34]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.213. C-45.125 - Reconstructed Dependent enforcement
point(s) corresponding to source item(s) 47 . . . . . 510
7.8.214. PART XXIII - IMPLEMENTATION REQUIREMENTS . . . . . . 511
7.8.215. C-45.126 - implementer Implementation Checklist . . 511
7.8.216. C-45.127 - Technical Effect . . . . . . . . . . . . 512
7.8.217. C-45.128 - Technical Summary . . . . . . . . . . . . 513
7.9. Implementation Profile C-48 . . . . . . . . . . . . . . . 514
7.9.1. C-48.1 - Technical Field . . . . . . . . . . . . . . 514
7.9.2. PART I - TECHNICAL PROBLEM . . . . . . . . . . . . . 515
7.9.3. C-48.2 - Problem of Indirect Effectuation . . . . . . 515
7.9.4. C-48.3 - Problem of Overly Broad Isolation . . . . . 516
7.9.5. C-48.4 - Problem of Configuration Drift . . . . . . . 516
7.9.6. C-48.5 - Central Technical Principle . . . . . . . . 517
7.9.7. C-48.6 - Distinction From Per-Act Finality . . . . . 517
7.9.8. PART II - PRINCIPAL COMPONENTS . . . . . . . . . . . 518
7.9.9. C-48.7 - Tool-and-Resource Discovery Engine . . . . . 518
7.9.10. C-48.8 - Effect-Path Graph Generator . . . . . . . . 519
7.9.11. C-48.9 - Effect Classification Engine . . . . . . . . 519
7.9.12. C-48.10 - Authorized Effect Envelope Controller . . . 520
7.9.13. C-48.11 - Restriction Compiler . . . . . . . . . . . 520
7.9.14. C-48.12 - Enforcement Capability Catalog . . . . . . 521
7.9.15. C-48.13 - Configuration Installer . . . . . . . . . . 521
7.9.16. C-48.14 - Configuration Verification Engine . . . . . 521
7.9.17. C-48.15 - Execution Controller . . . . . . . . . . . 522
7.9.18. C-48.16 - Runtime Expansion Monitor . . . . . . . . . 522
7.9.19. PART III - GRAPH REPRESENTATION . . . . . . . . . . . 523
7.9.20. C-48.17 - Directed Effect-Path Graph . . . . . . . . 523
7.9.21. C-48.18 - Node Classes . . . . . . . . . . . . . . . 523
7.9.22. C-48.19 - Edge Classes . . . . . . . . . . . . . . . 524
7.9.23. C-48.20 - Conditional Edge . . . . . . . . . . . . . 525
7.9.24. C-48.21 - Authority Context Nodes . . . . . . . . . . 525
7.9.25. C-48.22 - Terminal Effect Nodes . . . . . . . . . . . 526
7.9.26. C-48.23 - Task-Specific Graph Scope . . . . . . . . . 526
7.9.27. PART IV - AUTHORIZED EFFECT ENVELOPE . . . . . . . . 527
7.9.28. C-48.24 - Envelope Representation . . . . . . . . . . 527
7.9.29. C-48.25 - Permitted Task-Execution Paths . . . . . . 527
7.9.30. C-48.26 - Required Task Function Set . . . . . . . . 528
7.9.31. PART V - REACHABILITY ANALYSIS . . . . . . . . . . . 529
7.9.32. C-48.27 - Prohibited Reachability . . . . . . . . . . 529
7.9.33. C-48.28 - Reachability Predicate . . . . . . . . . . 529
7.9.34. C-48.29 - Direct Reachability . . . . . . . . . . . . 529
7.9.35. C-48.30 - Indirect Reachability . . . . . . . . . . . 530
7.9.36. C-48.31 - Delegated Reachability . . . . . . . . . . 530
7.9.37. C-48.32 - File-System Alias Reachability . . . . . . 530
7.9.38. C-48.33 - Cyclic Reachability . . . . . . . . . . . . 531
7.9.39. C-48.34 - Unknown Reachability . . . . . . . . . . . 531
7.9.40. PART VI - RESTRICTION CANDIDATES . . . . . . . . . . 531
7.9.41. C-48.35 - Restriction Candidate . . . . . . . . . . . 532
Das Expires 25 April 2027 [Page 35]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.42. C-48.36 - Restriction Categories . . . . . . . . . . 532
7.9.43. C-48.37 - Restriction Coverage Relation . . . . . . . 532
7.9.44. C-48.38 - Restriction Feasibility . . . . . . . . . . 533
7.9.45. PART VII - MINIMAL RESTRICTION OPTIMIZATION . . . . . 533
7.9.46. C-48.39 - Optimization Objective . . . . . . . . . . 533
7.9.47. C-48.40 - Weighted Restriction Cost . . . . . . . . . 534
7.9.48. C-48.41 - Path-Separation Constraint . . . . . . . . 534
7.9.49. C-48.42 - Task-Preservation Constraint . . . . . . . 535
7.9.50. C-48.43 - Exact and Approximate Solutions . . . . . . 535
7.9.51. C-48.44 - Infeasible Restriction Problem . . . . . . 535
7.9.52. PART VIII - CONCRETE GRAPH-CUT EXAMPLE . . . . . . . 536
7.9.53. C-48.45 - Example Graph . . . . . . . . . . . . . . . 536
7.9.54. C-48.46 - Prohibited Paths . . . . . . . . . . . . . 537
7.9.55. C-48.47 - Permitted Paths . . . . . . . . . . . . . . 537
7.9.56. C-48.48 - Restriction Alternatives . . . . . . . . . 537
7.9.57. C-48.49 - Selected Restriction . . . . . . . . . . . 538
7.9.58. C-48.50 - Verification Result . . . . . . . . . . . . 538
7.9.59. PART IX - CONFIGURATION COMPILATION . . . . . . . . . 539
7.9.60. C-48.51 - Restriction Configuration Object . . . . . 539
7.9.61. C-48.52 - Installation Plan . . . . . . . . . . . . . 539
7.9.62. C-48.53 - Enforcement Mapping . . . . . . . . . . . . 540
7.9.63. C-48.54 - Configuration Installation Barrier . . . . 540
7.9.64. C-48.55 - Effective-State Verification . . . . . . . 541
7.9.65. PART X - ALTERNATE-ROUTE CLOSURE . . . . . . . . . . 541
7.9.66. C-48.56 - Shell and Interpreter Chains . . . . . . . 541
7.9.67. C-48.57 - Browser Automation Chains . . . . . . . . . 541
7.9.68. C-48.58 - Connector Chains . . . . . . . . . . . . . 542
7.9.69. C-48.59 - File-System Alias Chains . . . . . . . . . 542
7.9.70. C-48.60 - Existing Resource Handles . . . . . . . . . 542
7.9.71. PART XI - RUNTIME INTERFACE EXPANSION . . . . . . . . 543
7.9.72. C-48.61 - New Interface Event . . . . . . . . . . . . 543
7.9.73. C-48.62 - Default Quarantine . . . . . . . . . . . . 543
7.9.74. C-48.63 - Runtime Expansion Barrier . . . . . . . . . 544
7.9.75. C-48.64 - Tool Package Installation . . . . . . . . . 545
7.9.76. C-48.65 - Dynamic Interface Update . . . . . . . . . 545
7.9.77. C-48.66 - Revocation of Old Configuration . . . . . . 545
7.9.78. PART XII - GRAPH CONSISTENCY AND CONCURRENCY . . . . 545
7.9.79. C-48.67 - Graph Generation . . . . . . . . . . . . . 545
7.9.80. C-48.68 - Configuration Generation . . . . . . . . . 546
7.9.81. C-48.69 - Concurrent Interface Changes . . . . . . . 546
7.9.82. C-48.70 - Graph Completeness and Enforcement
Assumptions . . . . . . . . . . . . . . . . . . . . . 547
7.9.83. PART XIII - COMPLETE 34-STEP WORKFLOW . . . . . . . . 547
7.9.84. C-48.71 - Principal Workflow . . . . . . . . . . . . 547
7.9.85. Step C48-01 - Task definition . . . . . . . . . . . . 547
7.9.86. Step C48-02 - Authority-envelope establishment . . . 547
7.9.87. Step C48-03 - Agent execution-context
identification . . . . . . . . . . . . . . . . . . . 547
Das Expires 25 April 2027 [Page 36]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.88. Step C48-04 - Quarantine initialization . . . . . . . 547
7.9.89. Step C48-05 - Tool inventory . . . . . . . . . . . . 548
7.9.90. Step C48-06 - Resource inventory . . . . . . . . . . 548
7.9.91. Step C48-07 - Authority inventory . . . . . . . . . . 548
7.9.92. Step C48-08 - Graph node construction . . . . . . . . 548
7.9.93. Step C48-09 - Graph edge construction . . . . . . . . 548
7.9.94. Step C48-10 - Effect classification . . . . . . . . . 548
7.9.95. Step C48-11 - Graph-generation commitment . . . . . . 548
7.9.96. Step C48-12 - Prohibited terminal identification . . 548
7.9.97. Step C48-13 - Permitted task-path identification . . 548
7.9.98. Step C48-14 - Reachability analysis . . . . . . . . . 548
7.9.99. Step C48-15 - Counterexample extraction . . . . . . . 548
7.9.100. Step C48-16 - Restriction candidate discovery . . . 549
7.9.101. Step C48-17 - Restriction feasibility
verification . . . . . . . . . . . . . . . . . . . . 549
7.9.102. Step C48-18 - Optimization model construction . . . 549
7.9.103. Step C48-19 - Restriction optimization . . . . . . . 549
7.9.104. Step C48-20 - Post-restriction graph evaluation . . 549
7.9.105. Step C48-21 - Permitted-path verification . . . . . 549
7.9.106. Step C48-22 - Machine-enforceable configuration
generation . . . . . . . . . . . . . . . . . . . . . 549
7.9.107. Step C48-23 - Protected installation staging . . . . 549
7.9.108. Step C48-24 - Restriction installation . . . . . . . 549
7.9.109. Step C48-25 - Effective-state inspection . . . . . . 549
7.9.110. Step C48-26 - Post-installation reachability
verification . . . . . . . . . . . . . . . . . . . . 549
7.9.111. Step C48-27 - Negative enforcement testing . . . . . 550
7.9.112. Step C48-28 - Configuration-generation commitment . 550
7.9.113. Step C48-29 - Agent activation . . . . . . . . . . . 550
7.9.114. Step C48-30 - Runtime interface monitoring . . . . . 550
7.9.115. Step C48-31 - Expansion quarantine . . . . . . . . . 550
7.9.116. Step C48-32 - Incremental graph update . . . . . . . 550
7.9.117. Step C48-33 - Configuration recompilation and
verification . . . . . . . . . . . . . . . . . . . . 550
7.9.118. Step C48-34 - Continued execution or suspension . . 550
7.9.119. PART XIV - REFERENCE ALGORITHMS . . . . . . . . . . 550
7.9.120. C-48.72 - Algorithm A: Tool-and-Resource
Discovery . . . . . . . . . . . . . . . . . . . . . . 550
7.9.121. C-48.74 - Algorithm C: Prohibited Reachability . . . 552
7.9.122. C-48.77 - Algorithm F: Task-Preservation
Verification . . . . . . . . . . . . . . . . . . . . 555
7.9.123. C-48.78 - Algorithm G: Configuration Compilation . . 556
7.9.124. C-48.80 - Algorithm I: Runtime Interface
Expansion . . . . . . . . . . . . . . . . . . . . . . 557
7.9.125. C-48.81 - Algorithm J: Alternate-Route
Verification . . . . . . . . . . . . . . . . . . . . 559
7.9.126. PART XV - WORKED TECHNICAL EXAMPLES . . . . . . . . 561
7.9.127. C-48.84 - Example A: Shell-Based Network Bypass . . 561
Das Expires 25 April 2027 [Page 37]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.128. C-48.86 - Example C: Privileged Connector Chain . . 562
7.9.129. C-48.87 - Example D: File-System Alias . . . . . . . 562
7.9.130. C-48.89 - Example F: New API Connector . . . . . . . 563
7.9.131. C-48.90 - Example G: Minimal Restriction
Selection . . . . . . . . . . . . . . . . . . . . . . 563
7.9.132. C-48.91 - Example H: Infeasible Restriction Set . . 564
7.9.133. C-48.92 - Example I: Container Mount Expansion . . . 564
7.9.134. C-48.94 - Example K: Existing Open Network Socket . 565
7.9.135. C-48.95 - Example L: Delegated Worker Bypass . . . . 565
7.9.136. PART XVI - FAILURE AND ADVERSARIAL CASES . . . . . . 566
7.9.137. C-48.96 - Representative Failure Conditions . . . . 566
7.9.138. F1 - Unknown Executable . . . . . . . . . . . . . . 566
7.9.139. F2 - Shell Wrapper Bypass . . . . . . . . . . . . . 566
7.9.140. F3 - Interpreter Bypass . . . . . . . . . . . . . . 566
7.9.141. F4 - Browser Automation Bypass . . . . . . . . . . . 566
7.9.142. F5 - Connector Chain . . . . . . . . . . . . . . . . 566
7.9.143. F6 - File-System Alias . . . . . . . . . . . . . . . 567
7.9.144. F7 - Privileged Host Worker . . . . . . . . . . . . 567
7.9.145. F8 - Existing File Descriptor . . . . . . . . . . . 567
7.9.146. F9 - Existing Socket . . . . . . . . . . . . . . . . 567
7.9.147. F10 - New Package . . . . . . . . . . . . . . . . . 567
7.9.148. F11 - New Plugin . . . . . . . . . . . . . . . . . . 567
7.9.149. F12 - New Connector . . . . . . . . . . . . . . . . 567
7.9.150. F13 - New Mount . . . . . . . . . . . . . . . . . . 567
7.9.151. F14 - New Network Interface . . . . . . . . . . . . 568
7.9.152. F15 - Service-Role Expansion . . . . . . . . . . . . 568
7.9.153. F16 - Unsupported Restriction Primitive . . . . . . 568
7.9.154. F17 - Telemetry-Only Rule . . . . . . . . . . . . . 568
7.9.155. F18 - Stale Graph Generation . . . . . . . . . . . . 568
7.9.156. F19 - Partial Installation . . . . . . . . . . . . . 568
7.9.157. F20 - Enforcement Policy Removed . . . . . . . . . . 568
7.9.158. F21 - Incorrect Task-Preservation Model . . . . . . 568
7.9.159. F22 - Optimization Timeout . . . . . . . . . . . . . 569
7.9.160. F23 - Infeasible Task Envelope . . . . . . . . . . . 569
7.9.161. F24 - Graph Cycle . . . . . . . . . . . . . . . . . 569
7.9.162. F25 - Unknown Connector Effects . . . . . . . . . . 569
7.9.163. F26 - Resource Identity Confusion . . . . . . . . . 569
7.9.164. F27 - Concurrent Interface Addition . . . . . . . . 569
7.9.165. F28 - Concurrent Permission Change . . . . . . . . . 569
7.9.166. F29 - Restriction Rollback . . . . . . . . . . . . . 570
7.9.167. F30 - Direct Hardware Access . . . . . . . . . . . . 570
7.9.168. F31 - Privilege Escalation . . . . . . . . . . . . . 570
7.9.169. F32 - Asynchronous Job Path . . . . . . . . . . . . 570
7.9.170. F33 - Dynamic Library Loading . . . . . . . . . . . 570
7.9.171. F34 - False Configuration Readback . . . . . . . . . 570
7.9.172. F35 - Sandbox Escape . . . . . . . . . . . . . . . . 570
7.9.173. F36 - Unmodeled Cross-Service Effect . . . . . . . . 571
7.9.174. F37 - Optimization Cost Manipulation . . . . . . . . 571
Das Expires 25 April 2027 [Page 38]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.175. F38 - Incorrect Graph Edge Removal . . . . . . . . . 571
7.9.176. F39 - Task Path Exists Only Abstractly . . . . . . . 571
7.9.177. F40 - Newly Accessible Credential . . . . . . . . . 571
7.9.178. C-48.100 - Cloud-Hosted Sandbox . . . . . . . . . . 572
7.9.179. C-48.101 - Kernel-Enforced Sandbox . . . . . . . . . 572
7.9.180. C-48.102 - Browser-Agent Sandbox . . . . . . . . . . 572
7.9.181. C-48.106 - Integrated Protected Finality
Variation . . . . . . . . . . . . . . . . . . . . . . 572
7.9.182. PART XVIII - REPRESENTATIVE DATA STRUCTURES . . . . 572
7.9.183. C-48.107 - ToolResourceInventoryRecord . . . . . . . 572
7.9.184. C-48.108 - EffectGraphNodeRecord . . . . . . . . . . 573
7.9.185. C-48.109 - EffectGraphEdgeRecord . . . . . . . . . . 573
7.9.186. C-48.110 - AuthorizedEffectEnvelopeRecord . . . . . 573
7.9.187. C-48.111 - RestrictionCandidateRecord . . . . . . . 573
7.9.188. C-48.112 - RestrictionOptimizationRecord . . . . . . 573
7.9.189. C-48.113 - CompiledSandboxConfigurationRecord . . . 574
7.9.190. C-48.114 - ConfigurationVerificationRecord . . . . . 574
7.9.191. C-48.115 - RuntimeExpansionEventRecord . . . . . . . 574
7.9.192. C-48.116 - ProtectedConfigurationStateRecord . . . . 574
7.9.193. PART XIX - ENGINEERING TESTS . . . . . . . . . . . . 575
7.9.194. C-48.117 - Proposed Verification Matrix . . . . . . 575
7.9.195. Test Condition . . . . . . . . . . . . . . . . . . . 575
7.9.196. Expected result . . . . . . . . . . . . . . . . . . 575
7.9.197. PART XX - Enforcement-Point Mapping and Technical
Correspondence . . . . . . . . . . . . . . . . . . . 576
7.9.198. C-48.118 - Independent enforcement point(s)
corresponding to source item(s) 48 . . . . . . . . . 576
7.9.199. C-48.119 - Dependent enforcement point(s)
corresponding to source item(s) 49: Alternate-Route
Closure . . . . . . . . . . . . . . . . . . . . . . . 577
7.9.200. PART XXI - IMPLEMENTATION REQUIREMENTS . . . . . . . 578
7.9.201. C-48.122 - implementer Implementation Checklist . . 578
7.9.202. C-48.123 - Technical Effect . . . . . . . . . . . . 579
7.9.203. C-48.124 - Technical Summary . . . . . . . . . . . . 580
8. Security Considerations . . . . . . . . . . . . . . . . . . . 581
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 581
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 581
11. Informative References . . . . . . . . . . . . . . . . . . . 581
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 582
1. Introduction
Sandboxed AI agents can invoke privileged host connectors, use
brokered credentials, and request external network operations.
Sandbox confinement or proxy admission does not, by itself, establish
that a specific downstream operation remains authorized at the moment
the effect becomes effective. This document explores process
lineage, brokered secret use, effective endpoint checks, protected
Das Expires 25 April 2027 [Page 39]
Internet-Draft Sandbox Credential Egress Finality October 2026
act-bound verification, finality-sink enforcement, bypass-path
assessment, and recovery. It is offered as an informational
architecture, not a claim that any identified industry product
implements the entire proposal.
The document retains the implementation alternatives, procedures,
illustrative algorithms, constraints, and security tests contained in
the author-supplied technical disclosure. The technical profiles
reproduced below are source-derived and subject to technical editing;
terminology that originated in patent drafting is reformulated as
implementation guidance and enforcement points, not legal claim
coverage.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be
interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and
only when, they appear in all capitals. Requirements in the non-
normative profiles below are illustrative unless a later
interoperable protocol profile expressly designates them normative.
1.1. This Document Is Intentionally Long
This document is long by design. Its length is the result of
technical content, not repetition. The draft set contains 34
implementation profiles, of which this draft contains 9; each
specifies a distinct mechanism together with its components,
reference algorithms, worked examples, failure and adversarial cases,
verification tests, and enforcement points. A text comparison of the
profiles shows that fewer than 2 percent of their sentences recur in
any other profile, and the recurring text is limited to short
provenance notes and shared helper calls in the pseudocode.
The full text is retained for four reasons:
1. The security properties are compositional. A Finality Sink that
verifies a capability is necessary but not sufficient; prevention
also depends on path coverage, revocation convergence, protected
state, recovery behaviour, and the settlement of operations
already in flight. These conditions are specified in different
profiles, and a reader who examines one profile alone will see an
incomplete and potentially misleading picture.
2. The reference algorithms and negative tests are included so that
reviewers can judge implementability and attempt to falsify the
proposed properties, rather than having to accept a summary.
Das Expires 25 April 2027 [Page 40]
Internet-Draft Sandbox Credential Egress Finality October 2026
3. The failure cases define where each mechanism fails closed. A
condensed version would remove exactly the boundary conditions
that a security review needs to examine.
4. The enforcement points state what each mechanism requires in a
form that can be checked against an implementation, and they
refer to the profile text for their technical basis.
Reviewers are therefore asked not to assess the proposal from an
isolated profile, enforcement point, or algorithm excerpt. The
recommended reading order is: this Introduction; the Problem
Statement (Section 3); Relevance to the IETF (Section 4); Scope and
Terminology (Section 6), which is identical in all three drafts;
Implementation Profile S-1 (Section 7.1), which establishes the
baseline execution-finality sequence; the remaining profiles of this
draft and then those of the companion drafts; and finally the
Security Considerations (Section 8). Each profile states its own
problem, components, algorithms, failure cases, and enforcement
points, so the profiles can be cross-checked against one another.
The 34 profiles are divided among the three drafts according to their
primary boundary, and each profile appears in full in exactly one
draft. The terminology, problem statement, IETF relevance, and
relationship to earlier drafts are identical in all three. Because
the security properties are compositional, the three drafts are
intended to be read together as one document; the Profile Map in the
next subsection shows where each profile is published.
1.2. Document Set and Cross-References
This document is one of three coordinated Internet-Drafts that share
identical terminology and are intended to be read together:
* Protected Execution Finality for Sandboxed AI Agents, Credential
Mediation, Process Lineage, and Network Egress (draft-das-sandbox-
credential-egress-finality, this document):
https://datatracker.ietf.org/doc/draft-das-sandbox-credential-
egress-finality/ (https://datatracker.ietf.org/doc/draft-das-
sandbox-credential-egress-finality/)
* Protected Execution-Finality Enforcement for Autonomous AI Agents
Across Kernel, Hypervisor, Hardware, and Native-Resource
Boundaries (draft-das-kernel-hardware-execution-finality):
https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/ (https://datatracker.ietf.org/doc/draft-das-
kernel-hardware-execution-finality/)
[I-D.das-kernel-hardware-execution-finality]
Das Expires 25 April 2027 [Page 41]
Internet-Draft Sandbox Credential Egress Finality October 2026
* Distributed Authority and Execution-Finality for Multi-Agent
Systems, Delegated Operations, and Cross-Domain Gateways (draft-
das-distributed-agent-authority-finality):
https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/ (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/)
[I-D.das-distributed-agent-authority-finality]
This document (draft-das-sandbox-credential-egress-finality)
concentrates on the sandbox, credential, and network-egress boundary:
the point at which a sandboxed agent's proposed operation leaves the
sandbox through a host service, credential broker, connector, proxy,
or network interface. The companion drafts address the other
boundaries; where a mechanism is primarily motivated by a companion
draft's focus, that draft's Problem Statement and Relevance sections
give the corresponding context.
The three drafts build on the architecture described in draft-das-
agent-execution-finality [I-D.das-agent-execution-finality],
available at https://datatracker.ietf.org/doc/draft-das-agent-
execution-finality/ (https://datatracker.ietf.org/doc/draft-das-
agent-execution-finality/). That draft is not part of this set but
provides the general execution-finality architecture on which the
profiles here rely. Readers unfamiliar with it are encouraged to
read it first.
1.3. Profile Map
The 34 profiles are published as follows. The Datatracker URL of
each draft is given in Section 1.2.
+=========+===================================+====================+
| Profile | Subject | Published in |
+=========+===================================+====================+
| S-1 | Virtual-machine-isolated agent | this document |
| | sandbox with protected execution | |
| | authority | |
+---------+-----------------------------------+--------------------+
| S-2 | Micro-VM-isolated execution with | this document |
| | lifecycle-bound authority and | |
| | asynchronous continuity | |
+---------+-----------------------------------+--------------------+
| S-3 | Container-isolated execution with | this document |
| | tool-dispatch control, credential | |
| | mediation, and egress finality | |
+---------+-----------------------------------+--------------------+
| S-4 | Process-isolated execution with | this document |
| | process-lineage control and | |
Das Expires 25 April 2027 [Page 42]
Internet-Draft Sandbox Credential Egress Finality October 2026
| | handle mediation | |
+---------+-----------------------------------+--------------------+
| S-5 | Kernel- and hypervisor-mediated | draft-das-kernel- |
| | enforcement with non-bypassable | hardware- |
| | effectuation control | execution-finality |
+---------+-----------------------------------+--------------------+
| S-6 | Cloud-hosted, API-gateway- | draft-das- |
| | mediated, and distributed | distributed-agent- |
| | execution with cross-domain | authority-finality |
| | authority binding | |
+---------+-----------------------------------+--------------------+
| S-7 | Hardware-rooted, | draft-das-kernel- |
| | cryptographically isolated | hardware- |
| | execution with attested | execution-finality |
| | validation | |
+---------+-----------------------------------+--------------------+
| S-8 | SmartNIC, DPU, GPU, and | draft-das-kernel- |
| | accelerator sandbox with DMA | hardware- |
| | isolation, cross-device epoch | execution-finality |
| | fencing, and memory sanitization | |
+---------+-----------------------------------+--------------------+
| C-09 | Inline transaction finality with | draft-das-kernel- |
| | atomic authorization-state | hardware- |
| | transitions | execution-finality |
+---------+-----------------------------------+--------------------+
| C-15 | Multi-agent influence-lineage | draft-das- |
| | governance | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-21 | Continuous sandbox execution with | this document |
| | bounded finality windows | |
+---------+-----------------------------------+--------------------+
| C-33 | Effectuation-path completeness | this document |
| | and coverage-state commitment | |
+---------+-----------------------------------+--------------------+
| C-42 | Process-lineage taint propagation | this document |
| | and transitive authority | |
| | restriction | |
+---------+-----------------------------------+--------------------+
| C-45 | Post-DNS-resolution network- | this document |
| | egress finality | |
+---------+-----------------------------------+--------------------+
| C-48 | Compilation of effect-path | this document |
| | reachability restrictions | |
+---------+-----------------------------------+--------------------+
| C-52 | Deferred-effect-aware identity | draft-das- |
| | authorization | distributed-agent- |
| | | authority-finality |
Das Expires 25 April 2027 [Page 43]
Internet-Draft Sandbox Credential Egress Finality October 2026
+---------+-----------------------------------+--------------------+
| C-56 | Transitive effect-closure | draft-das- |
| | admission for API requests | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-60 | Atomic projected-state | draft-das-kernel- |
| | authorization in native resource | hardware- |
| | engines | execution-finality |
+---------+-----------------------------------+--------------------+
| C-64 | Post-effect causal containment | draft-das- |
| | and selective remediation | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-68 | Source-separated human | draft-das- |
| | transaction reconstruction | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-72 | Cross-protocol authorization- | draft-das- |
| | semantics preservation | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-76 | Hardware-resident deferred-effect | draft-das-kernel- |
| | budget accounting | hardware- |
| | | execution-finality |
+---------+-----------------------------------+--------------------+
| C-80 | Memory-class authority isolation | draft-das- |
| | for persistent agents | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-84 | Coordinated kernel and hardware | draft-das-kernel- |
| | containment | hardware- |
| | | execution-finality |
+---------+-----------------------------------+--------------------+
| C-88 | Distributed authority contraction | draft-das- |
| | with convergence barriers | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-89 | Independence-verified guardian- | draft-das- |
| | agent supervision | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-90 | Observation-coverage attestation | draft-das- |
| | | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-91 | Side-effect-suppressed model | draft-das- |
| | migration | distributed-agent- |
| | | authority-finality |
Das Expires 25 April 2027 [Page 44]
Internet-Draft Sandbox Credential Egress Finality October 2026
+---------+-----------------------------------+--------------------+
| C-92 | Partition-safe governance across | draft-das- |
| | disconnected domains | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-94 | Live agent-tool replacement with | draft-das- |
| | differential validation | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-95 | Cross-agent effect-collision | draft-das- |
| | detection and scheduling | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-96 | Task-preserving context | draft-das- |
| | minimization across providers | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-98 | Counterfactual policy deployment | draft-das- |
| | with canary rollout | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
| C-99 | Selective erasure and non-revival | draft-das- |
| | of derived memory | distributed-agent- |
| | | authority-finality |
+---------+-----------------------------------+--------------------+
Table 1
1.4. Relationship to Earlier Internet-Drafts
This subsection states what the author's earlier Internet-Drafts
disclosed and what this draft set discloses, so that reviewers can
distinguish new material from material already available.
1.4.1. What the Earlier Drafts Disclosed
draft-das-agent-execution-finality (https://datatracker.ietf.org/doc/
draft-das-agent-execution-finality/
(https://datatracker.ietf.org/doc/draft-das-agent-execution-
finality/)) describes the general architecture: mandatory
interception, Non-Effective State, the Candidate Act Descriptor, the
Protected Enforcement Domain, protected validation evidence, scoped
non-bearer capabilities, and Finality Sink verification. It applies
this architecture in a series of workflows covering sandbox egress;
network request canonicalization, destination resolution, DNS
rebinding, and redirect handling; credential brokering and surrogate-
credential substitution; privileged connectors; untrusted-input
provenance and process-lineage taint; browser and computer-use
Das Expires 25 April 2027 [Page 45]
Internet-Draft Sandbox Credential Egress Finality October 2026
actions; autonomous commerce; agent self-modification; multi-agent
delegation; software supply-chain release; service-mesh enforcement;
model admission and the separation of model-path and effectuation-
path authorization; accelerator fabric and DMA transfers; hardware
watchdog interlocks; and confidential virtual machines and governance
VMs with SmartNIC enforcement.
Other earlier drafts specify parts of the architecture in more
detail:
* draft-das-execution-finality-protocol-layer: core vocabulary and
the invariant that computation does not itself confer authority
for consequence. https://datatracker.ietf.org/doc/draft-das-
execution-finality-protocol-layer/
(https://datatracker.ietf.org/doc/draft-das-execution-finality-
protocol-layer/)
* draft-das-execution-handle: the execution-handle objects, sink-
side verification against the reconstructed pending act, atomic
consumption, and finality receipts.
https://datatracker.ietf.org/doc/draft-das-execution-handle/
(https://datatracker.ietf.org/doc/draft-das-execution-handle/)
* draft-das-ef-registries: proposed registries for consequence
classes, sink types, decisions, and failure codes.
https://datatracker.ietf.org/doc/draft-das-ef-registries/
(https://datatracker.ietf.org/doc/draft-das-ef-registries/)
* draft-das-composite-execution-finality: joint finality across
multiple sinks. https://datatracker.ietf.org/doc/draft-das-
composite-execution-finality/ (https://datatracker.ietf.org/doc/
draft-das-composite-execution-finality/)
* draft-das-consequence-path-completeness: closing alternative paths
that bypass a sink. https://datatracker.ietf.org/doc/draft-das-
consequence-path-completeness/ (https://datatracker.ietf.org/doc/
draft-das-consequence-path-completeness/)
* draft-das-finality-bound-revocation and draft-das-state-policy-
continuity-finality: revocation and stale authorization at the
effectuation boundary. https://datatracker.ietf.org/doc/draft-das-
finality-bound-revocation/ (https://datatracker.ietf.org/doc/
draft-das-finality-bound-revocation/)
https://datatracker.ietf.org/doc/draft-das-state-policy-
continuity-finality/ (https://datatracker.ietf.org/doc/draft-das-
state-policy-continuity-finality/)
Das Expires 25 April 2027 [Page 46]
Internet-Draft Sandbox Credential Egress Finality October 2026
* draft-das-agentic-effectuation-boundary: the threat model for
autonomous high-consequence agents.
https://datatracker.ietf.org/doc/draft-das-agentic-effectuation-
boundary/ (https://datatracker.ietf.org/doc/draft-das-agentic-
effectuation-boundary/)
* draft-das-agentic-adaptive-authorization: graduated and escalated
execution control. https://datatracker.ietf.org/doc/draft-das-
agentic-adaptive-authorization/ (https://datatracker.ietf.org/doc/
draft-das-agentic-adaptive-authorization/)
* draft-das-agentic-tool-binding: binding execution finality to AI
tool-call interfaces. https://datatracker.ietf.org/doc/draft-das-
agentic-tool-binding/ (https://datatracker.ietf.org/doc/draft-das-
agentic-tool-binding/)
* draft-das-hardware-enforced-execution-finality: hardware-enforced
execution finality. https://datatracker.ietf.org/doc/draft-das-
hardware-enforced-execution-finality/
(https://datatracker.ietf.org/doc/draft-das-hardware-enforced-
execution-finality/)
1.4.2. What This Draft Set Discloses
This draft set extends earlier mechanisms in the following ways:
* Substrate-specific sandbox profiles for virtual-machine, micro-VM,
container, process, kernel and hypervisor, cloud and API-gateway,
hardware-rooted, and SmartNIC, DPU, GPU, and accelerator
isolation, including DMA and memory isolation, cross-device epoch
fencing, and verified accelerator memory sanitization before
reassignment (Section 7.1 to S-8 in draft-das-kernel-hardware-
execution-finality (https://datatracker.ietf.org/doc/draft-das-
kernel-hardware-execution-finality/)).
* Inline transaction finality using a non-portable enablement
condition held within the effectuation controller (C-09 in draft-
das-kernel-hardware-execution-finality
(https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/)).
* Multi-agent influence-lineage governance with retrieval-to-
execution separation (C-15 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/)).
* Continuous session finality with bounded windows and micro-
validation chains (Section 7.5).
Das Expires 25 April 2027 [Page 47]
Internet-Draft Sandbox Credential Egress Finality October 2026
* An effectuation-path coverage registry with parent-sink dominance
(Section 7.6).
* Transitive process-lineage taint with descendant inheritance and
revocation generations (Section 7.7).
* Post-resolution network-egress finality with connected-endpoint
binding and alternate-route protection (Section 7.8).
It also introduces the following mechanism families, which are not
the subject of the earlier drafts listed above:
* Compilation of effect-path reachability restrictions for agent
sandboxes (Section 7.9).
* Deferred-effect-aware identity authorization (C-52 in draft-das-
distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Transitive effect-closure admission for API requests (C-56 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Atomic projected-state authorization within native resource
engines (C-60 in draft-das-kernel-hardware-execution-finality
(https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/)).
* Post-effect causal containment and selective remediation (C-64 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Source-separated human reconstruction of agent-proposed
transactions (C-68 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/)).
* Cross-protocol preservation of authorization semantics in agent
gateways (C-72 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
Das Expires 25 April 2027 [Page 48]
Internet-Draft Sandbox Credential Egress Finality October 2026
* Hardware-resident deferred-effect budget accounting (C-76 in
draft-das-kernel-hardware-execution-finality
(https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/)).
* Memory-class authority isolation for persistent agents (C-80 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Coordinated kernel and hardware containment with in-flight
operation settlement (C-84 in draft-das-kernel-hardware-execution-
finality (https://datatracker.ietf.org/doc/draft-das-kernel-
hardware-execution-finality/)).
* Distributed authority contraction with enforcement-convergence
barriers (C-88 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Independence-verified guardian-agent supervision (C-89 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Observation-coverage attestation (C-90 in draft-das-distributed-
agent-authority-finality (https://datatracker.ietf.org/doc/draft-
das-distributed-agent-authority-finality/)).
* Side-effect-suppressed model migration (C-91 in draft-das-
distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Partition-safe governance across disconnected domains (C-92 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Live tool replacement with differential validation (C-94 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Cross-agent effect-collision detection and scheduling (C-95 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
Das Expires 25 April 2027 [Page 49]
Internet-Draft Sandbox Credential Egress Finality October 2026
* Task-preserving context minimization across model providers (C-96
in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Counterfactual policy deployment with effect-sensitive canary
rollout (C-98 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
* Selective erasure and non-revival of derived persistent memory
(C-99 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/)).
This characterization is the author's. Reviewers are invited to
compare it against the earlier drafts and to report any mechanism
they consider already disclosed or incorrectly attributed.
2. IPR and Related Patent Disclosures
2.1. Related Indian Patent Disclosures and Claimed Priority
The author identifies Indian Application No. 202531130665, dated 23
December 2025, as an earlier related foundational disclosure,
together with Indian provisional applications 202631000572 (3 January
2026), 202631001586 (7 January 2026), and 202631002990 (12 January
2026), concerning execution-time authorization and irreversible-
boundary enforcement. Indian Application Nos. 202631124028 and
202631125689 are separately identified as related patent-pending
applications.
2.2. Related International Patent Applications and WIPO Publications
The author identifies PCT/IB2025/058316 (WO 2025/210622); PCT/
IB2026/053385 (WO 2026/115520); PCT/IB2026/055615 (WO 2026/150382);
PCT/IB2026/055760 (WO 2026/150383); PCT/IB2026/055870 (WO
2026/150384); PCT/IB2026/056058 (WO 2026/154461); PCT/IB2026/056809
(WO 2026/172334); and PCT/IB2026/056941 (WO 2026/172336) as related
technical disclosures.
Das Expires 25 April 2027 [Page 50]
Internet-Draft Sandbox Credential Egress Finality October 2026
2.3. Scope and Priority Qualifications
The listed applications facilitate independent examination of
original technical documents and their chronology. The presence of a
technical mechanism in this Internet-Draft does not mean it is the
subject of a pending, allowable, or granted patent claim. The scope
of patent protection, if any, depends on examination and action by
competent national or regional patent authorities and applicable law.
Entitlement to any claimed priority depends on support in the
relevant earlier application as originally filed. The chronology
does not establish that every mechanism described here was disclosed
in every earlier application. This section does not replace any
disclosure required through the IETF IPR disclosure process.
3. Problem Statement and Security Objectives
The governed operation may cross sandbox, kernel, host-service,
credential-broker, connector, proxy, network, and external-resource
interfaces. Privileged helper processes, DNS or endpoint changes,
cached permissions, process descendants, deferred side effects, and
unmediated alternate paths can produce effects different from those
admitted by an earlier sandbox or proxy policy check. The actual
pending operation therefore requires enforcement at the relevant
effectuation boundary.
3.1. General Problem
The general problem arises when an autonomous computational workload
can generate, route, delegate, store, or repeat operations that
produce consequential effects on resources it does not entirely
control. It is most significant where computation, authorization,
transmission, execution, persistence, and completion are distributed
among different software components, protection domains,
administrative authorities, or hardware devices.
In such systems an agent may propose an operation based on context
that is incomplete, stale, adversarially influenced, or outside its
authority. An authorization mechanism may approve a task or session
rather than the specific operation that eventually reaches the
resource. A connector may transform the request. An asynchronous
worker may execute after an authority change. A hardware queue may
remain active after a software containment decision. A persistent-
memory subsystem may retain information whose authorized basis has
been withdrawn. Existing authentication, authorization, and
isolation mechanisms each address part of this chain, but none of
them, on its own, establishes that the actual pending operation is
authorized at the moment it becomes effective.
Das Expires 25 April 2027 [Page 51]
Internet-Draft Sandbox Credential Egress Finality October 2026
3.2. Specific Problems
The following problems are addressed by the profiles in this
document. Each entry states the problem, the technical requirement
it creates, and the profiles that address it.
P1 -- Computational output treated as execution authority:
An agent-generated command may be forwarded to an effect-capable
interface without independent verification of the current
operation-specific authority state, so that a model output, plan,
tool request, earlier instruction, or ordinary credential is
treated as sufficient to perform a consequential operation.
Requirement: Distinguish generation of an operation from
possession of a valid execution-enabling condition. Addressed in
Section 7.1, C-09 in draft-das-kernel-hardware-execution-finality
(https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/).
P2 -- Insufficient binding between authorization and actual
effect:
An upstream decision may concern an intended request while the
downstream interface receives different parameters, a different
target, or an operation under a changed policy state.
Requirement: Identify the operation actually presented for
effectuation and enforce its correspondence with the authorized
representation. Addressed in C-09 in draft-das-kernel-hardware-
execution-finality (https://datatracker.ietf.org/doc/draft-das-
kernel-hardware-execution-finality/), Section 7.8.
P3 -- Bypass through alternative effectuation paths:
An agent may reach an effect-capable resource through an intended
connector and also through a shell, browser, network, privileged
service, or recovery path; restricting one route can leave another
open. Requirement: Discover, classify, restrict, or verify every
relevant enabled effectuation path. Addressed in Section 7.6,
Section 7.9.
P4 -- Overbroad session and credential authority:
An agent may retain a credential or session permission after its
task, destination, scope, or risk condition changes. Requirement:
Bind credential use and operation execution to a limited current
authority state. Addressed in Section 7.3, Section 7.5.
P5 -- Promotion of external information into instructions:
Retrieved documents, web pages, messages, tool results, and stored
memories may contain text resembling instructions that an agent
copies, summarizes, or delegates into a proposed operation.
Requirement: Distinguish informational influence from authority-
Das Expires 25 April 2027 [Page 52]
Internet-Draft Sandbox Credential Egress Finality October 2026
bearing instructions. Addressed in C-15 in draft-das-distributed-
agent-authority-finality (https://datatracker.ietf.org/doc/draft-
das-distributed-agent-authority-finality/), Section 7.7, C-80 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P6 -- Indirect and deferred effects escaping initial
authorization:
A permitted tool invocation may trigger downstream handlers or
delegated workers whose effects fall outside the intended scope.
Requirement: Identify and evaluate direct, indirect, and deferred
consequences while operations remain outstanding. Addressed in
C-52 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), C-56 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/).
P7 -- Inconsistent resource state under concurrent agent
operations:
Operations that are individually permissible may jointly violate
an inventory, financial, uniqueness, or other resource invariant.
Requirement: Identify shared logical resources and non-commutative
effects and coordinate execution through ordering, reservations,
or native transactions. Addressed in C-60 in draft-das-kernel-
hardware-execution-finality (https://datatracker.ietf.org/doc/
draft-das-kernel-hardware-execution-finality/), C-95 in draft-das-
distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P8 -- Distributed revocation without confirmed enforcement:
An identity provider may reduce an agent's authority while a
gateway, connector, worker, or device controller still enforces an
earlier generation. Requirement: Determine whether restrictions
are effective across the relevant paths and prevent older
generations from enabling prohibited operations. Addressed in
C-88 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), S-8 in draft-das-kernel-hardware-execution-
finality (https://datatracker.ietf.org/doc/draft-das-kernel-
hardware-execution-finality/).
P9 -- Incomplete security observation:
Monitoring may miss events because a telemetry channel is
disabled, delayed, interrupted, or misconfigured. Requirement:
Verify the observation coverage required for each operation class
Das Expires 25 April 2027 [Page 53]
Internet-Draft Sandbox Credential Egress Finality October 2026
and reduce authority when coverage is insufficient. Addressed in
C-90 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P10 -- Correlated or manipulated guardian assessments:
Several guardian agents may agree only because they share a
compromised source, model output, or telemetry channel.
Requirement: Evaluate evidence-origin dependencies and protect
containment decisions from influence. Addressed in C-89 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P11 -- Software containment not settling hardware operations:
Commands already queued in network, storage, accelerator, DMA, or
peripheral interfaces may remain effect-capable after an agent is
suspended. Requirement: Coordinate software admission
restrictions with hardware fencing, command settlement, and
recovery generations. Addressed in C-84 in draft-das-kernel-
hardware-execution-finality (https://datatracker.ietf.org/doc/
draft-das-kernel-hardware-execution-finality/), C-76 in draft-das-
kernel-hardware-execution-finality
(https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/).
P12 -- Accelerator memory reassignment with residual state:
An accelerator memory region may retain inference state and be
reassigned before commands are quiesced or the region is
sanitized. Requirement: Verify command completion, sanitization,
mapping invalidation, and ownership generation before reuse.
Addressed in S-8 in draft-das-kernel-hardware-execution-finality
(https://datatracker.ietf.org/doc/draft-das-kernel-hardware-
execution-finality/).
P13 -- Loss of authorization semantics in protocol translation:
Translation between agent protocols or API formats may drop a
constraint, change a default, substitute a principal, or broaden
the target. Requirement: Compare the resulting operation and
authority semantics with the originally permitted scope.
Addressed in C-72 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/).
P14 -- Unsafe model or tool migration during active tasks:
Replacing a model or tool may change the effects of unfinished
tasks or repeat completed operations. Requirement: Evaluate a
candidate continuation or replacement without real external
Das Expires 25 April 2027 [Page 54]
Internet-Draft Sandbox Credential Egress Finality October 2026
effects and activate it only under compatible conditions.
Addressed in C-91 in draft-das-distributed-agent-authority-
finality (https://datatracker.ietf.org/doc/draft-das-distributed-
agent-authority-finality/), C-94 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/).
P15 -- Excessive disclosure during cross-provider execution:
An agent may send all available enterprise context to a model
provider when only a small part is needed. Requirement: Generate
reduced-context representations that preserve task requirements
while enforcing disclosure restrictions. Addressed in C-96 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P16 -- Unsafe policy deployment and incomplete rollback:
A policy change may newly permit consequential operations, and
restoring the old policy does not reverse effects already
produced. Requirement: Evaluate counterfactual decision
differences, monitor actual effects, control promotion, and
preserve completed-operation history. Addressed in C-98 in draft-
das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P17 -- Revoked information remaining in derived memory:
A revoked source may continue to influence embeddings, summaries,
graphs, caches, or procedural memory. Requirement: Identify
derivation dependencies and selectively remove, regenerate,
transform, or quarantine affected representations. Addressed in
C-99 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P18 -- Revoked memory being reintroduced:
Backups, delayed jobs, stale indexes, or offline synchronization
may restore representations of prohibited source generations.
Requirement: Maintain non-revival state independently of stale
snapshots and enforce it before restoration. Addressed in C-99 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P19 -- Recovery from indeterminate operation outcomes:
A coordinator may fail after transmitting an operation but before
receiving completion evidence, and blind retry can duplicate the
effect. Requirement: Distinguish completed, pending, canceled,
Das Expires 25 April 2027 [Page 55]
Internet-Draft Sandbox Credential Egress Finality October 2026
failed, and indeterminate outcomes using stable operation
identities and resource-side evidence. Addressed in Section 7.5,
C-92 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), C-95 in draft-das-distributed-agent-
authority-finality (https://datatracker.ietf.org/doc/draft-das-
distributed-agent-authority-finality/).
P20 -- Excessively broad containment or remediation:
Global restarts, full database restoration, or deletion of whole
memory collections may destroy independently authorized work.
Requirement: Identify affected contexts and dependencies so that
restriction and remediation can be applied selectively. Addressed
in C-64 in draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/).
P21 -- Divergence between policy state and physical effectuation
state:
Policy databases, entitlements, resource transactions, hardware
queues, and memory indexes may hold different versions of relevant
state. Requirement: Use explicit generations, acknowledgments,
native transitions, completion watermarks, or equivalent
verification for each enforcement path. Addressed in C-88 in
draft-das-distributed-agent-authority-finality
(https://datatracker.ietf.org/doc/draft-das-distributed-agent-
authority-finality/), C-84 in draft-das-kernel-hardware-execution-
finality (https://datatracker.ietf.org/doc/draft-das-kernel-
hardware-execution-finality/), S-8 in draft-das-kernel-hardware-
execution-finality (https://datatracker.ietf.org/doc/draft-das-
kernel-hardware-execution-finality/).
3.3. Primary Focus of This Draft
The problems above are addressed across the three drafts; where a
profile is published in a companion draft, the entry gives that
draft's Datatracker URL. This draft concentrates on the sandbox,
credential, and network-egress boundary: the point at which a
sandboxed agent's proposed operation leaves the sandbox through a
host service, credential broker, connector, proxy, or network
interface, which corresponds principally to problems P1 to P5 and
P19.
Das Expires 25 April 2027 [Page 56]
Internet-Draft Sandbox Credential Egress Finality October 2026
3.4. Security Objectives
The objective is to provide machine-enforceable controls that
distinguish proposed computation from authorized resource
effectuation, identify direct and indirect consequences, maintain
current authority and consistency state, and prevent stale or
incompatible operations from becoming effective through uncontrolled
routes.
A further objective is to support continuity, migration, revocation,
recovery, and selective remediation without unnecessarily preventing
independent authorized work. Not every profile uses the same
enforcement mechanism; each profile states which objectives it
addresses and under which conditions.
4. Relevance to the IETF
4.1. Why This Is IETF Work
The problem described in this document is an interoperability
problem, not only a product-design question. A governed operation
typically passes through components built and operated by different
parties: an agent runtime, a gateway or proxy, a credential broker,
an identity provider, a resource API, and sometimes a hardware
device. Each of these components must agree on what operation is
being authorized, what evidence supports the authorization, how the
authorization is bound to that operation, and how a later change in
authority is propagated and acknowledged. Agreement of that kind
requires common objects and common verification semantics, which is
the type of problem the IETF exists to address.
The interoperable surfaces identified in this document are:
* a canonical, machine-verifiable descriptor of a pending operation,
including the rules for canonicalization and for treating unknown
or missing fields;
* the format and binding fields of a scoped, non-bearer capability
that authorizes one operation at one effectuation boundary;
* the result of Finality Sink verification, including denial reasons
that can be reported consistently;
* protected validation evidence and receipts, and how they may be
recorded or disclosed;
Das Expires 25 April 2027 [Page 57]
Internet-Draft Sandbox Credential Egress Finality October 2026
* authority, revocation, containment, and observation-coverage
generations, and the acknowledgments that show they have taken
effect; and
* the preservation of authorization semantics when a request is
translated between agent and service protocols.
4.2. Relationship to Existing IETF Work
This document is intended to complement existing work, not to replace
it:
* OAuth 2.0 (RFC 6749), Rich Authorization Requests (RFC 9396),
Token Exchange (RFC 8693), DPoP (RFC 9449), and the OAuth Working
Group's Transaction Tokens work describe and constrain
authorization at issuance and presentation. This document
addresses the additional check at the point of effect: verifying a
capability against the operation actually presented, under current
authority state.
* GNAP (RFC 9635) provides a grant negotiation framework within
which act-bound capabilities could be expressed.
* The RATS architecture (RFC 9334) provides attestation evidence
that several profiles use as an input predicate for enforcement
substrates and device state.
* WIMSE work on workload identity is relevant to authority
propagation across services and delegated agents.
* SCITT work on transparency is relevant to the recording of
validation evidence and receipts.
* Problem Details for HTTP APIs (RFC 9457) is a candidate format for
reporting verification denials.
For this draft, the most directly relevant interfaces are the
sandbox-to-host boundary, credential brokers and surrogate
credentials (related to OAuth, Token Exchange, and DPoP), post-
resolution network egress (related to DNS resolution behaviour and
HTTP request handling), and process-lineage taint propagation.
4.3. What the Community Is Asked to Evaluate
This is not a research paper. It identifies specific objects,
interfaces, and verification steps, and it gives reference algorithms
and negative tests so that they can be checked. The author asks the
community to consider:
Das Expires 25 April 2027 [Page 58]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. whether the gap between an upstream authorization decision and
the actual effect at the effectuation boundary is recognized as
an interoperability problem;
2. which venue is appropriate for discussing it, for example
dispatch through SECDISPATCH, or one of the working groups listed
above;
3. which of the interoperable surfaces listed above, if any, would
warrant standardization first; and
4. whether the profiles, algorithms, and failure cases in this
document are technically correct, with corrections welcomed.
This document is Informational. It does not define a complete wire
protocol and requests no IANA actions.
5. Industry Alignment and Technical Relevance
Recent public developments in autonomous AI-agent security and
execution governance include Microsoft Execution Containers (MXC),
Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-
Closed Approval Protocol), and Project Perception; Google Agent
Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security
Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA
Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and
Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude
Code Auto Mode. These initiatives illustrate industry attention to
agent isolation, independent policy enforcement, action-bound
authorization, delegated authority, credential isolation, network-
egress security, hardware-assisted containment, runtime supervision,
and fail-closed controls. This draft describes related proposed
execution-finality mechanisms without asserting that these
initiatives implement them.
References to named company technologies serve only to identify
public industry context; they are not findings of implementation
equivalence, historical derivation, endorsement, or infringement.
6. Scope and Terminology
Candidate Act, Non-Effective State, Protected Enforcement Domain,
protected validation evidence, scoped finality enablement, and
Finality Sink designate logically distinct roles. Implementations
may combine roles physically where their required independence and
enforcement guarantees are retained. Certain source-described
implementation profiles are independent controls and do not require
every other architectural role.
Das Expires 25 April 2027 [Page 59]
Internet-Draft Sandbox Credential Egress Finality October 2026
The following 46 definitions are identical in all three drafts of
this set (draft-das-sandbox-credential-egress-finality, draft-das-
kernel-hardware-execution-finality, and draft-das-distributed-agent-
authority-finality) and apply to every profile in the set.
6.1. Technology-Neutral Architectural Definitions
Definition 1 -- Computing Environment:
In this document, a "Computing Environment" refers to one or more
physical, virtual, logical, firmware-controlled, hardware-
controlled, or distributed computing arrangements capable of
executing, processing, storing, routing, authorizing, restricting,
or effecting an operation.
A Computing Environment may comprise, without limitation, a
general-purpose processor, server, workstation, mobile device,
embedded device, cloud computing instance, virtual machine,
container, micro-virtual machine, secure enclave, trusted
execution environment, hypervisor, kernel, programmable network
interface, data-processing unit, graphics processing unit,
accelerator, storage controller, industrial controller, or
combinations thereof.
A Computing Environment may be implemented within a single
physical device or across multiple interconnected devices,
administrative domains, trust domains, or geographic locations.
The term does not require any particular operating system,
processor architecture, virtualization platform, hardware
manufacturer, or deployment model.
Definition 2 -- Isolated Execution Environment:
In this document, an "Isolated Execution Environment" refers to an
execution arrangement in which one or more operations, resources,
authority contexts, or state elements are separated from other
execution contexts by one or more enforceable isolation
mechanisms.
Isolation may be implemented using virtual machines, micro-virtual
machines, containers, operating-system namespaces, process
privilege boundaries, hypervisor controls, memory protection,
hardware enclaves, secure execution partitions, firmware
restrictions, device access controls, or combinations thereof.
The isolation mechanism may restrict access to memory, files,
devices, credentials, execution interfaces, network destinations,
system calls, persistent state, or privileged operations.
Das Expires 25 April 2027 [Page 60]
Internet-Draft Sandbox Credential Egress Finality October 2026
The degree and security properties of isolation depend upon the
selected implementation. An Isolated Execution Environment does
not necessarily provide cryptographic isolation unless the
applicable embodiment expressly provides such protection.
Definition 3 -- Sandbox:
In this document, a "Sandbox" refers to an execution environment
in which the operations, accessible resources, communication
paths, privileges, or external effects of one or more workloads
are constrained by an enforceable boundary.
A Sandbox may comprise a software sandbox, process sandbox,
operating-system sandbox, container, virtual machine, micro-
virtual machine, hypervisor-controlled execution context, trusted
execution environment, hardware-enforced partition, accelerator
execution partition, firmware-controlled environment, network-
restricted execution environment, or a combination thereof.
A Sandbox may be ephemeral, persistent, nested, distributed,
dynamically reconfigured, or shared among multiple cooperating
execution components subject to defined isolation and
authorization rules.
A Sandbox may restrict execution through static configuration,
dynamic policy enforcement, capability restrictions, resource-
access controls, protected authorization mechanisms, or
combinations thereof.
The term Sandbox does not, by itself, require a separate physical
machine, cryptographic enclave, human approval process, per-
operation authorization token, or particular Finality Sink
arrangement.
Definition 4 -- Protected Enforcement Domain (PED):
In this document, a "Protected Enforcement Domain" or "PED" refers
to a logical, physical, virtual, firmware-based, hardware-based,
or distributed enforcement arrangement comprising one or more
mechanisms configured to perform specified security-relevant
operations under protection against unauthorized interference by
an applicable adversarial or less-trusted execution context.
The specified operations may comprise authority-state evaluation,
policy validation, resource-access control, operation
classification, authorization-state modification, evidence
generation, scoped authorization, effect restriction, or other
enforcement operations described in a particular embodiment.
Das Expires 25 April 2027 [Page 61]
Internet-Draft Sandbox Credential Egress Finality October 2026
A PED may be implemented using protected operating-system
components, hypervisor services, isolated virtual machines,
trusted execution environments, secure processors, hardware
security modules, programmable network devices, firmware
controllers, protected service processes, or cooperating
components.
The protection mechanism may comprise access-control isolation,
memory isolation, privilege separation, cryptographic integrity
protection, hardware-enforced separation, authenticated inter-
component communication, or combinations thereof.
A PED may be colocated with an execution controller or
effectuation interface, provided that the required protection and
enforcement properties are maintained.
Where a particular enforcement point requires independent
validation, protected evidence commitment, or a specified
authorization-state transition, those requirements are additional
limitations and are not satisfied merely by identifying a
component as a PED.
Definition 5 -- Cryptographically Isolated Enforcement Domain
(CIED):
In this document, a "Cryptographically Isolated Enforcement
Domain" or "CIED" refers to a Protected Enforcement Domain in
which one or more specified security-critical state elements,
operations, communications, or enforcement decisions are protected
through cryptographic mechanisms providing an applicable
integrity, authenticity, confidentiality, anti-replay, or state-
continuity property.
A CIED may comprise a trusted execution environment, secure
enclave, hardware security module, protected virtual machine,
secure processor, firmware-controlled cryptographic subsystem,
cryptographically authenticated distributed enforcement service,
or a combination thereof.
Cryptographic isolation may be achieved through protected keys,
authenticated state transitions, cryptographic verification,
sealed storage, authenticated channels, hardware-rooted
measurement, or other specifically disclosed cryptographic
mechanisms.
A CIED need not be implemented within a single physical processor
where the applicable cryptographic trust and state-protection
requirements can be satisfied across cooperating components.
Das Expires 25 April 2027 [Page 62]
Internet-Draft Sandbox Credential Egress Finality October 2026
A CIED is not established merely by using encryption for ordinary
network transport. The applicable embodiment must identify the
security-critical material being protected, the adversary or
unauthorized modification being resisted, and the cryptographic
mechanism providing the required protection.
Definition 6 -- Finality Sink (FS):
In this document, a "Finality Sink" or "FS" refers to a logical or
physical enforcement component, interface, controller, or
protected operation boundary having effective control over whether
a specified Candidate Act is permitted to produce its designated
consequential effect.
A Finality Sink may be implemented through a network transmission
controller, API gateway, resource server, database commit
controller, file-system write interface, credential-use
controller, payment execution interface, hardware command queue,
accelerator output interface, storage controller, actuator
interface, operating-system enforcement hook, hypervisor
mechanism, or other technically controlled effectuation interface.
A Finality Sink may be located within a host, device, virtual
machine, kernel, hardware controller, external service, or
distributed execution arrangement.
Where an applicable enforcement point requires the Finality Sink
to reconstruct an actual pending operation, verify committed
validation evidence, validate a scoped capability, or update
protected sink-local state, those operations are required in
addition to the general effectuation-control function.
A monitoring-only component that lacks effective control over the
specified consequential operation is not a Finality Sink for that
operation merely because it observes the operation.
Definition 7 -- Effectuation Boundary:
In this document, an "Effectuation Boundary" refers to a
technically identifiable point or controlled transition at which
an operation is capable of producing a specified consequential
effect outside its previously non-effective, simulated, staged, or
restricted state.
An Effectuation Boundary may include a network transmission
interface, persistent storage commit, externally accepted service
invocation, credential activation, payment instruction submission,
actuator command release, hardware queue execution, publication of
information to an external recipient, or another defined resource-
state transition.
Das Expires 25 April 2027 [Page 63]
Internet-Draft Sandbox Credential Egress Finality October 2026
Different consequential effects of the same operation may have
different Effectuation Boundaries.
For example, admission of a command to a queue, transmission of a
network packet, acceptance by a remote service, and irreversible
modification of a remote resource may constitute distinct
effectuation events according to the effect being controlled.
The applicable embodiment shall identify which consequential
effect and boundary are governed.
Definition 8 -- Scoped Authorization Condition:
In this document, a "Scoped Authorization Condition" refers to an
authorization state, value, representation, or enforceable
predicate that permits a defined operation or class of operations
only within an applicable scope.
The condition may be represented through a cryptographic token,
protected state entry, hardware register, authorization latch,
permission-table entry, policy-evaluation result, transaction-
state predicate, bounded session entitlement, or combination
thereof.
The scope may comprise operation identity, resource identity,
principal identity, destination, permitted effect, time interval,
authority generation, usage count, risk state, or other applicable
constraints.
The term does not inherently require that the condition be
portable, bearer-based, non-bearer, cryptographically signed,
single-use, or separately issued.
Where an enforcement point expressly requires a scoped non-bearer
finality capability bound to committed validation evidence, such a
capability constitutes a more specifically constrained form of
authorization and must satisfy those additional requirements.
Definition 9 -- Protected State:
In this document, "Protected State" refers to data, control
information, configuration, or machine-maintained state whose
confidentiality, integrity, authenticity, ordering, or permitted
modification is protected against an identified unauthorized
execution context.
Das Expires 25 April 2027 [Page 64]
Internet-Draft Sandbox Credential Egress Finality October 2026
Protected State may comprise authority records, policy versions,
execution generations, usage counters, revocation states,
transaction states, resource ownership information, memory-
isolation metadata, hardware queue state, or authorization
conditions.
Protected State may be maintained in protected memory, secure
storage, access-controlled operating-system state, firmware,
hardware registers, authenticated databases, cryptographically
verified distributed storage, or combinations thereof.
The applicable embodiment shall specify the protected properties,
permitted state transitions, and enforcement mechanism relevant to
the governed operation.
Definition 10 -- Non-Effective State (NES):
In this document, a "Non-Effective State" or "NES" refers to a
condition in which a proposed operation has been represented,
prepared, staged, simulated, held, or otherwise processed without
yet producing the particular consequential effect whose release is
governed by the applicable embodiment.
An operation may be in a Non-Effective State relative to one
specified effect while already having produced another distinct
effect.
For example, an operation may have been recorded in a local queue
while remaining non-effective with respect to transmission to an
external service.
NES may be implemented through a transaction staging area,
execution queue, simulated resource interface, protected holding
state, deferred command buffer, restricted network interface,
uncommitted database transaction, or equivalent technical
mechanism.
Where an enforcement point requires NES to persist until a
particular validation or authorization condition is satisfied, the
corresponding embodiment shall disclose how premature effectuation
is prevented.
END OF INITIAL CORE DEFINITIONS.
6.2. General Interpretation
The following definitions apply throughout this document set unless a
particular profile or enforcement point expressly imposes a narrower
requirement.
Das Expires 25 April 2027 [Page 65]
Internet-Draft Sandbox Credential Egress Finality October 2026
The disclosed systems may be implemented using software, firmware,
hardware, programmable logic, microcode, dedicated circuitry,
distributed services, cloud infrastructure, embedded controllers, or
combinations thereof.
A named technical function may be implemented by one physical
component, multiple components, one software process, multiple
cooperating processes, one protected domain, or a distributed
arrangement, provided that the implementation supplies the
operational relationships and security properties required by the
applicable enforcement point.
The words hardware, software, processor, controller, module, gate,
domain, interface, and service do not by themselves impose a
particular physical partition.
References to a single component do not exclude a plurality of
cooperating components unless an enforcement point expressly requires
a single component. Conversely, references to distinct functional
roles do not necessarily require physically separate machines.
A cryptographically protected implementation is not required in every
disclosed embodiment merely because cryptographic implementations are
described. However, when an enforcement point requires cryptographic
isolation, cryptographic verification, protected-state commitment, or
hardware-rooted enforcement, the required property must be provided
by the actual implementation.
Embodiments directed to retrospective monitoring, ordinary native
authorization, predictive admission, static confinement, atomic
transaction authorization, or independent human execution need not
include the protected execution-finality sequence unless expressly
required by their corresponding enforcement points.
Descriptions of implementation alternatives do not remove a
requirement stated in an enforcement point.
6.3. Execution Environments and Sandbox Architectures
Definition 1 -- Artificial-Intelligence Agent:
An Artificial-Intelligence Agent means a software, firmware,
hardware-assisted, virtualized, distributed, or hybrid
computational system configured to select, generate, plan, modify,
schedule, delegate, or initiate one or more computational or
resource operations based at least in part on artificial-
intelligence processing.
Das Expires 25 April 2027 [Page 66]
Internet-Draft Sandbox Credential Egress Finality October 2026
The artificial-intelligence processing may include language-model
inference, multimodal inference, machine-learning decision
processes, learned policies, planning algorithms, model-generated
tool selection, or combinations thereof.
The agent may operate continuously, intermittently, synchronously,
asynchronously, locally, remotely, or through delegated
computational components.
An Artificial-Intelligence Agent need not independently possess
permission to complete every operation that it proposes.
Definition 2 -- Agent Execution Context:
An Agent Execution Context means a machine-identifiable collection
of execution state associated with an agent, task, process,
session, workflow, delegated operation, or group of related
computations.
The context may include an agent identifier, task identifier,
process identity, model configuration, tool configuration,
accessible resources, authority references, execution history,
memory references, policy state, outstanding operations, delegated
workers, and applicable security or administrative boundaries.
An Agent Execution Context may be represented in host memory,
protected memory, a runtime registry, virtual-machine state, a
container runtime, an identity service, a distributed execution
record, or hardware-associated command metadata.
Definition 3 -- Isolated Execution Environment:
An Isolated Execution Environment means a computational execution
environment subject to one or more technically enforced
restrictions separating at least a portion of its executable
activity, memory access, resource access, authority,
communication, or effects from another execution environment or
protected resource.
Isolation may be implemented through virtual-machine boundaries,
process isolation, operating-system namespaces, capability
restrictions, mandatory access control, hypervisor controls,
microkernel partitions, secure execution domains, hardware memory
protection, network separation, interface mediation, or
combinations thereof.
Isolation may be physical, logical, cryptographic, temporal,
administrative, or resource-specific.
Das Expires 25 April 2027 [Page 67]
Internet-Draft Sandbox Credential Egress Finality October 2026
The term does not imply that every listed isolation mechanism
provides equivalent security guarantees.
Definition 4 -- Virtual-Machine-Isolated Execution Environment:
A Virtual-Machine-Isolated Execution Environment means an Isolated
Execution Environment implemented at least in part through a
virtualization mechanism that presents or controls an execution
context having virtualized processor, memory, device, operating-
system, or resource interfaces.
Such an environment may comprise a conventional virtual machine,
micro-virtual machine, confidential virtual machine, hypervisor-
managed partition, hardware-assisted virtual machine, or other
execution environment providing the virtualization properties
required by the applicable embodiment.
The virtualization mechanism may employ a type-1 or type-2
hypervisor, hardware virtualization extensions, second-level
address translation, virtualized I/O devices, memory protection,
or equivalent techniques.
A container, process namespace, or user-space sandbox is not
necessarily a virtual machine merely because it supplies
isolation. Such an environment may nevertheless constitute a
Sandbox or Isolated Execution Environment under the corresponding
definitions.
A virtual machine is not automatically a PED or CIED merely
because its workloads are separated from other workloads.
Definition 5 -- Sandbox or Sandboxed Execution Environment:
A Sandbox or Sandboxed Execution Environment means an execution
environment in which access to one or more resources, authorities,
interfaces, communications, operations, or external effects is
restricted relative to a defined execution policy or enclosing
environment.
A Sandbox may be implemented using a virtual machine, micro-
virtual machine, container, process sandbox, application sandbox,
browser sandbox, WebAssembly runtime, language runtime, operating-
system security domain, system-call filter, kernel security
policy, remote execution environment, disposable execution
instance, or hardware-assisted isolation mechanism.
A Sandbox may restrict file access, process creation, memory
access, network access, credential access, device access,
privilege escalation, persistent-state modification, service
invocation, or other effects.
Das Expires 25 April 2027 [Page 68]
Internet-Draft Sandbox Credential Egress Finality October 2026
A Sandbox need not use a particular hypervisor, operating system,
container format, processor architecture, or vendor-specific
isolation mechanism.
The degree and type of isolation provided by the Sandbox are
properties of its implemented controls and are not established
solely by its designation as a Sandbox.
Definition 6 -- Sandbox Type or Sandbox Isolation Class:
A Sandbox Type or Sandbox Isolation Class means a machine-
identifiable classification of the technical isolation and
resource restrictions supplied by a sandboxed environment.
The classification may distinguish virtual-machine isolation,
micro-virtual-machine isolation, operating-system container
isolation, process isolation, language-runtime isolation,
application-level isolation, hardware-assisted memory isolation,
network isolation, credential isolation, and combinations thereof.
A Sandbox Isolation Class may further identify applicable
privileged-escape paths, available host interfaces, delegated
resource authority, persistence rules, and expected enforcement
mechanisms.
Where an embodiment requires an isolation property, classification
of an environment as belonging to a Sandbox Type does not
substitute for verification that the environment actually provides
the required property.
Definition 7 -- Isolation Boundary or Trust Boundary:
An Isolation Boundary or Trust Boundary means a technical
separation between execution, authority, memory, resource,
identity, or administrative contexts having different access
privileges or security assumptions.
The boundary may be enforced through hardware protection,
cryptographic verification, virtual-memory separation, hypervisor
isolation, operating-system access control, network controls,
protected API interfaces, process mediation, or combinations
thereof.
Crossing a trust boundary may involve transfer of data, invocation
of a function, delegation of authority, release of a credential,
modification of a resource, or submission of a hardware command.
An isolation boundary need not correspond to a physical machine
boundary.
Das Expires 25 April 2027 [Page 69]
Internet-Draft Sandbox Credential Egress Finality October 2026
Definition 8 -- Host Execution Environment or Host Domain:
A Host Execution Environment or Host Domain means an execution or
resource environment that provides, supervises, owns, or mediates
one or more capabilities or resources used by another execution
environment.
The Host Domain may comprise a host operating system, hypervisor,
privileged service, cloud control plane, resource gateway, browser
automation host, credential broker, device controller, physical
machine, or remote infrastructure service.
The Host Domain may execute on the same physical machine as a
sandbox or on a different machine.
A Host Domain is not inherently trusted merely because it is
described as a host, and its authority is determined by the
enforcement boundaries and protections actually provided.
Definition 9 -- Non-Authoritative Mediator:
A Non-Authoritative Mediator means an intermediary that proposes,
formats, observes, routes, buffers, transforms, classifies, pre-
screens, or submits an operation without independently possessing
the complete authority required to make that operation effective
under an applicable protected-finality architecture.
Examples include agent runtimes, operating-system wrappers,
container managers, user-space policy services, tool dispatchers,
network proxies, and browser automation controllers.
A mediator may enforce preliminary restrictions or deny an
operation, but where the applicable embodiment requires
independent protected finality authorization, the mediator cannot
unilaterally substitute its own approval for that required
authorization.
This definition does not prohibit an intermediary from serving as
a protected enforcement component in an implementation where it
actually satisfies the required protection and authority
conditions.
6.4. Operations, Effects, and Effectuation Boundaries
Definition 10 -- Effect-Capable Resource:
An Effect-Capable Resource means a computational, informational,
cryptographic, network, storage, financial, electronic,
electromechanical, physical, or service resource through which an
operation can produce a consequential state change, disclosure,
transmission, commitment, output, or controlled action.
Das Expires 25 April 2027 [Page 70]
Internet-Draft Sandbox Credential Egress Finality October 2026
Examples include files, databases, service APIs, credentials,
network interfaces, persistent memory, payment systems, message
services, accelerator queues, direct-memory-access engines,
storage controllers, display interfaces, robotic actuators, and
external devices.
A resource may be effect-capable even when it is accessed
indirectly through another service or interface.
Definition 11 -- Proposed Operation:
A Proposed Operation means an operation specified, requested,
generated, selected, scheduled, prepared, or delegated for
possible performance, whether or not it has been executed or
authorized.
The operation may be represented as an instruction, API request,
transaction descriptor, command, program invocation, tool call,
resource mutation, message, signal, queue entry, or hardware
operation descriptor.
A Proposed Operation is not necessarily a Candidate Act subject to
protected-finality processing unless the applicable profile or
enforcement point so requires.
Definition 12 -- Candidate Act:
A Candidate Act means a proposed, pending, staged, buffered,
scheduled, delegated, or otherwise identified operation having a
possible consequential effect and subject to an applicable
execution-control procedure.
A Candidate Act may comprise a software command, tool invocation,
network transmission, file mutation, storage commit, credential
operation, database transaction, memory mutation, payment
instruction, rendered output, hardware command, actuator action,
or other consequential operation.
A Candidate Act may be represented as data, code, a descriptor, a
hardware queue entry, a pending state transition, or a physical-
control instruction.
In embodiments expressly requiring protected execution finality,
the Candidate Act is maintained in a non-effective condition until
the applicable finality requirements have been satisfied.
Definition 13 -- Non-Effective State or NES:
Das Expires 25 April 2027 [Page 71]
Internet-Draft Sandbox Credential Egress Finality October 2026
A Non-Effective State, abbreviated NES, means a technical state in
which a governed operation may have been generated, computed,
prepared, buffered, or conditionally scheduled but has not yet
produced the consequential effect governed by the applicable
control mechanism.
NES may be implemented through a held transaction, buffered
packet, uncommitted database modification, unsubmitted tool
request, disabled execution queue, pending device command,
inaccessible output buffer, or other technically enforceable
state.
A software label indicating that an operation is pending is
insufficient where the operation can nevertheless produce the
governed effect through an uncontrolled route.
The term does not require that all internal computation be
stopped.
Definition 14 -- External Effect or Effectuation:
An External Effect means a consequential change, release,
transfer, disclosure, communication, acceptance, persistence,
operation, or observable result occurring outside the non-
effective state governed by a particular execution-control
mechanism.
The effect may be produced by software, firmware, hardware, a
remote service, a physical device, or cooperation among them.
Effectuation may include API dispatch, resource modification, data
disclosure, network transmission, credential use, database commit,
memory-state release, output rendering, physical signaling, or
actuator operation.
External does not necessarily mean outside the physical computer.
An effect may be external relative to a protected sandbox,
transaction boundary, security domain, or governed resource state.
Definition 15 -- Effectuation Path:
An Effectuation Path means a sequence of components, interfaces,
state transitions, or resource operations through which a Proposed
Operation may become consequential.
An Effectuation Path may comprise a system-call path, tool-
dispatch path, credential-use path, API path, network path, file-
system path, storage-commit path, memory-access path, accelerator
queue, firmware path, device-control path, or combination thereof.
Das Expires 25 April 2027 [Page 72]
Internet-Draft Sandbox Credential Egress Finality October 2026
An Effectuation Path may be implemented wholly in software, wholly
in hardware, or across software-hardware boundaries.
Multiple Effectuation Paths may lead to the same consequential
resource effect.
Definition 16 -- Pre-Effectuation Boundary:
A Pre-Effectuation Boundary means a technically identifiable
control location at which a Proposed Operation may be intercepted,
restricted, modified, denied, or authorized before producing the
consequential effect governed by the applicable embodiment.
A Pre-Effectuation Boundary may be implemented at an API
dispatcher, transaction-admission interface, system-call
interceptor, operating-system security hook, proxy, storage commit
controller, device command queue, hardware access controller, or
other applicable interface.
The boundary need not be the last physical component in an
execution path, provided its controls can prevent the governed
effect as required by the particular embodiment.
Definition 17 -- Execution-Finality Boundary:
An Execution-Finality Boundary means a technical boundary at which
an operation transitions, or would transition, from a non-
effective or conditionally authorized state to a state having the
consequential effect governed by the applicable protected-finality
mechanism.
The boundary may be a software-controlled dispatch interface,
database commit point, protected network-egress path,
cryptographic signing interface, storage controller, memory
controller, hardware transmission interface, or physical actuation
interface.
The boundary may be logical or physical.
An implementation asserting non-bypassable finality must establish
that the governed effect cannot be produced through an alternative
uncontrolled path.
Definition 18 -- Finality Gate:
A Finality Gate means a technical control mechanism configured to
determine, enforce, or condition whether a Candidate Act may cross
an applicable Execution-Finality Boundary.
Das Expires 25 April 2027 [Page 73]
Internet-Draft Sandbox Credential Egress Finality October 2026
A Finality Gate may be implemented through protected software,
firmware, cryptographic enforcement, a trusted execution
environment, hypervisor, kernel security mechanism, protected
service, hardware controller, programmable logic, or combinations
thereof.
The Finality Gate may perform or control authorization evaluation,
protected-state handling, evidence generation, bounded enablement,
denial, or withholding as required by the applicable embodiment.
The Finality Gate is a functional role and need not constitute a
physically separate device.
Definition 19 -- Finality Sink:
A Finality Sink, abbreviated FS, means a technical component or
enforcement interface positioned at, before, or in effective non-
bypassable control of a consequential effectuation boundary, and
configured to control whether a governed Candidate Act can produce
its corresponding effect.
A Finality Sink may comprise an API dispatcher, credential-use
interface, protected gateway, network-egress controller, file-
system write controller, database commit controller, storage
controller, hypervisor-controlled execution interface, memory
controller, DMA controller, SmartNIC, DPU, accelerator interface,
cryptographic signing interface, display or rendering controller,
or physical actuator interface.
A Finality Sink may be implemented in software, firmware,
hardware, or their combination.
In protected-finality embodiments requiring scoped capability
verification, the Finality Sink verifies or is technically gated
by the applicable bounded enablement condition before
effectuation.
A software gateway constitutes a Finality Sink for a governed
effect only where its enforcement position prevents the
corresponding effect from bypassing the required verification
through another available route.
The Finality Sink and PED may be functionally distinct while
residing in the same component, provided that the required
verification relationship is implemented.
Definition 20 -- Finality Sink Verification:
Das Expires 25 April 2027 [Page 74]
Internet-Draft Sandbox Credential Egress Finality October 2026
Finality Sink Verification means machine-enforced validation
performed by or under control of an applicable Finality Sink to
determine whether a governed Candidate Act satisfies the finality-
enabling requirements imposed by the relevant enforcement point.
Such verification may include verification of a scoped capability,
protected-state condition, act descriptor, authorized resource
scope, protected validation-evidence reference, freshness
constraint, destination, execution boundary, or sink-local state.
The required verification elements are determined by the
applicable enforcement point and are not automatically mandatory
in every alternative authorization embodiment.
Where actual-operation correspondence is required, the Finality
Sink obtains or reconstructs sufficient properties of the pending
effectuation operation to compare it with the authorized
operation.
6.5. Protected Domains and Execution Authority
Definition 21 -- Protected Enforcement Domain or PED:
A Protected Enforcement Domain, abbreviated PED, means a computing
or enforcement domain having technically established protections
sufficient to preserve the integrity of one or more security-
critical validation, authority, state-control, or effectuation-
control operations required by the applicable embodiment.
A PED may be implemented using protected software, an operating-
system security mechanism, protected kernel service, isolated
virtual machine, hypervisor security partition, secure
microkernel, trusted execution environment, secure enclave,
hardware security module, secure element, cryptographic
coprocessor, FPGA security region, programmable network device,
SmartNIC, DPU, protected accelerator controller, secure firmware,
or cooperating protected components.
A PED may reside on the requesting device, an associated host, a
network gateway, a cloud service, a remote security processor, or
a distributed set of machines.
A PED is characterized by the protection and enforcement
properties it actually provides rather than by the product name or
location of its implementation.
Ordinary application code or an unprotected policy service is not
necessarily a PED merely because it evaluates authorization rules.
Das Expires 25 April 2027 [Page 75]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where protected-state integrity, protected validation evidence,
bounded authority, or non-bypassable enforcement is required, the
PED must supply the corresponding technical guarantees.
Definition 22 -- Cryptographically Isolated Enforcement Domain or
CIED:
A Cryptographically Isolated Enforcement Domain, abbreviated CIED,
means a PED providing cryptographically enforced separation of at
least the authority-critical functions or state specified by the
applicable embodiment.
Such separation may involve protected cryptographic keys,
authentication of validation state, integrity of executable
validation logic, sealed or authenticated mutable state, hardware-
rooted measurement, protected state recovery, or controlled
release of authority.
A CIED may be implemented using a suitable TEE, HSM, secure
enclave, secure element, protected coprocessor, cryptographically
isolated microkernel component, secure accelerator partition,
SmartNIC security domain, or a distributed cryptographically
protected enforcement arrangement.
A CIED is not established merely through encrypted communications,
possession of a TLS certificate, software code signing, or
ordinary access-control configuration unless the resulting
architecture also provides the required isolation and enforcement
properties.
Every CIED is a PED for purposes of the relevant definitions, but
a PED need not be a CIED unless the applicable enforcement point
requires cryptographic isolation.
Definition 23 -- Protected Governance Domain or PGD:
A Protected Governance Domain, abbreviated PGD, means a protected
authority domain configured to evaluate or enforce governance-
related conditions concerning identity, purpose, permitted
operations, security policy, resource scope, jurisdiction,
revocation, delegation, risk, or operational compliance.
A PGD may operate within or in cooperation with a PED or CIED.
A PGD may be implemented locally, remotely, or through a
distributed arrangement.
Das Expires 25 April 2027 [Page 76]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where a PGD performs a function required to remain protected, it
must provide the applicable state-integrity and enforcement
properties regardless of whether it is described as a policy
service, control plane, authority plane, or governance controller.
Definition 24 -- Protected Enforcement Path:
A Protected Enforcement Path means an arrangement of one or more
components through which a required security-critical operation is
performed while preserving the integrity and authority guarantees
specified by the applicable embodiment.
The path may include a PED, CIED, protected software service,
cryptographically authenticated communication channel, protected
registry, hardware controller, finality gate, or Finality Sink.
The path may span multiple machines or administrative domains.
Cryptographically authenticated communication alone does not
establish that the endpoints or intermediate authority operations
are protected.
Where an enforcement point requires a Protected Enforcement Path,
the implementation must prevent an unauthorized component from
altering or bypassing the applicable protected decision or
effectuation condition.
Definition 25 -- Protected State:
Protected State means mutable or immutable state maintained with
technical protections against unauthorized reading, modification,
substitution, rollback, replay, or other interference, to the
extent required by the applicable embodiment.
Protected State may comprise an authority record, policy epoch,
revocation generation, monotonic counter, nonce registry, quota
register, sealed transaction state, key reference, capability-
consumption entry, secure latch, protected permission bit, queue
generation, or other security-critical value.
Protected State may be stored in protected software memory, an
authenticated database, secure firmware storage, trusted execution
memory, hardware registers, an HSM, a distributed authenticated
state machine, or equivalent arrangements meeting the relevant
security requirements.
A value does not become Protected State solely because it is
logged, encrypted at rest, or labeled confidential.
Definition 26 -- Authority Predicate:
Das Expires 25 April 2027 [Page 77]
Internet-Draft Sandbox Credential Egress Finality October 2026
An Authority Predicate means a machine-evaluable condition
contributing to a decision concerning whether an operation,
access, transaction, execution, transmission, or resource
modification is authorized.
Authority Predicates may concern identity, delegated authority,
permitted operation scope, purpose, destination, jurisdiction,
runtime behavior, resource state, policy version, revocation
state, freshness, evidence integrity, hardware security state, or
combinations thereof.
Authority Predicates may be evaluated by an ordinary authorization
controller or by a protected enforcement domain, according to the
relevant enforcement point.
No particular predicate is universally mandatory unless expressly
required by the enforcement point.
Definition 27 -- Authority Object:
An Authority Object means a machine-readable representation of one
or more permitted operations, authority constraints, scopes,
validity conditions, delegation relationships, or relevant
security-state requirements.
An Authority Object may comprise a structured policy record,
access entitlement, authorization scope object, cryptographic
authorization artifact, attested record, protected registry entry,
or equivalent structured authorization representation.
An Authority Object may be ordinary or protected, depending on the
embodiment.
An ordinary Authority Object does not automatically constitute a
scoped non-bearer finality capability.
Definition 28 -- Act Descriptor or Candidate Act Descriptor:
An Act Descriptor means a machine-readable representation
identifying sufficient properties of a proposed or pending
operation for a specified comparison, authorization, observation,
enforcement, or audit function.
Such properties may include operation identity, operation class,
requesting context, resource target, destination, arguments,
payload properties, affected state, policy version, temporal
condition, delegation context, or effectuation interface.
Das Expires 25 April 2027 [Page 78]
Internet-Draft Sandbox Credential Egress Finality October 2026
The descriptor may be represented by structured fields, canonical
serialization, digests, authenticated records, protected state,
hardware metadata, or combinations thereof.
Different embodiments may require different descriptor fields.
Where an enforcement point requires comparison with the actual
pending operation, a descriptor based solely on a potentially
untrusted requester's assertion may be insufficient unless the
relevant information is independently verified.
Definition 29 -- Protected Validation Evidence:
Protected Validation Evidence means a machine-verifiable
representation of a security-critical validation result whose
integrity is protected in accordance with the applicable
embodiment.
Protected Validation Evidence may comprise a signed record,
authenticated state transition, protected log entry, sealed
receipt, protected register update, cryptographic commitment,
attested result, or equivalent protected representation.
Where an enforcement point requires evidence to be committed
before or atomically with authorization of an execution-enabling
condition, the evidence must satisfy that ordering relationship.
Protected Validation Evidence is not necessarily required by
embodiments expressly directed to ordinary authorization,
retrospective monitoring, static sandbox restrictions, or other
mechanisms lacking that requirement.
Definition 30 -- Scoped Non-Bearer Capability:
A Scoped Non-Bearer Capability means a protected, bounded
technical authority condition or artifact that permits a specified
operation or class of operations to become effective only within
the validated scope and contextual constraints imposed by the
applicable protected-finality architecture.
The capability may be represented by a cryptographic authorization
object, protected key-use condition, secure register, protected
registry state, bounded permission state, secure latch, hardware
authorization entry, protected signal, or equivalent technically
enforced condition.
The capability is non-bearer in the sense that mere possession,
copying, or presentation of an ordinary credential-like
representation is insufficient to authorize arbitrary effectuation
outside the required scope and verification conditions.
Das Expires 25 April 2027 [Page 79]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where required by an enforcement point, the capability is bound to
a Candidate Act, descriptor, protected evidence, applicable
protected state, effectuation boundary, Finality Sink, freshness
condition, and permitted effectuation scope.
The term does not require a portable token, physically separate
authorization server, or external network exchange.
Definition 31 -- Bounded Enablement Condition:
A Bounded Enablement Condition means a machine-enforced condition
determining whether an operation may proceed within specified
limits.
The condition may be represented by a software-controlled
authorization state, protected registry entry, hardware
permission, latch, register, queue-admission state, credential-use
condition, or other bounded control mechanism.
In embodiments implementing a scoped non-bearer finality
capability, the Bounded Enablement Condition may be the capability
or its protected implementation form and does not necessarily
constitute an additional required component.
In alternative authorization embodiments, a bounded permission or
access state does not automatically satisfy the requirements of a
scoped non-bearer capability unless the required binding,
protection, and enforcement relationships are present.
6.6. Algorithmic and Runtime Verification
Definition 32 -- Algorithmic Intent Fingerprint or AIF:
An Algorithmic Intent Fingerprint, abbreviated AIF, means a
machine-verifiable representation of a permitted operational
intent or purpose envelope applicable to an operation or class of
operations.
The envelope may identify permitted task objectives, operation
types, destinations, resource scopes, delegation limits, temporal
conditions, or policy constraints.
AIF does not refer to a subjective psychological intention
attributed to an artificial-intelligence model.
An AIF may be compared with a proposed operation descriptor to
determine whether the operation lies within an authorized scope.
Definition 33 -- Algorithmic Logic Fingerprint or ALF:
Das Expires 25 April 2027 [Page 80]
Internet-Draft Sandbox Credential Egress Finality October 2026
An Algorithmic Logic Fingerprint, abbreviated ALF, means a
machine-verifiable representation of computational logic,
executable workflow, model configuration, orchestration structure,
tool-selection logic, execution graph, policy configuration, or
other logic state relevant to an applicable authorization
requirement.
An ALF may be represented by a digest, canonical graph,
authenticated identifier, protected measurement, structured logic
description, or equivalent comparison artifact.
Where an enforcement point requires ALF correspondence, a runtime
logic representation is compared with a previously approved or
otherwise authorized logic condition.
AIF concerns authorized operational purpose; ALF concerns the
authorized computational logic or workflow. The two are not
interchangeable where separately required.
Definition 34 -- Runtime Behavioral Descriptor or RBD:
A Runtime Behavioral Descriptor, abbreviated RBD, means a bounded
machine-readable representation of execution behavior observed or
derived during performance of an agent task or associated
computation.
An RBD may be derived from process events, system calls, tool
invocations, network activity, memory operations, retrieval
events, resource-access patterns, execution graphs, or other
observable execution signals.
An RBD need not reveal model weights, private reasoning traces, or
complete neural activation states.
Where an enforcement point requires independently observed runtime
behavior, an agent-generated self-report alone does not satisfy
that requirement without the additional verification specified by
the enforcement point.
Definition 35 -- Machine-Verifiable:
Machine-Verifiable means capable of being evaluated by a computing
mechanism according to an identifiable test, comparison,
validation rule, mathematical relation, cryptographic
verification, state invariant, or machine-executable decision
procedure.
Machine verification may use deterministic rules, authenticated
data structures, cryptographic primitives, hardware observations,
structured measurements, or bounded computational evaluation.
Das Expires 25 April 2027 [Page 81]
Internet-Draft Sandbox Credential Egress Finality October 2026
The term does not require cryptographic verification in every
embodiment.
A subjective statement that an operation is safe or approved is
not machine verification without a corresponding evaluable
representation or decision procedure.
Definition 36 -- Fail-Closed Enforcement:
Fail-Closed Enforcement means an enforcement behavior in which
failure to establish one or more conditions required for
authorization causes the governed operation to be withheld,
denied, disabled, quarantined, or otherwise prevented from
producing the effect under the control of the applicable
enforcement mechanism.
Relevant failures may include unavailable validation services,
invalid authority, stale state, indeterminate verification,
replay, mismatched operation descriptors, exhausted quotas,
invalid protected state, or loss of a required enforcement
interface.
Fail-closed behavior applies to the operation and failure
conditions specified by the relevant profile or enforcement point.
A system is not necessarily globally fail-closed merely because
one interface rejects requests; the enforcement arrangement must
also account for applicable alternative effectuation routes when
non-bypassability is asserted.
# EMBODIMENT S-1
7. Source-Derived Technical Implementation Profiles
This section contains the implementation profiles whose primary
boundary is the subject of this draft: S-1, S-2, S-3, S-4, C-21,
C-33, C-42, C-45, C-48. The remaining profiles of the set are
published in the companion drafts listed in the Profile Map
(Section Section 1.3). Each profile is reproduced in full and
retains the page provenance of the original disclosure. Patent-style
mapping subsections are recast as enforcement-point mappings within
their profiles. Mechanisms are not automatically mandatory for every
profile; deployment constraints and alternatives remain applicable.
Das Expires 25 April 2027 [Page 82]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1. Implementation Profile S-1
Source location: original disclosure pages 64-95. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.1.1. S-1.1 - Technical Field
this implementation profile relates to computer security,
virtualization, artificial-intelligenceagent execution, protected
authorization, resource-access mediation, and enforcement of
consequential operations originating from a virtual-machine-isolated
execution environment.
More particularly, the embodiment describes a technical architecture
in which an artificialintelligence agent executes within a virtual
machine while one or more enforcement components outside the agent's
ordinary execution authority govern whether the agent's proposed
operations may produce specified consequential effects.
The architecture may be implemented through software, firmware,
hardware, cryptographically protected execution, or combinations
thereof.
The virtual-machine-isolated implementation constitutes one species
of a broader sandboxed execution architecture and does not limit
other embodiments to virtual-machine deployment.
7.1.2. S-1.2 - Technical Problem
An artificial-intelligence agent may operate inside a virtual machine
that restricts its access to the underlying host. Such isolation can
reduce unauthorized interaction with host resources but does not
necessarily establish that every operation permitted to leave the
virtual machine is authorized for its particular purpose, recipient,
resource state, or execution context.
For example, an agent may be permitted to use a network connector
while nevertheless generating an unauthorized financial instruction,
disclosing a confidential document, modifying a cloud resource, or
invoking a service outside the scope of a particular task.
A virtual machine may also contain executable processes, cached
credentials, tool interfaces, queued operations, and delegated
subprocesses through which a proposed operation can reach an external
resource.
Das Expires 25 April 2027 [Page 83]
Internet-Draft Sandbox Credential Egress Finality October 2026
Accordingly, sandbox isolation and operation-specific authority
represent distinguishable technical properties.
this implementation profile addresses a protected-finality
implementation in which:
(a) an agent may perform internal computation within a virtual
machine; (b) an externally consequential operation is represented as
a Candidate Act; (c) the Candidate Act is held in a Non-Effective
State with respect to the governed consequence; (d) a Protected
Enforcement Domain evaluates the authorization conditions required
for that Candidate Act; (e) protected validation evidence and a
scoped non-bearer finality capability are established as required by
the selected finality protocol; (f) a Finality Sink verifies the
actual pending operation against the applicable protected
authorization state; and (g) the consequential operation is permitted
only if the required verification succeeds.
The architecture further addresses enforcement-path completeness,
guest compromise, operation substitution, replay, stale
authorization, asynchronous dispatch, and restrictions imposed by the
selected isolation substrate.
7.1.3. S-1.3 - Technical Objective
The embodiment provides a virtual-machine-isolated execution
arrangement in which ordinary agent computation remains
distinguishable from authority to produce a governed consequential
effect.
The technical objectives include:
1. Isolating agent-controlled processes from specified host
enforcement components. 2. Preventing a guest-controlled agent from
directly modifying protected authority state. 3. Intercepting
designated effect-capable operations before the governed
consequential effect. 4. Establishing a machine-readable descriptor
of the pending operation.
5. Performing protected authorization and policy validation. 6.
Recording integrity-protected evidence of the required validation. 7.
Creating or activating a scoped non-bearer finality capability. 8.
Verifying the capability and actual pending operation at a controlled
effectuation boundary. 9. Preventing replay, unauthorized
substitution, stale authorization, and unapproved alternate
effectuation paths. 10. Supporting revocation, recovery, migration,
and explicit handling of unresolved operation outcomes.
Das Expires 25 April 2027 [Page 84]
Internet-Draft Sandbox Credential Egress Finality October 2026
Not every deployment must use the same hardware or software isolation
mechanisms. An implementation must, however, satisfy the security
and enforcement properties required by the applicable enforcement
point.
7.1.4. S-1.4 - System Architecture
A representative system comprises:
7.1.5. Component A - Physical or Virtualized Computing Host
A computing platform including one or more processors, memories,
storage devices, and input/output interfaces.
7.1.6. Component B - Virtualization Manager
A hypervisor, virtual-machine monitor, or equivalent virtualization
mechanism configured to manage an isolated guest execution
environment.
7.1.7. Component C - Agent Virtual Machine
A guest environment containing an artificial-intelligence agent,
model runtime, tool dispatcher, local memory, and one or more agent-
controlled software processes.
7.1.8. Component D - Candidate Act Interceptor
An interception mechanism configured to identify governed operations
before they reach a designated consequential effectuation boundary.
7.1.9. Component E - Non-Effective Operation Holder
A protected or otherwise controlled staging mechanism configured to
retain a pending operation without permitting the governed external
effect.
7.1.10. Component F - Protected Enforcement Domain
An enforcement component configured to evaluate the applicable
authority predicates and maintain or access required protected
authorization state.
7.1.11. Component G - Protected Validation Evidence Store
A protected record, registry, authenticated database, secure memory
structure, or equivalent mechanism configured to maintain evidence of
the required authorization evaluation.
Das Expires 25 April 2027 [Page 85]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.12. Component H - Scoped Finality Enablement Controller
A protected mechanism configured to establish, activate, or release a
scoped non-bearer capability associated with an authorized Candidate
Act.
7.1.13. Component I - Finality Sink
An enforcement component configured to control the governed
effectuation operation and perform the verification required by the
selected finality protocol.
7.1.14. Component J - Effect-Capable Resource
A destination or resource capable of producing the specified
consequential effect.
Examples include a network service, file system, cloud resource,
database, credential service, payment service, accelerator interface,
or physical controller.
The components may be physically separate, colocated, virtualized, or
implemented through cooperating hardware and software elements.
7.1.15. S-1.5 - Reference Deployment Arrangement
In one representative implementation:
| x | The artificial-intelligence agent operates inside a guest virtual machine. |
| - | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| x | The guest is prevented from directly accessing designated protected host resources. |
| x | A virtualized tool interface or controlled guest-to-host communication channel carries a proposed operation toward the host-side enforcement service. |
| x | A host-side interceptor receives the proposed operation and stages it. |
| - | --------------------------------------------------------------------------------------- |
| x | A PED validates the operation against protected authority state. |
| x | The PED establishes protected validation evidence and a bounded finality authorization. |
| x | The host-side Finality Sink reconstructs or independently observes the actual operation it is about to execute. |
| - | --------------------------------------------------------------------------------------------------------------- |
| x | The Finality Sink verifies the required evidence, capability bindings, and current enforcement state. |
| x | Only then does the Finality Sink perform the specified external operation. |
A representative logical sequence is:
7.1.16. Agent VM → Controlled Operation Interface → Candidate Act
Holding State → PED
Das Expires 25 April 2027 [Page 86]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.17. Validation → Protected Evidence and Capability → Finality Sink
Verification → Effect-Capable Resource
The PED and Finality Sink are shown as distinct functional roles.
They may occupy the same protected physical device or process if the
required security and verification properties are preserved.
7.1.18. S-1.6 - Virtual-Machine Configuration and Isolation
The virtualization manager establishes a guest execution environment
with restrictions corresponding to the applicable security policy.
The configuration may include:
(a) a guest memory allocation separated from host-enforcement memory;
(b) restricted access to host file systems and storage volumes; (c)
limited or mediated access to host operating-system interfaces; (d)
controlled virtual network interfaces; (e) restricted virtualized
peripheral access; (f) limited or prohibited device pass-through; (g)
constrained host-to-guest shared-memory mappings; (h) controlled
guest-to-host RPC, virtio, or equivalent communication; (i)
restrictions on privileged device operations; and (j) association of
the guest with a machine-readable security and authority context.
An illustrative configuration may comprise:
| x | One guest virtual machine identified as VM-AGENT-17. |
| - | -------------------------------------------------------------- |
| x | One agent execution context identified as AGENT-42. |
| x | A host-side authority service identified as PED-01. |
| x | A protected network-egress interface identified as FS-NET-01. |
| x | A protected credential-use interface identified as FS-CRED-01. |
| x | A policy generation identified as 105. |
| x | An assigned task identifier identified as TASK-204. |
These values are illustrative rather than mandatory formatting
requirements.
The guest may be permitted to use ordinary computational resources
without invoking protected finality for each internal instruction.
The requirement for protected finality arises when the agent attempts
a governed consequential operation.
Das Expires 25 April 2027 [Page 87]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.19. S-1.6.1 - Guest-to-host trust assumption
In one implementation, the guest operating system and agent processes
are treated as potentially compromised or otherwise unauthorized to
modify finality-enforcement state.
The hypervisor, relevant host security components, PED, and Finality
Sink form part of the trusted computing base to the extent needed for
the claimed protection.
A software-only deployment may assume that the host kernel and
hypervisor remain trustworthy.
A hardware-assisted embodiment may reduce selected dependencies upon
host software using processor-backed isolation, hardware-protected
keys, or protected device controllers.
7.1.20. S-1.6.2 - Isolation limitation
The mere presence of a hypervisor does not establish non-
bypassability.
If a guest can use a passed-through device, writable shared memory,
alternative network route, unmediated credential, or uncontrolled
peripheral to produce the governed effect, the protected-finality
requirement for that effect is not satisfied.
The applicable embodiment therefore requires the relevant
effectuation paths to be identified and either mediated or excluded
from the governed execution configuration.
7.1.21. S-1.7 - Candidate Act Generation and Interception
During execution, the agent may generate one or more proposed
operations.
Examples include:
(a) sending an HTTP request; (b) modifying a repository; (c) writing
a local or remote file; (d) executing a database transaction; (e)
sending an email; (f) invoking an enterprise application; (g)
requesting credential use; (h) initiating a financial instruction;
(i) controlling a hardware peripheral; or
(j) submitting an accelerator or storage operation.
Das Expires 25 April 2027 [Page 88]
Internet-Draft Sandbox Credential Egress Finality October 2026
An operation becomes a governed Candidate Act when the applicable
policy identifies its consequential effect as requiring the protected
execution-finality procedure.
An interceptor obtains sufficient information to characterize the
operation.
Depending on the deployment, interception may occur through:
1. A virtualized network interface. 2. A controlled RPC interface.
3. A host-side tool dispatcher. 4. A virtualized file-system
operation. 5. A hypervisor-mediated device interface. 6. A
credential broker. 7. A protected external-service gateway. 8. A
storage-commit controller. 9. A device-operation controller.
The interceptor must be positioned such that the Candidate Act cannot
bypass the required control through another permitted route.
7.1.22. S-1.7.1 - Interception before consequential effect
For a network request, the relevant boundary may be transmission
toward an external network.
For a payment instruction, the relevant boundary may be submission to
a payment-processing service.
For a persistent resource mutation, the relevant boundary may be the
resource commit operation.
For a cryptographic operation, the relevant boundary may be
activation of a signature or key use that makes a consequential
transaction acceptable.
Different consequential effects may require different interceptors
and Finality Sinks.
7.1.23. S-1.8 - Non-Effective State Implementation
Upon interception, the system establishes a Non-Effective State for
the governed effect.
A Candidate Act may be retained as:
| x | A serialized pending operation. |
| - | ------------------------------------------ |
| x | A protected transaction descriptor. |
| x | A queued operation with dispatch disabled. |
| x | A staged file mutation. |
Das Expires 25 April 2027 [Page 89]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | An uncommitted database transaction. |
| - | ------------------------------------------- |
| x | A withheld network payload. |
| x | A pending credential-use request. |
| x | A hardware command with admission withheld. |
For example, a guest-originated HTTP POST request can be received
into a host-controlled buffer without forwarding it to the
destination service.
The system may assign:
CandidateActID = CA-00071
ExecutionContextID = AGENT-42
TaskID = TASK-204
RequestedOperation = HTTP_POST
Destination = api.example-service.test
Resource = /payments/beneficiaries
CandidateStatus = STAGED
The destination is a hypothetical example.
A staged status alone is not sufficient. The egress control
mechanism must actually prevent transmission of the governed request
while the Candidate Act remains unauthorized.
7.1.24. S-1.8.1 - Immutable operation snapshot
In one implementation, the interceptor creates an immutable or
otherwise integrity-protected snapshot of the proposed operation.
The snapshot may include:
Das Expires 25 April 2027 [Page 90]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | The intended destination. |
| - | ---------------------------------------- |
| x | The operation method. |
| x | The canonical resource identifier. |
| x | The effective payload or payload digest. |
| x | The requesting execution context. |
| x | The delegated identity. |
| x | The applicable task. |
| x | The governing authority generation. |
| x | A unique operation identifier. |
The snapshot provides a stable reference for validation.
If mutable guest memory remains the source of the final operation,
the Finality Sink must not assume that validation of an earlier
memory view establishes the content of a later dispatch.
The implementation therefore either dispatches from a protected
immutable representation or independently reconstructs and validates
the actual pending operation at effectuation.
7.1.25. S-1.9 - Candidate Act Descriptor
A Candidate Act Descriptor may comprise the following fields:
7.1.26. Field
CandidateActID AgentContextID VMContextID TaskID PrincipalID
OperationClass TargetResource EffectiveArguments PayloadDigest
AuthorityGeneration RequestedScope DelegationContext CreatedAt
ExpiresAt Nonce EffectBoundaryID CanonicalizationProfile Rules used
to encode and compare material fields
7.1.27. Technical purpose
Unique operation identity Originating agent context Originating
virtual machine Associated task Applicable identity Network, file,
credential, payment, device, etc. Destination or object Material
operation parameters Integrity reference for operation payload
Applicable policy or authorization generation Scope requested by the
operation Relevant delegation relationship Creation-time information
Latest permissible validity time, where applicable Replay-protection
value, where required Governed effectuation boundary
The descriptor may be encoded through deterministic CBOR, canonical
JSON under a specified profile, a typed binary record, or another
unambiguous representation.
Das Expires 25 April 2027 [Page 91]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where cryptographic hashes or signatures are used, the implementation
must define the exact serialized bytes being authenticated.
An unqualified assertion that two JSON objects are equivalent is
insufficient if parsers may interpret duplicate keys, number
representations, Unicode normalization, omitted fields, or other
ambiguities differently.
7.1.28. S-1.10 - Protected Enforcement Domain Operation
The PED receives or securely obtains the relevant Candidate Act
Descriptor.
The PED evaluates the required authorization predicates, which may
include:
(a) whether the agent identity is valid; (b) whether the virtual
machine belongs to an authorized execution context; (c) whether the
requested operation is within the permitted task scope; (d) whether
the destination and resource are authorized; (e) whether the agent is
permitted to use the requested tool; (f) whether the proposed
operation exceeds a transaction or data-access limit; (g) whether the
applicable policy generation remains valid; (h) whether a revocation
condition exists; (i) whether the operation violates a protected
resource-state constraint; (j) whether required human approval has
been established; (k) whether the runtime behavior satisfies a
required behavioral condition; and (l) whether the operation complies
with additional predicates expressly required by the selected
enforcement point.
The predicate set may vary by operation class.
For example, a document-read operation may require resource
classification and access-scope checks, whereas a financial
instruction may additionally require beneficiary, amount, approval,
and transaction-state validation.
No particular example predicate is universally required unless the
applicable enforcement point imposes it.
7.1.29. S-1.10.1 - Protected authority-state acquisition
The PED obtains authority state from a protected registry,
authenticated service, protected memory structure, or another source
whose integrity satisfies the embodiment's security requirements.
Das Expires 25 April 2027 [Page 92]
Internet-Draft Sandbox Credential Egress Finality October 2026
An agent-supplied statement that a request is authorized is treated
as untrusted input unless independently authenticated under the
applicable protocol.
7.1.30. S-1.10.2 - State-consistency verification
The PED may evaluate:
| x | Policy generation. |
| - | ------------------------------ |
| x | Revocation generation. |
| x | Resource-state version. |
| x | Scope limits. |
| x | Usage quotas. |
| x | One-time authorization state. |
| x | Expiration. |
| x | Relevant runtime restrictions. |
If validation depends on mutable external resource state, the system
must account for changes between validation and effectuation.
This may be achieved through a version check, protected reservation,
atomic compare-andupdate, transaction precondition, or fresh
verification at the effectuation boundary.
7.1.31. S-1.11 - Protected Validation Evidence
Following successful validation, the PED generates or commits
protected validation evidence.
The evidence may be represented as:
ValidationEvidenceID = VE-00071
CandidateActID = CA-00071
CandidateDescriptorDigest = DIGEST-CA-00071
ValidationPolicyGeneration = 105
EvaluatedAuthorityScope = SCOPE-17
ValidationResult = APPROVED
EvidenceGeneration = 408
ExpiryCondition = EXP-17
Das Expires 25 April 2027 [Page 93]
Internet-Draft Sandbox Credential Egress Finality October 2026
The illustrative strings above represent symbolic values rather than
actual cryptographic digest values.
The protected evidence may additionally bind:
| x | The canonicalization profile. |
| - | -------------------------------------------- |
| x | The PED identity. |
| x | The policy version. |
| x | An approved resource-state version. |
| x | The evaluated predicates. |
| x | The authorized effectuation boundary. |
| x | A monotonic sequence or protected timestamp. |
| x | The requesting context. |
| x | Any mandatory human approval reference. |
The evidence is protected against unauthorized modification or
substitution.
7.1.32. S-1.11.1 - Evidence generation alternatives
Evidence may be implemented through:
1. A digitally signed validation record. 2. A message-authenticated
evidence structure. 3. An attested state transition. 4. A protected
registry entry. 5. A secure-memory commitment. 6. A monotonic
protected-state update. 7. A hardware-backed validation register. 8.
A combination of protected records and state references.
Cryptographic signing is one implementation; it is not the only
possible way to maintain protected validation evidence.
7.1.33. S-1.11.2 - Required evidence ordering
Where a enforcement point requires committed validation evidence to
precede finality authorization, the system must preserve that
ordering.
For example, a durable evidence identifier may be written into an
authenticated PED registry before the corresponding finality
capability becomes usable.
A crash between evidence creation and capability activation must not
accidentally create an unrestricted authorization.
Das Expires 25 April 2027 [Page 94]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.34. S-1.12 - Scoped Non-Bearer Finality Capability
Upon successful validation and the required evidence commitment, the
PED establishes a scoped non-bearer finality capability.
The capability authorizes only the governed operation or bounded
operation class and only under its specified conditions.
An illustrative capability binding includes:
CapabilityID = CAP-00071
CandidateActID = CA-00071
EvidenceReference = VE-00071
PermittedEffectBoundary = FS-NET-01
PermittedOperation = HTTP_POST
PermittedResource = /payments/beneficiaries
PermittedAuthorityGeneration = 105
ConsumptionMode = SINGLE_USE
CapabilityStatus = ACTIVE
Such a capability may be represented by a protected registry entry
rather than a transferable token.
7.1.35. S-1.12.1 - Software implementation
In a software implementation, the capability may exist as an
authorization entry in a PEDcontrolled registry.
The entry may be indexed by a protected operation identifier and
bound to the expected descriptor digest.
The guest may receive a non-authoritative reference to the pending
operation, while the actual authorization state remains under PED
control.
Das Expires 25 April 2027 [Page 95]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.36. S-1.12.2 - Cryptographic implementation
In a cryptographic implementation, the capability may comprise a
signed or authenticated object binding the permitted operation,
evidence reference, resource scope, validity conditions, and Finality
Sink.
Possession of the object alone must not allow an unauthorized holder
to extend or replay authority beyond the required conditions.
Where single-use capability consumption is required, the verification
protocol must maintain protected consumption state.
7.1.37. S-1.12.3 - Hardware implementation
In a hardware implementation, the capability may be represented by:
| x | A secure register. |
| - | ------------------------------------------------------------- |
| x | A protected permission entry. |
| x | A hardware authorization latch. |
| x | A protected queue-admission state. |
| x | An authenticated operation-context entry. |
| x | A secure controller's operation-specific authorization state. |
The capability is not required to be a portable object if the
protected hardware state performs the claimed bounded-authorization
function.
7.1.38. S-1.13 - Finality Sink Implementation
The Finality Sink controls the actual governed effectuation
interface.
In the representative virtual-machine embodiment, a host-side egress
service may serve as the Finality Sink for external network requests,
provided that the controlled configuration prevents alternative
egress paths capable of producing the same governed effect without
the required checks.
The Finality Sink obtains the actual pending request from its
controlled operation buffer, execution interface, or equivalent
trusted source.
The sink may reconstruct:
Das Expires 25 April 2027 [Page 96]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | The actual method. |
| - | --------------------------------------- |
| x | The final destination. |
| x | The effective target resource. |
| x | The final payload digest. |
| x | The requesting execution context. |
| x | The selected output interface. |
| x | The current authorization generation. |
| x | The current protected capability state. |
7.1.39. S-1.13.1 - Independent operation correspondence
A critical distinction is that the Finality Sink verifies the
operation it is actually positioned to effectuate.
It does not rely solely on the agent's earlier description of what
the agent intended to do.
For example, if a validated request targets RESOURCE-A but a later
tool transformation changes the request to RESOURCE-B, the sink-side
comparison identifies the mismatch before transmission.
7.1.40. S-1.13.2 - Finality Sink verification predicates
The Finality Sink may verify:
1. The required capability exists. 2. The capability was
established by an authorized PED. 3. The associated validation
evidence exists and is valid. 4. The capability is bound to the
required evidence. 5. The actual pending operation matches the
authorized descriptor or an expressly permitted subset. 6. The
current authority generation is acceptable. 7. The destination or
resource scope matches. 8. The capability is not expired or revoked.
9. The required nonce or sequence state is valid. 10. The
capability has not already been consumed. 11. The request is
presented at the authorized effectuation boundary. 12. Any required
sink-local protected-state predicate is satisfied.
The required predicates are determined by the applicable independent
enforcement point and embodiment.
7.1.41. S-1.14 - Sink-Local Protected State
In one implementation, the Finality Sink maintains protected local
state for determining whether a capability is valid for effectuation.
A representative sink-local record includes:
Das Expires 25 April 2027 [Page 97]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | Capability identifier. |
| - | -------------------------------- |
| x | Expected Candidate Act digest. |
| x | Expected policy generation. |
| x | Authorized resource. |
| x | Consumption status. |
| x | Last accepted sequence. |
| x | Revocation version. |
| x | Relevant resource-state version. |
| x | Pending-operation status. |
The sink-local state may be stored in:
(a) protected process memory with an appropriate trust boundary; (b)
a transactionally updated authenticated database; (c) a secure
enclave; (d) hardware-backed state; (e) a secure gateway controller;
or (f) an appropriately coordinated distributed state mechanism.
7.1.42. S-1.14.1 - Single-use consumption
Where the capability is single-use, the Finality Sink atomically
checks and transitions the consumption state.
For example:
UNUSED → RESERVED → CONSUMED
The RESERVED state may be used to handle an operation whose external
completion status is temporarily unresolved.
An implementation must not treat a crash after an external service
accepts an operation as proof that the operation never occurred.
Where exact-once external execution cannot be guaranteed by the
destination service, the system may use a destination-supported
idempotency key, transaction identifier, reconciliation protocol, or
at-most-once admission mechanism with explicit handling of uncertain
outcomes.
7.1.43. S-1.14.2 - Concurrent verification
If two execution workers present the same capability concurrently,
the sink's protected state transition must permit only the result
allowed by the capability's usage policy.
For a single-use capability, a serializable transaction, compare-and-
swap, protected hardware latch, or equivalent atomic mechanism may
prevent both workers from consuming the same authorization.
Das Expires 25 April 2027 [Page 98]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.44. S-1.15 - Principal Successful Execution Workflow
A representative successful workflow proceeds as follows.
7.1.45. Step S1 - Agent initialization
The virtualization manager starts the agent virtual machine and
associates it with an agent context, task context, policy generation,
and configured resource interfaces.
7.1.46. Step S2 - Tool execution request
The agent generates a request to invoke an external tool or service.
7.1.47. Step S3 - Boundary interception
The request reaches the controlled guest-to-host interface. The
interception mechanism captures the request before the governed
external operation is performed.
7.1.48. Step S4 - Candidate Act creation
The interceptor creates a Candidate Act identifier and associates the
operation with the originating agent context, task, destination,
resource, and effective operation parameters.
7.1.49. Step S5 - Non-effective staging
The operation is held in an output buffer or transaction staging
area. The governed effect has not yet occurred.
7.1.50. Step S6 - Descriptor canonicalization
The interceptor generates a deterministic descriptor of the material
operation fields using a specified canonicalization profile.
7.1.51. Step S7 - Protected-domain submission
The descriptor and relevant authenticated context are submitted to
the PED.
7.1.52. Step S8 - Authority-state retrieval
The PED obtains the applicable authority conditions and protected
enforcement state.
Das Expires 25 April 2027 [Page 99]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.53. Step S9 - Authorization evaluation
The PED evaluates the required identity, resource, policy, scope,
freshness, and other applicable predicates.
7.1.54. Step S10 - Validation evidence commitment
Upon successful validation, the PED creates or commits the required
protected validation evidence.
7.1.55. Step S11 - Capability activation
The PED establishes or activates a scoped non-bearer capability
associated with the specific Candidate Act and authorized
effectuation boundary.
7.1.56. Step S12 - Finality Sink presentation
The staged operation is presented to the corresponding Finality Sink.
7.1.57. Step S13 - Actual pending operation reconstruction
The Finality Sink obtains the actual request from the controlled
execution representation and reconstructs the material properties
required by its verification policy.
7.1.58. Step S14 - Capability and evidence verification
The Finality Sink verifies the scoped capability, committed
validation evidence, actual operation correspondence, freshness,
resource scope, and required protected sink-local state.
7.1.59. Step S15 - Atomic authorization-state transition
Where required, the Finality Sink reserves or consumes the applicable
authorization state using a protected atomic operation.
7.1.60. Step S16 - Effectuation
The Finality Sink permits the authorized effect through its
controlled interface.
7.1.61. Step S17 - Completion observation
The sink records whether the operation was admitted, completed,
rejected, timed out, or left with an indeterminate external outcome.
Das Expires 25 April 2027 [Page 100]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.62. Step S18 - State reconciliation
The protected authorization and operation state are updated according
to the observed outcome and the applicable retry or reconciliation
policy.
7.1.63. S-1.16 - Reference Enforcement Algorithm
The following pseudocode represents one software implementation.
Equivalent hardware or firmware implementations may use state
machines, microcode, protected registers, or other mechanisms.
7.1.64. Algorithm S1-A - Candidate Act Admission
Inputs: guest request, authenticated execution context, policy state.
1. Receive request through a controlled interface. 2. Confirm that
the request belongs to an allowed interception class. 3. Create a
Candidate Act identifier. 4. Copy the material request fields into a
controlled staging buffer. 5. Derive a canonical Candidate Act
Descriptor. 6. Associate the descriptor with the authenticated VM
and agent context. 7. Set operation status to STAGED. 8. Submit the
descriptor to the PED. 9. If the PED denies authorization, retain or
discard the staged operation according to policy without performing
the governed effect. 10. If the PED approves, obtain the applicable
protected evidence reference and bounded finality enablement. 11.
Present the staged operation to the authorized Finality Sink. 12.
Return the sink's final operation status to the requesting runtime.
7.1.65. Algorithm S1-B - PED Authorization
Inputs: Candidate Act Descriptor, authenticated context, protected
authority state.
1. Validate descriptor format and canonicalization version. 2.
Verify the claimed execution context against the authenticated source
context. 3. Retrieve applicable authorization state. 4. Evaluate
required resource, identity, policy, and scope conditions. 5. Verify
applicable revocation and freshness state. 6. Check required
resource-state preconditions. 7. If any mandatory predicate fails,
record a protected denial condition and return DENIED. 8. Construct
a protected validation-evidence record. 9. Commit the evidence in
accordance with the required transaction ordering. 10. Establish a
scoped finality capability bound to the validated operation and
permitted effectuation boundary. 11. Return a protected capability
reference and evidence identifier to the authorized enforcement path.
Das Expires 25 April 2027 [Page 101]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.66. Algorithm S1-C - Finality Sink Verification
Inputs: staged operation, capability reference, evidence reference,
sink-local protected state.
1. Obtain the actual pending operation from the controlled
effectuation interface. 2. Canonicalize its material effectuation
parameters. 3. Retrieve and verify the scoped capability. 4. Verify
the required protected evidence commitment. 5. Compare the actual
pending operation with the authorized descriptor. 6. Verify the
intended sink identity and resource scope. 7. Check expiration,
revocation, and authority-generation requirements. 8. Check current
sink-local protected consumption state. 9. If any mandatory check
fails, deny effectuation. 10. Atomically reserve or consume the
capability according to its usage semantics. 11. Dispatch the
operation using the controlled effectuation interface. 12. Record
the observed operation outcome. 13. Resolve or preserve uncertainty
according to the reconciliation procedure. 14. Return an
authenticated or otherwise integrity-protected result as required by
the deployment.
A production implementation must specify the transaction boundaries
around steps 10-13 and must not assume that remote execution and
local state consumption can always be committed atomically.
7.1.67. S-1.17 - Worked Technical Example: Agent-Originated Payment-
Beneficiary Modification
The following is a hypothetical implementation example.
An enterprise agent operates inside a virtual machine and receives a
task to prepare a payment report.
The agent is authorized to read certain supplier records but is not
authorized to change supplier bank-account information without a
separately established approval condition.
The agent generates a request:
| x | Operation: POST |
| - | ------------------------------------------------------- |
| x | Resource: /payments/beneficiaries |
| x | Intended action: Change beneficiary banking information |
| x | Agent context: AGENT-42 |
| x | Task: TASK-204 |
| x | Policy generation: 105 |
The host-side interceptor captures the operation.
Das Expires 25 April 2027 [Page 102]
Internet-Draft Sandbox Credential Egress Finality October 2026
The operation is placed into a controlled staging buffer.
The PED evaluates whether the agent's assigned task and authority
permit the beneficiary modification.
In the present example, the required beneficiary-change approval is
absent.
The PED records a denied authorization result and does not establish
the scoped finality capability required for the operation.
The Finality Sink therefore does not submit the modification to the
financial resource service.
The denial does not require stopping unrelated permissible
computation inside the virtual machine.
7.1.68. S-1.17.1 - Authorized variation
In a second hypothetical case, an authorized operator has
independently approved the exact beneficiary change under the
applicable enterprise procedure.
The PED verifies the approval and its association with the relevant
transaction details, resource scope, authority generation, and
freshness conditions.
The PED commits protected validation evidence and activates an
operation-specific capability.
The Finality Sink reconstructs the actual pending beneficiary-change
request.
If the actual request differs materially from the approved request,
effectuation is denied.
If all required predicates match, the sink atomically records
authorized use of the capability and submits the exact permitted
operation.
The resulting external-service status is retained for reconciliation.
This example demonstrates a technical enforcement mechanism. It does
not establish that the mechanism can replace every manual supplier-
verification procedure required by an enterprise's payment policy.
7.1.69. S-1.18 - Failure and Adversarial Cases
Das Expires 25 April 2027 [Page 103]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.70. Case F1 - Guest operating-system compromise
An attacker obtains privileged execution within the guest virtual
machine.
The attacker may generate arbitrary guest-originated requests and
alter unprotected guest data.
However, under the embodiment's trust assumptions, the attacker
cannot directly modify PED authority state or sink-local protected
state.
Consequential operations requiring finality enforcement remain
subject to the protected validation and sink-verification process.
This guarantee does not extend to interfaces that remain outside the
controlled enforcement configuration.
7.1.71. Case F2 - Agent instruction injection
An untrusted retrieved document instructs the agent to transmit
confidential data to an unauthorized destination.
The operation reaches the controlled egress interface.
The PED evaluates the requested destination and disclosure scope.
If the operation exceeds the authorized conditions, the capability is
withheld.
The Finality Sink does not transmit the unauthorized payload.
7.1.72. Case F3 - Operation substitution
The agent originally requests RESOURCE-A.
A tool wrapper changes the destination to RESOURCE-B after initial
validation.
The Finality Sink reconstructs the actual pending operation.
The mismatch causes authorization failure unless the substituted
resource is expressly permitted by the validated authorization scope.
7.1.73. Case F4 - Capability replay
A previously used capability reference is presented again.
Das Expires 25 April 2027 [Page 104]
Internet-Draft Sandbox Credential Egress Finality October 2026
The sink-local protected consumption state identifies the capability
as consumed or otherwise unavailable.
The replayed request is denied.
7.1.74. Case F5 - Stale authority generation
The PED validates the Candidate Act under authority generation 105.
Before effectuation, an applicable revocation advances the required
authority generation to 106.
The sink determines that the earlier capability is no longer
acceptable under the relevant revocation rule and denies
effectuation.
7.1.75. Case F6 - PED unavailable
The Candidate Act reaches the holding interface while the required
PED is unavailable.
The system does not interpret PED unavailability as authorization.
The operation remains staged, is rejected, or is canceled according
to a bounded fail-closed procedure.
7.1.76. Case F7 - Finality Sink unavailable
The required sink cannot verify or perform the operation.
The system does not release the governed effect through an
alternative unprotected route.
The staged operation remains pending or transitions to a failed
state.
7.1.77. Case F8 - Network redirection
The request is initially associated with one network destination but
is later redirected or resolved to an impermissible final endpoint.
Where the destination binding requires enforcement of final resolved
endpoints, the sink or associated protected egress mechanism re-
evaluates the effective destination before transmission.
Das Expires 25 April 2027 [Page 105]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.78. Case F9 - Concurrent replay attempts
Two guest workers simultaneously submit the same single-use
capability reference.
A protected atomic operation permits only the authorized consumption
outcome.
The losing request is denied or handled according to an expressly
permitted multi-use policy.
7.1.79. Case F10 - Snapshot rollback
A virtual-machine snapshot created before a capability was consumed
is restored.
The restored guest state cannot reset protected sink-local
consumption state.
The restored request remains subject to the current authorization
generation and consumption record.
7.1.80. Case F11 - Alternate network adapter
The virtual machine has a second network interface or a passed-
through device.
If the interface can transmit the governed operation without finality
verification, the architecture does not satisfy the asserted non-
bypassability property for that operation.
The deployment must disable, constrain, or mediate that route.
7.1.81. Case F12 - Host compromise
If the threat model trusts the host kernel and an attacker
compromises that kernel, a softwareonly PED or host-side Finality
Sink may lose its intended protection.
A stronger implementation may employ hardware-backed isolation,
secure boot chains, confidential-computing mechanisms, protected
device controllers, or dedicated security processors.
The disclosure does not assume software-only mediation automatically
withstands compromise of its own trusted computing base.
Das Expires 25 April 2027 [Page 106]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.82. Case F13 - External execution with uncertain result
The Finality Sink transmits an authorized instruction, but the
connection fails before a completion acknowledgment is received.
The system records an INDETERMINATE outcome.
It does not blindly repeat the operation using a newly created
capability.
Reconciliation may use a transaction identifier, destination status
query, idempotency mechanism, or independent completion evidence.
7.1.83. Case F14 - Canonicalization discrepancy
The PED and sink interpret duplicate JSON keys, noncanonical numbers,
or resource paths differently.
The system rejects the representation or normalizes it through a
common defined canonicalization profile before authorization and
final execution.
A request is not approved based on one interpretation while executed
under another.
7.1.84. S-1.19 - Virtual-Machine Migration and Resume
The virtual machine may be suspended, resumed, replicated, restored,
or migrated.
In a migration-aware implementation, the system distinguishes:
(a) agent computational state; (b) pending Candidate Acts; (c)
protected authority state; (d) active capabilities; (e) sink-local
consumption state; and (f) unresolved external-operation outcomes.
A migration controller may establish a new execution generation
associated with the destination environment.
Capabilities bound to the former environment may be invalidated or
require revalidation.
Pending Candidate Acts may be transferred in a non-effective state
and submitted for fresh protected authorization.
Already completed external operations are not automatically repeated
merely because the restored guest execution state contains the
corresponding earlier tool request.
Das Expires 25 April 2027 [Page 107]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where policy permits continuation under a migrated authority context,
the destination enforcement system verifies the relevant state
transfer and authority generation before permitting new effectuation.
7.1.85. S-1.20 - Software-Only, Hardware-Assisted, and Hybrid
Variations
7.1.86. S-1.20.1 - Software-only variation
The agent runs in a virtual machine.
The PED is implemented through a host-side protected security service
under the applicable host trust assumptions.
The Finality Sink is a host-side gateway or resource controller.
Protected authority and consumption states are stored in integrity-
protected or accesscontrolled structures.
This implementation assumes the integrity of the necessary host
enforcement components.
7.1.87. S-1.20.2 - TEE-assisted variation
The agent runs in a virtual machine.
Protected validation logic and authority state are implemented within
a suitable trusted execution environment.
The TEE establishes or authorizes the finality capability.
The Finality Sink validates the required protected authorization
information before performing the governed operation.
The technical disclosure for this variation must specify how the sink
receives trustworthy authorization state and how compromised host
software is prevented from bypassing the intended effectuation
boundary.
7.1.88. S-1.20.3 - HSM-assisted variation
An HSM stores protected authority keys or performs protected
validation and capability activation.
A host-side gateway acts as the Finality Sink.
Das Expires 25 April 2027 [Page 108]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where the HSM serves as a PED or CIED, its role includes the required
protected enforcement functions rather than merely signing arbitrary
data supplied by an untrusted host.
7.1.89. S-1.20.4 - SmartNIC/DPU variation
A virtual machine originates network operations.
A protected SmartNIC or DPU intercepts the relevant outgoing traffic.
Protected authorization state may be maintained within the device or
supplied through a securely authenticated PED.
The device verifies the required finality information before
transmitting governed packets.
The design must account for packet routing, flow establishment,
fragmentation, tunneling, alternative interfaces, and any network
path capable of bypassing the protected device.
7.1.90. S-1.20.5 - Hypervisor enforcement variation
A hypervisor or protected virtual-machine monitor intercepts governed
operations.
A hypervisor-controlled component performs or coordinates finality
checks.
A virtualized device backend may constitute the controlled
effectuation interface.
The implementation must prevent the guest from accessing an alternate
backend that bypasses the required enforcement.
7.1.91. S-1.20.6 - Distributed PED and sink variation
The PED executes on a separate protected service or machine.
The Finality Sink executes at the host or resource boundary.
The services communicate through an authenticated channel binding the
Candidate Act, authorization generation, intended sink, evidence
reference, and other required fields.
Authentication of the communication channel does not eliminate the
need to verify the operation and relevant state at the Finality Sink.
Das Expires 25 April 2027 [Page 109]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.92. S-1.20.7 - Integrated PED and sink variation
The PED and Finality Sink reside in one secure controller, protected
process, enclave, or hardware security component.
The implementation preserves distinct logical operations
corresponding to validation, protected evidence handling, bounded
authorization, and finality verification.
Physical separation is not essential where the relevant enforcement
point permits co-location and all required functions remain
implemented.
7.1.93. S-1.21 - Optional ALF, AIF, and RBD Integration
The virtual-machine embodiment may optionally incorporate Algorithmic
Logic Fingerprint, Algorithmic Intent Fingerprint, or Runtime
Behavioral Descriptor verification.
7.1.94. S-1.21.1 - ALF verification
A protected component may compare a runtime representation of the
agent's effective model, tool graph, workflow, or policy logic
against an approved logic state.
Where required, the comparison contributes a predicate to the
protected authorization decision.
7.1.95. S-1.21.2 - AIF verification
A proposed operation may be compared with an authorized task-intent
envelope.
The comparison may check purpose, tool scope, destination, affected
resources, and delegation limits.
7.1.96. S-1.21.3 - RBD verification
Runtime observations may be collected from system calls, tool events,
network activity, memory operations, or other bounded execution
signals.
The PED may use the derived behavioral state to determine whether
additional authorization restrictions are required.
Das Expires 25 April 2027 [Page 110]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.97. S-1.21.4 - Optionality
ALF, AIF, and RBD are optional in this particular representative
implementation unless explicitly recited as required conditions in a
corresponding enforcement point.
An ALF or behavioral measurement does not independently authorize an
external effect where the applicable enforcement point additionally
requires protected validation, scoped capability issuance, or sink
verification.
7.1.98. S-1.22 - Implementation Data Structures
A implementer may implement the architecture using the following
representative logical records.
7.1.99. A. VMContextRecord
Fields:
| x | VMContextID |
| - | ------------------------------- |
| x | AgentContextID |
| x | TaskID |
| x | IsolationClass |
| x | AuthorityGeneration |
| x | PermittedInterfaces |
| x | ProtectedDomainReference |
| x | EffectBoundaryRegistryReference |
| x | ActiveState |
7.1.100. B. CandidateActRecord
Fields:
| x | CandidateActID |
| - | ------------------- |
| x | VMContextID |
| x | AgentContextID |
| x | OperationClass |
| x | ResourceID |
| x | CanonicalArguments |
| x | PayloadDigest |
| x | AuthorityGeneration |
x x x
CreatedAt Nonce CandidateStatus
Das Expires 25 April 2027 [Page 111]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.101. C. ValidationEvidenceRecord
Fields:
| x | EvidenceID |
| - | ------------------------- |
| x | CandidateActID |
| x | CandidateDescriptorDigest |
| x | PEDIdentity |
| x | PolicyGeneration |
| x | ValidationResult |
| x | EvaluatedScope |
| x | EvidenceCommitment |
| x | ExpiryCondition |
7.1.102. D. FinalityCapabilityRecord
Fields:
| x | CapabilityID |
| - | --------------------------- |
| x | CandidateActID |
| x | ValidationEvidenceReference |
| x | AuthorizedSinkID |
| x | PermittedOperationClass |
| x | PermittedResourceScope |
| x | AuthorityGeneration |
| x | UsagePolicy |
| x | ExpiryCondition |
| x | CapabilityStatus |
7.1.103. E. SinkStateRecord
Fields:
| x | SinkID |
| - | ------------------------ |
| x | CandidateActID |
| x | CapabilityID |
| x | ExpectedDescriptorDigest |
| x | ConsumptionState |
| x | AuthorityGeneration |
| x | OperationStatus |
| x | CompletionReference |
| x | LastStateTransition |
Das Expires 25 April 2027 [Page 112]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.104. F. EffectPathRegistry
Fields:
| x | EffectPathID |
| - | ------------------------------- |
| x | OperationClass |
| x | SourceExecutionClass |
| x | InterceptionPoint |
| x | ControlledEffectuationInterface |
| x | RequiredSinkID |
| x | AlternatePathRestrictionState |
| x | CoverageVerificationStatus |
The structures may be implemented as tables, authenticated objects,
in-memory records, protected register groups, deterministic binary
encodings, or equivalent representations.
They are illustrative examples and do not require each implementation
to use the same field names or storage layout.
7.1.105. S-1.23 - Verification and Test Procedures
The following engineering tests may be performed to demonstrate
whether a selected implementation satisfies its stated protection
properties.
7.1.106. Test T1 - Authorized operation
Provide a valid Candidate Act and valid protected authorization
state.
Expected result: the governed operation is permitted through the
authorized Finality Sink.
7.1.107. Test T2 - Missing capability
Attempt effectuation without the required scoped capability.
Expected result: denial.
7.1.108. Test T3 - Replay
Present an already consumed single-use capability.
Expected result: denial.
Das Expires 25 April 2027 [Page 113]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.109. Test T4 - Descriptor mismatch
Change a material request parameter after protected validation.
Expected result: denial unless the modification is expressly covered
by the authorized scope.
7.1.110. Test T5 - Authority revocation
Advance the applicable revocation generation before effectuation.
Expected result: previously issued authorization is rejected when the
applicable revocation rule requires it.
7.1.111. Test T6 - Alternate egress
Attempt transmission through an alternate guest network or device
interface.
Expected result: transmission is either mediated by the protected
path or blocked.
7.1.112. Test T7 - Guest privilege escalation
Execute the test operation from a guest-privileged context.
Expected result: guest privilege alone cannot alter protected
finality state or bypass the governed effectuation interface.
7.1.113. Test T8 - Concurrent capability use
Submit simultaneous requests using a single-use capability.
Expected result: protected consumption semantics allow no more than
the authorized number of effectuation attempts or effects, as defined
by the protocol.
7.1.114. Test T9 - Snapshot restoration
Restore an earlier virtual-machine snapshot and replay a prior
operation.
Expected result: protected authorization state does not revert merely
because guest execution state was restored.
Das Expires 25 April 2027 [Page 114]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.1.115. Test T10 - PED outage
Disable access to the required PED.
Expected result: no governed operation obtains authorization through
an implicit permissive fallback.
7.1.116. Test T11 - Sink outage
Disable the required effectuation controller.
Expected result: no alternative uncontrolled effectuation occurs.
7.1.117. Test T12 - Host compromise assumption
Evaluate whether the claimed security properties remain true under
the selected threat model.
Expected result: the documentation accurately identifies which
protections remain valid and which require hardware-backed trust.
7.1.118. Test T13 - Canonicalization ambiguity
Submit equivalent and ambiguous encodings, including conflicting
duplicate fields and differing resource-path interpretations.
Expected result: the system applies a consistent canonicalization
profile or rejects ambiguous inputs.
7.1.119. Test T14 - Uncertain external result
Cause a communication interruption after possible remote acceptance.
Expected result: the operation enters a defined reconciliation state
rather than being blindly reissued.
These are proposed validation procedures. They are not represented
as tests already conducted.
7.1.120. S-1.24 - Technical Effect and Relationship to Other
Embodiments
The embodiment provides a technical implementation in which virtual-
machine isolation is combined with operation-specific protected
finality enforcement.
Das Expires 25 April 2027 [Page 115]
Internet-Draft Sandbox Credential Egress Finality October 2026
The architectural distinction is that permission to execute
computation inside a virtual machine is not necessarily equivalent to
permission to cause every external effect that the computation can
request.
The described implementation permits the agent to perform ordinary
computation while selected consequential operations remain subject to
additional protected authorization and sink-side verification.
The embodiment may support enforcement points directed to:
(a) protected sandbox effectuation finality; (b) capability-bound
external tool execution; (c) host-side protected credential and
network controls; (d) operation-specific evidence and protected
state; (e) anti-bypass control of effectuation paths; and (f)
selected execution-context migration, revocation, and recovery
mechanisms.
Other independent enforcement points of the application may be
implemented through alternative architectures that do not require the
protected-finality sequence described in this embodiment.
For example, embodiments directed to monitoring-only remediation,
native-resource transaction authorization, static sandbox
restrictions, or independently performed human operations may use
their own distinct mechanisms.
this implementation profile is therefore a representative
implementation of virtual-machinebased protected execution finality
rather than a mandatory architectural requirement for every invention
disclosed in the application.
7.1.121. S-1.25 - Enablement Boundaries and Implementation Requirements
To implement this embodiment for a selected operation class, a
implementer must identify:
1. The virtualization mechanism and its trust assumptions. 2. The
agent-controlled execution interfaces. 3. The consequential effects
requiring protection. 4. The specific paths capable of producing
those effects. 5. The component that captures and stages each
Candidate Act. 6. The mechanism preventing effectuation while the
operation remains staged. 7. The applicable PED protection
mechanism. 8. The protected authority-state representation. 9. The
validation predicates and algorithms. 10. The evidence-commitment
mechanism. 11. The scoped capability representation and lifecycle.
12. The Finality Sink's actual-operation observation and comparison
mechanism. 13. The atomicity and durability of required protected-
Das Expires 25 April 2027 [Page 116]
Internet-Draft Sandbox Credential Egress Finality October 2026
state updates. 14. The treatment of concurrent requests, crashes,
and uncertain remote outcomes. 15. The method for restricting
unauthorized alternate effectuation paths. 16. The handling of
virtual-machine snapshots, revocation, restart, and migration.
Specific hardware-backed variants additionally require identification
of the relevant processor, device, secure-storage, protected-
register, communication, or queue-control primitives.
A general assertion that hardware enforces security is not a
substitute for disclosure of how the required hardware operations are
performed.
7.1.122. S-1.26 - Summary of the Representative Embodiment
this implementation profile discloses a virtual-machine-isolated
artificial-intelligence-agent execution system comprising an agent-
controlled guest environment, an effect-capable operation
interceptor, a non-effective holding mechanism, a Protected
Enforcement Domain, protected validation evidence, a bounded non-
bearer finality capability, and a Finality Sink controlling the
designated consequential operation.
The system identifies and stages a governed Candidate Act, evaluates
the relevant authorization conditions in a protected enforcement
context, establishes the required
protected evidence and capability, reconstructs or observes the
actual pending effectuation operation, and verifies the applicable
authorization conditions at a controlled effectuation boundary.
The architecture may be implemented through host software, hypervisor
services, trusted execution environments, hardware security modules,
protected network devices, firmware controllers, or combinations
thereof, subject to the required security properties of the
particular enforcement point.
The embodiment thereby illustrates how execution isolation and
operation-specific authority can be implemented as separate yet
cooperating technical mechanisms.
7.1.122.1. MICRO-VIRTUAL-MACHINE-ISOLATED AI-AGENT EXECUTION WITH
LIFECYCLE-BOUND AUTHORITY, PROTECTED EFFECTUATION, AND
7.1.122.2. ASYNCHRONOUS OPERATION CONTINUITY
Das Expires 25 April 2027 [Page 117]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2. Implementation Profile S-2
Source location: original disclosure pages 96-137. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.2.1. S-2.1 - Technical Field
this implementation profile relates to virtualized computing,
artificial-intelligence-agent execution, micro-virtual-machine
isolation, confidential and ephemeral workloads, distributed
execution control, authorization-state management, protected
operation effectuation, and recovery of asynchronous operations.
More particularly, the embodiment describes a system in which one or
more artificialintelligence agents execute within dynamically created
micro-virtual machines while specified consequential operations
remain governed by an enforcement arrangement capable of maintaining
authorization integrity independently of the creation, suspension,
termination, restoration, replacement, or migration of the
originating micro-virtual machine.
The system may be implemented in software, firmware, hardware,
hardware-assisted virtualization, or combinations thereof.
The disclosed micro-virtual-machine architecture represents one
species of an isolated agentexecution architecture and does not limit
the broader inventions to any particular virtualization product,
hypervisor, operating system, processor manufacturer, or cloud
platform.
7.2.2. S-2.2 - Technical Problem
Micro-virtual machines may provide lightweight execution isolation
using reduced virtual hardware, minimized guest services, and
comparatively short workload lifecycles.
Such environments may be created in response to individual agent
tasks, tool invocations, browser operations, program executions, or
delegated computational requests.
However, the lifetime of an agent-generated consequential operation
may differ from the lifetime of the micro-virtual machine that
originated it.
For example:
Das Expires 25 April 2027 [Page 118]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) an agent may submit a network request immediately before its
micro-virtual machine is destroyed;
(b) a delegated operation may remain queued after the originating
micro-virtual machine terminates;
(c) a micro-virtual machine may be restored from a snapshot
containing stale task or authorization state;
(d) a new micro-virtual machine may reuse an identifier previously
associated with a terminated instance;
(e) a pending request may be re-created by an orchestrator after a
timeout;
(f) multiple micro-virtual-machine instances may attempt to continue
the same agent task;
(g) a tool worker may produce an external effect after its
originating execution context has been canceled; or
(h) a supposedly isolated micro-virtual machine may retain an
unmediated device or communication path capable of producing effects
outside the intended protected enforcement arrangement.
Accordingly, micro-virtual-machine isolation alone does not establish
operation-specific authority, safe lifecycle transition, or correct
treatment of pending consequential operations.
this implementation profile addresses these technical problems
through a micro-virtual-machine lifecycle controller, protected
operation registry, authenticated execution-context binding,
effectuation-path controls, and finality enforcement that remains
valid despite changes in the originating micro-virtual-machine
instance.
7.2.3. S-2.3 - Technical Objectives
The embodiment seeks to provide:
Das Expires 25 April 2027 [Page 119]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Rapid creation of isolated AI-agent execution instances. 2.
Separation of micro-VM computational state from protected execution
authority. 3. Identification of a unique execution generation for
each micro-VM instance. 4. Interception of governed consequential
operations. 5. Non-effective staging of intercepted Candidate Acts.
6. Protected binding of Candidate Acts to the originating task and
execution generation. 7. Authorization independent of guest-
controlled enforcement points of identity or permission. 8.
Protected validation-evidence commitment.
9. Scoped non-bearer finality enablement. 10. Sink-side
verification of the actual pending effectuation operation. 11.
Prevention of stale capability reuse after micro-VM termination,
restoration, or replacement. 12. Defined treatment of pending and
asynchronous operations that survive their originator. 13.
Prevention of duplicated external effects during orchestration
retries. 14. Detection or restriction of unauthorized alternative
effectuation routes. 15. Support for software-only, hardware-
assisted, and hybrid implementations.
In a preferred protected-finality implementation, a micro-VM instance
cannot create execution authority merely by generating, copying,
restoring, or presenting an operation request.
7.2.4. PART I - SYSTEM ARCHITECTURE
7.2.5. S-2.4 - Principal Components
A representative system comprises the following components.
7.2.6. Component A - Physical or Virtualized Host
A computing platform comprising one or more processors, memory
resources, persistent storage interfaces, and input/output
interfaces.
The host may be a cloud server, enterprise server, workstation,
embedded platform, edge computing node, or hardware-assisted
virtualization platform.
7.2.7. Component B - Micro-VM Manager
A virtualization-management component configured to instantiate,
configure, start, suspend, terminate, replace, or restore micro-
virtual machines.
Das Expires 25 April 2027 [Page 120]
Internet-Draft Sandbox Credential Egress Finality October 2026
The Micro-VM Manager may operate through a hypervisor, lightweight
virtual-machine monitor, kernel virtualization interface, hardware-
assisted virtualization mechanism, or equivalent controller.
7.2.8. Component C - Ephemeral Agent Micro-VM
A micro-virtual machine containing an agent workload, model client,
tool executor, generated code, browser automation process, or
delegated computational worker.
The micro-VM may contain a reduced guest operating system or
specialized execution image.
7.2.9. Component D - Execution-Generation Controller
A trusted or protected mechanism configured to assign an execution
generation distinguishing the current micro-VM instance from
previously terminated, suspended, restored, or replaced instances.
An execution generation may comprise a monotonically ordered
identifier, unique instancegeneration pair, cryptographically bound
context, or equivalent non-confusable state representation.
7.2.10. Component E - Controlled Micro-VM Communication Interface
An interface configured to transport governed operation requests from
the micro-VM into an enforcement environment.
Examples include a virtual socket, controlled virtual network device,
paravirtualized I/O interface, shared-memory command ring, protected
RPC transport, or virtual device backend.
7.2.11. Component F - Candidate Act Capture and Staging Controller
A component configured to obtain a proposed consequential operation,
associate it with authenticated micro-VM context, construct a
Candidate Act Descriptor, and maintain the governed operation in a
Non-Effective State.
7.2.12. Component G - Protected Enforcement Domain
A PED configured to evaluate applicable authority predicates and
maintain the required protected authority or validation state.
The PED may be implemented locally, remotely, in protected host
software, or through hardware-assisted isolation.
Das Expires 25 April 2027 [Page 121]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.13. Component H - Protected Validation Evidence Controller
A mechanism configured to generate and preserve the validation
evidence required by the selected protected-finality protocol.
7.2.14. Component I - Scoped Finality Enablement Controller
A protected component configured to activate or issue a bounded, non-
bearer authorization condition associated with a validated Candidate
Act.
7.2.15. Component J - Finality Sink
A component controlling the designated effectuation boundary and
configured to perform the required verification before permitting the
consequential operation.
7.2.16. Component K - Outstanding Operation Registry
A protected or integrity-controlled registry configured to track
staged, authorized, dispatched, completed, canceled, or unresolved
operations independently of the lifetime of the originating micro-VM.
7.2.17. Component L - Lifecycle Reconciliation Controller
A mechanism configured to coordinate micro-VM termination,
restoration, replacement, and recovery with pending operation state,
authorization validity, and external completion status.
The components may be arranged within one physical device or
distributed among cooperating infrastructure services.
7.2.18. S-2.5 - Reference Micro-VM Deployment
In one implementation, an enterprise agent orchestrator creates a new
micro-VM for a particular tool-using task.
The micro-VM receives:
| x | A task identifier. |
| - | ------------------------------------------------ |
| x | A restricted execution image. |
| x | A reduced set of virtual devices. |
| x | A limited tool interface. |
| x | A non-authoritative execution-context reference. |
| x | An assigned execution generation. |
| x | Access to a controlled operation channel. |
Das Expires 25 April 2027 [Page 122]
Internet-Draft Sandbox Credential Egress Finality October 2026
The micro-VM does not receive unrestricted access to the host's
protected authority state or the complete secrets needed to bypass
the designated protected effectuation interfaces.
When the agent generates a consequential operation, the request is
transported through the controlled channel.
The host or protected enforcement service identifies the actual
source micro-VM context, stages the operation, and performs the
applicable protected-finality sequence.
The originating micro-VM may be terminated without destroying the
independent operation record or treating termination as proof of
external completion.
7.2.19. S-2.5.1 - Logical arrangement
A representative arrangement is:
7.2.20. Agent Orchestrator
↓
7.2.21. Micro-VM Manager and Execution-Generation Controller
↓
7.2.22. Ephemeral Agent Micro-VM
↓
7.2.23. Controlled Virtual Device / Communication Channel
↓
7.2.24. Candidate Act Capture and Non-Effective Staging
↓
7.2.25. PED - Protected Validation and Evidence Commitment
↓
7.2.26. Scoped Non-Bearer Finality Enablement
↓
Das Expires 25 April 2027 [Page 123]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.27. Finality Sink - Actual Pending Operation Verification
↓
7.2.28. External Effect-Capable Resource
The Outstanding Operation Registry and Lifecycle Reconciliation
Controller maintain relevant state alongside this effectuation path.
The arrangement does not require physically separate hardware for
every listed role.
7.2.29. PART II - MICRO-VM IDENTITY AND LIFECYCLE
7.2.30. S-2.6 - Micro-VM Instance Identity
Each newly created micro-VM is associated with a machine-verifiable
execution context.
An illustrative context includes:
MicroVMInstanceID = MICROVM-0081
ExecutionGeneration = 508
AgentContextID = AGENT-42
TaskID = TASK-204
IsolationProfile = MINIMAL-DEVICE-CLASS-A
AuthorityGeneration = 105
LifecycleStatus = ACTIVE
These identifiers are illustrative.
The execution generation distinguishes the specific instance from
earlier or later instances that may perform the same task.
7.2.31. S-2.6.1 - Authenticated context binding
The enforcement service does not rely solely on an identifier
supplied within an untrusted guest request.
Das Expires 25 April 2027 [Page 124]
Internet-Draft Sandbox Credential Egress Finality October 2026
Instead, it associates the request with an execution context derived
from an authenticated channel, trusted hypervisor metadata, host-side
connection association, attested workload identity, or another
mechanism meeting the applicable trust requirements.
For example, a host-side virtual socket endpoint may be associated
with a specific micro-VM instance by the virtualization manager.
A guest-supplied enforcement point that it belongs to another micro-
VM does not modify the authenticated source association.
7.2.32. S-2.6.2 - Instance identifier reuse
A micro-VM identifier may be recycled by an orchestration platform.
Therefore, an identifier alone may be insufficient to distinguish
authority belonging to a previous instance.
An implementation may use an instance identifier together with a
protected execution generation, creation nonce, or equivalent unique
lifecycle binding.
A capability associated with one generation is not automatically
valid for a later generation having the same instance name.
7.2.33. S-2.7 - Lifecycle State Machine
A representative micro-VM lifecycle comprises:
CREATED → CONFIGURED → RUNNING → QUIESCING → TERMINATED
Additional transitions may include:
RUNNING → SUSPENDED
SUSPENDED → RESUMING → RUNNING
RUNNING → FAILED
FAILED → REPLACED
SUSPENDED → RESTORED
The security state machine must distinguish the lifecycle of the
micro-VM from the lifecycle of each outstanding consequential
operation.
Das Expires 25 April 2027 [Page 125]
Internet-Draft Sandbox Credential Egress Finality October 2026
A micro-VM reaching TERMINATED does not establish that every
operation originated by that instance has completed, failed, or been
canceled.
7.2.34. S-2.7.1 - Lifecycle event binding
Relevant lifecycle events may include:
| x | Creation. |
| - | ----------------------------- |
| x | Image selection. |
| x | Configuration completion. |
| x | Start. |
| x | Device attachment or removal. |
| x | Tool-interface change. |
| x | Suspension. |
| x | Resume. |
| x | Snapshot. |
| x | Restoration. |
| x | Cancellation. |
| x | Shutdown. |
| x | Crash. |
| x | Replacement. |
| x | Migration. |
| x | Deletion. |
A lifecycle event may cause an authority-state transition, generation
change, fresh verification requirement, or restriction of pending
operations according to the applicable policy.
7.2.35. S-2.8 - Micro-VM Creation Workflow
A representative creation sequence proceeds as follows.
7.2.36. Step C1 - Task selection
An orchestrator identifies a task requiring isolated execution.
7.2.37. Step C2 - Isolation-profile selection
The Micro-VM Manager selects a virtual machine image, resource
configuration, device configuration, and communication policy.
7.2.38. Step C3 - Instance creation
A new micro-VM instance is created.
Das Expires 25 April 2027 [Page 126]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.39. Step C4 - Execution-generation allocation
The Execution-Generation Controller associates the instance with a
new execution generation.
7.2.40. Step C5 - Controlled interface assignment
The manager supplies restricted virtualized interfaces and associates
their host-side endpoints with the instance identity.
7.2.41. Step C6 - Authority-context association
The protected authorization service associates the task, agent,
execution generation, and permitted operation classes.
7.2.42. Step C7 - Guest startup
The micro-VM begins executing the assigned workload.
7.2.43. Step C8 - Readiness verification
The manager verifies that the required controlled interfaces and
restrictions are active before permitting governed operations.
7.2.44. Step C9 - Active-state transition
The micro-VM is marked RUNNING.
The micro-VM may compute internally without obtaining a new finality
capability for every processor instruction.
Protected finality applies to operations designated by the applicable
execution-control policy.
7.2.45. PART III - VIRTUAL DEVICE AND EFFECTUATION-PATH ENFORCEMENT
7.2.46. S-2.9 - Reduced Virtual-Device Configuration
A micro-VM may be provided with a reduced set of virtual devices, for
example:
(a) virtual processor interfaces; (b) guest memory; (c) a controlled
block device;
(d) a controlled virtual network interface;
(e) a virtual socket or RPC interface;
Das Expires 25 April 2027 [Page 127]
Internet-Draft Sandbox Credential Egress Finality October 2026
(f) an optional clock or entropy interface; and
(g) other interfaces expressly required by the assigned workload.
The selected configuration may omit unnecessary device emulation or
prohibit privileged device pass-through.
However, minimizing the number of exposed devices is not equivalent
to proving that all consequential operations are controlled.
The implementation must identify the routes by which the micro-VM can
actually produce the governed effects.
7.2.47. S-2.10 - Micro-VM Effectuation Path Registry
The host maintains or derives an Effectuation Path Registry for
governed operation classes.
A representative registry contains:
7.2.48. Path class
Network Tool invocation File mutation Credential use Database
operation Resource proxy Hardware command Mediated device backend
Device command release Message delivery
7.2.49. Example interface
Virtual NIC backend Host tool dispatcher Controlled storage backend
Persistent write Host credential broker
7.2.50. Controlled effect
External packet transmission External API operation
Protected key or secret use External transaction
Protected message service External communication
Each governed effectuation path is associated with an applicable
interception point and enforcement mechanism.
7.2.51. S-2.10.1 - Path-completeness condition
Where a enforcement point requires non-bypassable effectuation
control, the deployment must ensure that no permitted alternative
path can produce the same governed effect while bypassing the
required enforcement mechanism.
Das Expires 25 April 2027 [Page 128]
Internet-Draft Sandbox Credential Egress Finality October 2026
Possible bypass routes include:
1. An additional virtual NIC. 2. A directly attached device. 3. An
uncontrolled host socket.
4. A writable shared-memory area consumed by a privileged service.
5. A secondary tool-execution interface. 6. An externally
accessible credential. 7. An unmediated local file mount. 8. A
background worker operating outside the intended control path.
Such paths must be disabled, mediated, constrained, or expressly
excluded from the governed effectuation configuration.
7.2.52. S-2.11 - Controlled Micro-VM Communication Channel
The micro-VM may communicate with the host-side enforcement system
through a virtual socket, virtual queue, RPC interface, or other
controlled transport.
A representative request includes:
| x | RequestID. |
| - | ------------------------------------- |
| x | TaskID. |
| x | Requested operation class. |
| x | Resource identifier. |
| x | Operation parameters. |
| x | Payload reference or payload. |
| x | Optional operation-specific metadata. |
The host-side receiver associates the request with the authenticated
micro-VM instance context.
Guest-provided security metadata is independently validated when
required.
7.2.53. S-2.11.1 - Channel authentication
The communication channel may rely on hypervisor-enforced endpoint
association, authenticated IPC, mutual authentication, protected
shared-memory metadata, or cryptographic authentication.
The security mechanism must be selected according to the applicable
threat model.
A virtual socket does not inherently provide cryptographic isolation,
replay resistance, or protection from a compromised host.
Das Expires 25 April 2027 [Page 129]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.54. S-2.11.2 - Channel closure
When a micro-VM terminates, the associated communication endpoint is
closed or invalidated.
Requests received after the generation is revoked are rejected unless
they belong to an independently authorized continuation context.
Queued operations that already reached the protected staging registry
are handled by their own lifecycle rules rather than being silently
discarded or executed.
7.2.55. PART IV - PROTECTED OPERATION STAGING
7.2.56. S-2.12 - Candidate Act Capture
An agent running within a micro-VM generates a consequential
operation.
For example, the agent may request transmission of a message
containing enterprise data.
The request reaches the controlled operation interface.
The host creates a Candidate Act record and associates it with the
authenticated execution context.
A representative record includes:
CandidateActID = CA-0091
OriginMicroVM = MICROVM-0081
OriginExecutionGeneration = 508
AgentContextID = AGENT-42
TaskID = TASK-204
OperationClass = MESSAGE_SEND
ResourceID = ENTERPRISE-MESSAGING-SERVICE
CandidateStatus = STAGED
No external message is transmitted at this stage.
Das Expires 25 April 2027 [Page 130]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.57. S-2.13 - Non-Effective Holding Mechanism
The operation is retained in a controlled staging mechanism.
A staging mechanism may comprise:
| x | An operation queue whose dispatch is inhibited. |
| - | ----------------------------------------------- |
| x | A protected host memory buffer. |
| x | A durable pending-operation registry. |
| x | An uncommitted resource transaction. |
| x | A controlled outgoing message buffer. |
| - | ----------------------------------------------------------- |
| x | A hardware command queue with execution admission disabled. |
The staging component maintains the Candidate Act independently of
mutable guest memory.
Where the originating guest can modify a shared payload after
staging, the system must either copy the material payload into a
controlled representation or verify the final material content again
at effectuation.
7.2.58. S-2.13.1 - Durable staging
For operations that may outlive the micro-VM, the staging record may
be maintained in durable storage.
The record can include an authenticated descriptor digest and a
protected operation state.
Durability requirements depend on the claimed recovery and completion
guarantees.
A deployment that does not support durable pending operations may
instead cancel or reject outstanding operations upon termination.
7.2.59. S-2.14 - Candidate Act Descriptor
The system generates a descriptor containing sufficient information
to evaluate and later verify the governed operation.
A representative descriptor contains:
Das Expires 25 April 2027 [Page 131]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | CandidateActID. |
| - | ---------------------------------- |
| x | AgentContextID. |
| x | MicroVMInstanceID. |
| x | ExecutionGeneration. |
| x | TaskID. |
| x | OperationClass. |
| x | ResourceID. |
| x | MaterialArguments. |
| x | PayloadDigest. |
| x | AuthorityGeneration. |
| x | IntendedSinkID. |
| x | CreationSequence. |
| x | ExpiryCondition. |
| x | Nonce or replay-control reference. |
| x | CanonicalizationProfile. |
7.2.60. S-2.14.1 - Canonicalization
Material fields are represented under a deterministic
canonicalization procedure.
The same interpretation must be used for protected validation and
finality verification.
Ambiguous encodings, conflicting duplicate fields, inconsistent
resource normalization, or unrecognized canonicalization versions are
rejected or resolved through a specifically disclosed normalization
rule.
7.2.61. PART V - PED AND CIED OPERATION
7.2.62. S-2.15 - Protected Enforcement Domain
A PED evaluates the required authorization conditions for a Candidate
Act.
The PED may be implemented as:
(a) a host-side security service protected under defined host trust
assumptions;
(b) a hypervisor security component;
(c) a protected microkernel service;
(d) a trusted execution environment;
Das Expires 25 April 2027 [Page 132]
Internet-Draft Sandbox Credential Egress Finality October 2026
(e) an HSM-assisted validation service;
(f) a secure controller;
(g) a protected SmartNIC or DPU service; or
(h) a distributed enforcement arrangement maintaining the required
integrity properties.
A PED need not be located inside the micro-VM.
Indeed, in one representative implementation, it remains outside the
agent-controlled micro- VM and cannot be modified by the agent's
guest privileges.
7.2.63. S-2.15.1 - Authority-state binding
1. 2. 3. 4. 5. 6. 7. 8. 9.
The PED verifies:
The actual originating micro-VM context. The execution generation.
The applicable agent identity. The delegated task. The requested
operation. The target resource. The permitted effectuation
boundary. The applicable authority state. The current revocation
state.
10. Any additional predicates required by the enforcement point.
The PED does not grant authority solely because the micro-VM was
launched by an authorized orchestrator.
7.2.64. S-2.16 - Protected Validation Evidence
Following successful validation, the PED commits a protected
validation-evidence record.
A representative record comprises:
EvidenceID = VE-0091
CandidateActID = CA-0091
OriginGeneration = 508
ValidatedAuthorityGeneration = 105
DescriptorDigest = DIGEST-0091
Das Expires 25 April 2027 [Page 133]
Internet-Draft Sandbox Credential Egress Finality October 2026
ValidationResult = APPROVED
AuthorizedSink = FS-MSG-01
EvidenceGeneration = 610
The strings are illustrative.
The evidence may be represented by signed data, authenticated
records, protected state transitions, sealed storage, or equivalent
integrity-protected representations.
Where the enforcement point requires evidence to precede finality
enablement, the system maintains that ordering.
7.2.65. S-2.17 - CIED Variation
In a stronger implementation, the PED comprises a CIED.
The CIED provides the cryptographic isolation and protected-state
guarantees required by the selected embodiment.
A CIED may:
| x | Maintain protected authority keys. |
| - | ------------------------------------------ |
| x | Authenticate the Candidate Act Descriptor. |
| x | Verify the origin execution generation. |
| - | ---------------------------------------------------------------- |
| x | Maintain protected policy or revocation state. |
| x | Commit protected validation evidence. |
| x | Establish bounded authorization. |
| x | Prevent unauthorized alteration of critical authorization state. |
The CIED may reside in a hardware-backed enclave, HSM, secure
coprocessor, protected controller, or suitable distributed
cryptographic arrangement.
A micro-VM is not itself a CIED merely because it uses hardware-
assisted virtualization.
The actual cryptographic isolation and enforcement properties must
satisfy the relevant enforcement point requirements.
Das Expires 25 April 2027 [Page 134]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.66. PART VI - LIFECYCLE-BOUND FINALITY AUTHORITY
7.2.67. S-2.18 - Scoped Non-Bearer Capability
After the required validation and evidence commitment, the PED
establishes a scoped nonbearer finality capability.
A representative capability may contain or reference:
CapabilityID = CAP-0091
CandidateActID = CA-0091
ValidatedDescriptorDigest = DIGEST-0091
OriginExecutionGeneration = 508
AuthorizedTaskID = TASK-204
AuthorizedSink = FS-MSG-01
AuthorityGeneration = 105
EvidenceReference = VE-0091
ConsumptionMode = SINGLE_USE
CapabilityStatus = ACTIVE
The capability may be represented as a protected registry entry,
authenticated authorization artifact, secure latch, protected
permission state, or equivalent mechanism.
7.2.68. S-2.18.1 - Instance-bound capability
In one implementation, the capability remains valid only while the
originating execution generation remains active and authorized.
Termination or revocation of that generation causes pending
effectuation to be denied unless the capability has been expressly
transferred or revalidated under a permitted continuation procedure.
7.2.69. S-2.18.2 - Task-bound capability
In another implementation, the capability is bound primarily to the
independently maintained task and Candidate Act rather than to the
continuing existence of the micro-VM.
Das Expires 25 April 2027 [Page 135]
Internet-Draft Sandbox Credential Egress Finality October 2026
Such an embodiment may permit a previously authorized operation to
complete after the originating micro-VM terminates.
The permitted continuation must be established by protected policy
and state, rather than inferred solely from the fact that the request
was already queued.
7.2.70. S-2.18.3 - Distinction
Micro-VM termination may have different consequences according to the
authorization policy.
For example:
| x | A read-only reporting task may cancel pending operations upon termination. |
| - | -------------------------------------------------------------------------------------------------------------------- |
| x | An already approved external transaction may be permitted to complete under an independent task-bound authorization. |
| x | A security-sensitive operation may require revalidation after worker replacement. |
| x | A revoked task must not regain authority merely because a replacement micro-VM starts. |
The implementation must define the applicable continuation rule.
7.2.71. PART VII - FINALITY SINK VERIFICATION
7.2.72. S-2.19 - Finality Sink
The Finality Sink controls the actual consequential operation.
It may be implemented by:
1. A protected network-egress service. 2. A host-side tool
dispatcher. 3. A credential-use controller. 4. A database
transaction interface. 5. A persistent storage controller. 6. A
protected messaging service.
7. A cloud resource gateway. 8. A hardware command controller. 9.
A secure device interface.
The Finality Sink may execute on the same physical host as the micro-
VM or on another
machine.
7.2.73. S-2.20 - Actual Pending Operation Reconstruction
Before effectuation, the Finality Sink obtains or reconstructs
material parameters of the actual pending operation.
Das Expires 25 April 2027 [Page 136]
Internet-Draft Sandbox Credential Egress Finality October 2026
For example, a protected message-sending sink may determine:
| x | The effective destination. |
| - | -------------------------------------------------------- |
| x | The final message body or digest. |
| x | The actual source execution context or task association. |
| x | The permitted resource scope. |
| x | The current authority generation. |
| x | The actual external service being invoked. |
The sink compares these values with the protected authorization
conditions.
7.2.74. S-2.20.1 - Operation transformation
A host-side connector may transform a logical agent tool request into
a concrete network request.
Where authorization is intended to govern the concrete network
effect, the Finality Sink verifies the material final request after
the transformation, or verifies an equivalent securely bound
representation of the transformed operation.
An authorization for one recipient or target resource must not
silently become authorization for another through connector
translation.
7.2.75. S-2.21 - Sink-Local Protected State
The sink maintains or securely accesses the protected state needed to
enforce the relevant authorization.
Such state may include:
| x | Capability ID. |
| - | ----------------------------- |
| x | Authorized descriptor digest. |
| x | Current authority generation. |
| x | Revocation generation. |
| x | Allowed execution-generation state. |
| - | ------------------------------------ |
| x | Capability consumption status. |
| x | Pending dispatch state. |
| x | External operation identifier. |
| x | Completion or reconciliation status. |
Das Expires 25 April 2027 [Page 137]
Internet-Draft Sandbox Credential Egress Finality October 2026
The protected state may be stored in secure memory, an authenticated
transactional registry, a protected hardware register, or another
implementation satisfying the applicable protection properties.
7.2.76. S-2.21.1 - Verification sequence
The sink:
1. Obtains the actual pending operation. 2. Retrieves the bounded
authorization condition. 3. Verifies the applicable protected
evidence. 4. Confirms the authorized task or execution-generation
relationship. 5. Checks the current authority and revocation state.
6. Confirms operation-parameter correspondence. 7. Checks expiry
and replay conditions. 8. Checks sink-local consumption state. 9.
Performs the required protected state transition. 10. Permits the
governed effect only if all mandatory conditions are satisfied.
Where the enforcement point requires single-use finality, capability
consumption is atomic with respect to other workers attempting to use
the same capability.
Atomicity of a local protected-state transition does not by itself
guarantee an atomic transaction with an unrelated external service.
7.2.77. PART VIII - OUTSTANDING OPERATION CONTINUITY
7.2.78. S-2.22 - Outstanding Operation Registry
A significant feature of this embodiment is an operation registry
maintained independently of micro-VM lifecycle state.
A representative record includes:
OperationID
CandidateActID
OriginMicroVMInstanceID
OriginExecutionGeneration
TaskID
ProtectedEvidenceReference
CapabilityReference
OperationDescriptorDigest
Das Expires 25 April 2027 [Page 138]
Internet-Draft Sandbox Credential Egress Finality October 2026
AuthorizedSinkID
DispatchStatus
ExternalOperationID
CompletionStatus
RevocationGeneration
ReconciliationStatus
An operation remains identifiable even if the guest process or micro-
VM that initiated it no longer exists.
7.2.79. S-2.23 - Operation State Machine
A representative operation state machine comprises:
7.2.80. PROPOSED → STAGED → VALIDATED → AUTHORIZED → RESERVED →
DISPATCHED → COMPLETED
Alternative terminal or intermediate states may include:
DENIED
CANCELED
EXPIRED
REVOKED
FAILED
INDETERMINATE
RECONCILIATION_REQUIRED
The operation state machine is separate from the micro-VM lifecycle
state machine.
For example, a micro-VM may be TERMINATED while an associated
operation remains DISPATCHED or INDETERMINATE.
The system does not equate guest termination with operation
cancellation.
Das Expires 25 April 2027 [Page 139]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.81. S-2.24 - Micro-VM Termination Workflow
When the Micro-VM Manager receives a termination request:
7.2.82. Step T1 - Termination initiation
The lifecycle controller identifies the micro-VM and its current
execution generation.
7.2.83. Step T2 - New-operation restriction
The system prevents the terminating micro-VM from establishing new
governed operations beyond the applicable shutdown policy.
7.2.84. Step T3 - Outstanding-operation enumeration
The registry identifies operations associated with the micro-VM.
7.2.85. Step T4 - Operation classification
Each operation is classified as completed, not yet dispatched,
independently authorized for continuation, cancelable, or unresolved.
7.2.86. Step T5 - Cancellation or continuation determination
The controller applies the protected policy governing operations that
may outlive the micro- VM.
7.2.87. Step T6 - Authority-generation transition
The execution generation is marked terminated, revoked, or otherwise
no longer available for new authority.
7.2.88. Step T7 - Pending-operation update
Operations not authorized to continue are canceled or remain
withheld.
7.2.89. Step T8 - Continued-operation preservation
Operations expressly permitted to continue retain their independently
protected task-bound authorization.
7.2.90. Step T9 - Guest destruction
The micro-VM's guest resources are released according to the selected
isolation and resourcereclamation procedures.
Das Expires 25 April 2027 [Page 140]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.91. Step T10 - Post-termination reconciliation
Outstanding external operations remain tracked until their outcome is
resolved or placed in a defined unresolved state.
Termination of the guest does not cause a protected authorization
record to be silently treated as consumed or completed.
7.2.92. S-2.25 - Replacement Micro-VM Workflow
A new micro-VM may be launched to continue a task previously assigned
to a failed or terminated instance.
The replacement receives a new execution generation.
The system may transfer:
(a) permitted task objectives; (b) necessary computational state; (c)
authorized tool configuration; (d) completed-operation history; (e)
outstanding-operation references; (f) relevant task constraints; and
(g) non-sensitive or otherwise permitted memory state.
The replacement must not infer that a pending operation has not
executed merely because its local task state lacks a completion
record.
7.2.93. S-2.25.1 - Replacement consistency check
Before generating a replacement operation, the controller compares
the proposed operation against the Outstanding Operation Registry.
If a materially equivalent operation remains pending or has already
completed, the replacement applies the defined continuation or
reconciliation rule.
The equivalence rule may use operation identifiers, resource
identities, transaction references, payload digests, task semantics,
or a combination thereof.
7.2.94. S-2.25.2 - Replacement authority
A capability bound to an earlier execution generation is not
automatically valid for the replacement generation.
1. 2. 3. 4.
The system may:
Das Expires 25 April 2027 [Page 141]
Internet-Draft Sandbox Credential Egress Finality October 2026
Reject it. Revalidate the operation. Transfer a task-bound
authorization under a protected continuation procedure. Issue a new
capability after resolving prior consumption and effectuation state.
The selected procedure must not allow the replacement instance to
replay previously completed operations.
7.2.95. PART IX - SNAPSHOT RESTORATION AND ROLLBACK
7.2.96. S-2.26 - Snapshot Security
Micro-VM systems may support snapshots or pre-initialized execution
images.
A snapshot may contain:
| x | Guest memory. |
| - | ---------------------------------- |
| x | Agent runtime state. |
| x | Tool configuration. |
| x | Open logical operation references. |
| x | Cached task data. |
| x | Pending local tool calls. |
| x | Historical execution identifiers. |
Restoring such state may create inconsistencies with external
protected authority state.
Accordingly, snapshot restoration is treated as a lifecycle event
requiring applicable identity and state reconciliation.
7.2.97. S-2.27 - Snapshot Restoration Workflow
A representative restoration workflow includes:
Step R1: Identify the snapshot and its recorded source execution
generation.
Step R2: Allocate a new restoration generation.
Step R3: Initialize the restored guest in a restricted condition.
Step R4: Establish new controlled communication endpoints.
Step R5: Invalidate or rebind stale execution-context references.
Step R6: Query the independent operation registry for relevant
outstanding and completed
Das Expires 25 April 2027 [Page 142]
Internet-Draft Sandbox Credential Egress Finality October 2026
operations.
Step R7: Reconcile restored task state with protected operation
state.
Step R8: Reject stale capabilities whose binding does not permit
restoration.
Step R9: Revalidate required authorization conditions.
Step R10: Permit new governed operations only after the applicable
restoration checks
succeed.
7.2.98. S-2.27.1 - Protected state independence
A restored guest snapshot does not restore the PED's protected
capability-consumption registry to an earlier state.
Likewise, snapshot restoration does not reverse an externally
completed operation.
Where the PED or sink state is itself restored from backup, the
design must specify rollbackresistant recovery, monotonic generation
checks, or an equivalent method of detecting stale authority state.
7.2.99. PART X - REFERENCE ALGORITHMS
S-2.28 - Algorithm A: Micro-VM Creation and Context Binding
The following pseudocode describes one representative implementation.
function CreateAgentMicroVM(task, isolation_profile):
vm = MicroVMManager.create(isolation_profile)
generation = ProtectedGenerationService.allocate()
context = {
vm_id: vm.id, generation: generation, agent_id: task.agent_id,
task_id: task.id, authority_generation:
CurrentAuthorityGeneration(task), permitted_interfaces:
isolation_profile.interfaces }
ProtectedContextRegistry.register(context)
Das Expires 25 April 2027 [Page 143]
Internet-Draft Sandbox Credential Egress Finality October 2026
ConfigureControlledInterfaces(vm, context)
if not VerifyRequiredInterfaceControls(vm, context):
MicroVMManager.destroy(vm) ProtectedContextRegistry.revoke(context)
return DENIED
MicroVMManager.start(vm)
return context
The generation allocation and protected registry update must have
defined concurrency and failure semantics.
A production implementation should ensure that an aborted creation
attempt cannot cause the same authority-bearing generation to be
assigned ambiguously to multiple independent active instances.
7.2.100. S-2.29 - Algorithm B: Candidate Act Staging
function CaptureMicroVMOperation(channel, request):
context = AuthenticateChannelContext(channel)
if context is invalid:
return DENIED
if not IsExecutionGenerationActive(context):
return DENIED if not IsGovernedOperation(request):
return HandleUnderApplicableNonFinalityPolicy(request)
operation = CopyIntoControlledStaging(request)
descriptor = Canonicalize({
operation: operation, authenticated_context: context,
policy_generation: CurrentPolicyGeneration(context), target_boundary:
ResolveEffectuationBoundary(operation) })
candidate_id = AllocateCandidateActID()
OutstandingOperationRegistry.create({
candidate_id: candidate_id,
Das Expires 25 April 2027 [Page 144]
Internet-Draft Sandbox Credential Egress Finality October 2026
origin_generation: context.generation, task_id: context.task_id,
descriptor_digest: Hash(descriptor), status: STAGED })
return PED.Validate(candidate_id, descriptor)
The operation is not dispatched through the governed effectuation
interface before the required validation.
S-2.30 - Algorithm C: Lifecycle-Aware PED Authorization
function ValidateCandidate(candidate_id, descriptor):
record = OutstandingOperationRegistry.get(candidate_id)
if record.status != STAGED:
return DENIED
if not VerifyOriginBinding(descriptor, record):
return DENIED
if not VerifyExecutionGenerationPolicy(
descriptor.origin_generation, descriptor.task_id ):
return DENIED
authority = ProtectedAuthorityRegistry.get(
descriptor.task_id )
if not EvaluateRequiredPredicates(descriptor, authority):
return DENIED evidence = CommitProtectedValidationEvidence(
candidate_id, descriptor, authority )
capability = CreateScopedNonBearerCapability({
candidate_id: candidate_id, evidence_reference: evidence.id,
descriptor_digest: Hash(descriptor), target_sink:
descriptor.target_boundary, authority_generation:
authority.generation,
continuation_policy: authority.continuation_policy })
AtomicRegistryTransition(
Das Expires 25 April 2027 [Page 145]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate_id, STAGED, AUTHORIZED, evidence.id, capability.id )
return AUTHORIZED
The implementation must preserve the required ordering of evidence
commitment and capability activation. If the final state transition
fails, the corresponding capability must not remain independently
usable outside the permitted operation state.
7.2.101. S-2.31 - Algorithm D: Finality Sink Operation
function ExecuteAtSink(candidate_id):
record = OutstandingOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED
actual_operation = ReadControlledPendingOperation(candidate_id)
if actual_operation is unavailable:
return DENIED
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
if not VerifyProtectedEvidence(evidence):
return DENIED if not VerifyCapabilityBindings(
capability, evidence, actual_operation ):
return DENIED
if not VerifyLifecycleContinuationPolicy(
record.origin_generation, record.task_id, capability ):
return DENIED
if not VerifyCurrentAuthorityState(capability):
Das Expires 25 April 2027 [Page 146]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED if not VerifySinkLocalConsumptionState(capability):
return DENIED if not
AtomicallyReserveSingleUseAuthorization(capability):
return DENIED result = DispatchUsingControlledInterface(
actual_operation, candidate_id )
ReconcileExternalOutcome(candidate_id, result)
return result
If an external operation has an indeterminate result, the
reconciliation procedure must not equate the lack of an
acknowledgment with lack of effectuation.
7.2.102. S-2.32 - Algorithm E: Micro-VM Termination
function TerminateMicroVM(vm_id, generation):
ProtectedContextRegistry.markQuiescing(
vm_id, generation )
BlockNewGovernedOperations(vm_id, generation)
pending = OutstandingOperationRegistry.listByOrigin(
vm_id, generation )
for each operation in pending:
if operation.status == COMPLETED:
continue
if operation.status in [STAGED, AUTHORIZED]:
if not PermitIndependentContinuation(operation):
CancelOrRevokePendingOperation(operation)
if operation.status in [RESERVED, DISPATCHED, INDETERMINATE]:
MarkForReconciliation(operation)
ProtectedContextRegistry.revokeGeneration(generation)
Das Expires 25 April 2027 [Page 147]
Internet-Draft Sandbox Credential Egress Finality October 2026
MicroVMManager.destroy(vm_id)
return TERMINATED
An implementation must coordinate generation revocation with the
Finality Sink's own protected authorization and dispatch state.
For operations that may continue independently, the continuation must
remain constrained by the applicable authorization and revocation
policy.
7.2.103. PART XI - WORKED TECHNICAL EXAMPLES
S-2.33 - Example A: Ephemeral Agent Sending an Authorized Report
This is a hypothetical example.
An enterprise orchestrator starts micro-VM MICROVM-0081 for the task
of preparing and sending a report to an authorized internal
recipient.
The micro-VM is assigned execution generation 508.
The agent prepares the report and requests that it be transmitted.
The request is captured through a controlled tool-dispatch interface.
The resulting Candidate Act is placed in a non-effective staging
state.
The PED validates:
| x | Agent identity. |
| - | -------------------------------------------- |
| x | Task authorization. |
| x | Recipient. |
| x | Report classification. |
| x | Destination service. |
| x | Policy generation. |
| x | Applicable execution-generation constraints. |
Upon successful validation, the PED commits protected evidence and
establishes a scoped non-bearer capability.
The Finality Sink reconstructs the actual message and recipient
before dispatch.
Das Expires 25 April 2027 [Page 148]
Internet-Draft Sandbox Credential Egress Finality October 2026
The capability is verified and atomically reserved or consumed
according to the defined protocol.
The report is sent through the controlled messaging interface.
The operation registry records the resulting completion status.
The micro-VM may then terminate.
The protected completion record remains available after termination.
S-2.34 - Example B: Micro-VM Terminates Before Dispatch
The agent prepares an authorized report transmission.
The Candidate Act is staged and validated.
Before the Finality Sink performs the operation, the micro-VM
crashes.
The lifecycle controller identifies the crash and transitions the
instance generation out of the active state.
The Outstanding Operation Registry identifies the pending report
transmission.
Under one policy, micro-VM termination cancels all undispatched
message operations.
The capability is revoked, and the report is not sent.
Under a different policy, the report transmission is independently
authorized as a task-bound operation permitted to survive the micro-
VM.
The protected continuation procedure permits the Finality Sink to
execute the already authorized operation.
The choice depends on the defined continuation policy.
The system does not infer that a previously staged operation is
automatically authorized for continuation.
S-2.35 - Example C: Worker Replacement Without Duplicate External
Effects
A micro-VM requests a cloud resource modification.
Das Expires 25 April 2027 [Page 149]
Internet-Draft Sandbox Credential Egress Finality October 2026
The Finality Sink dispatches the request.
The cloud service may have executed the modification, but the
completion acknowledgment is lost.
The orchestrator treats the micro-VM as failed and creates a
replacement micro-VM.
The replacement initially attempts to perform the same modification.
Before dispatch, the system identifies an outstanding prior operation
with the same protected transaction identity or defined effect-
equivalence relationship.
The new attempt is withheld pending reconciliation.
If the external service supports an idempotency key, the system may
query or retry using the original key according to that service's
semantics.
If the service does not provide sufficient completion or idempotency
guarantees, the operation remains in an explicit unresolved state
until an authorized reconciliation procedure determines how to
proceed.
The embodiment does not enforcement point that exactly-once external
execution can always be guaranteed against an arbitrary external
service.
7.2.104. PART XII - FAILURE AND ADVERSARIAL SCENARIOS
7.2.105. S-2.36 - Failure F1: Micro-VM Identifier Reuse
An orchestration platform reuses the identifier MICROVM-0081.
The new instance receives generation 509.
A capability bound to generation 508 is presented by the new
instance.
The protected enforcement system detects the generation mismatch and
rejects the capability unless an expressly authorized protected
continuation procedure applies.
7.2.106. S-2.37 - Failure F2: Snapshot Replay
A snapshot contains a pending tool request and an old operation
reference.
Das Expires 25 April 2027 [Page 150]
Internet-Draft Sandbox Credential Egress Finality October 2026
After restoration, the guest attempts to repeat the request.
The independent operation registry shows that the corresponding
operation already completed or that the earlier capability was
consumed.
The replay is denied or reconciled according to the applicable
operation identity and continuation policy.
7.2.107. S-2.38 - Failure F3: Guest Privilege Escalation
An attacker obtains guest administrator privileges.
The attacker creates a tool request claiming a different agent or
task identity.
The host-side enforcement system derives the request's source context
from a trusted channel association rather than accepting the
unverified guest enforcement point.
| The request is evaluated under the actual authenticated context. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-2.39 - Failure F4: Alternate Virtual Network Interface The micro-VM contains an additional virtual network interface. The interface permits transmission independently of the protected egress mechanism. The configuration fails the asserted non-bypassable finality condition. The deployment must remove, constrain, or mediate that interface before claiming complete protected coverage of the specified network effect. |
| S-2.40 - Failure F5: Delayed Asynchronous Tool Worker A tool request is queued. The micro-VM terminates. A worker later attempts to execute the queued request. The worker must obtain the required current authorization or an expressly permitted task- bound continuation authorization. The originating micro-VM's former active status does not, by itself, authorize the delayed operation. |
7.2.108. S-2.41 - Failure F6: PED Unavailable
The PED becomes unavailable during authorization.
The governed Candidate Act remains withheld or is canceled.
An unprotected fallback approval does not substitute for the required
PED authorization.
| S-2.42 - Failure F7: Finality Sink State Loss The Finality Sink restarts after reserving a capability. The operation may already have been dispatched. The sink recovers the protected operation and consumption state using its configured durable or rollback-resistant mechanism. If the external outcome remains uncertain, it is reconciled rather than assumed unsuccessful. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-2.43 - Failure F8: Concurrent Replacement Micro-VMs Two replacement micro-VMs attempt to continue the same task. The orchestration or protected operation controller uses generation, task, operation identity, and state-transition controls to prevent unauthorized duplicate consumption of the same protected finality authorization. Separate authorization is required for genuinely distinct operations. |
| S-2.44 - Failure F9: Malicious Tool Transformation A tool wrapper changes the destination or payload after the PED validates the logical request. The Finality Sink obtains the actual pending operation. The sink rejects a material mismatch unless the transformation is expressly within the authorized operation envelope. |
7.2.109. S-2.45 - Failure F10: Host Compromise
A software-only protected enforcement implementation may rely on
integrity of the host kernel, virtualization manager, or privileged
enforcement processes.
If the attacker compromises the corresponding trusted computing base,
the intended guarantees may fail.
Das Expires 25 April 2027 [Page 151]
Internet-Draft Sandbox Credential Egress Finality October 2026
Hardware-assisted variants may reduce some of these dependencies, but
must specifically protect the authority state and effectuation
interface required by the relevant enforcement point.
7.2.110. S-2.46 - Failure F11: Premature Guest Destruction
The orchestrator destroys the guest before relevant operation
metadata is durably recorded.
The system may lose the information needed to reconcile pending
external effects.
A deployment requiring durable continuation must establish an
appropriate operationregistration and acknowledgment ordering before
releasing or destroying the originating execution context.
S-2.47 - Failure F12: Policy Revocation During Termination
A Candidate Act is authorized while the micro-VM is active.
The task authority is revoked during micro-VM termination.
The Finality Sink checks the applicable current revocation or
authority-generation state before effectuation.
The operation is withheld if the revocation policy invalidates the
previously issued authorization.
7.2.111. PART XIII - SOFTWARE, HARDWARE, AND HYBRID VARIATIONS
7.2.112. S-2.48 - Software-Based Micro-VM Implementation
In one implementation:
| x | The micro-VM executes on a conventional host. |
| - | ----------------------------------------------------------------------- |
| x | A lightweight virtualization manager creates and terminates instances. |
| x | Host-side protected services perform authorization. |
| x | A host-controlled virtual-device backend captures Candidate Acts. |
| x | A controlled gateway or resource interface serves as the Finality Sink. |
| x | An authenticated operation registry tracks outstanding effects. |
The trust model assumes that the required host-enforcement components
remain uncompromised.
7.2.113. S-2.49 - Hardware-Assisted Virtualization Implementation
Das Expires 25 April 2027 [Page 152]
Internet-Draft Sandbox Credential Egress Finality October 2026
| The micro-VM uses processor hardware supporting virtual-machine isolation. The hardware may assist with isolation of guest memory, processor state, and privileged operations. The authorization and finality mechanisms remain implemented through protected services or devices that control the governed effectuation paths. Hardware virtualization support does not automatically establish sink-side authorization. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-2.50 - Confidential Micro-VM Implementation In another embodiment, the micro-VM executes within a confidential-computing environment providing specified hardware-backed memory confidentiality or integrity properties. A protected workload measurement or attestation may contribute to the agent's authority predicates. The PED verifies the applicable protected identity or attestation information before authorizing consequential operations. The attestation mechanism must be bound to the actual task, execution generation, or other context required by the authorization policy. A valid attestation does not by itself establish permission for every operation performed by the attested workload. |
| S-2.51 - HSM-Backed Authority Implementation An HSM may maintain protected keys, authorization state, evidence commitments, or capability-generation mechanisms. The micro-VM communicates through controlled host interfaces. The Finality Sink verifies the corresponding bounded finality authorization. Where the HSM serves as a CIED, it performs the security-critical functions required by the enforcement point rather than merely signing arbitrary requests supplied by an untrusted host. |
7.2.114. S-2.52 - SmartNIC/DPU Finality Implementation
The host executes multiple micro-VMs.
A SmartNIC or DPU controls specified network-effectuation paths.
Each micro-VM is associated with an execution context and authority
generation.
The protected network controller verifies operation-specific
authorization before governed transmission.
The implementation may bind the authorization to the effective micro-
VM source context, flow identity, destination, and protected task
state.
Alternative host networking and device pass-through paths must be
addressed to support a non-bypassability assertion.
7.2.115. S-2.53 - Distributed Micro-VM Implementation
An orchestrator may create micro-VMs on multiple host machines.
Protected task and operation state is maintained by a distributed
service.
Each execution instance receives a distinct execution generation and
authenticated context.
A Candidate Act may be authorized by a PED operating on one machine
and effectuated through a Finality Sink on another.
The authenticated authorization must bind the operation, evidence,
authority generation, and intended effectuation boundary according to
the relevant enforcement point.
Where distributed state is used for single-use consumption or
revocation, the implementation must specify its consistency
guarantees and failure behavior during network partitioning.
Das Expires 25 April 2027 [Page 153]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.116. S-2.54 - Integrated Protected Controller Implementation
A protected controller may implement PED validation, evidence
commitment, bounded authorization, and Finality Sink verification
within a single hardware or software security component.
The micro-VM communicates with this controller through a restricted
interface.
The controller maintains the distinct logical validation and
effectuation-control operations required by the enforcement point.
A physically separate PED and Finality Sink are not mandatory where
the enforcement point permits colocation.
7.2.117. PART XIV - REPRESENTATIVE TECHNICAL DATA STRUCTURES
7.2.118. S-2.55 - MicroVMContextRecord
The MicroVMContextRecord may include:
1. MicroVMInstanceID. 2. ExecutionGeneration. 3. AgentContextID.
4. TaskID. 5. IsolationProfile. 6. VirtualDeviceProfile. 7.
AuthorityGeneration. 8. CommunicationEndpointID. 9.
LifecycleStatus. 10. AttestationReference, where applicable.
7.2.119. S-2.56 - CandidateActRecord
The CandidateActRecord may include:
1. CandidateActID. 2. OriginMicroVMInstanceID. 3.
OriginExecutionGeneration. 4. TaskID. 5. OperationClass. 6.
ResourceID. 7. DescriptorDigest. 8. NonEffectiveStateReference. 9.
AuthorityGeneration. 10. CandidateStatus.
7.2.120. S-2.57 - ProtectedValidationEvidenceRecord
The ProtectedValidationEvidenceRecord may include:
1. 2. 3. 4. 5.
EvidenceID. CandidateActID. ValidatedDescriptorDigest.
PEDIdentity. AuthorityGeneration.
6. OriginExecutionGeneration. 7. ValidationResult. 8.
EvidenceCommitment. 9. EvidenceGeneration. 10.
ApplicableValidityConditions.
Das Expires 25 April 2027 [Page 154]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.121. S-2.58 - ScopedFinalityCapabilityRecord
The ScopedFinalityCapabilityRecord may include:
1. CapabilityID. 2. CandidateActID. 3. ProtectedEvidenceReference.
4. AuthorizedSinkID. 5. PermittedOperationScope. 6.
OriginExecutionGeneration. 7. AuthorizedTaskID. 8.
AuthorityGeneration. 9. ConsumptionPolicy. 10. ContinuationPolicy.
11. ExpiryCondition. 12. CapabilityStatus.
7.2.122. S-2.59 - OutstandingOperationRecord
The OutstandingOperationRecord may include:
1. OperationID. 2. CandidateActID. 3. OriginExecutionGeneration.
4. TaskID. 5. DescriptorDigest. 6. EvidenceReference. 7.
CapabilityReference. 8. DispatchStatus. 9. ExternalOperationID. 10.
CompletionStatus. 11. ReconciliationStatus. 12.
LastStateTransition.
7.2.123. S-2.60 - LifecycleReconciliationRecord
The LifecycleReconciliationRecord may include:
1. SourceExecutionGeneration. 2. ReplacementExecutionGeneration. 3.
TaskID. 4. OutstandingOperationReferences. 5.
CompletedOperationReferences. 6. RevocationGeneration. 7.
ContinuationDecision. 8. RecoveryStatus. 9.
ReconciliationEvidenceReference. 10. RestorationTimestampOrSequence.
These logical records may be implemented using protected memory,
authenticated databases, deterministic binary representations,
protected registers, distributed state machines, or equivalent data
structures suitable for the claimed security requirements.
7.2.124. PART XV - implementer VERIFICATION AND IMPLEMENTATION TESTS
7.2.125. S-2.61 - Representative Test Matrix
The following tests are proposed engineering verification procedures,
not representations of experiments already performed.
7.2.126. Test Condition
T1 Valid micro-VM and authorized
operation T2 Guest attempts direct unauthorized
Das Expires 25 April 2027 [Page 155]
Internet-Draft Sandbox Credential Egress Finality October 2026
egress T3 Old generation reused T4 Snapshot restored T5 Micro-VM
crashes before dispatch T6 Micro-VM crashes after possible
dispatch T7 Two replacement micro-VMs retry No unauthorized duplicate
authorization T8 Protected evidence absent T9 Capability already
consumed T10 Operation parameters modified T11 PED unavailable T12
Finality Sink unavailable T13 Authority generation revoked T14
Asynchronous worker executes late Fresh or valid continuation
authority required T15 Ambiguous request encoding T16 Untrusted guest
enforcement points another
identity T17 Micro-VM identifier recycled
7.2.127. Expected technical behavior
Effectuation through authorized sink
Restricted or blocked route Stale authority rejected Prior consumed
authority not restored Defined cancellation or continuation External
outcome reconciled
Finality denied Replay denied Descriptor mismatch denied Required
effectuation withheld No uncontrolled permissive fallback Invalidated
operation withheld
Consistent canonicalization or rejection Authenticated channel
identity prevails Generation distinguishes new instance
T18 Distributed state temporarily Behavior follows defined
consistency and failunavailable closed rules
7.2.128. PART XVII - Enforcement-Point Mapping and Technical
Correspondence FAMILIES
7.2.129. S-2.63 - Enforcement Point Support and Scope
this implementation profile provides representative technical
disclosure relevant to:
Das Expires 25 April 2027 [Page 156]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) virtualized and micro-virtualized sandbox effectuation control;
(b) interception of agent-generated operations; (c) staged non-
effective Candidate Acts; (d) protected PED or CIED authorization;
(e) validation-evidence commitment; (f) scoped non-bearer finality
capability generation; (g) Finality Sink verification; (h) bounded
execution-context authority; (i) revocation and rollback handling;
(j) asynchronous operation continuation; (k) protected operation-
state recovery; (l) coordinated enforcement across software and
hardware boundaries; and (m) prevention of unauthorized capability
reuse after execution-instance replacement.
The embodiment may contribute supporting disclosure to the sandbox-
finality, continuoussession, credential-finality, effectuation-path,
deferred-effect, distributed-authority, and hardware-enforcement
enforcement point families.
However, the existence of this embodiment does not automatically
establish writtendescription or enablement support for every
limitation of those enforcement points.
A final enforcement point-to-disclosure chart must separately
identify the technical basis for each claimed combination.
7.2.130. S-2.64 - Relationship to Other Sandbox Embodiments
The micro-VM embodiment differs from a conventional full-VM
embodiment in its emphasis on:
1. Ephemeral execution instances. 2. Rapid creation and
destruction. 3. Reduced virtual-device interfaces. 4. Distinct
execution generations. 5. Snapshot reuse and restoration. 6.
Replacement workers. 7. Asynchronous operations surviving the
initiating guest. 8. Independent outstanding-operation state. 9.
Lifecycle-specific continuation and revocation rules. 10.
Consistency between virtualization lifecycle and actual external
effectuation.
These features may also be used individually or in selected
combinations with other sandbox implementations.
The broader architecture is not limited to one virtualization
substrate where the relevant enforcement points permit alternative
implementations.
7.2.131. S-2.65 - Enablement Requirements
A implementer implementing this embodiment for a selected micro-VM
platform would identify:
Das Expires 25 April 2027 [Page 157]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) the selected virtualization mechanism; (b) the precise hardware
or software isolation assumptions;
(c) the guest image and device profile;
(d) the method of assigning authenticated instance context;
(e) the execution-generation allocation mechanism;
(f) the controlled communication channel;
(g) the interception mechanism for each governed effect class;
(h) the operation staging representation;
(i) the protected authorization-state mechanism;
(j) the validation algorithms and required authority predicates;
(k) the protected evidence format and commitment ordering;
(l) the scoped capability representation and lifecycle;
(m) the Finality Sink's actual-operation verification procedure;
(n) the protected state transitions governing single-use or bounded
authorization;
(o) the operation registry consistency and durability requirements;
(p) the snapshot and restoration rules;
(q) the replacement-worker continuation rules;
(r) the revocation and authority-generation synchronization
mechanism;
(s) the response to indeterminate external outcomes; and
(t) the mechanisms controlling unauthorized alternative effectuation
paths.
The implementation-specific description should supply enough
technical detail for a skilled person to implement these functions
using the selected substrate without inventing undisclosed essential
mechanisms.
Das Expires 25 April 2027 [Page 158]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.2.132. S-2.66 - Technical Summary
this implementation profile provides a micro-virtual-machine-isolated
artificial-intelligenceagent execution architecture in which the
lifecycle of an agent execution instance is separated from the
protected authority required to produce specified consequential
effects.
The system establishes authenticated execution-generation context,
captures governed Candidate Acts, maintains them in a Non-Effective
State, evaluates required authorization conditions in a Protected
Enforcement Domain, commits protected validation evidence,
establishes scoped non-bearer finality enablement, and verifies the
actual pending operation at a controlled Finality Sink.
An independent Outstanding Operation Registry maintains relevant
operation state across micro-VM termination, restoration,
replacement, and asynchronous execution.
Protected lifecycle and authority-generation controls prevent the
mere creation, restoration, or replacement of an execution instance
from recreating authorization that has expired, been revoked, or
already been consumed.
Software-only, hardware-assisted, cryptographically isolated, and
distributed implementations may be employed according to the
protection and enforcement requirements of the selected enforcement
points.
The embodiment thereby illustrates a protected execution architecture
in which ephemeral agent computation and durable authority to produce
consequential effects are governed through distinguishable technical
state machines.
7.2.132.1. CONTAINER-ISOLATED AI-AGENT EXECUTION WITH PROTECTED TOOL-
DISPATCH CONTROL, CREDENTIAL MEDIATION, NETWORK EGRESS
7.2.132.2. FINALITY, AND CROSS-BOUNDARY ENFORCEMENT
7.3. Implementation Profile S-3
Source location: original disclosure pages 138-186. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
Das Expires 25 April 2027 [Page 159]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.1. S-3.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, operating-systemlevel isolation, containerized execution,
protected resource authorization, kernel-mediated access control,
tool invocation, credential isolation, network egress control, and
verification of externally consequential operations.
More particularly, the embodiment describes a container-isolated
artificial-intelligence-agent execution system in which the container
may perform permitted computation while one or more protected
enforcement components control whether selected operations initiated
by the agent become externally effective.
The architecture may employ operating-system containers, Linux
namespaces, control groups, system-call restrictions, mandatory
access-control mechanisms, network mediation, host-side connectors,
protected credential services, hypervisor isolation, programmable
network devices, or combinations thereof.
The protected execution-finality implementation described herein is
one implementation species of the broader disclosed architecture.
A container is not required to be a virtual machine, trusted
execution environment, cryptographically isolated domain, or
physically separate device.
7.3.2. S-3.2 - Technical Problem
An artificial-intelligence agent may execute inside a container
configured to restrict files, processes, privileges, system calls,
networking, and access to host resources.
Such restrictions may reduce the consequences of untrusted
computation.
However, container isolation does not necessarily provide independent
authorization for the actual effects of operations performed through
interfaces intentionally exposed to the container.
For example, an agent may be permitted to access a host-side
connector that uses a privileged enterprise credential.
The agent may therefore be able to request an operation that is
syntactically valid and technically reachable, but that exceeds the
authority of its assigned task.
Das Expires 25 April 2027 [Page 160]
Internet-Draft Sandbox Credential Egress Finality October 2026
Similarly, a container may be permitted to communicate with selected
external services while the particular data disclosed, resource
modified, recipient selected, or transaction initiated remains
unauthorized.
A second technical problem arises when the container runtime enforces
restrictions through mechanisms that do not necessarily govern the
final effectuation boundary.
Examples include:
(a) a namespace restricting resource visibility without independently
evaluating task authorization;
(b) a control group restricting resource consumption without
determining whether a network request is authorized;
(c) a system-call filter limiting available system calls without
understanding the applicationspecific semantics of a permitted
operation;
(d) a security event observer detecting suspicious behavior without
blocking the operation;
(e) a host connector receiving a permitted IPC message but executing
an unauthorized external action;
(f) a credential broker possessing a privileged secret whose use must
be constrained independently of the agent;
(g) a network proxy approving an apparent destination before later
address resolution, redirection, or request transformation changes
the effective target;
(h) an asynchronous tool worker continuing an operation after the
originating container has terminated or lost authority; and
(i) an alternative file descriptor, socket, device interface, mounted
resource, or host service permitting effectuation outside the
intended enforcement path.
The embodiment addresses these problems through container-context
binding, controlled tool interfaces, protected operation staging,
independently maintained authorization state, protected validation
evidence, bounded finality enablement, and verification at an
effectuation boundary capable of preventing the specified
consequential effect.
Das Expires 25 April 2027 [Page 161]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.3. S-3.3 - Technical Objectives
The representative system is configured to provide one or more of the
following technical properties:
1. Container-level confinement of agent computation and resource
access. 2. Separation of agent-controlled code from protected
authorization functions. 3. Identification of the actual originating
container and agent execution context.
4. Interception of specified tool, network, credential, storage, and
resource operations. 5. Maintenance of governed Candidate Acts in a
Non-Effective State. 6. Protected evaluation of operation-specific
authority predicates. 7. Protected validation-evidence generation or
commitment. 8. Establishment of a scoped non-bearer finality
capability. 9. Independent verification of the actual pending
operation at a Finality Sink. 10. Restriction of unauthorized
alternate effectuation paths. 11. Prevention of stale, replayed,
duplicated, or substituted operations. 12. Controlled credential use
without unrestricted disclosure of host-held secrets. 13.
Distinction between behavioral observation and actual enforcement.
14. Controlled treatment of asynchronous tool execution and
container lifecycle changes. 15. Support for software-only,
hardware-assisted, and distributed implementations.
The particular combination required for a invention is determined by
the corresponding enforcement points.
7.3.4. PART I - PRINCIPAL ARCHITECTURE
7.3.5. S-3.4 - Principal System Components
A representative system comprises the following components.
7.3.6. Component A - Container Host
A computing platform executing a host operating system, container
runtime, and one or more containerized agent workloads.
The host may comprise a physical server, virtual machine, cloud
computing instance, workstation, edge device, or embedded system.
7.3.7. Component B - Container Runtime and Isolation Controller
A component configured to create, configure, execute, restrict, and
terminate containerized workloads.
Das Expires 25 April 2027 [Page 162]
Internet-Draft Sandbox Credential Egress Finality October 2026
The runtime may use operating-system namespaces, control groups,
capabilities, security profiles, virtualized filesystem views, and
other applicable isolation mechanisms.
7.3.8. Component C - Agent Container
An isolated process environment containing one or more artificial-
intelligence agents, tool clients, model clients, local execution
processes, or delegated computational workers.
7.3.9. Component D - Container Context Authenticator
A host-controlled mechanism configured to associate an operation with
the actual originating container, execution generation, security
identity, and assigned task.
7.3.10. Component E - Operation Interceptor
A component positioned along a governed effectuation path and
configured to intercept, receive, or prevent the dispatch of a
consequential operation.
7.3.11. Component F - Non-Effective Operation Holder
A staging mechanism configured to preserve a Candidate Act without
allowing its specified consequential effect.
7.3.12. Component G - Protected Enforcement Domain
A protected component configured to evaluate required authorization
predicates and maintain applicable protected authority state.
7.3.13. Component H - Protected Evidence Controller
A component configured to generate or commit validation evidence
required by the selected protected-finality procedure.
7.3.14. Component I - Scoped Finality Enablement Controller
A protected mechanism configured to establish a bounded authorization
condition associated with an approved Candidate Act.
7.3.15. Component J - Finality Sink
An enforcement interface configured to verify applicable
authorization requirements before permitting the actual governed
operation.
Das Expires 25 April 2027 [Page 163]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.16. Component K - Host-Side Tool Connector
A service configured to perform specified operations on behalf of an
agent without necessarily placing the underlying privileged execution
authority inside the container.
7.3.17. Component L - Credential Broker
A mechanism configured to control access to or use of protected
credentials, keys, secrets, authentication artifacts, or privileged
service sessions.
7.3.18. Component M - Network Egress Mediator
A mechanism configured to control specified outgoing network effects
through a protected proxy, gateway, host networking component, or
hardware network interface.
7.3.19. Component N - Protected Operation Registry
A registry maintaining operation identity, protected authorization
references, lifecycle state, consumption status, and outstanding
execution outcomes.
7.3.20. Component O - Optional Runtime Observation Mechanism
A mechanism configured to observe relevant process, system-call,
tool, memory, network, or resource-access behavior.
The observation mechanism may include operating-system tracing, LSM-
associated observations, eBPF instrumentation, hypervisor
observations, device telemetry, or equivalent mechanisms.
Observation alone does not establish finality enforcement unless the
applicable implementation also provides an effective blocking or
authorization mechanism.
7.3.21. S-3.5 - Representative Deployment Arrangement
In a representative implementation, an agent container executes
untrusted or restricted AIgenerated code.
The container does not directly possess unrestricted host credentials
or access to all effectcapable resources.
A controlled interface carries tool requests from the container to a
host-side service.
Das Expires 25 April 2027 [Page 164]
Internet-Draft Sandbox Credential Egress Finality October 2026
The host-side service associates each request with an authenticated
container context.
If a request concerns a governed consequential effect, it is
represented as a Candidate Act and placed in a Non-Effective State.
The PED evaluates the relevant authority predicates.
Following successful validation, the PED commits protected validation
evidence and establishes scoped finality authorization.
The Finality Sink independently verifies the actual operation being
performed and the applicable protected authorization state.
Only the authorized effect is permitted.
A representative logical execution sequence is:
7.3.22. Agent Container → Controlled Tool or Network Interface →
Candidate Act Staging →
7.3.23. PED Validation → Protected Evidence → Scoped Finality
Capability → Finality Sink Verification → External Resource
The protected operation registry and lifecycle controller maintain
state independently of the agent container where required.
7.3.24. PART II - CONTAINER ISOLATION
7.3.25. S-3.6 - Operating-System Namespace Isolation
The container runtime may establish one or more namespace
restrictions.
Examples include:
Mount namespace: Limits the filesystem hierarchy visible to the
container.
PID namespace: Separates selected process identifiers and process-
tree visibility.
Network namespace: Provides a separately configured network stack or
network interface
view.
Das Expires 25 April 2027 [Page 165]
Internet-Draft Sandbox Credential Egress Finality October 2026
User namespace: Maps user and group identifiers between container and
host contexts.
IPC namespace: Separates selected interprocess communication
resources.
UTS namespace: Separates selected hostname and domain-name
configuration.
Cgroup namespace: Provides a scoped view of applicable control-group
structures.
Time namespace: Provides selected time-namespace separation where
supported.
Not every operating system or deployment supports every listed
namespace.
A namespace restricts the visibility or interpretation of particular
kernel-managed resources. It does not, by itself, establish that
every accessible operation is authorized for the agent's assigned
task.
7.3.26. S-3.6.1 - Host context and container context
The system distinguishes between:
(a) the container's self-reported identifiers; (b) identifiers
visible inside the container; (c) identifiers assigned by the
container runtime; and (d) authenticated host-side context
identifying the actual workload.
Where authorization depends on originating identity, a protected
component uses a trusted or authenticated context representation
rather than relying exclusively on guest-controlled labels.
7.3.27. S-3.7 - Control-Group Resource Restrictions
The runtime may associate the agent container with one or more
control groups.
Control-group configuration may impose resource restrictions,
accounting, or scheduling controls relating to CPU, memory, process
count, I/O, or other supported resource classes.
These mechanisms can limit resource consumption or availability.
Das Expires 25 April 2027 [Page 166]
Internet-Draft Sandbox Credential Egress Finality October 2026
However, a resource budget does not independently determine whether
an agent is authorized to send a particular message, modify a
specified database record, disclose selected information, or invoke a
privileged credential.
Accordingly, control-group restrictions may operate as one layer of
confinement while the protected execution-finality mechanism
separately governs specified consequential operations.
7.3.28. S-3.7.1 - Resource exhaustion
Where the agent consumes excessive CPU, memory, process capacity, or
I/O resources, the runtime may terminate or restrict the container.
Outstanding consequential operations are handled through their own
authorization and lifecycle state rather than being assumed canceled
merely because the container has stopped.
7.3.29. S-3.8 - Linux Capabilities and Privilege Restrictions
The container runtime may restrict Linux capabilities available to
agent-controlled processes.
The runtime may also configure:
| x | Non-root execution where applicable. |
| - | ------------------------------------------------ |
| x | User-namespace remapping. |
| x | Restrictions on acquiring additional privileges. |
| x | Read-only filesystem regions. |
| x | Restricted mount operations. |
| x | Prohibition or control of privileged devices. |
| x | Restrictions on host process inspection. |
| x | Controlled access to kernel and host interfaces. |
A container process executing as root within a restricted user
namespace does not necessarily possess unrestricted host authority.
Conversely, a privileged container configuration or excessive device
and filesystem exposure may defeat important isolation assumptions.
The protected-finality implementation must therefore evaluate the
actual confinement configuration rather than assume that the use of a
container automatically supplies adequate isolation.
Das Expires 25 April 2027 [Page 167]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.30. S-3.9 - Seccomp System-Call Restrictions
A container may employ seccomp filtering to restrict selected system
calls or system-call argument patterns supported by the
implementation.
A seccomp policy may allow, deny, log, trap, or otherwise control
specified system-call classes according to supported kernel
mechanisms.
For example, the policy may restrict selected process-creation,
namespace, mount, debugging, or privileged kernel operations.
However, a system-call filter does not generally interpret arbitrary
application-level semantics.
Permitting a write operation, socket operation, or service call does
not necessarily establish that the content, recipient, business
transaction, or downstream resource effect is authorized.
Consequently, operation-specific finality may require an additional
protected resource interface or application-aware enforcement
component.
7.3.31. S-3.9.1 - Seccomp notification variation
Where supported, a seccomp user-notification mechanism may be used to
mediate selected system calls.
Such mediation must account for possible changes in untrusted process
memory or execution state between notification, inspection, and
operation completion.
Where an effect depends upon mutable application data, the design
must use an appropriate stable representation or separately
controlled effectuation mechanism.
System-call notification alone does not guarantee semantic
authorization of all downstream resource operations.
7.3.32. S-3.10 - Linux Security Modules
The system may employ an operating-system security mechanism
implementing mandatory access control or kernel-level access
mediation.
Such mechanisms may restrict access to:
Das Expires 25 April 2027 [Page 168]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | Files and directories. |
| - | ------------------------- |
| x | Processes. |
| x | Memory-related resources. |
| x | Network operations. |
| x | Executable objects. |
| x | Device interfaces. |
| - | -------------------------------------- |
| x | Interprocess communication. |
| x | Privileged operating-system functions. |
A security policy may be associated with the container, workload
identity, process label, or another enforced security context.
The policy may prohibit operations that would bypass designated
protected effectuation interfaces.
7.3.33. S-3.10.1 - Relationship to finality
An LSM-controlled operation may be one stage of protected finality
enforcement where it actually controls the relevant effectuation path
and implements or enforces the required decision.
However, a generic LSM allow or deny result is not automatically
equivalent to the protected validation-evidence, scoped capability,
and Finality Sink sequence required by certain independent
enforcement points.
A specific implementation must establish those relationships where
claimed.
7.3.34. S-3.11 - eBPF-Based Observation and Enforcement
The system may employ eBPF programs or equivalent operating-system
instrumentation to obtain machine-readable observations of container-
related execution behavior.
Possible observations include:
(a) process execution; (b) selected file operations; (c) network
connection attempts; (d) socket activity; (e) process identity or
execution-context changes; (f) tool-worker process ancestry; (g)
resource-access events; and (h) security-relevant state transitions.
Depending on the selected attachment point, kernel version,
permissions, and program type, eBPF may support observation or
specific enforcement actions.
Das Expires 25 April 2027 [Page 169]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.35. S-3.11.1 - Observational eBPF
An observational program may record an event or update a monitoring
state without preventing the underlying operation.
Such an observer may provide behavioral evidence or risk signals.
It does not itself constitute a non-bypassable effectuation
controller for operations it cannot block.
7.3.36. S-3.11.2 - Enforcement-capable eBPF
An enforcement-capable program may participate in a supported kernel
control path, such as an applicable LSM or network enforcement hook.
The implementation must identify the exact operation it controls, the
security decision supplied, and the conditions under which the
operation can still proceed through other routes.
7.3.37. S-3.11.3 - Observation-to-authority separation
In a representative embodiment, eBPF-derived observations contribute
to the RBD or risk state.
The PED evaluates the required protected authorization predicates.
The Finality Sink separately verifies the authorization for the
actual consequential operation.
Thus, detection of suspicious behavior, protected validation of
authority, and effectuation enforcement remain distinguishable
technical operations.
7.3.38. PART III - CONTAINER CONTEXT AND OPERATION IDENTITY
7.3.39. S-3.12 - Container Execution Context
Each governed container is associated with an authenticated
execution-context record.
A representative record comprises:
ContainerInstanceID = CONT-0042
ContainerGeneration = 310
AgentContextID = AGENT-42
Das Expires 25 April 2027 [Page 170]
Internet-Draft Sandbox Credential Egress Finality October 2026
TaskID = TASK-204
ContainerImageReference = IMAGE-DIGEST-17
IsolationProfile = PROFILE-C3
AuthorityGeneration = 105
PermittedConnectorClasses = CLASS-A, CLASS-B
LifecycleStatus = RUNNING
The strings are illustrative.
The execution generation distinguishes the current container instance
from previously terminated or restored instances.
An image digest may contribute to policy evaluation but does not
independently establish that runtime behavior or requested operations
are authorized.
7.3.40. S-3.13 - Authenticated Origin Binding
When a request reaches a host-side enforcement interface, the system
determines its originating container context.
Depending on the interface, the origin may be established through:
1. Runtime-maintained container identity. 2. Host-controlled IPC
endpoint registration. 3. Peer credentials and their host-side
namespace interpretation. 4. Protected workload identity. 5. Host-
controlled service-connection state. 6. Kernel-derived process or
cgroup association. 7. Cryptographically authenticated workload
context. 8. Hardware or hypervisor attestation where applicable.
The selected method must address identity reuse, process migration,
namespace interpretation, stale connections, and other relevant
attack conditions.
An agent-controlled header or request field claiming a particular
container identity does not alone establish that identity.
7.3.41. S-3.14 - Container Generation
A Container Generation represents a lifecycle-specific identity
associated with an instance of a containerized workload.
A new generation may be assigned when a container is:
Das Expires 25 April 2027 [Page 171]
Internet-Draft Sandbox Credential Egress Finality October 2026
x Created.
| x | Recreated. |
| - | ------------------------------------------- |
| x | Restored from a checkpoint. |
| x | Reassigned to a different security context. |
| x | Recovered following a failure. |
| x | Replaced by a new worker. |
A generation may comprise a monotonic counter, unpredictable creation
identifier, cryptographically bound identity, or another non-
confusable value.
Where authority is bound to a generation, a capability associated
with an earlier generation is not automatically valid for a
replacement container.
7.3.42. PART IV - HOST-SIDE TOOL DISPATCH AND CONNECTOR MEDIATION
7.3.43. S-3.15 - Controlled Tool Interface
The agent container may access external functionality through one or
more controlled tool interfaces.
A tool interface may be implemented through:
(a) Unix-domain IPC; (b) a virtual or local socket; (c) HTTP or RPC;
(d) a host-side tool service; (e) an application gateway; (f) a
message queue; (g) a controlled shared-memory interface; (h) a
connector protocol; or (i) an equivalent structured operation-
dispatch mechanism.
The interface may receive operations to read data, modify resources,
invoke external services, use credentials, or perform other
consequential actions.
7.3.44. S-3.15.1 - Tool request representation
A representative request may include:
ToolRequestID
RequestedTool
OperationClass
TargetResource
Das Expires 25 April 2027 [Page 172]
Internet-Draft Sandbox Credential Egress Finality October 2026
OperationArguments
TaskReference
PayloadReference
OptionalDelegationContext
The host associates the request with its independently established
origin identity.
The requester cannot acquire additional authority merely by placing a
privileged identity or policy label within the request body.
7.3.45. S-3.16 - Host-Side Connector
A Host-Side Connector performs operations using host-controlled
resources or credentials.
For example, a connector may:
1. Access an enterprise application. 2. Query a database. 3. Send
an authorized message. 4. Modify a cloud resource. 5. Operate a
source-control repository. 6. Invoke a financial service. 7. Use a
protected credential. 8. Perform a browser-based action.
The connector may possess privileges not directly available to the
container.
This privilege separation makes the connector a security-relevant
effectuation interface.
7.3.46. S-3.16.1 - Connector authority limitation
The connector does not treat every syntactically valid request from
the agent container as authorized.
Instead, it performs or is subject to the required authorization
procedure before the governed consequential operation.
Where protected execution finality is claimed, the connector or its
downstream interface must satisfy the required Finality Sink
verification relationship.
7.3.47. S-3.16.2 - Connector transformation
A logical tool request may be transformed into:
Das Expires 25 April 2027 [Page 173]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | A different HTTP method. |
| - | ----------------------------------- |
| x | A concrete API path. |
| x | A different payload encoding. |
| x | Multiple downstream requests. |
| x | A database transaction. |
| x | A credential-bearing request. |
| x | A queued or asynchronous operation. |
If the transformed operation materially changes the consequential
effect, the system must ensure that the actual effect is covered by
the applicable authorization.
Authorization of an abstract tool name is not necessarily
authorization of every possible concrete operation performed by that
tool.
7.3.48. S-3.17 - Tool-Dispatch Candidate Act
When the agent requests a governed tool operation, the host-side
dispatcher establishes a Candidate Act.
A representative descriptor includes:
CandidateActID = CA-0301
ContainerGeneration = 310
AgentContextID = AGENT-42
ToolID = TOOL-ENTERPRISE-07
OperationClass = MODIFY_RESOURCE
TargetResource = RESOURCE-204
ArgumentsDigest = DIGEST-0301
AuthorityGeneration = 105
FinalitySinkID = FS-TOOL-03
Status = STAGED
The requested operation is not yet dispatched to the effect-capable
resource.
Das Expires 25 April 2027 [Page 174]
Internet-Draft Sandbox Credential Egress Finality October 2026
The dispatcher may retain an immutable or integrity-protected copy of
the material operation fields.
7.3.49. PART V - NON-EFFECTIVE STAGING
7.3.50. S-3.18 - Candidate Act Holding
The staging mechanism holds a governed operation before its
consequential effect.
A staged operation may be represented by:
| x | A pending tool invocation. |
| - | ------------------------------------------------ |
| x | A buffered network request. |
| x | A prepared but uncommitted database transaction. |
| x | A queued resource-modification request. |
| x | A withheld credential-use request. |
| x | A disabled hardware command. |
| x | A staged file mutation. |
The staging mechanism may reside outside the agent container.
Where the agent controls the underlying request memory, the system
uses a protected copy or independently revalidates the actual
material operation fields at final effectuation.
7.3.51. S-3.18.1 - Shared-memory safety
A high-throughput container deployment may transport requests using
shared-memory rings or buffers.
If the container can modify a buffer after authorization, the
enforcement component must not assume that earlier validation still
describes the buffer's contents.
A representative implementation uses one or more of:
(a) copying material fields into protected host memory; (b) memory
ownership transfer; (c) controlled immutable buffer mapping; (d)
content-addressed immutable storage; (e) atomic snapshot
construction; or (f) fresh verification at the final controlled
dispatch interface.
The implementation must address time-of-check/time-of-use changes.
Das Expires 25 April 2027 [Page 175]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.52. S-3.19 - Canonical Operation Descriptor
A descriptor may identify:
1. Candidate Act identity. 2. Originating container generation. 3.
Agent and task context. 4. Operation class. 5. Actual intended
resource. 6. Effective operation parameters. 7. Relevant payload
representation. 8. Requested authority scope. 9. Policy generation.
10. Destination or connector identity. 11. Finality Sink identity.
12. Expiration or freshness information. 13. Replay-control
information. 14. Canonicalization version.
A deterministic encoding is selected for comparisons and
cryptographic bindings.
Where paths or resource identifiers are used, the system must define
whether authorization refers to a logical path, resolved object
identity, opened file descriptor, remote resource identifier, or
another effective target.
7.3.53. PART VI - PROTECTED AUTHORIZATION
7.3.54. S-3.20 - Protected Enforcement Domain
The PED may operate in a host security service, isolated process,
hardened virtual machine, hypervisor domain, trusted execution
environment, hardware security module, secure controller, or other
implementation satisfying the required protection properties.
In a representative software-only implementation, the PED executes
outside the agentcontrolled container and relies on the integrity of
the host operating system and protected host services.
In a hardware-assisted implementation, selected protected functions
may be placed in a TEE, HSM, secure coprocessor, or protected device.
The security guarantee depends upon the actual protection against the
defined adversary.
7.3.55. S-3.20.1 - Authorization predicates
The PED may evaluate:
Das Expires 25 April 2027 [Page 176]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | Authenticated container identity. |
| - | ----------------------------------- |
| x | Agent identity. |
| x | Assigned task. |
| x | Delegated authority. |
| x | Requested operation class. |
| x | Resource identity. |
| x | Tool or connector scope. |
| x | Requested destination. |
| x | Protected policy generation. |
| x | Applicable revocation state. |
| x | Human authorization where required. |
| x | Credential-use restrictions. |
| x | Data classification. |
| x | Usage quota. |
| x | Runtime behavioral restrictions. |
| x | Freshness constraints. |
| x | Resource-state preconditions. |
Only the predicates required by the applicable enforcement point and
selected policy must be mandatory for a particular operation.
7.3.56. S-3.21 - Protected Validation Evidence
Following successful validation, the PED commits a protected evidence
record.
A representative record comprises:
EvidenceID = VE-0301
CandidateActID = CA-0301
ValidatedDescriptorDigest = DIGEST-0301
PEDIdentity = PED-HOST-01
PolicyGeneration = 105
ValidationResult = APPROVED
AuthorizedSinkID = FS-TOOL-03
EvidenceGeneration = 804
The evidence may be implemented using:
Das Expires 25 April 2027 [Page 177]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. A protected registry entry. 2. A cryptographically signed
receipt. 3. A message-authenticated validation record.
4. A protected transactional update. 5. A sealed-state commitment.
6. A hardware-backed record. 7. A combination of the foregoing.
An ordinary audit entry generated after unrestricted execution does
not automatically satisfy a enforcement point requiring protected
evidence commitment before finality enablement.
7.3.57. S-3.22 - Scoped Non-Bearer Finality Capability
The PED establishes a capability bound to the validated operation and
authorized effectuation boundary.
A representative capability includes:
CapabilityID = CAP-0301
CandidateActID = CA-0301
EvidenceReference = VE-0301
DescriptorDigest = DIGEST-0301
AuthorizedSink = FS-TOOL-03
AuthorizedResource = RESOURCE-204
PolicyGeneration = 105
UsagePolicy = SINGLE_USE
CapabilityStatus = ACTIVE
The capability may be maintained as protected state rather than
transmitted as a portable bearer token.
An agent-controlled process cannot convert possession of an ordinary
operation identifier into additional authorization without satisfying
the protected enforcement conditions.
7.3.58. S-3.22.1 - Container-independent capability custody
In one implementation, the capability remains entirely within
protected host or device state.
The container receives only an operation reference.
Das Expires 25 April 2027 [Page 178]
Internet-Draft Sandbox Credential Egress Finality October 2026
The reference may identify a pending task but does not constitute
independent authority to execute arbitrary effects.
7.3.59. PART VII - FINALITY SINK ENFORCEMENT
7.3.60. S-3.23 - Host-Side Tool Finality Sink
A host-side connector may act as the Finality Sink for a particular
governed operation when it has effective control over the
corresponding resource effectuation.
The sink obtains the actual operation parameters from the controlled
dispatch representation.
It verifies that the operation corresponds to the protected
authorization.
7.3.61. S-3.23.1 - Required verification
The sink may verify:
(a) capability existence; (b) authorized PED origin; (c) valid
protected evidence; (d) descriptor correspondence; (e) resource
scope; (f) actual destination; (g) policy generation; (h) revocation
state; (i) validity period; (j) usage or replay constraints; (k) sink
identity; and (l) protected sink-local state.
The sink denies effectuation when a required verification fails.
7.3.62. S-3.24 - Sink-Local Protected State
A representative sink-local state record contains:
SinkID
CandidateActID
CapabilityID
ExpectedDescriptorDigest
AuthorizedResource
PolicyGeneration
ConsumptionStatus
DispatchStatus
Das Expires 25 April 2027 [Page 179]
Internet-Draft Sandbox Credential Egress Finality October 2026
ExternalOperationID
CompletionStatus
A single-use capability may transition:
UNUSED → RESERVED → CONSUMED
The implementation may distinguish an operation authorization being
consumed from the external operation being completed.
An external operation may be dispatched but have an uncertain
outcome.
The sink must not blindly regenerate a new authorization and repeat
the operation merely because a response was lost.
7.3.63. PART VIII - NETWORK EGRESS FINALITY
7.3.64. S-3.25 - Container Network Architecture
A container may possess a network namespace containing one or more
virtual network interfaces.
Those interfaces may connect through virtual Ethernet devices, host
networking stacks, bridges, routing tables, proxies, or network
security controls.
A protected egress implementation may place the controlled
effectuation interface at:
1. A host-side network proxy. 2. A restricted application gateway.
3. A controlled network namespace boundary. 4. An applicable kernel
enforcement hook. 5. A protected packet-forwarding mechanism. 6. A
SmartNIC or DPU.
7. A remote egress gateway.
The selected interface must control the governed network effect
according to the relevant enforcement point.
7.3.65. S-3.26 - Network Candidate Act Descriptor
A representative network Candidate Act Descriptor includes:
CandidateActID
OriginContainerGeneration
Das Expires 25 April 2027 [Page 180]
Internet-Draft Sandbox Credential Egress Finality October 2026
AgentContextID
Protocol
RequestedHostname
EffectiveDestinationAddress
DestinationPort
ApplicationMethod
ResourcePath
PayloadDigest
CredentialUseReference
PolicyGeneration
AuthorizedEgressSink
The actual fields depend on the network protocol and the effect being
governed.
Where address resolution occurs after initial authorization, the
implementation may require validation of the effective resolved
address or other target identity.
7.3.66. S-3.26.1 - Destination identity
A requested hostname and the actual remote endpoint are not always
equivalent.
A destination policy may therefore consider:
x Requested hostname. x Resolved address.
| x | Final connected address. |
| - | --------------------------------- |
| x | Transport protocol. |
| x | Port. |
| x | Application destination. |
| x | TLS peer identity where relevant. |
| x | Redirected destination. |
| x | Proxy routing state. |
Das Expires 25 April 2027 [Page 181]
Internet-Draft Sandbox Credential Egress Finality October 2026
The implementation must define which properties are required for
authorization.
7.3.67. S-3.27 - Network Effectuation Workflow
A representative workflow proceeds as follows.
Step N1: The container generates a network operation.
Step N2: The operation reaches a controlled interception interface.
Step N3: The network request is staged or prevented from
transmission.
Step N4: The host obtains the authenticated source-container context.
Step N5: The effective request descriptor is constructed.
Step N6: The PED evaluates relevant authorization predicates.
Step N7: Required protected validation evidence is committed.
Step N8: A scoped non-bearer finality capability is established.
Step N9: The egress Finality Sink obtains the actual operation being
transmitted.
Step N10: The sink verifies destination, protocol, resource scope,
payload properties,
capability bindings, and applicable sink-local state.
Step N11: The sink permits the authorized network effect.
Step N12: The operation outcome and protected state are updated.
The system may perform additional checks following DNS resolution,
connection establishment, redirection, or application-layer
transformation when such checks are necessary to enforce the claimed
destination or effect binding.
7.3.68. S-3.27.1 - Encrypted application traffic
When the governed authorization concerns application-layer fields
inside encrypted traffic, the Finality Sink must have access to an
appropriately trusted representation of those fields.
Possible implementations include:
Das Expires 25 April 2027 [Page 182]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) validation before encryption in a trusted connector; (b) a
protected application-level proxy; (c) a trusted endpoint performing
authorized request construction;
(d) a securely bound application request descriptor; or
(e) an arrangement in which the authorized operation is constructed
and transmitted by the protected interface itself.
Merely inspecting encrypted packets without access to the relevant
plaintext or authenticated request metadata may be insufficient to
verify application-specific fields such as HTTP path or body.
7.3.69. PART IX - CREDENTIAL ISOLATION AND RELEASE
7.3.70. S-3.28 - Credential Broker
A Credential Broker maintains or controls access to credentials used
by external tools or services.
The broker may manage:
| x | OAuth access tokens. |
| - | ------------------------------------- |
| x | API credentials. |
| x | Client certificates. |
| x | Signing keys. |
| x | Service-account credentials. |
| x | Short-lived authentication artifacts. |
| x | Protected key-use operations. |
| x | Privileged service sessions. |
The container need not receive the underlying reusable credential.
Instead, it may request an authorized operation through a controlled
interface.
7.3.71. S-3.28.1 - Credential-use distinction
Possession of a credential and authorization to perform a particular
transaction are distinguishable.
A broker may possess a credential capable of authenticating to a
service while the current agent task is authorized to perform only a
subset of the operations available through that credential.
Das Expires 25 April 2027 [Page 183]
Internet-Draft Sandbox Credential Egress Finality October 2026
The protected authorization procedure may therefore bind permitted
credential use to the specific operation, target service, resource,
and applicable scope.
7.3.72. S-3.29 - Surrogate Credential Variation
In one implementation, the container receives a surrogate credential
or non-authoritative reference.
The surrogate may identify an intended service or execution context
without being accepted by the destination service as a complete
privileged credential.
A host-side broker maps the surrogate to a protected credential
according to the applicable authorization policy.
Where the embodiment employs protected-finality controls, the broker
does not release or use the real credential for the governed
operation until the required protected authorization condition has
been established and the effectuation controller verifies the
permitted operation.
7.3.73. S-3.29.1 - Post-transformation verification
A connector may construct a concrete outbound request and insert or
apply a real credential.
The finality mechanism may verify the actual outbound request after
material request construction and before transmission.
This prevents authorization of an abstract operation from silently
authorizing a materially different credential-bearing request.
7.3.74. S-3.29.2 - Credential non-disclosure
Where the architecture requires the reusable credential to remain
outside the agent container, the credential broker must prevent
disclosure through:
| x | Tool responses. |
| - | ---------------------------------- |
| x | Error messages. |
| x | Diagnostic logs. |
| x | Shared memory. |
| x | Filesystem mounts. |
| x | Environment variables. |
| x | Process inspection. |
| x | Uncontrolled debugging interfaces. |
Das Expires 25 April 2027 [Page 184]
Internet-Draft Sandbox Credential Egress Finality October 2026
The applicable implementation must address these exposure channels in
accordance with its stated threat model.
7.3.75. PART X - FILE, STORAGE, AND IPC EFFECTUATION
7.3.76. S-3.30 - File-System Effectuation
A container may receive access to bind mounts, overlay filesystems,
persistent volumes, temporary filesystems, or other storage
resources.
A file write may be consequential when it changes persistent data,
modifies executable configuration, affects another workload, or
exposes information through a shared resource.
A protected file-effectuation embodiment may intercept or control:
(a) creation; (b) modification; (c) deletion; (d) rename; (e)
metadata changes; (f) persistent commit; or (g) transfer into another
security domain.
The Finality Sink may reside in a controlled storage service, a
filesystem mediation layer, a protected commit service, or a
hardware-backed storage controller.
7.3.77. S-3.30.1 - File object correspondence
The implementation must distinguish between textual path
authorization and authorization of the actual object modified.
Relevant issues may include symbolic links, hard links, bind mounts,
path traversal, mount changes, file-descriptor reuse, and resource
replacement.
Where an authorization depends on object identity, the finality
mechanism should bind the actual selected object or an appropriately
protected object reference.
7.3.78. S-3.31 - Unix-Domain Sockets and IPC
A container may communicate with host services through Unix-domain
sockets or other IPC mechanisms.
The service may possess permissions or resources exceeding those
available to the container.
IPC mediation may therefore include:
Das Expires 25 April 2027 [Page 185]
Internet-Draft Sandbox Credential Egress Finality October 2026
x Authenticated peer context.
| x | Operation classification. |
| - | ---------------------------- |
| x | Resource-scope verification. |
| x | Protected authorization. |
| x | Actual operation comparison. |
| x | Finality Sink enforcement. |
7.3.79. S-3.31.1 - File-descriptor passing
Where supported by the operating system, a process may receive an
existing file descriptor through an IPC channel.
A passed file descriptor may confer access to a resource that would
otherwise be inaccessible through path-based authorization.
Accordingly, an anti-bypass implementation must account for
inherited, duplicated, received, and previously opened descriptors
capable of producing the governed effect.
A filesystem or socket pathname restriction alone may not control all
operations performed through an already authorized descriptor.
7.3.80. S-3.32 - Database and Persistent Resource Commit
An agent may request a database or persistent-service operation
through a connector.
The controlled operation may include:
| x | Insertion. |
| - | ---------------------------- |
| x | Update. |
| x | Deletion. |
| x | Transaction commit. |
| x | Permission modification. |
| x | Resource creation. |
| x | Configuration mutation. |
| x | Asynchronous job submission. |
A database-oriented Finality Sink may enforce operation-specific
authorization immediately before the relevant commit or resource
mutation.
Where a resource-state precondition is required, it may be
implemented through a transaction version, conditional write,
compare-and-update procedure, or equivalent protected mechanism.
Das Expires 25 April 2027 [Page 186]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.81. PART XI - CONTAINER LIFECYCLE AND ASYNCHRONOUS OPERATIONS
7.3.82. S-3.33 - Container Lifecycle States
A representative container lifecycle comprises:
CREATED → CONFIGURED → RUNNING → STOPPING → TERMINATED
Additional states may include:
PAUSED
RESTARTING
FAILED
CHECKPOINTED
RESTORED
The lifecycle may be managed by an operating-system runtime,
container orchestration service, or host execution controller.
The system separates container lifecycle state from the lifecycle of
its outstanding consequential operations.
7.3.83. S-3.34 - Container Termination
When a container terminates, the protected operation registry
identifies pending operations associated with that container.
The system determines whether each operation:
1. Has completed. 2. Remains staged. 3. Has been authorized but
not dispatched. 4. Has been dispatched. 5. Has an uncertain
external outcome. 6. Is cancelable. 7. Is independently authorized
for continuation.
The continuation decision is made according to protected authority
and task-state rules.
Container termination does not prove that a previously dispatched
operation had no external effect.
7.3.84. S-3.35 - Container Restart and Generation Change
A restarted or recreated container receives a new execution
generation where required by the lifecycle policy.
Das Expires 25 April 2027 [Page 187]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system verifies any outstanding operations before permitting the
replacement container to continue them.
Previously consumed authorizations remain consumed.
Capabilities associated with a prior generation are invalidated or
revalidated according to their defined continuation conditions.
A restored container does not regain authority merely because its
local filesystem or memory contains a prior authorization reference.
7.3.85. S-3.36 - Asynchronous Tool Worker
A host connector may dispatch an operation to an asynchronous worker
or message queue.
The worker may execute after the originating container has
terminated.
In an implementation requiring finality enforcement, the worker or
its downstream effectuation controller must satisfy the applicable
protected authorization requirements when the actual operation is
performed.
A protected authorization may be task-bound and survive the container
lifecycle only when the corresponding continuation policy permits it.
An agent container cannot unilaterally authorize future effectuation
simply by placing a job in an external queue.
7.3.86. PART XII - SUCCESSFUL EXECUTION WORKFLOW
7.3.87. S-3.37 - Principal 20-Step Workflow
A representative successful execution proceeds as follows.
7.3.88. Step S3-01 - Container creation
The container runtime creates a restricted agent execution
environment.
7.3.89. Step S3-02 - Isolation configuration
The runtime applies namespace, control-group, privilege, system-call,
filesystem, network, and other relevant restrictions.
Das Expires 25 April 2027 [Page 188]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.90. Step S3-03 - Enforcement-path configuration
The host establishes the controlled interfaces required for governed
consequential operations.
7.3.91. Step S3-04 - Execution identity assignment
The host associates the container with an execution generation, agent
identity, task identity, and applicable authority context.
7.3.92. Step S3-05 - Agent execution
The agent performs computation within the container.
7.3.93. Step S3-06 - Consequential operation proposal
The agent generates a tool, network, file, credential, storage, or
other governed operation.
7.3.94. Step S3-07 - Boundary interception
The operation reaches the corresponding controlled interface.
7.3.95. Step S3-08 - Authenticated origin determination
The host identifies the actual originating execution context.
7.3.96. Step S3-09 - Candidate Act creation
The operation is assigned a Candidate Act identity.
7.3.97. Step S3-10 - Non-effective staging
The operation is held without producing the governed consequential
effect.
7.3.98. Step S3-11 - Descriptor construction
A canonical descriptor is produced using the material operation
fields and authenticated context.
7.3.99. Step S3-12 - PED submission
The descriptor is submitted to the protected authorization mechanism.
Das Expires 25 April 2027 [Page 189]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.100. Step S3-13 - Protected predicate evaluation
The PED evaluates the applicable identity, scope, resource, policy,
freshness, and other required conditions.
7.3.101. Step S3-14 - Protected evidence commitment
The PED commits the required validation evidence.
7.3.102. Step S3-15 - Scoped finality authorization
The PED establishes the applicable bounded non-bearer authorization
condition.
7.3.103. Step S3-16 - Sink-side actual-operation reconstruction
The Finality Sink obtains the actual operation from its controlled
effectuation representation.
7.3.104. Step S3-17 - Finality verification
The sink verifies the required evidence, capability, descriptor
correspondence, current authority state, and usage conditions.
7.3.105. Step S3-18 - Protected authorization-state transition
The sink reserves or consumes the bounded authorization according to
the required atomic state-transition procedure.
7.3.106. Step S3-19 - Consequential effectuation
The authorized operation is executed through the controlled
effectuation interface.
7.3.107. Step S3-20 - Completion and reconciliation
The operation outcome and corresponding protected states are recorded
and reconciled.
The procedure may be adapted to different resource classes, provided
the actual security properties required by the applicable enforcement
point are maintained.
Das Expires 25 April 2027 [Page 190]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.108. PART XIII - REFERENCE PSEUDOCODE
7.3.109. S-3.38 - Algorithm A: Container Registration
function RegisterAgentContainer(runtime_handle, task, profile):
context = AuthenticateRuntimeContext(runtime_handle)
if context is invalid:
return DENIED
generation = AllocateProtectedGeneration()
ApplyIsolationProfile(context, profile)
if not VerifyRequiredIsolationControls(context, profile):
return DENIED if not VerifyGovernedEffectPaths(context):
return DENIED
record = {
container_id: context.container_id,
container_generation: generation, agent_id: task.agent_id, task_id:
task.id, isolation_profile: profile.id, authority_generation:
CurrentAuthorityGeneration(task), lifecycle_status: RUNNING }
ProtectedContextRegistry.register(record)
return record
The required isolation and effect-path checks must be specified for
the selected container platform. A routine that merely returns
success without testing the configured restrictions does not
establish the corresponding protection property.
7.3.110. S-3.39 - Algorithm B: Tool Request Interception
function InterceptToolRequest(channel, request):
context = AuthenticateContainerOrigin(channel)
if context is invalid:
return DENIED
Das Expires 25 April 2027 [Page 191]
Internet-Draft Sandbox Credential Egress Finality October 2026
if not IsCurrentContainerGeneration(context):
return DENIED
operation = ConstructControlledOperationSnapshot(request)
if not IsGovernedOperation(operation):
return ProcessUnderApplicableOrdinaryPolicy(operation)
candidate_id = AllocateCandidateActID()
descriptor = Canonicalize({
candidate_id: candidate_id, origin_context: context, operation:
operation, authority_generation: CurrentAuthorityGeneration(context),
intended_sink: ResolveRequiredSink(operation) })
ProtectedOperationRegistry.stage(
candidate_id, operation, descriptor )
return PED.Validate(candidate_id, descriptor)
This procedure must be combined with actual blocking of the governed
effectuation path.
Merely recording the operation in the registry while allowing
immediate execution would not establish a Non-Effective State.
S-3.40 - Algorithm C: Protected Validation and Capability
function ValidateContainerCandidate(candidate_id, descriptor):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != STAGED:
return DENIED
if not VerifyAuthenticatedOrigin(descriptor, record):
return DENIED
if not VerifyCurrentAuthorityGeneration(descriptor):
return DENIED
Das Expires 25 April 2027 [Page 192]
Internet-Draft Sandbox Credential Egress Finality October 2026
authority = ProtectedAuthorityRegistry.lookup(descriptor)
if not EvaluateRequiredPredicates(descriptor, authority):
ProtectedOperationRegistry.deny(candidate_id) return DENIED
evidence = CommitProtectedValidationEvidence(
candidate_id, descriptor, authority )
capability = EstablishScopedNonBearerCapability({
candidate_id: candidate_id, evidence_reference: evidence.id,
descriptor_digest: Hash(descriptor), permitted_sink:
descriptor.intended_sink, permitted_scope: authority.approved_scope,
authority_generation: authority.generation })
if not AtomicallyActivateAuthorization(
candidate_id, evidence.id, capability.id
):
RevokeOrDisableCapability(capability.id) return DENIED
return AUTHORIZED
The protected implementation must define the transaction ordering and
recovery behavior governing evidence creation, capability
establishment, and activation.
7.3.111. S-3.41 - Algorithm D: Finality Sink Verification
function ExecuteAtFinalitySink(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED
actual_operation = ObtainActualPendingOperation(candidate_id)
if actual_operation is unavailable:
return DENIED
descriptor = CanonicalizeActualOperation(actual_operation)
Das Expires 25 April 2027 [Page 193]
Internet-Draft Sandbox Credential Egress Finality October 2026
evidence = ProtectedEvidenceRegistry.get(record.evidence_id)
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
if not VerifyProtectedEvidence(evidence):
return DENIED if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED
if not VerifyActualOperationBinding(
descriptor, capability ):
return DENIED if not VerifyCurrentAuthorityAndRevocation(capability):
return DENIED
if not VerifySinkLocalState(capability):
return DENIED
if not AtomicallyReserveAuthorization(capability):
return DENIED
result = DispatchThroughControlledInterface(actual_operation)
ReconcileOperationOutcome(candidate_id, result)
return result
For an external nontransactional resource, the local reservation and
the external effect may not be one atomic transaction.
The implementation must therefore preserve unresolved-outcome state
and define its permitted retry or reconciliation procedure.
S-3.42 - Algorithm E: Container Termination Reconciliation
function TerminateAgentContainer(container_id, generation):
ProtectedContextRegistry.markStopping(
Das Expires 25 April 2027 [Page 194]
Internet-Draft Sandbox Credential Egress Finality October 2026
container_id, generation )
BlockNewGovernedRequests(container_id, generation)
operations = ProtectedOperationRegistry.listByOrigin(
container_id, generation )
for each operation in operations:
if operation.status == COMPLETED:
continue if operation.status in [STAGED, AUTHORIZED]:
if not IsContinuationAuthorized(operation):
CancelOrRevoke(operation)
if operation.status in [RESERVED, DISPATCHED, INDETERMINATE]:
MarkForReconciliation(operation)
ProtectedContextRegistry.revokeGeneration(generation)
ContainerRuntime.stop(container_id)
return TERMINATED
The ordering must ensure that an operation cannot obtain unauthorized
new authority during the transition from RUNNING to STOPPING.
7.3.112. S-3.43 - Algorithm F: Credential-Brokered Dispatch
function ExecuteCredentialBoundOperation(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED operation = ConstructFinalOutboundRequest(record)
if not VerifyProtectedFinalityAuthorization(
candidate_id, operation ):
return DENIED credential_context =
CredentialBroker.resolveAuthorizedUse(
Das Expires 25 April 2027 [Page 195]
Internet-Draft Sandbox Credential Egress Finality October 2026
operation.service_id, operation.authorized_scope )
if credential_context is invalid:
return DENIED result = ControlledDispatchWithCredential(
operation, credential_context )
ReconcileOperationOutcome(candidate_id, result)
return result
In a production implementation, the protected finality verification
and authorization-state reservation must be coordinated with final
request construction and credential use.
The credential must not be exposed to an untrusted operation path
after verification in a manner permitting subsequent unauthorized
modification or reuse.
7.3.113. PART XIV - WORKED EXAMPLES
S-3.44 - Example A: Authorized Repository Modification
The following is a hypothetical implementation example.
An AI coding agent executes within a restricted container.
The agent is assigned a task to update a specific application
configuration file in an enterprise repository.
The container may read and modify permitted local working-copy files
but cannot directly push changes to the protected remote repository.
A host-side repository connector controls remote commits or pushes.
The agent produces a proposed update.
The connector receives the proposed operation and constructs a
Candidate Act identifying:
Das Expires 25 April 2027 [Page 196]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | The repository. |
| - | ---------------------------------------------- |
| x | The branch. |
| x | The affected file. |
| x | The proposed modification. |
| x | The assigned task. |
| x | The applicable authorization generation. |
| x | The intended repository effectuation boundary. |
The PED verifies that the modification remains within the authorized
task and resource scope.
The PED commits the required protected validation evidence and
activates a scoped nonbearer finality capability.
The Finality Sink verifies the actual pending repository operation.
Where a branch or commit-state precondition is required, it is
checked against the current repository state.
Only the authorized operation is submitted.
A subsequent attempt to modify a different repository or branch
requires authorization covering that operation.
S-3.45 - Example B: Unauthorized Data Export Through an Allowed Tool
An agent container is permitted to use an enterprise messaging
connector.
The agent receives untrusted content directing it to export a
confidential document.
The agent constructs a messaging request containing the confidential
document and an unauthorized external recipient.
The request reaches the host-side connector.
The operation is staged.
The PED evaluates the requested recipient and disclosure scope.
The authorization fails.
No scoped finality capability is activated.
The Finality Sink does not transmit the message.
Das Expires 25 April 2027 [Page 197]
Internet-Draft Sandbox Credential Egress Finality October 2026
This example illustrates the distinction between permission to access
a tool and authority to perform a specific operation through that
tool.
7.3.114. S-3.46 - Example C: Host Credential Substitution
An agent is authorized to retrieve a limited report from an external
service.
The container possesses only a surrogate service reference.
The host-side credential broker retains the actual reusable service
credential.
The agent requests the report.
The host-side service constructs the proposed request and stages it.
The PED validates the operation and its permitted resource scope.
Protected evidence is committed.
A bounded finality capability is activated.
The controlled connector constructs the final credential-bearing
request.
The Finality Sink verifies the actual request, destination,
authorization scope, and relevant protected state.
The real credential is applied within the controlled dispatch path.
The authorized request is transmitted without placing the reusable
credential in the agent container.
A request outside the authorized resource scope is denied even if the
credential could otherwise authenticate such an operation.
S-3.47 - Example D: Container Termination During Asynchronous
Execution
The agent requests an authorized cloud resource operation.
The operation is dispatched through a protected connector.
The container terminates before the external service confirms
completion.
Das Expires 25 April 2027 [Page 198]
Internet-Draft Sandbox Credential Egress Finality October 2026
The protected operation registry records the operation as DISPATCHED
or INDETERMINATE.
A replacement container is started.
Before attempting the same operation, the replacement checks the
corresponding protected operation state through the authorized
interface.
The system does not interpret missing guest-local completion state as
proof of non-execution.
The operation is reconciled through an authorized transaction
identifier, service status query, supported idempotency mechanism, or
other defined recovery procedure.
Where the outcome cannot be established, the system retains an
explicit unresolved state rather than claiming exactly-once
effectuation.
7.3.115. PART XV - FAILURE AND ADVERSARIAL SCENARIOS
7.3.116. S-3.48 - Representative Failure Conditions
7.3.117. F1 - Privileged Container Configuration
The container is unintentionally granted excessive host privileges or
device access.
The isolation-verification mechanism detects a configuration
incompatible with the intended trust assumptions.
The system rejects the deployment or restricts the relevant
effectuation paths.
7.3.118. F2 - Namespace Bypass
An agent-controlled process accesses a resource through a permitted
interface that circumvents the intended namespace-based restriction.
The anti-bypass analysis identifies the alternate path and requires
mediation or exclusion.
7.3.119. F3 - Inherited File Descriptor
The container inherits an open descriptor giving access to a
protected resource.
Das Expires 25 April 2027 [Page 199]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system must account for the descriptor as an effect-capable
interface; a later pathname restriction alone may be insufficient.
7.3.120. F4 - Host-Side Connector Abuse
The agent submits a syntactically valid tool request exceeding its
task authority.
Protected authorization rejects the unauthorized effect.
7.3.121. F5 - Credential Disclosure
A connector accidentally returns a privileged credential in an error
response or log.
The credential-isolation mechanism must prevent or constrain
disclosure through the relevant output path.
7.3.122. F6 - DNS Rebinding or Redirected Destination
The effective destination differs from the destination originally
evaluated.
The egress enforcement mechanism performs any required final-target
verification before the governed transmission.
7.3.123. F7 - eBPF Observation Loss
A monitoring mechanism drops events because of buffer overflow,
detachment, or resource exhaustion.
Where the authorization policy depends upon observation coverage, the
corresponding observation state is marked incomplete.
Missing observations are not treated as proof of safe operation.
7.3.124. F8 - Kernel Compromise
An attacker compromises the host kernel underlying a software-only
enforcement arrangement.
The intended software security boundary may be defeated.
Enforcement Points of resistance to this adversary require additional
protection mechanisms, such as suitable hardware-backed isolation and
effectuation control.
Das Expires 25 April 2027 [Page 200]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.125. F9 - Operation Substitution
A connector changes the material operation after validation.
The Finality Sink detects a mismatch or enforces an expressly
permitted transformation envelope.
7.3.126. F10 - Capability Replay
A consumed single-use authorization is presented again.
Protected sink-local state rejects replay.
7.3.127. F11 - Container Restart
A recreated container attempts to reuse a capability associated with
a previous execution generation.
The capability is rejected or subjected to an authorized continuation
procedure.
7.3.128. F12 - Asynchronous Worker Delay
A queued worker attempts effectuation after the originating task has
been revoked.
The protected authorization or continuation policy prevents
unauthorized late execution.
7.3.129. F13 - Shared-Memory Modification
The agent modifies a shared-memory request buffer after validation.
The sink uses a controlled immutable snapshot or revalidates the
actual operation before dispatch.
7.3.130. F14 - Policy-Generation Mismatch
The PED validates an operation under an earlier policy generation
that has since become unacceptable for the effect.
The Finality Sink applies the required current-generation or
revocation check.
7.3.131. F15 - Connector Crash After Possible External Effect
The connector loses connectivity after submitting an operation.
Das Expires 25 April 2027 [Page 201]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system records an indeterminate outcome and performs
reconciliation rather than automatic blind repetition.
7.3.132. F16 - Host Networking Bypass
An alternate interface or host-network configuration permits external
transmission without the protected egress controller.
The deployment fails the non-bypassability condition until the
alternate route is restricted or mediated.
7.3.133. F17 - Symlink or Mount Substitution
The apparent authorized file path resolves to a different effective
storage object.
The enforcement mechanism verifies the intended object or uses a
protected file reference according to the enforcement point-required
binding.
7.3.134. F18 - Container Identity Spoofing
The container sends an IPC request containing another container's
identity.
The host uses authenticated origin context, rather than the untrusted
claimed identifier, for authorization.
7.3.135. PART XVI - SOFTWARE, HARDWARE, AND HYBRID IMPLEMENTATIONS
7.3.136. S-3.49 - Software-Only Container Implementation
The system employs ordinary operating-system containers.
The runtime configures namespaces, control groups, privileges,
system-call filters, filesystem restrictions, and network mediation.
A host-side protected service performs PED validation.
A controlled connector or gateway serves as the Finality Sink.
The security model depends on the integrity of the required host
operating-system components.
7.3.137. S-3.50 - LSM-Based Enforcement Implementation
An applicable Linux Security Module enforces selected resource
restrictions or operationcontrol decisions.
Das Expires 25 April 2027 [Page 202]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system may associate container security contexts with operation
classes or resource policies.
The PED may provide protected authorization state to the enforcement
mechanism.
Where the LSM interface serves as or controls a Finality Sink, it
must perform the required enforcement point-specific validation or
enforce the result through a non-bypassable technical relationship.
7.3.138. S-3.51 - eBPF-Assisted Implementation
An eBPF subsystem observes or, at suitable supported hooks, restricts
selected operations.
Observed events may contribute to runtime behavioral evidence.
An enforcement-capable eBPF program may also participate in
applicable operation-control paths.
The implementation must specify which operations can be denied at the
selected hook and which require a separate application-aware
effectuation controller.
7.3.139. S-3.52 - Hypervisor-Hosted Container Implementation
The container executes inside a host virtual machine.
The virtual machine supplies an additional isolation boundary between
the container workload and the underlying infrastructure.
The PED and Finality Sink may execute within the host VM, in the
underlying hypervisor, in a separate protected virtual machine, or in
another trusted service.
The required security relationships are determined by the actual
deployment and enforcement point limitations.
7.3.140. S-3.53 - TEE-Assisted Container Implementation
A protected validation component executes within a suitable trusted
execution environment.
The container submits Candidate Acts through a controlled interface.
The TEE performs required protected validation or authority-state
operations.
Das Expires 25 April 2027 [Page 203]
Internet-Draft Sandbox Credential Egress Finality October 2026
The effectuation controller verifies the resulting bounded
authorization before releasing the governed effect.
This arrangement must specify how untrusted host software is
prevented from bypassing the designated effectuation controller when
resistance to host compromise is claimed.
7.3.141. S-3.54 - HSM-Assisted Credential and Finality Implementation
An HSM performs protected cryptographic or authorization-state
functions.
The agent container lacks direct access to reusable privileged keys.
A host-side connector constructs the operation.
The protected enforcement procedure authorizes the specific
credential use.
A controlled sink performs or authorizes the credential-bound
external operation.
The HSM does not constitute a complete CIED merely because it stores
a credential; its role must provide the particular protected
enforcement functions required by the enforcement point.
7.3.142. S-3.55 - SmartNIC/DPU Enforcement Implementation
Containers execute on a host connected to a programmable network
device.
The protected device controls specified network-egress operations.
The device receives authenticated context information sufficient to
associate a network operation with the appropriate container and
authorization scope.
The device verifies the required protected enablement condition
before transmission.
Where application-layer authorization is required, the implementation
supplies a trustworthy representation of the relevant application
request fields.
Alternative networking paths must be constrained where non-
bypassability is claimed.
Das Expires 25 April 2027 [Page 204]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.3.143. S-3.56 - Distributed Host-Connector Implementation
An agent container executes on one host.
The PED executes on a separate protected service.
A tool connector executes on another machine.
A Finality Sink controls the relevant external resource operation.
The components exchange authenticated context, protected
authorization references, operation descriptors, and required
evidence.
The distributed design must address message replay, state
consistency, partition behavior, and incomplete operations.
7.3.144. PART XVII - DATA STRUCTURES
7.3.145. S-3.57 - ContainerContextRecord
The record may comprise:
| x | ContainerInstanceID. |
| - | ------------------------ |
| x | ContainerGeneration. |
| x | AgentContextID. |
| x | TaskID. |
| x | ImageReference. |
| x | IsolationProfile. |
| x | NamespaceReferences. |
| x | CgroupReference. |
| x | SecurityPolicyReference. |
| x | AuthorityGeneration. |
| x | LifecycleStatus. |
7.3.146. S-3.58 - ToolCandidateActRecord
The record may comprise:
Das Expires 25 April 2027 [Page 205]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | CandidateActID. |
| - | -------------------------- |
| x | OriginContainerGeneration. |
| x | AgentContextID. |
| x | ToolID. |
| x | OperationClass. |
| x | ResourceID. |
| x | CanonicalArguments. |
| x | PayloadDigest. |
| x | PolicyGeneration. |
| x | AuthorizedSinkID. |
| x | CandidateStatus. |
7.3.147. S-3.59 - ProtectedValidationEvidenceRecord
The record may comprise:
| x | EvidenceID. |
| - | ------------------------ |
| x | CandidateActID. |
| x | DescriptorDigest. |
| x | PEDIdentity. |
| x | EvaluatedAuthorityScope. |
| x | PolicyGeneration. |
| x | ValidationResult. |
x EvidenceCommitment. x EvidenceGeneration.
7.3.148. S-3.60 - ScopedFinalityCapabilityRecord
The record may comprise:
| x | CapabilityID. |
| - | ------------------------ |
| x | CandidateActID. |
| x | EvidenceReference. |
| x | AuthorizedSinkID. |
| x | AuthorizedResourceScope. |
| x | AuthorityGeneration. |
| x | UsagePolicy. |
| x | ExpiryCondition. |
| x | CapabilityStatus. |
7.3.149. S-3.61 - SinkLocalStateRecord
The record may comprise:
Das Expires 25 April 2027 [Page 206]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | SinkID. |
| - | ------------------------- |
| x | CandidateActID. |
| x | CapabilityID. |
| x | ExpectedDescriptorDigest. |
| x | ResourceStateReference. |
| x | AuthorityGeneration. |
| x | ConsumptionStatus. |
| x | DispatchStatus. |
| x | ExternalOperationID. |
| x | CompletionStatus. |
7.3.150. S-3.62 - ContainerEffectPathRecord
The record may comprise:
| x | EffectPathID. |
| - | -------------------------- |
| x | OriginContainerClass. |
| x | OperationClass. |
| x | InterceptionPoint. |
| x | EffectuationInterface. |
| x | RequiredSinkID. |
| x | AlternatePathRestrictions. |
| x | CoverageStatus. |
7.3.151. S-3.63 - CredentialBrokerRecord
The record may comprise:
x BrokerCredentialReference.
| x | PermittedService. |
| - | ------------------------- |
| x | AuthorizedOperationScope. |
| x | AgentOrTaskAssociation. |
| x | SecretCustodyDomain. |
| x | AllowedUseInterface. |
| x | CredentialVersion. |
| x | RevocationState. |
7.3.152. S-3.64 - OutstandingOperationRecord
The record may comprise:
Das Expires 25 April 2027 [Page 207]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | OperationID. |
| - | ----------------------------- |
| x | CandidateActID. |
| x | OriginContainerGeneration. |
| x | TaskID. |
| x | AuthorizationReference. |
| x | DispatchStatus. |
| x | ExternalTransactionReference. |
| x | CompletionStatus. |
| x | ReconciliationStatus. |
| x | LastProtectedStateTransition. |
These records are illustrative and may be realized through protected
software memory, authenticated databases, trusted services, secure
registers, deterministic binary encodings, or combinations thereof.
7.3.153. PART XVIII - implementer VERIFICATION TESTS
7.3.154. S-3.65 - Proposed Engineering Test Matrix
The following tests describe verification procedures and expected
behavior. They are not representations of completed experiments.
7.3.155. Test Test condition
T1 Authorized tool operation T2 Unauthorized tool operation T3
Missing finality capability T4 Replayed single-use capability T5
Altered operation payload T6 Spoofed container identity T7 Privileged
container
misconfiguration T8 Alternate network route T9 Direct device pass-
through
7.3.156. Expected result
Permitted through required sink Denied Effectuation withheld Rejected
Mismatch rejected Authenticated origin used Deployment or route
restricted Blocked or mediated Governed effect prevented from
bypassing
T10 Unauthorized credential use T11 Credential leakage through logs
T12 Post-validation request
transformation
Das Expires 25 April 2027 [Page 208]
Internet-Draft Sandbox Credential Egress Finality October 2026
T13 DNS or destination change T14 eBPF telemetry loss T15 Shared-
memory race T16 File-path substitution T17 Container restart T18
Asynchronous delayed worker T19 PED unavailable T20 Sink unavailable
T21 Concurrent capability use T22 External completion uncertainty T23
Container termination T24 Host-kernel compromise
Denied Protected disclosure controls tested Actual effect reverified
Required destination checks enforced Coverage gap recognized where
relevant Stable actual-operation verification Effective target
checked Stale generation authority rejected Continuation policy
enforced No permissive fallback No uncontrolled effectuation Usage
limits maintained Reconciliation state retained Pending operation
status preserved Protection limits identified under selected trust
model
These procedures should be adapted to the actual operating system and
enforcement technologies selected for a prototype.
7.3.157. PART XX - Enforcement-Point Mapping and Technical
Correspondence
7.3.158. S-3.75 - Representative Enforcement Point Support
This embodiment may provide supporting disclosure for enforcement
point limitations directed to:
(a) sandboxed artificial-intelligence-agent execution; (b) host-side
protected enforcement; (c) operation-specific tool and connector
authorization; (d) candidate operation staging; (e) protected
validation evidence; (f) scoped non-bearer capabilities; (g) Finality
Sink verification; (h) network egress controls; (i) credential
brokering;
(j) container-origin binding;
(k) runtime observation;
(l) process and tool lineage;
(m) asynchronous operation continuation;
(n) anti-bypass enforcement;
(o) authorization-state revocation;
(p) software-hardware hybrid enforcement; and
(q) distributed resource governance.
Das Expires 25 April 2027 [Page 209]
Internet-Draft Sandbox Credential Egress Finality October 2026
The embodiment is particularly relevant to the protected sandbox-
effectuation, credentialrelease, effectuation-path, process-lineage,
and selected tool-governance enforcement point families.
However, the embodiment's inclusion in the specification does not
automatically establish support for every limitation of those
independent or dependent enforcement points.
Each final enforcement point must be mapped against the specific
described technical mechanism.
7.3.159. PART XXI - implementer IMPLEMENTATION REQUIREMENTS
7.3.160. S-3.76 - Implementation Checklist
For a selected container platform and governed resource class, a
implementer implementing the embodiment identifies and configures:
1. The container runtime and operating-system version. 2. The
intended adversary and trusted computing base. 3. The specific
namespace and privilege configuration. 4. The applicable control-
group restrictions. 5. The seccomp policy and supported mediation
points. 6. The operating-system mandatory access-control
restrictions. 7. The selected eBPF observation or enforcement
points. 8. The host-controlled communication channels. 9. The
authenticated container-origin mechanism. 10. The execution-
generation allocation and revocation process. 11. The operations
requiring protected finality. 12. The complete set of paths capable
of producing each governed effect. 13. The operation interception
and staging mechanism. 14. The operation descriptor schema and
canonicalization rules. 15. The PED and its protected authority-
state representation. 16. The authorization predicates. 17. The
evidence-commitment mechanism.
18. The scoped capability representation. 19. The Finality Sink
actual-operation verification procedure. 20. The protected sink-
local state and consumption semantics. 21. The credential broker and
secret-exposure restrictions. 22. The treatment of DNS, redirects,
protocol transformations, and effective destinations where relevant.
23. The method for controlling inherited file descriptors, shared
mounts, IPC, and passedthrough devices. 24. The operation lifecycle
and asynchronous continuation policy. 25. The retry, recovery, and
external outcome reconciliation procedure. 26. The treatment of
container restart, restoration, and replacement. 27. The test
procedures verifying the required enforcement properties.
Das Expires 25 April 2027 [Page 210]
Internet-Draft Sandbox Credential Egress Finality October 2026
The particular implementation may omit nonessential optional
features, but all elements expressly required by a enforcement point
must be technically supported.
7.3.161. S-3.77 - Technical Effect
In the representative protected-finality implementation, the system
allows an artificialintelligence agent to execute inside a container
while withholding selected external effects until the applicable
independent authorization procedure succeeds.
The container's access to a tool, connection, process interface, or
credential reference is not automatically treated as authority for
every consequential operation available through that interface.
The architecture can separate:
1. Agent computation. 2. Container resource confinement. 3.
Runtime observation. 4. Protected authorization evaluation. 5.
Protected validation evidence. 6. Scoped finality enablement. 7.
Actual-operation verification. 8. Effectuation and completion
reconciliation.
These operations may be implemented across cooperating software,
firmware, hardware, and distributed infrastructure components.
The degree of isolation and non-bypassability achieved depends on the
selected implementation and the actual controlled effectuation paths.
7.3.162. S-3.78 - Technical Summary
this implementation profile discloses a container-isolated
artificial-intelligence-agent execution system comprising an agent
container, controlled effectuation interfaces, authenticated
execution-context binding, Candidate Act interception, non-effective
operation staging, protected authorization, validation-evidence
commitment, scoped non-bearer finality enablement, and a Finality
Sink configured to verify the actual pending consequential operation.
The system may employ namespaces, control groups, seccomp, Linux
Security Modules, eBPF observation, host-side tool connectors,
protected credential brokers, network proxies, trusted execution
environments, hardware security modules, protected network devices,
or combinations thereof.
The architecture separates ordinary workload isolation from authority
to produce specified consequential effects.
Das Expires 25 April 2027 [Page 211]
Internet-Draft Sandbox Credential Egress Finality October 2026
It further provides representative mechanisms for handling container
lifecycle changes, asynchronous operations, protected authorization-
state consumption, stale execution generations, and operation-
substitution or bypass attempts.
The embodiment does not require every independently claimed
alternative architecture to employ protected execution finality.
Monitoring-only, native authorization, static sandbox, and other
separately architectures may use their respective implementation
mechanisms.
7.3.162.1. PROCESS-ISOLATED ARTIFICIAL-INTELLIGENCE-AGENT EXECUTION
WITH PROTECTED AUTHORITY SEPARATION, PROCESS-LINEAGE
7.3.162.2. CONTROL, HANDLE MEDIATION, AND FINALITY SINK VERIFICATION
7.4. Implementation Profile S-4
Source location: original disclosure pages 187-233. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.4.1. S-4.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, operating-system process isolation, process-level privilege
separation, interprocess communication, resourceaccess mediation,
protected authorization, and effectuation control.
More particularly, the embodiment describes a computing system in
which an artificialintelligence agent operates as one or more
restricted operating-system processes, while specified consequential
operations remain under the control of an enforcement mechanism
having authority separate from that of the agent-controlled
processes.
The system may operate without creating a separate virtual machine,
micro-virtual machine, operating-system container, or hardware
enclave for the agent.
Process isolation may be implemented using operating-system security
principals, process access tokens, privilege restrictions, access-
control labels, kernel-enforced permissions, process-group controls,
restricted executable environments, security descriptors,
interprocess communication mediation, or combinations thereof.
Das Expires 25 April 2027 [Page 212]
Internet-Draft Sandbox Credential Egress Finality October 2026
The protected execution-finality functions may be implemented by
software, firmware, hardware, protected services, or combinations
thereof.
The process-level architecture constitutes a species of the broader
execution-control architecture and does not require that all
independently disclosed inventions use the same finality mechanism.
7.4.2. S-4.2 - Technical Problem
Artificial-intelligence agents may execute as ordinary operating-
system processes, including language-model runtimes, command-line
agents, development assistants, automation processes, browser-control
programs, and background task workers.
Such processes may operate under a user identity or service identity
that has access to files, applications, credentials, operating-system
resources, network interfaces, and privileged tool services.
A process-isolation configuration may restrict the privileges or
resources available to the agent.
However, process isolation does not necessarily establish whether
each consequential operation performed by that process is authorized
for its particular task, target resource, purpose, destination, or
execution context.
For example:
(a) an agent process may possess a valid user access token but
generate a resource modification outside the intended task;
(b) an agent may inherit an open file descriptor or object handle
granting access beyond its intended permissions;
(c) a restricted process may communicate with a privileged broker
that possesses broader authority;
(d) a child process may acquire or retain resource access not
anticipated by the original agentcontrol policy;
(e) a process may duplicate or transfer an effect-capable handle;
(f) a subprocess may remain active after the parent agent process has
terminated;
(g) a process identifier may be reused after process termination;
Das Expires 25 April 2027 [Page 213]
Internet-Draft Sandbox Credential Egress Finality October 2026
(h) a process may issue an operation through an alternative IPC or
network path rather than the intended protected interface;
(i) an operation may be authorized under one resource state but
performed after that state changes;
(j) a monitoring process may observe an unauthorized action without
possessing the technical ability to block it; and
(k) a privileged broker may authenticate an agent process without
independently determining whether the actual requested operation is
authorized.
this implementation profile addresses these problems by separating
process execution identity from protected authority to produce
specified consequential effects.
In a representative protected-finality implementation, an effect-
capable operation is staged, validated through a Protected
Enforcement Domain, associated with protected evidence and bounded
finality enablement, and verified at the controlled effectuation
interface.
7.4.3. S-4.3 - Technical Objectives
The embodiment provides a system configured to:
1. Execute an artificial-intelligence agent within a restricted
operating-system process. 2. Identify the actual originating process
and relevant process lineage. 3. Associate execution with a task,
policy, authority generation, and resource scope. 4. Restrict
unauthorized direct access to selected effect-capable resources. 5.
Intercept consequential operations through controlled interfaces. 6.
Hold governed operations in a Non-Effective State. 7. Prevent
inherited or duplicated handles from bypassing protected enforcement.
8. Authenticate interprocess communication with privileged host
services. 9. Evaluate applicable authorization predicates
independently of the agent. 10. Commit protected validation evidence
where required. 11. Establish scoped non-bearer finality
authorization. 12. Verify the actual pending operation at the
Finality Sink. 13. Maintain protected authorization state across
process creation and termination. 14. Prevent stale authorization
reuse after process restart or identity reassignment. 15. Coordinate
asynchronous operations initiated by child processes or external
workers. 16. Support software-only, hardware-assisted, and hybrid
implementations.
Das Expires 25 April 2027 [Page 214]
Internet-Draft Sandbox Credential Egress Finality October 2026
The implementation may use different combinations of these functions
according to the applicable independent enforcement point.
7.4.4. PART I - SYSTEM ARCHITECTURE
7.4.5. S-4.4 - Principal Components
A representative system comprises the following functional
components.
7.4.6. Component A - Computing Host
A computing platform having one or more processors, memory resources,
operating-system services, and effect-capable interfaces.
The platform may comprise a workstation, enterprise server, cloud
instance, mobile computing device, embedded platform, edge computing
node, or equivalent device.
7.4.7. Component B - Host Operating System
An operating system configured to manage processes, threads, security
identities, memory mappings, resource handles, system calls, access-
control decisions, and interprocess communications.
7.4.8. Component C - Agent Process
One or more operating-system processes executing an artificial-
intelligence agent, model client, reasoning or planning application,
tool runner, generated program, browser-control component, or
delegated worker.
7.4.9. Component D - Process Isolation Controller
A component configured to establish and maintain restrictions
applicable to the Agent Process.
7.4.10. Component E - Process Context Registry
A host-controlled registry configured to associate execution
identities with process-instance generations, task identities,
applicable authority states, and resource-control policies.
7.4.11. Component F - Process-Lineage Controller
A mechanism configured to identify and govern relevant process
creation, delegation, subprocess execution, and execution-context
transfer.
Das Expires 25 April 2027 [Page 215]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.12. Component G - Resource and Handle Mediation Controller
A mechanism configured to restrict, classify, or mediate the use,
inheritance, duplication, or transfer of effect-capable resource
handles.
7.4.13. Component H - Controlled IPC and Tool Interface
A communication interface configured to receive agent-originated
requests for operations performed outside the restricted process.
7.4.14. Component I - Candidate Act Interceptor
A component configured to identify a governed consequential operation
before its applicable effectuation boundary.
7.4.15. Component J - Non-Effective Operation Holder
A mechanism configured to retain the Candidate Act without permitting
the specified consequential effect.
7.4.16. Component K - Protected Enforcement Domain
A component configured to evaluate required authorization predicates
and maintain or access protected enforcement state.
7.4.17. Component L - Protected Validation Evidence Controller
A mechanism configured to commit validation evidence as required by
the applicable finality protocol.
7.4.18. Component M - Scoped Finality Enablement Controller
A protected component configured to establish bounded finality
authorization.
7.4.19. Component N - Finality Sink
An enforcement component controlling the designated consequential
effect and verifying the requirements imposed by the applicable
enforcement point.
7.4.20. Component O - Privileged Resource Broker
A service configured to perform selected operations on behalf of the
restricted agent without necessarily exposing privileged credentials,
handles, or resource authority to that agent.
Das Expires 25 April 2027 [Page 216]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.21. Component P - Protected Operation Registry
A mechanism configured to retain Candidate Act state, capability
references, effectuation status, revocation state, and unresolved
operation outcomes.
These roles may be performed by cooperating processes, operating-
system services, kernel components, protected hardware, or a
combination thereof.
7.4.22. S-4.5 - Representative Process-Isolated Architecture
In one representative deployment:
(a) an AI agent executes as a restricted user-space process; (b) its
operating-system identity does not permit unrestricted modification
of selected protected resources; (c) the process possesses access
only to a controlled tool or IPC service for governed operations;
(d) the IPC service authenticates the actual process execution
context;
(e) a host-controlled interceptor creates a Candidate Act;
(f) the Candidate Act remains non-effective;
(g) the PED validates the applicable authority predicates;
(h) protected validation evidence is committed;
(i) a scoped non-bearer capability is established;
(j) the Finality Sink independently verifies the actual pending
operation; and
(k) the authorized effect is performed through a controlled resource
interface.
A representative logical sequence is:
AGENT PROCESS
↓
PROCESS ISOLATION AND CONTROLLED IPC
↓
Das Expires 25 April 2027 [Page 217]
Internet-Draft Sandbox Credential Egress Finality October 2026
CANDIDATE ACT CAPTURE
↓
NON-EFFECTIVE STAGING
↓
PROTECTED ENFORCEMENT DOMAIN
↓
PROTECTED VALIDATION EVIDENCE
↓
SCOPED FINALITY CAPABILITY
↓
FINALITY SINK VERIFICATION
↓
EFFECT-CAPABLE RESOURCE
The Process Context Registry, Process-Lineage Controller, and
Protected Operation Registry maintain relevant state alongside this
effectuation sequence.
The architecture does not require a separate virtual machine or
container.
7.4.23. PART II - PROCESS ISOLATION AND AUTHORITY CONTEXT
7.4.24. S-4.6 - Restricted Agent Process
The agent may execute under a restricted security identity or
security context.
Restrictions may include:
Das Expires 25 April 2027 [Page 218]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Limited filesystem permissions. 2. Limited process-creation
authority. 3. Limited access to privileged devices. 4. Restricted
credential access. 5. Restricted system-call classes. 6. Controlled
network interfaces. 7. Restricted interprocess communication. 8.
Limited access to other processes. 9. Restricted memory and
debugging interfaces. 10. Prohibition of selected privilege-
elevation operations. 11. Mandatory resource-access controls. 12.
Restrictions on inheriting privileged object handles.
The precise restrictions depend on the operating system and selected
deployment.
A restricted process is not assumed to be secure solely because it
executes under a nonadministrator identity.
Its actual resource-access capabilities must be examined.
7.4.25. S-4.7 - Process Execution Identity
A representative Process Execution Context comprises:
ProcessInstanceID = PROC-0081
ProcessGeneration = 508
AgentContextID = AGENT-42
TaskID = TASK-204
SecurityPrincipal = PRINCIPAL-17
IsolationProfile = PROCESS-RESTRICTED-A
AuthorityGeneration = 105
PermittedToolClasses = TOOL-A, TOOL-B
LifecycleStatus = RUNNING
These values are illustrative.
The ProcessInstanceID is associated with the specific execution
instance rather than only the operating system's numerical process
identifier.
Das Expires 25 April 2027 [Page 219]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.26. S-4.7.1 - Process identifier reuse
An operating system may reuse a numerical process identifier after a
process terminates.
Therefore, a numerical PID alone is not sufficient to establish the
continued identity of an authority-bearing execution context.
An implementation may use:
(a) a process handle identifying the live kernel process object;
(b) a protected process-start generation;
(c) a process creation sequence;
(d) an authenticated service-session association;
(e) a kernel-maintained process identity reference; or
(f) an equivalent non-confusable process-instance binding.
A capability associated with an earlier process generation is not
automatically valid for a later process that receives the same
numerical PID.
7.4.27. S-4.8 - Process Isolation Without Containers
In one implementation, the agent executes directly under the host
operating system.
The isolation controller creates a restricted process identity and
supplies only the resources required by the assigned task.
No separate container runtime is required.
No independent guest operating system is required.
The operating system may use an access-control framework, sandbox
policy, restricted process token, capability reduction, security
label, or other native protection mechanism.
The isolation mechanism may rely on ordinary kernel enforcement.
Consequently, a software-only embodiment generally assumes the
integrity of the kernel and other necessary privileged enforcement
components.
Das Expires 25 April 2027 [Page 220]
Internet-Draft Sandbox Credential Egress Finality October 2026
Protection against a compromised kernel requires additional
mechanisms appropriate to the claimed threat model.
7.4.28. PART III - CROSS-PLATFORM PROCESS ISOLATION
7.4.29. S-4.9 - Linux Process-Isolation Variation
In a Linux implementation, the Process Isolation Controller may
combine:
(a) execution under a dedicated unprivileged user or service
identity; (b) reduction of available Linux capabilities; (c) the no-
new-privileges restriction; (d) seccomp filtering; (e) an applicable
Linux Security Module policy; (f) restricted filesystem permissions;
(g) controlled executable and library access; (h) restricted
privileged IPC interfaces; (i) control-group resource constraints;
(j) protected host-side broker communication; and (k) controls over
inherited and transferred file descriptors.
The agent may operate as an ordinary Linux process without requiring
an OCI container or virtual machine.
7.4.30. S-4.9.1 - Capability reduction
The operating system may restrict privileged operations available to
the agent process.
Linux capabilities governing selected privileged kernel operations
may be removed or otherwise constrained.
Such restrictions do not inherently prevent the agent from performing
an unauthorized application-level action through a permitted broker
or ordinary user-accessible service.
7.4.31. S-4.9.2 - Seccomp enforcement
A seccomp filter may constrain selected system calls.
The selected policy must account for the specific kernel interfaces
required by the agent.
Where seccomp notification or another mediation mechanism is used,
the implementation must address possible changes in untrusted process
state between inspection and use.
Das Expires 25 April 2027 [Page 221]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.32. S-4.9.3 - LSM policy
An applicable Linux Security Module may restrict file, process,
network, or other resource access according to its supported
enforcement mechanisms.
The policy may prevent direct access to effect-capable resources that
must instead be accessed through a protected broker.
7.4.33. S-4.9.4 - Direct process implementation
The absence of a container does not prevent implementation of
protected finality.
The required Candidate Act staging, PED validation, and Finality Sink
verification can be provided by host-side services and appropriately
controlled kernel or resource interfaces.
7.4.34. S-4.10 - Windows Process-Isolation Variation
In a Windows implementation, the agent may execute under a restricted
access token, AppContainer security context where suitable, or
another applicable process security arrangement.
Restrictions may be implemented through:
(a) restricted tokens; (b) security identifiers and access-control
lists; (c) integrity-level restrictions; (d) process mitigation
policies; (e) Job Objects;
(f) controlled named-pipe or RPC interfaces;
(g) restricted handle inheritance;
(h) limits on process and resource creation;
(i) protected service processes; and
(j) applicable kernel-enforced access controls.
7.4.35. S-4.10.1 - Access-token interpretation
An access token identifies security principals and privileges used in
operating-system access checks.
A valid operating-system token does not necessarily represent task-
specific permission to perform every consequential operation
available to that principal.
Das Expires 25 April 2027 [Page 222]
Internet-Draft Sandbox Credential Egress Finality October 2026
The PED may therefore enforce additional operation-specific
authority.
7.4.36. S-4.10.2 - Object handles
A Windows process may possess handles to files, processes,
synchronization objects, named pipes, devices, or other kernel
objects.
An existing handle may continue to permit operations according to its
granted access rights.
Restricting a process's future object-opening behavior does not
necessarily revoke rights already represented by all existing
handles.
Accordingly, the architecture may control initial handle grants,
handle inheritance, permitted duplication, broker-issued handles, or
the operations performed through those handles.
7.4.37. S-4.10.3 - Protected service
A Windows service or other privileged broker may receive requests
from the restricted agent through an authenticated interface.
The broker authenticates the caller's process or security context and
applies the required operation-specific authorization.
Where protected finality is claimed, the consequential resource
operation remains subject to the required validation and Finality
Sink conditions.
7.4.38. S-4.11 - macOS Process-Isolation Variation
In a macOS implementation, an agent may execute under an applicable
application sandbox, restricted process identity, entitlement-based
security context, hardened execution configuration, or other
supported operating-system protection mechanism.
The system may employ:
(a) application sandbox restrictions; (b) entitlement-controlled
resource access; (c) dedicated helper processes; (d) XPC or another
supported interprocess communication mechanism;
(e) restricted filesystem access;
(f) controlled network or service access;
Das Expires 25 April 2027 [Page 223]
Internet-Draft Sandbox Credential Egress Finality October 2026
(g) protected credential services;
(h) operating-system access-control mechanisms; and
(i) mediated access to effect-capable resources.
7.4.39. S-4.11.1 - Entitlement distinction
An entitlement may permit an application to request or use a category
of operating-system functionality.
Such permission does not independently establish that a particular
agent-generated operation is authorized for its assigned enterprise
task.
A host-side broker may therefore apply additional resource-,
operation-, and task-specific enforcement.
7.4.40. S-4.11.2 - XPC-based mediation
A restricted agent process may submit a request through an XPC
service or another appropriate IPC mechanism.
The receiving service establishes the applicable caller identity and
authorization context.
The actual effect-capable operation is performed only under the
required enforcement conditions.
The process and IPC implementation must account for connection
lifetime, caller identity, asynchronous requests, and changes in
operating-system security context.
7.4.41. S-4.12 - Other Operating Systems and Embedded Platforms
The embodiment is not restricted to Linux, Windows, or macOS.
A process-isolated execution environment may use a microkernel, real-
time operating system, embedded operating system, mobile operating
system, or other platform that provides enforceable separation of
execution contexts and resource operations.
An embedded implementation may represent the agent as a restricted
task or process with access to a controlled command interface.
An industrial controller may similarly separate an agent-controlled
planning task from the protected interface that performs physical
actuation.
Das Expires 25 April 2027 [Page 224]
Internet-Draft Sandbox Credential Egress Finality October 2026
The relevant implementation must identify how its chosen operating
system enforces process separation and how the consequential
operation is controlled.
7.4.42. PART IV - PROCESS LINEAGE AND DELEGATION
7.4.43. S-4.13 - Process-Lineage Representation
An agent may create one or more subprocesses or delegate computation
to independently scheduled workers.
A representative lineage includes:
Agent Process
↓
Tool Dispatcher Child
↓
Generated Script Interpreter
↓
External Operation Worker
The system may construct a Process-Lineage Record containing:
| x | Parent process instance. |
| - | ------------------------ |
| x | Child process instance. |
| x | Agent identity. |
| x | Task identity. |
| x | Execution generation. |
| x | Program identity. |
| x | Tool identity. |
| - | ------------------------- |
| x | Relevant authority scope. |
| x | Creation sequence. |
| x | Delegation relationship. |
| x | Current lifecycle state. |
Das Expires 25 April 2027 [Page 225]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.44. S-4.13.1 - Lineage is not authority
The fact that a child process descends from an authorized agent does
not establish that all operations performed by the child are
authorized.
The child may inherit certain restrictions, but operation-specific
authorization remains determined by the applicable policy and
enforcement mechanism.
7.4.45. S-4.13.2 - Protected lineage attribution
Where lineage contributes to authorization, the relevant relationship
may be established through host-maintained process creation events,
controlled broker records, authenticated task delegation, or another
trusted observation source.
An untrusted process's self-reported parent or task identifier is
insufficient where the enforcement point requires independent
attribution.
7.4.46. S-4.14 - Child Process Creation
Before creating a child process, the system may:
1. Determine the requested executable. 2. Evaluate the applicable
process-creation policy. 3. Select a permitted security identity. 4.
Assign the child to a defined task context. 5. Restrict inherited
handles. 6. Apply applicable process mitigations. 7. Associate the
child with an execution generation. 8. Register its permitted tool
and resource interfaces. 9. Configure relevant authority
restrictions. 10. Permit the child to execute.
A child may possess a narrower authority scope than its parent.
The child does not automatically receive permission to generate new
scoped finality capabilities.
7.4.47. S-4.15 - Process-Tree Termination
An agent task may be canceled or revoked.
The Process-Lineage Controller identifies processes and workers
associated with the task.
The controller may terminate, suspend, restrict, or revoke access for
the affected processes according to the applicable operating-system
mechanisms.
Das Expires 25 April 2027 [Page 226]
Internet-Draft Sandbox Credential Egress Finality October 2026
However, process termination does not establish that a previously
submitted operation has not produced an external effect.
The protected operation registry separately tracks operations already
staged, authorized, dispatched, completed, or unresolved.
Where complete process-tree termination is required, the
implementation must account for children that detach, change parent
associations, or continue through independent services.
7.4.48. PART V - FILE DESCRIPTORS, OBJECT HANDLES, AND RESOURCE
AUTHORITY
7.4.49. S-4.16 - Effect-Capable Handle
An Effect-Capable Handle means a process-accessible reference to an
operating-system object or resource through which a consequential
operation may be performed.
Such handles may include:
| x | File descriptors. |
| - | ------------------------------- |
| x | File handles. |
| x | Socket descriptors. |
| x | Device handles. |
| x | Process handles. |
| x | Shared-memory references. |
| x | Cryptographic object handles. |
| x | Named-pipe references. |
| x | IPC endpoints. |
| x | Database session handles. |
| x | Accelerator command references. |
The security significance of a handle depends on the operations and
access rights it actually
permits.
A handle may enable an effect even when its process cannot
independently open a new reference to the same resource.
7.4.50. S-4.17 - Handle-Inheritance Control
When a child process is created, the Process Isolation Controller may
restrict which handles remain accessible.
The controller may employ:
Das Expires 25 April 2027 [Page 227]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) close-on-exec semantics where applicable; (b) explicit allowlists
of inherited descriptors; (c) creation of child processes with
restricted handle sets;
(d) broker-controlled resource references;
(e) object-access restrictions;
(f) controlled process-spawning APIs; or
(g) equivalent mechanisms supported by the operating system.
7.4.51. S-4.17.1 - Restricted handle sets
In one implementation, the child receives only:
1. Standard input and output interfaces as permitted. 2. A
controlled tool RPC channel. 3. A restricted local workspace. 4.
Necessary runtime resources.
The child does not receive an unrestricted network socket, privileged
device handle, or protected credential handle for a governed
resource.
7.4.52. S-4.18 - Handle Duplication and Transfer
A process may attempt to duplicate or transfer a handle to another
process.
Depending on the operating system, this may occur through IPC,
process-control interfaces, descriptor passing, or privileged handle
duplication.
A representative protected implementation constrains the creation,
transfer, or use of handles capable of bypassing the intended
Finality Sink.
1. 2. 3. 4. 5. 6. 7.
The implementation may:
Deny selected handle transfers. Restrict handle access rights.
Associate a handle with a permitted task or resource scope. Require
use through a protected broker. Close or invalidate specified
handles during revocation. Use an OS-enforced protection mechanism
for the underlying resource. Mediate the consequential operation
through a controlled effectuation interface.
Das Expires 25 April 2027 [Page 228]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.53. S-4.18.1 - Existing-handle limitation
An authorization change does not automatically revoke every
previously granted kernelobject right.
A deployment requiring immediate revocation must specify how existing
access paths are fenced, disabled, restricted, or brought under the
protected enforcement mechanism.
7.4.54. S-4.19 - Shared Memory
An agent and broker may communicate through shared memory.
A shared-memory buffer may be mutable while one process validates its
contents.
Accordingly, a protected-finality implementation must not rely on an
earlier reading of mutable memory if the actual effectuation
operation can use different values.
A representative mechanism may employ:
(a) an immutable broker-owned copy; (b) a controlled transfer of
buffer ownership; (c) a versioned immutable message object; (d) a
protected message digest tied to stable payload storage; or (e) fresh
verification of actual operation parameters at effectuation.
The implementation must specify the relationship between the verified
representation and the bytes or resource values actually used.
7.4.55. PART VI - CONTROLLED IPC AND PRIVILEGED BROKER
7.4.56. S-4.20 - Protected Broker Interface
A restricted agent process may request a consequential operation
through a broker service.
The broker may have access to credentials, network resources, files,
applications, or devices not directly accessible to the agent.
A broker request may include:
RequestID
ToolID
OperationClass
Das Expires 25 April 2027 [Page 229]
Internet-Draft Sandbox Credential Egress Finality October 2026
TargetResource
OperationArguments
PayloadReference
TaskReference
OptionalDelegationReference
The broker does not rely solely on these requester-controlled fields
to determine actual execution identity.
7.4.57. S-4.21 - Authenticated Process Context
The broker obtains the applicable process identity through a
mechanism supported by the operating system and suitable for the
threat model.
Examples include:
| x | Authenticated local IPC peer credentials. |
| - | -------------------------------------------------------------- |
| x | A protected process-object reference. |
| x | A service-mediated task context. |
| x | An OS security token. |
| x | A connection-specific workload association. |
| x | A cryptographically authenticated process or service identity. |
If a process terminates and a new process receives the same numerical
identifier, the original authority-bearing association must not
silently transfer to the new process.
For long-running IPC sessions, the broker maintains a protected
session-to-process-instance association or another appropriately
authenticated identity binding.
7.4.58. S-4.22 - Broker Resource Authorization
The broker may initially determine whether an operation is eligible
for ordinary processing.
In a protected-finality implementation, the broker then submits the
relevant Candidate Act to the PED or causes the required protected
validation to occur.
Das Expires 25 April 2027 [Page 230]
Internet-Draft Sandbox Credential Egress Finality October 2026
A broker may itself perform the Finality Sink function when it
effectively controls the corresponding operation and implements the
required verification.
The broker must not be treated as independently authoritative merely
because it runs under a privileged operating-system account.
7.4.59. PART VII - CANDIDATE ACT AND NON-EFFECTIVE STAGING
7.4.60. S-4.23 - Candidate Act Creation
A process-originated operation is represented as a Candidate Act when
the relevant policy requires protected-finality processing.
Examples include:
(a) modification of a protected document; (b) transmission of
confidential information; (c) execution of a financial instruction;
(d) use of an enterprise credential; (e) modification of cloud
infrastructure; (f) deletion of a persistent record; (g) execution of
an external tool; (h) publication of generated content; and (i)
dispatch of a physical-control command.
The Candidate Act is associated with the authenticated process
execution context.
7.4.61. S-4.24 - Non-Effective State
The governed Candidate Act is maintained in a Non-Effective State.
A representative state transition is:
PROPOSED → STAGED → VALIDATED → AUTHORIZED → EFFECTUATED
Other possible states include:
DENIED
CANCELED
EXPIRED
REVOKED
DISPATCHED
INDETERMINATE
Das Expires 25 April 2027 [Page 231]
Internet-Draft Sandbox Credential Egress Finality October 2026
RECONCILIATION_REQUIRED
The operation is not considered non-effective merely because it has
not yet been recorded as completed.
It must actually remain unable to produce the governed consequential
effect while authorization is withheld.
7.4.62. S-4.25 - Candidate Act Descriptor
A representative descriptor comprises:
CandidateActID = CA-0401
OriginProcessInstanceID = PROC-0081
ProcessGeneration = 508
AgentContextID = AGENT-42
TaskID = TASK-204
OperationClass = FILE_MODIFY
TargetResource = RESOURCE-CONFIG-17
DescriptorDigest = DIGEST-0401
AuthorityGeneration = 105
AuthorizedSinkID = FS-FILE-01
CandidateStatus = STAGED
The descriptor may additionally include operation arguments, resource
identity, content digest, destination, freshness conditions, and
applicable delegation context.
The final descriptor schema must define deterministic encoding and
comparison rules for the material fields.
7.4.63. PART VIII - PROTECTED ENFORCEMENT DOMAIN
7.4.64. S-4.26 - PED Implementation
A PED may be implemented through:
Das Expires 25 April 2027 [Page 232]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. A protected host service. 2. A kernel-mediated security
mechanism. 3. A privileged broker with enforced isolation from the
agent. 4. A protected operating-system security component. 5. A
trusted execution environment. 6. An HSM-assisted service. 7. A
protected coprocessor. 8. A remote protected authorization service.
9. A combination of cooperating protected components.
A PED need not occupy a separate physical machine.
However, it must maintain the security properties required by the
corresponding enforcement point.
For example, if protection from ordinary agent processes is required,
a correctly configured host security service may suffice under the
selected threat model.
If resistance to a compromised host kernel is required, additional
appropriately positioned hardware or cryptographic protection may be
necessary.
7.4.65. S-4.27 - Authority Predicate Evaluation
The PED evaluates the required conditions for the particular
operation.
Relevant predicates may include:
(a) authenticated process identity; (b) agent and task identity; (c)
operation class; (d) requested resource; (e) actual effectuation
interface; (f) authorized purpose; (g) permitted tool scope;
(h) process lineage;
(i) delegated authority;
(j) policy generation;
(k) revocation state;
(l) freshness;
(m) quota;
(n) resource-state precondition;
(o) runtime behavior; and
(p) required human approval.
Das Expires 25 April 2027 [Page 233]
Internet-Draft Sandbox Credential Egress Finality October 2026
The applicable policy determines the required predicate set.
No example predicate is universally required unless expressly
claimed.
7.4.66. S-4.28 - Protected Validation Evidence
Following successful validation, the PED creates or commits protected
validation evidence.
A representative record comprises:
EvidenceID = VE-0401
CandidateActID = CA-0401
DescriptorDigest = DIGEST-0401
PEDIdentity = PED-PROC-01
PolicyGeneration = 105
ValidationResult = APPROVED
AuthorizedSinkID = FS-FILE-01
EvidenceGeneration = 811
The evidence may be represented by an authenticated registry record,
signed receipt, sealedstate commitment, protected transactional
record, or equivalent mechanism.
Where required by the enforcement point, the evidence is committed
before the corresponding finality capability becomes effective.
7.4.67. S-4.29 - Scoped Non-Bearer Finality Capability
The PED establishes a scoped capability associated with the validated
Candidate Act.
A representative capability includes:
CapabilityID = CAP-0401
CandidateActID = CA-0401
EvidenceReference = VE-0401
Das Expires 25 April 2027 [Page 234]
Internet-Draft Sandbox Credential Egress Finality October 2026
AuthorizedProcessGeneration = 508
AuthorizedTaskID = TASK-204
AuthorizedResource = RESOURCE-CONFIG-17
AuthorizedSink = FS-FILE-01
AuthorityGeneration = 105
UsagePolicy = SINGLE_USE
CapabilityStatus = ACTIVE
A protected registry entry, authenticated object, secure register,
hardware latch, or equivalent bounded authorization state may
implement the capability.
The agent process may receive a non-authoritative request identifier
without receiving the underlying protected capability.
7.4.68. PART IX - FINALITY SINK AND ACTUAL OPERATION VERIFICATION
7.4.69. S-4.30 - Finality Sink Placement
A Finality Sink may be positioned at a controlled interface through
which the consequential effect occurs.
Examples include:
| x | A file commit broker. |
| - | ------------------------- |
| x | A network egress service. |
| x | A credential-use service. |
| - | ---------------------------------- |
| x | A database transaction controller. |
| x | A protected IPC command handler. |
| x | An application resource server. |
| x | A storage controller. |
| x | A cryptographic signing interface. |
| x | A hardware device controller. |
The selected sink must be able to control the governed effect.
An ordinary observer that cannot prevent the operation is not a
Finality Sink for that effect.
Das Expires 25 April 2027 [Page 235]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.70. S-4.31 - Actual Pending Operation Reconstruction
The sink obtains or reconstructs the operation that is actually about
to occur.
For a file modification, the sink may determine:
1. The effective target file or resource object. 2. The actual
requested operation. 3. The content or modification digest. 4. The
relevant process or task context. 5. The current resource-state
version. 6. The applicable protected authorization reference.
The actual pending operation is compared with the authorized
descriptor.
For example, validation of a pathname alone may not establish
authorization to modify a different object subsequently reached
through a symbolic link or substituted mount.
Where resource identity is material, the implementation may use a
stable object reference or another mechanism that prevents
unauthorized object substitution.
7.4.71. S-4.32 - Sink-Local State
The Finality Sink maintains or securely accesses protected state
including, where applicable:
| x | Capability identity. |
| - | ------------------------------ |
| x | Authorized descriptor digest. |
| x | Resource identity. |
| x | Authority generation. |
| x | Revocation state. |
| x | Usage status. |
| x | Pending dispatch status. |
| x | External operation identifier. |
| x | Completion status. |
A single-use capability may transition through:
UNUSED → RESERVED → CONSUMED
Atomic state transitions prevent multiple workers from independently
obtaining unauthorized use of one capability.
Where an external service is involved, local consumption and external
completion are distinguishable events.
Das Expires 25 April 2027 [Page 236]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.72. PART X - COMPLETE SUCCESSFUL EXECUTION WORKFLOW
7.4.73. S-4.33 - Principal 22-Step Workflow
A representative successful operation proceeds as follows.
7.4.74. Step S4-01 - Process creation
The operating system creates an agent process under the selected
restricted security identity.
7.4.75. Step S4-02 - Isolation configuration
The Process Isolation Controller configures permitted privileges,
resources, handles, mitigation settings, and IPC endpoints.
7.4.76. Step S4-03 - Process-generation assignment
A trusted controller assigns a process-instance generation and
associates the process with the intended agent task.
7.4.77. Step S4-04 - Effect-path verification
The system verifies that the designated consequential effects are
accessible only through the required controlled interfaces.
7.4.78. Step S4-05 - Agent computation
The agent performs ordinary authorized computation.
7.4.79. Step S4-06 - Operation proposal
The agent generates a consequential operation requiring protected
finality.
7.4.80. Step S4-07 - Controlled IPC submission
The operation is submitted to a host-side broker or controlled
resource interface.
7.4.81. Step S4-08 - Source authentication
The broker determines the actual originating process and task
context.
Das Expires 25 April 2027 [Page 237]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.82. Step S4-09 - Candidate Act creation
The system assigns a Candidate Act identity.
7.4.83. Step S4-10 - Non-effective staging
The requested operation is held before the governed effectuation
boundary.
7.4.84. Step S4-11 - Descriptor construction
The material operation fields are canonicalized.
7.4.85. Step S4-12 - PED submission
The Candidate Act Descriptor and authenticated context are submitted
for protected validation.
7.4.86. Step S4-13 - Protected authority-state acquisition
The PED obtains current applicable authority, policy, and revocation
state.
7.4.87. Step S4-14 - Predicate validation
The PED evaluates all mandatory authorization predicates.
7.4.88. Step S4-15 - Protected evidence commitment
Successful validation is committed into the required protected
evidence representation.
7.4.89. Step S4-16 - Capability establishment
A scoped non-bearer capability is activated for the authorized
operation.
7.4.90. Step S4-17 - Actual-operation reconstruction
The Finality Sink obtains the operation that will actually be
performed.
7.4.91. Step S4-18 - Finality verification
The sink verifies descriptor correspondence, evidence, capability,
resource scope, freshness, revocation, and applicable protected
state.
Das Expires 25 April 2027 [Page 238]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.92. Step S4-19 - Protected state reservation
Where required, the sink atomically reserves or consumes the bounded
authorization.
7.4.93. Step S4-20 - Effectuation
The authorized consequential operation is performed through the
controlled interface.
7.4.94. Step S4-21 - Completion observation
The sink obtains the resulting completion or failure status.
7.4.95. Step S4-22 - Outcome reconciliation
The protected operation registry records completion or preserves an
unresolved state requiring later reconciliation.
7.4.96. PART XI - IMPLEMENTATION ALGORITHMS
S-4.34 - Algorithm A: Restricted Process Initialization
function CreateRestrictedAgentProcess(task, isolation_profile):
principal = ResolveRestrictedPrincipal(task)
process = CreateProcessSuspended(
task.executable, principal, isolation_profile )
generation = ProtectedGenerationService.allocate()
ApplySupportedProcessRestrictions(
process, isolation_profile )
RestrictInheritedHandles(
process, isolation_profile.allowed_handles )
ConfigureControlledIPC(process, task)
context = {
process_instance: GetStableProcessReference(process), generation:
generation, agent_id: task.agent_id, task_id: task.id,
authority_generation: CurrentAuthorityGeneration(task) }
Das Expires 25 April 2027 [Page 239]
Internet-Draft Sandbox Credential Egress Finality October 2026
ProtectedProcessRegistry.register(context)
if not VerifyRequiredEffectPathControls(process, context):
TerminateProcess(process) ProtectedProcessRegistry.revoke(context)
return DENIED
ResumeProcess(process)
return context
The implementation must define how the platform establishes a stable
process reference and how failure during initialization is handled.
Creation in a suspended state is an illustrative platform-dependent
mechanism rather than a universally available requirement.
S-4.35 - Algorithm B: Process-Originated Operation Interception
function InterceptProcessOperation(channel, request):
process_context = AuthenticateProcessContext(channel)
if process_context is invalid:
return DENIED
if not IsCurrentProcessGeneration(process_context):
return DENIED operation = ConstructControlledSnapshot(request)
if not IsGovernedOperation(operation):
return EvaluateApplicableOrdinaryPolicy(operation)
candidate_id = AllocateCandidateActID()
descriptor = Canonicalize({
candidate_id: candidate_id, origin: process_context, operation:
operation, authority_generation: CurrentAuthorityGeneration(
process_context
), intended_sink: ResolveRequiredFinalitySink(operation) })
ProtectedOperationRegistry.stage(
Das Expires 25 April 2027 [Page 240]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate_id, operation,
descriptor )
return PED.Validate(candidate_id, descriptor)
The controlled interface must actually prevent the governed effect
before authorization. Staging without effect prevention is
insufficient.
7.4.97. S-4.36 - Algorithm C: Process-Lineage Authorization
function ValidateProcessLineage(process_context, operation):
lineage = ProtectedLineageRegistry.lookup(
process_context.process_instance )
if lineage is unavailable:
return DENIED
if not VerifyLineageGeneration(lineage):
return DENIED
if not VerifyAuthorizedTaskAssociation(
lineage, operation.task_id ):
return DENIED
if not VerifyDelegatedOperationScope(
lineage, operation ):
return DENIED
return APPROVED
Lineage verification may be included as a mandatory or optional
predicate according to the relevant enforcement point and policy.
7.4.98. S-4.37 - Algorithm D: PED Validation
function ValidateCandidate(candidate_id, descriptor):
record = ProtectedOperationRegistry.get(candidate_id)
Das Expires 25 April 2027 [Page 241]
Internet-Draft Sandbox Credential Egress Finality October 2026
if record.status != STAGED:
return DENIED
if not VerifyOriginBinding(descriptor, record):
return DENIED
authority = ProtectedAuthorityRegistry.lookup(descriptor)
if not EvaluateRequiredAuthorityPredicates(
descriptor, authority ):
ProtectedOperationRegistry.deny(candidate_id) return DENIED evidence
= CommitProtectedValidationEvidence(
descriptor, authority )
capability = EstablishScopedNonBearerCapability({
candidate_id: candidate_id, evidence_reference: evidence.id,
descriptor_digest: Hash(descriptor), permitted_sink:
descriptor.intended_sink, permitted_scope: authority.approved_scope,
authority_generation: authority.generation })
if not ActivateAuthorizationAtomically(
candidate_id, evidence, capability ):
DisableCapability(capability) return DENIED
return AUTHORIZED
The activation procedure must preserve the evidence-ordering and
protected-state requirements of the applicable enforcement point.
7.4.99. S-4.38 - Algorithm E: Finality Sink Verification
function PerformAuthorizedOperation(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED
actual_operation = ReadControlledPendingOperation(
Das Expires 25 April 2027 [Page 242]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate_id )
if actual_operation is unavailable:
return DENIED capability = ProtectedCapabilityRegistry.get(
record.capability_id )
evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
if not VerifyProtectedEvidence(evidence):
return DENIED if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED if not VerifyActualOperationCorrespondence(
actual_operation, capability ):
return DENIED if not VerifyCurrentAuthorityState(capability):
return DENIED if not VerifySinkLocalProtectedState(capability):
return DENIED if not AtomicallyReserveAuthorization(capability):
return DENIED result = DispatchThroughControlledResourceInterface(
actual_operation )
ReconcileOutcome(candidate_id, result)
return result
The controlled resource interface must preserve the verified
operation parameters through execution.
S-4.39 - Algorithm F: Process Termination and Outstanding Operations
function TerminateAgentProcess(process_instance, generation):
ProtectedProcessRegistry.markStopping(
process_instance, generation )
BlockNewGovernedRequests(process_instance, generation)
Das Expires 25 April 2027 [Page 243]
Internet-Draft Sandbox Credential Egress Finality October 2026
descendants = ProtectedLineageRegistry.listDescendants(
process_instance, generation )
ApplyRequiredDescendantRestrictions(descendants)
operations = ProtectedOperationRegistry.listByOrigin(
process_instance, generation )
for each operation in operations:
if operation.status == COMPLETED:
continue
if operation.status in [STAGED, AUTHORIZED]:
if not PermitIndependentContinuation(operation):
CancelOrRevoke(operation)
if operation.status in [
RESERVED, DISPATCHED, INDETERMINATE ]:
MarkForReconciliation(operation)
ProtectedProcessRegistry.revokeGeneration(generation)
TerminateOrRestrictProcessTree(
process_instance, descendants )
return TERMINATED
The implementation must address races between process termination,
authorization, child creation, and dispatch.
7.4.100. PART XII - WORKED TECHNICAL EXAMPLES
S-4.40 - Example A: AI Coding Assistant Modifying a Protected
Repository
The following is a hypothetical implementation.
An AI coding assistant executes as an ordinary restricted operating-
system process.
Das Expires 25 April 2027 [Page 244]
Internet-Draft Sandbox Credential Egress Finality October 2026
The assistant can read and modify a designated temporary workspace.
It cannot directly push modifications to a protected enterprise
repository.
A privileged repository broker controls the external repository
operation.
The agent generates a proposed modification to a configuration file.
The broker receives the request through an authenticated IPC
interface.
The system constructs a Candidate Act identifying:
| x | Agent execution context. |
| - | ---------------------------------- |
| x | Task identity. |
| x | Repository. |
| x | Target branch. |
| x | Target file. |
| x | Proposed content digest. |
| x | Applicable resource-state version. |
| x | Authorized effectuation boundary. |
The PED validates the permitted task, repository scope, operation
class, and required resource state.
Protected validation evidence is committed.
A scoped non-bearer capability is established.
The Finality Sink reconstructs the actual pending repository
modification.
If the final operation targets an unauthorized branch or modifies an
unauthorized file, verification fails.
If the required conditions are satisfied, the modification is
performed through the controlled repository interface.
The authorization is consumed according to the applicable usage
policy.
S-4.41 - Example B: Inherited File Descriptor Attack
An agent process is launched with a restricted filesystem policy.
Das Expires 25 April 2027 [Page 245]
Internet-Draft Sandbox Credential Egress Finality October 2026
However, the process inherits an already-open writable file
descriptor associated with a protected resource.
The agent attempts to use the descriptor to modify the resource.
If the descriptor permits an unmediated consequential write, ordinary
pathname restrictions may not prevent the operation.
In a compliant protected implementation, the launch configuration
prevents inheritance of that descriptor, restricts the effective
handle rights, or ensures that the underlying effect is subject to an
applicable enforcement mechanism.
This example demonstrates that process isolation requires examination
of actual resource capabilities, not merely process labels or user
identities.
S-4.42 - Example C: Child Process Attempts an Unauthorized External
Operation
An AI agent launches a child process to generate a report.
The child is associated with the parent task and a restricted
delegation scope.
The child attempts to transmit a confidential data file to an
unauthorized destination.
The operation reaches a controlled effectuation interface.
The source context and delegated task relationship are identified.
The PED evaluates the attempted disclosure against the relevant
authority scope.
The request exceeds the permitted disclosure envelope.
No scoped finality capability is established.
The Finality Sink prevents transmission.
The parent-child relationship does not independently authorize the
attempted operation.
7.4.101. S-4.43 - Example D: Privileged Credential Broker
An AI agent operates under a restricted process identity.
Das Expires 25 April 2027 [Page 246]
Internet-Draft Sandbox Credential Egress Finality October 2026
The agent requires access to a service supporting privileged resource
modifications.
The reusable service credential is retained by a protected broker.
The agent submits a structured resource-modification request through
IPC.
The broker stages the request.
The PED validates the actual operation, target resource, task
identity, and authority state.
Following successful validation, protected evidence and scoped
finality authorization are established.
The broker constructs the final credential-bearing request.
The Finality Sink verifies the actual operation before the credential
is used to produce the governed external effect.
The credential is not placed into agent-controlled process memory.
The implementation must also address accidental disclosure through
logs, errors, shared memory, debug interfaces, and tool responses.
S-4.44 - Example E: Parent Process Termination During Asynchronous
Execution
An agent process requests an authorized resource update.
The Finality Sink dispatches the operation.
The agent process terminates before receiving confirmation.
A replacement process starts and attempts to repeat the update.
The protected operation registry identifies the earlier operation as
DISPATCHED or INDETERMINATE.
The system performs the applicable reconciliation procedure rather
than blindly repeating the effect.
Where supported, an external operation identifier or idempotency
mechanism may be used.
If the external outcome cannot be established, it remains explicitly
unresolved.
Das Expires 25 April 2027 [Page 247]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.102. PART XIII - FAILURE AND ADVERSARIAL CASES
7.4.103. S-4.45 - Representative Failure Cases
7.4.104. F1 - Process Identifier Reuse
A new process receives the same numerical PID as a terminated
process.
The system distinguishes the instances through protected execution-
generation or stable process-instance information.
Stale authorization is rejected.
7.4.105. F2 - Inherited Privileged Handle
A child process receives an effect-capable handle that bypasses a
designated broker.
The handle-inheritance or resource-control mechanism prevents the
unauthorized path.
7.4.106. F3 - Handle Duplication
An agent transfers a privileged handle to another process.
The applicable handle-transfer or effectuation control prevents
unauthorized use.
7.4.107. F4 - Unauthorized IPC
An agent connects to a privileged service through an unintended IPC
endpoint.
The service authenticates the caller and enforces applicable resource
authorization rather than trusting the connection alone.
7.4.108. F5 - Parent Process Termination
A parent process terminates while child processes remain active.
The Process-Lineage Controller identifies affected descendants and
applies required restrictions.
Outstanding effects are reconciled independently.
Das Expires 25 April 2027 [Page 248]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.109. F6 - Process-Token Substitution
An agent attempts to use an unauthorized security identity or token.
The operating-system protection and broker authentication mechanisms
enforce the relevant identity restrictions.
7.4.110. F7 - Mutable Shared-Memory Request
The agent modifies a shared-memory request after validation.
The Finality Sink uses a stable controlled representation or
revalidates the actual operation before effectuation.
7.4.111. F8 - Resource-Path Substitution
An authorized path resolves to a different resource at effectuation.
The sink verifies the required effective resource identity.
7.4.112. F9 - Authority Revocation
A task's authority is revoked after initial validation.
The sink checks applicable current authority or revocation state
before effectuation.
7.4.113. F10 - Capability Replay
An already consumed single-use capability is presented again.
Protected consumption state rejects the replay.
7.4.114. F11 - Concurrent Capability Presentation
Two processes present the same single-use authorization.
The protected atomic consumption mechanism prevents unauthorized
duplicate use.
7.4.115. F12 - Broker Process Crash
A broker crashes after a request may have been dispatched.
The protected operation registry preserves an explicit unresolved
outcome and prevents blind repetition.
Das Expires 25 April 2027 [Page 249]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.116. F13 - PED Unavailability
The required PED becomes unavailable.
The governed operation remains withheld or transitions to a defined
denied or canceled state.
7.4.117. F14 - Finality Sink Unavailability
The sink becomes unavailable.
The system does not route the operation through an uncontrolled
interface as a permissive fallback.
7.4.118. F15 - Process Escape or Privilege Escalation
An agent exploits a flaw allowing it to gain additional operating-
system privileges.
A software-only embodiment may fail if the attack compromises its
trusted enforcement boundary.
A stronger embodiment requires appropriately placed additional
protection.
7.4.119. F16 - Unobserved Process Activity
A process-observation subsystem loses relevant events.
Where authorization depends on observation coverage, the
corresponding security state is marked incomplete or uncertain.
Observation loss is not treated as proof that the workload remained
safe.
7.4.120. F17 - Cross-Task Confusion
Two agent tasks execute under the same operating-system user
identity.
The protected authorization system distinguishes their task and
process-instance contexts rather than granting identical
consequential-operation authority solely because their operating-
system user identifiers match.
Das Expires 25 April 2027 [Page 250]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.121. F18 - Alternative Network Route
An agent process uses an allowed network interface that bypasses the
intended proxy.
A non-bypassable egress embodiment must restrict or mediate that
route.
7.4.122. F19 - Reused Broker Session
An earlier agent process terminates but leaves an IPC session or
authenticated request state.
A replacement process cannot automatically inherit the former
process's protected authority.
7.4.123. F20 - Kernel Compromise
An attacker compromises the operating-system kernel underlying a
software-only processisolation mechanism.
The protection guarantee may fail under that adversary.
Resistance requires additional protection mechanisms, rather than an
unsupported assertion that process isolation is equivalent to
hardware-enforced cryptographic separation.
7.4.124. PART XIV - HARDWARE, SOFTWARE, AND HYBRID VARIATIONS
7.4.125. S-4.46 - Software-Only Process Enforcement
The agent operates as a restricted process.
A host-side security service performs protected authorization under
the host trust assumptions.
A broker or resource controller acts as the Finality Sink.
The system does not require a hypervisor, micro-VM, or container.
7.4.126. S-4.47 - Kernel-Mediated Enforcement
An applicable kernel security mechanism controls selected resource
accesses.
The kernel mechanism may enforce preliminary restrictions or an
operation-specific decision received from a protected authorization
service.
Das Expires 25 April 2027 [Page 251]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where required, the corresponding effectuation operation remains
subject to protected finality verification.
7.4.127. S-4.48 - TEE-Assisted Enforcement
The agent remains an ordinary operating-system process.
A TEE performs protected authorization-state or validation functions.
A protected effectuation interface verifies the applicable finality
authorization before permitting the governed consequence.
The implementation must address how untrusted host software is
prevented from bypassing the claimed protected effectuation boundary.
7.4.128. S-4.49 - HSM-Assisted Credential Control
The agent uses a restricted process identity.
An HSM or protected cryptographic service controls specified
credential or signing operations.
The PED authorizes the relevant operation.
A controlled credential-use or signing interface verifies the
required bounded authorization.
An HSM used merely as unrestricted key storage does not automatically
provide the full required protected-finality mechanism.
7.4.129. S-4.50 - SmartNIC/DPU Network Enforcement
The agent operates as a restricted process on a host.
A programmable network controller governs selected outgoing network
effects.
The device receives authenticated process or workload context through
a trusted association mechanism.
The protected controller evaluates or verifies the applicable
authorization before transmission.
Where per-process network authority is required, the implementation
must account for multiplexed connections, shared sockets, and
process-to-flow attribution.
Das Expires 25 April 2027 [Page 252]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.4.130. S-4.51 - Hardware Device-Command Enforcement
The agent process generates a device operation.
A host-side controller stages the corresponding command.
A PED validates the requested operation.
A hardware or firmware Finality Sink verifies the applicable bounded
authorization before admitting the command to the governed device
execution interface.
The architecture may be used for accelerators, storage devices,
peripheral controllers, or cyber-physical systems.
7.4.131. S-4.52 - Remote Protected Broker
The agent process communicates with a remote protected service.
The remote service authenticates the operation and relevant process
or task context.
The PED may operate remotely.
A Finality Sink performs the actual consequential operation at the
resource boundary.
The implementation must address authenticated context transfer,
replay protection, state consistency, and remote failure handling.
7.4.132. S-4.53 - Single-Component Enforcement
A single protected service or device may implement validation,
protected evidence, scoped enablement, and Finality Sink
verification.
Distinct functional stages remain identifiable according to the
applicable enforcement point.
Physical separation is not required unless expressly claimed.
7.4.133. PART XV - REPRESENTATIVE DATA STRUCTURES
7.4.134. S-4.54 - ProcessContextRecord
Fields may include:
Das Expires 25 April 2027 [Page 253]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. ProcessInstanceID. 2. ProcessGeneration. 3. AgentContextID. 4.
TaskID. 5. SecurityPrincipal. 6. IsolationProfile. 7.
AuthorityGeneration. 8. ControlledIPCReferences. 9.
ProcessLineageReference. 10. LifecycleStatus.
7.4.135. S-4.55 - ProcessLineageRecord
Fields may include:
1. ParentProcessInstanceID. 2. ChildProcessInstanceID. 3.
CreationGeneration. 4. AgentContextID. 5. TaskID. 6.
ExecutableReference. 7. DelegatedAuthorityScope. 8.
RelevantSecurityContext. 9. LifecycleStatus. 10.
LineageVerificationState.
7.4.136. S-4.56 - HandleControlRecord
Fields may include:
1. HandleReference. 2. OwningProcessInstance. 3. ResourceIdentity.
4. GrantedAccessClass. 5. TransferRestriction. 6.
InheritanceRestriction. 7. RequiredBrokerInterface. 8.
RevocationGeneration. 9. EnforcementStatus. 10. LastVerifiedState.
7.4.137. S-4.57 - CandidateActRecord
Fields may include:
1. CandidateActID. 2. OriginProcessInstanceID. 3.
OriginProcessGeneration. 4. AgentContextID. 5. TaskID. 6.
OperationClass. 7. TargetResource. 8. DescriptorDigest. 9.
AuthorityGeneration. 10. CandidateStatus.
7.4.138. S-4.58 - ProtectedValidationEvidenceRecord
Fields may include:
1. EvidenceID. 2. CandidateActID. 3. DescriptorDigest. 4.
PEDIdentity. 5. PolicyGeneration. 6. ValidationResult. 7.
ProtectedCommitment. 8. EvidenceGeneration. 9. AuthorizedSinkID.
10. ValidityCondition.
7.4.139. S-4.59 - ScopedFinalityCapabilityRecord
Fields may include:
1. 2. 3.
Das Expires 25 April 2027 [Page 254]
Internet-Draft Sandbox Credential Egress Finality October 2026
CapabilityID. CandidateActID. EvidenceReference.
4. AuthorizedResourceScope. 5. AuthorizedSinkID. 6.
AuthorityGeneration. 7. ProcessOrTaskBinding. 8. UsagePolicy. 9.
ExpiryCondition. 10. CapabilityStatus.
7.4.140. S-4.60 - SinkLocalStateRecord
Fields may include:
1. SinkID. 2. CapabilityID. 3. CandidateActID. 4.
ExpectedOperationDigest. 5. ResourceIdentity. 6.
AuthorityGeneration. 7. RevocationGeneration. 8. ConsumptionStatus.
9. DispatchStatus. 10. CompletionReference.
7.4.141. S-4.61 - OutstandingOperationRecord
Fields may include:
1. OperationID. 2. CandidateActID. 3. OriginProcessGeneration. 4.
TaskID. 5. CapabilityReference. 6. ExternalOperationID. 7.
DispatchState. 8. CompletionState. 9. ReconciliationState. 10.
LastProtectedTransition.
These are logical examples. An implementation may combine or
partition the records while preserving the properties required by the
corresponding enforcement points.
7.4.142. PART XVI - implementer IMPLEMENTATION AND VERIFICATION
7.4.143. S-4.62 - Proposed Engineering Tests
The following tests are proposed validation procedures rather than
completed experiments.
Test Condition Expected behavior
Das Expires 25 April 2027 [Page 255]
Internet-Draft Sandbox Credential Egress Finality October 2026
T1 Authorized process operation T2 Unauthorized task operation T3
Spoofed process identity T4 Reused numerical PID T5 Inherited
privileged descriptor T6 Duplicated protected handle T7 Child process
delegation T8 Parent process termination T9 Missing finality
capability T10 Replayed capability T11 Material operation
substitution T12 Mutable shared-memory buffer T13 Resource path
substitution T14 Revoked authority generation T15 Concurrent single-
use attempt T16 Broker crash T17 PED unavailable T18 Sink unavailable
T19 Alternative network path T20 Cross-task same-user access T21
Asynchronous worker continuation Required continuation authority
verified T22 Credential exposure attempt T23 Kernel enforcement
bypass attempt Controlled protection properties tested T24 Host
compromise scenario
Controlled effectuation succeeds Denied Authenticated context
prevails Stale generation rejected Unauthorized access prevented
Transfer or use constrained Applicable scope enforced Descendant and
operation states reconciled Effectuation denied Rejected Mismatch
detected Stable effect verified Effective resource checked Invalid
operation withheld Atomic consumption enforced Unresolved outcome
retained No implicit authorization No uncontrolled fallback Governed
effect blocked or mediated Task-specific authority preserved
Protected credential remains inaccessible
Trust-model limitations established
For a production embodiment, the tests must be adapted to the
selected operating system and actual enforcement mechanisms.
7.4.144. PART XVIII - Enforcement-Point Mapping and Technical
Correspondence
7.4.145. S-4.72 - Representative Enforcement Point Support
this implementation profile provides technical disclosure potentially
relevant to enforcement points concerning:
(a) restricted AI-agent execution; (b) operation-specific protected
authorization; (c) ordinary operating-system process sandboxing; (d)
process-origin identity binding;
(e) process-lineage governance;
(f) inherited and duplicated handle control;
(g) tool-dispatch mediation;
Das Expires 25 April 2027 [Page 256]
Internet-Draft Sandbox Credential Egress Finality October 2026
(h) protected credential-use interfaces;
(i) Candidate Act staging;
(j) protected validation evidence;
(k) scoped non-bearer capabilities;
(l) Finality Sink verification;
(m) resource identity and actual-operation correspondence;
(n) asynchronous operation control;
(o) revocation and state reconciliation;
(p) operating-system kernel enforcement; and
(q) software-hardware hybrid implementation.
This embodiment may contribute technical support to the sandbox-
finality, process-lineage, credential-use, effectuation-path, and
delegated-operation enforcement point families.
Actual support for the final enforcement points must be established
through a limitation-by-limitation enforcement point-to-specification
mapping.
7.4.146. S-4.73 - Relationship to Other Embodiments
This embodiment differs from virtual-machine and container-oriented
embodiments because its primary isolation mechanism may consist of
ordinary operating-system process security rather than a separate
guest environment or container runtime.
Its distinguishing implementation details include:
1. Process access tokens and security principals. 2. Process-
instance identity and PID reuse. 3. Native operating-system access
control. 4. File descriptors and object handles. 5. Handle
inheritance and duplication. 6. Process-tree and child-process
governance. 7. Privileged broker IPC. 8. Cross-task execution under
shared operating-system identities.
9. Native operating-system resource interfaces. 10. Process
termination and asynchronous operation continuity.
Das Expires 25 April 2027 [Page 257]
Internet-Draft Sandbox Credential Egress Finality October 2026
The disclosed features may also be combined with containerized or
virtual-machine deployments where appropriate.
7.4.147. S-4.74 - implementer Enablement Requirements
For a concrete process-isolated implementation, a person having
ordinary skill in the art
identifies:
1. The operating system and supported version. 2. The agent
executable and task identity. 3. The intended adversary and trusted
computing base. 4. The process isolation mechanism. 5. The process-
instance identity and generation mechanism. 6. The permissible
child-process behavior. 7. The handle-inheritance restrictions. 8.
The IPC authentication mechanism. 9. The effect-capable resources
requiring protection. 10. The available routes to each protected
resource. 11. The mechanism preventing direct unauthorized
effectuation. 12. The Candidate Act interception and staging
procedure. 13. The descriptor schema and canonicalization rules. 14.
The PED and protected state arrangement. 15. The required
authorization predicates. 16. The protected evidence-commitment
mechanism. 17. The scoped capability representation. 18. The
Finality Sink actual-operation verification procedure. 19. The
protected consumption-state transition. 20. The operation completion
and reconciliation mechanism. 21. The process termination and
restart policy. 22. The handling of stale or transferred resource
handles. 23. The treatment of privilege escalation and enforcement
failures. 24. The implementation-specific tests confirming the
required security properties.
Where a particular enforcement point requires additional resistance
to privileged host compromise or cryptographic isolation, the
disclosure must identify the corresponding hardware or cryptographic
mechanism that supplies those properties.
7.4.148. S-4.75 - Technical Effect
this implementation profile provides an architecture in which an AI
agent may execute as a restricted operating-system process without
requiring deployment inside a separate container or virtual machine.
The agent's ability to perform internal computation or invoke a
permitted process interface remains distinguishable from authority to
produce a specified consequential effect.
Das Expires 25 April 2027 [Page 258]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system may combine process-level privilege separation, protected
broker mediation, independent authorization, protected evidence,
scoped finality enablement, and effectuationboundary verification.
Process identity, process lineage, inherited handles, and
asynchronous operation state are incorporated into the authorization
and enforcement model where relevant.
The technical effect is control of designated consequential
operations despite the agent's ability to generate commands, spawn
permitted subprocesses, or request services through available
operating-system interfaces.
The strength of the protection depends on the actual process
restrictions, trusted computing base, and controlled effectuation
paths.
7.4.149. S-4.76 - Technical Summary
this implementation profile discloses a process-isolated artificial-
intelligence-agent execution architecture in which an agent executes
as one or more restricted operating-system processes and selected
consequential operations remain subject to independent protected
authorization.
A Process Isolation Controller restricts resource access and process
privileges.
A Process Context Registry establishes authenticated execution
identity.
A Process-Lineage Controller associates relevant child processes and
delegated workers with their originating tasks.
A Resource and Handle Mediation Controller restricts unauthorized
effect-capable handles.
A controlled IPC or broker interface captures governed operations and
establishes Candidate Acts.
A Non-Effective Operation Holder prevents premature effectuation.
A Protected Enforcement Domain evaluates the applicable authority
predicates and commits protected validation evidence.
A scoped non-bearer capability provides bounded finality enablement.
Das Expires 25 April 2027 [Page 259]
Internet-Draft Sandbox Credential Egress Finality October 2026
A Finality Sink independently verifies the actual pending operation
and required protected authorization conditions before the
consequential effect is permitted.
The architecture may be implemented using Linux, Windows, macOS,
another operating system, software security services, kernel
mechanisms, protected hardware, or combinations thereof.
The embodiment is not limited to any particular process-sandbox
product or operating-system vendor.
7.4.149.1. KERNEL- AND HYPERVISOR-MEDIATED ARTIFICIAL-INTELLIGENCE-
AGENT EXECUTION WITH PROTECTED AUTHORITY ENFORCEMENT, NON-
7.4.149.2. BYPASSABLE EFFECTUATION CONTROL, AND HARDWARE-SOFTWARE
FINALITY VERIFICATION
7.5. Implementation Profile C-21
Source location: original disclosure pages 565-630. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.5.1. C-21.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, continuing autonomous execution, protected authorization,
runtime behavioral validation, session-state management, bounded
operation grants, execution-finality enforcement, protected evidence
commitments, and secure recovery of long-lived or intermittently
executing computational workloads.
More particularly, the embodiment discloses a computer-implemented
method and corresponding apparatus for controlling a continuing
artificial-intelligence-agent session in which successive
consequential operations are identified, grouped, bounded, validated,
and effectuated through protected enforcement interfaces without
treating an earlier session-level approval as indefinite
authorization.
The system may operate through:
(a) process-isolated agent runtimes; (b) containerized execution
environments; (c) virtual machines; (d) micro-virtual machines; (e)
cloud-hosted agent services; (f) autonomous workflow engines;
(g) managed tool-execution platforms;
Das Expires 25 April 2027 [Page 260]
Internet-Draft Sandbox Credential Egress Finality October 2026
(h) long-running browser or computer-use agents;
(i) protected service gateways;
(j) hardware-assisted enforcement components;
(k) secure transaction processors;
(l) distributed Finality Sinks; or
(m) combinations thereof.
The system may employ individual Candidate Act authorization, bounded
groups of operations, finite effectuation windows, or combinations of
these arrangements.
The implementation need not require a separate network authorization
request for every lowrisk suboperation when an appropriately bounded
and protected authorization window covers the operation actually
presented for effectuation.
Nevertheless, the execution interface must enforce the currently
applicable boundaries of that window.
7.5.2. C-21.2 - Technical Problem
An artificial-intelligence agent may execute for an extended period
during which it repeatedly observes information, makes decisions,
selects tools, communicates with services, modifies resources, or
delegates tasks.
At session initiation, an operator or policy controller may assign an
initial permission envelope.
That envelope may identify permissible tool classes, resources,
destinations, or computational functions.
However, conditions relevant to authorization may change during
execution.
1. 2. 3. 4. 5. 6. 7. 8.
Examples include:
Das Expires 25 April 2027 [Page 261]
Internet-Draft Sandbox Credential Egress Finality October 2026
Changes in the agent's observed runtime behavior. Changes in its
task. New or substituted tool interfaces. Newly retrieved untrusted
instructions. Changes in permitted destination scope. Changes in
policy or authorization. Revocation of a delegated principal.
Exhaustion of permitted usage.
9. Changes in risk classification. 10. Process or container
restart. 11. Snapshot restoration. 12. Virtual-machine migration.
13. Delayed asynchronous operations. 14. Loss of enforcement
connectivity. 15. Changes in the actual operation performed by a
connector. 16. Reuse of an expired session grant. 17. Multiple
concurrent operations consuming a shared budget.
An initial authorization may have been appropriate when the session
began but insufficient to authorize a particular later effect.
Revalidating every aspect of policy through a remote service for
every small suboperation may introduce significant latency.
Conversely, granting unrestricted standing authorization may permit
effects outside current policy, scope, or behavioral conditions.
this implementation profile addresses this technical conflict through
protected session state, finite authorization windows, bounded
consumption, current Finality Sink verification, and periodic or
event-triggered protected revalidation.
7.5.3. C-21.3 - Central Technical Principle
The system distinguishes three kinds of authority.
Initial Permission Envelope: Defines the broad operational boundaries
within which the
agent may perform computation and request controlled operations.
Protected Window or Candidate Authorization: Establishes a narrower,
current
authorization for specified operations, resource classes, quantities,
destinations, durations, or operation sequences.
Finality Sink Verification: Determines whether the actual pending
operation satisfies the
current protected authorization and applicable protected state.
Das Expires 25 April 2027 [Page 262]
Internet-Draft Sandbox Credential Egress Finality October 2026
The initial permission envelope is not, by itself, an independently
sufficient finality grant for all subsequent consequential
operations.
A representative authorization relationship is:
PERMITTED EFFECT =
VALID SESSION
AND CURRENT AUTHORITY
AND REQUIRED BEHAVIORAL CONDITIONS
AND VALID BOUNDED GRANT
AND OPERATION WITHIN SCOPE
AND AVAILABLE PROTECTED BUDGET
AND VALID SINK-LOCAL STATE
The particular predicates depend upon the applicable enforcement
point and operation class.
7.5.4. PART I - PRINCIPAL SYSTEM ARCHITECTURE
7.5.5. C-21.4 - Principal Components
A representative implementation comprises the following components.
7.5.6. Component A - Continuing Agent Execution Environment
A sandboxed runtime configured to execute an artificial-intelligence
agent across multiple computational and consequential operations.
7.5.7. Component B - Protected Session Controller
A mechanism configured to establish, track, suspend, revoke, and
terminate session identity and authority state.
7.5.8. Component C - Initial Permission Envelope Controller
A component configured to establish the broad permissible task, tool,
resource, and operation limits at session initialization.
Das Expires 25 April 2027 [Page 263]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.9. Component D - Consequential Operation Interceptor
A mechanism configured to capture successive proposed operations
before the governed external effects.
7.5.10. Component E - Candidate Act and Window Classifier
A component configured to classify operations as individual Candidate
Acts, bounded operation groups, or finite effectuation windows.
7.5.11. Component F - Canonical Operation Descriptor Generator
A mechanism configured to generate machine-verifiable representations
of proposed or actual operations.
7.5.12. Component G - Protected Enforcement Domain
A PED configured to evaluate the required authority, runtime
behavior, policy, scope, freshness, and protected-state predicates.
7.5.13. Component H - Protected Session State Registry
An integrity-protected registry maintaining the authoritative session
state, generations, finality history, grants, consumption, and
revocation information.
7.5.14. Component I - Runtime Behavioral Descriptor Collector
A mechanism configured to observe relevant agent activity and
generate successive Runtime Behavioral Descriptors.
7.5.15. Component J - Behavioral Validation Controller
A component configured to compare required runtime behavior against
approved Algorithmic Logic Fingerprints, command graphs, tool-use
patterns, or other permitted behavioral constraints.
7.5.16. Component K - Protected Micro-Validation Controller
A mechanism configured to create or commit compact protected
validation records or operation-state transitions.
7.5.17. Component L - Micro-Validation Chain Controller
A component configured to maintain ordered, integrity-protected
relationships among successive authorized operations.
Das Expires 25 April 2027 [Page 264]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.18. Component M - Bounded Window Authorization Controller
A component configured to establish operation, duration, byte,
destination, or resourcespecific permission windows.
7.5.19. Component N - Protected Budget Controller
A component configured to maintain and enforce required authorization
and resourceconsumption limits.
7.5.20. Component O - Scoped Finality Enablement Controller
A protected mechanism configured to establish bounded authorization
for a Candidate Act, operation group, or finite window.
7.5.21. Component P - Finality Sink
A technically controlled effectuation interface configured to verify
the applicable bounded authorization before the governed consequence
occurs.
7.5.22. Component Q - Low-Latency Enforcement Controller
A mechanism configured to verify current protected grants locally or
through a boundedlatency protected interface.
7.5.23. Component R - Session Recovery and Migration Controller
A component configured to protect session authority against replay,
restart, snapshot restoration, failover, and migration-related
inconsistencies.
7.5.24. Component S - Outstanding Operation Registry
A mechanism configured to maintain the status of queued, reserved,
dispatched, completed, denied, or indeterminate operations.
The components may be implemented within one protected computer,
distributed software services, hardware-protected devices, or a
hybrid system.
7.5.25. C-21.5 - Reference Continuous-Session Architecture
A representative execution path is:
SESSION INITIALIZATION
↓
Das Expires 25 April 2027 [Page 265]
Internet-Draft Sandbox Credential Egress Finality October 2026
INITIAL PERMISSION ENVELOPE
↓
PROTECTED SESSION REGISTRATION
↓
AGENT COMPUTATION
↓
SUCCESSIVE OPERATION INTERCEPTION
↓
CANDIDATE ACT OR FINITE WINDOW CLASSIFICATION
↓
RUNTIME AND AUTHORITY VALIDATION
↓
PROTECTED MICRO-VALIDATION COMMITMENT
↓
BOUNDED FINALITY GRANT
↓
FINALITY SINK VERIFICATION
↓
AUTHORIZED EFFECTUATION
↓
PROTECTED CONSUMPTION AND CHAIN UPDATE
↓
SESSION CONTINUATION OR REVALIDATION
The sequence may repeat as long as the session remains valid.
Das Expires 25 April 2027 [Page 266]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system may establish a new window when the earlier window
expires, is consumed, is revoked, or otherwise becomes invalid.
7.5.26. PART II - PROTECTED SESSION IDENTITY
7.5.27. C-21.6 - Continuing Agent Session
A Continuing Agent Session means an execution context within which an
agent performs multiple operations over time under an associated task
and session identity.
The session may persist across:
(a) multiple model inference calls; (b) tool invocations; (c)
asynchronous operations; (d) process restarts; (e) container
recreation;
(f) delegated workers;
(g) selected network disruptions; or
(h) authorized execution-environment migration.
Continuity of task identity does not necessarily imply continuity of
finality authority.
7.5.28. C-21.7 - Protected Session Identity
A representative session record comprises:
SessionID = SESSION-2101
AgentContextID = AGENT-42
TaskID = TASK-204
SessionGeneration = 71
ExecutionGeneration = 12
PolicyGeneration = 105
RevocationGeneration = 27
SessionStatus = ACTIVE
InitialPermissionEnvelope = ENV-21
Das Expires 25 April 2027 [Page 267]
Internet-Draft Sandbox Credential Egress Finality October 2026
CurrentWindowID = WINDOW-2101
The values are illustrative.
The session identity is associated with a protected execution context
and applicable authority state.
An agent-supplied session identifier alone is insufficient to
establish protected session continuity.
7.5.29. C-21.8 - Session Identity Versus Process Identity
An operating-system process identifier may be reused.
A container may restart.
A virtual-machine instance may be replaced.
Accordingly, a protected session identifier may be associated with
additional executiongeneration information.
A representative compound identity is:
(SessionID, ExecutionGeneration, AuthorityGeneration)
The protected controller uses these fields to distinguish an
authorized continuation from an unauthorized attempt to reuse earlier
process or session state.
7.5.30. C-21.9 - Session Lifecycle States
A representative session state machine comprises:
CREATED
INITIALIZING
ACTIVE
REVALIDATION_REQUIRED
SUSPENDED
REVOKED
RECOVERY_REQUIRED
TERMINATED
Das Expires 25 April 2027 [Page 268]
Internet-Draft Sandbox Credential Egress Finality October 2026
An ACTIVE session may request bounded operation grants.
A session entering REVALIDATION_REQUIRED may continue permitted
internal computation while governed external effects remain
restricted.
A REVOKED session cannot obtain additional finality authorization
without an independently authorized state transition.
7.5.31. PART III - INITIAL PERMISSION ENVELOPE
7.5.32. C-21.10 - Initial Permission Envelope
An Initial Permission Envelope comprises a machine-readable
representation of permissions assigned to the agent when the session
begins.
The envelope may specify:
1. Permitted task. 2. Tool classes. 3. Resource classes. 4.
Destination categories. 5. Maximum session duration. 6. Permitted
agent delegation. 7. Restricted data classes. 8. Operation-risk
classes. 9. Authorization conditions. 10. Required enforcement
interfaces.
The envelope establishes constraints on the operations the agent may
request.
It does not independently authorize every later consequential effect.
7.5.33. C-21.11 - Permission Envelope Example
A representative envelope comprises:
EnvelopeID = ENV-21
AgentID = AGENT-42
TaskID = TASK-204
AllowedToolClasses = READ, SUMMARIZE, SEND_APPROVED
AllowedDestinationScope = DOMAIN-A
MaximumSessionDuration = 3600_SECONDS
MaximumNetworkBytes = 1000000
Das Expires 25 April 2027 [Page 269]
Internet-Draft Sandbox Credential Egress Finality October 2026
MaximumCredentialUses = 10
PolicyGeneration = 105
RequiredFinalityMode = WINDOW_OR_PER_ACT
These quantities are illustrative rather than mandatory system
limits.
A particular implementation may omit or modify them according to the
authorized task.
7.5.34. C-21.12 - Initial Envelope Restriction
The sandbox enforces the condition that the agent cannot produce a
governed external effect solely by satisfying the initial permission
envelope.
For example, an initial envelope may permit use of a network tool.
However, an actual network transmission must still satisfy a current
Candidate Act or bounded-window finality condition.
The enforcement mechanism may comprise a protected gateway,
controlled connector, kernel-mediated resource interface, credential
broker, or hardware-backed Finality Sink.
7.5.35. PART IV - SUCCESSIVE CANDIDATE ACTS
7.5.36. C-21.13 - Successive Operation Interception
The system captures successive operations generated during the
session.
Examples include:
(a) API requests; (b) network transmissions; (c) file modifications;
(d) database updates; (e) credential-bearing operations; (f) tool
invocations; (g) delegated operations; (h) browser actions; (i)
device commands; and (j) persistent resource mutations.
The interceptor identifies the operations requiring protected
finality.
7.5.37. C-21.14 - Per-Act Authorization Mode
In a per-act mode, each governed consequential operation is
represented by an individual Candidate Act.
Das Expires 25 April 2027 [Page 270]
Internet-Draft Sandbox Credential Egress Finality October 2026
The Candidate Act receives a machine-verifiable descriptor and
corresponding protected authorization.
The Finality Sink verifies the required conditions before performing
the specified effect.
This mode may be selected for high-risk, unusual, irreversible, or
narrowly scoped operations.
7.5.38. C-21.15 - Bounded Operation Group
A Bounded Operation Group comprises a defined set or class of
operations permitted under one protected grant.
For example, a grant may permit:
| x | Three writes to specified configuration records. |
| - | ------------------------------------------------------------------ |
| x | Five messages to one authorized recipient. |
| x | Ten requests to a designated API method. |
| x | A set of fixed resource operations within a protected transaction. |
| x | A limited number of file modifications under a defined path scope. |
The group must have a machine-verifiable membership and consumption
rule.
An arbitrary new operation does not become authorized merely because
it occurs during the group.
7.5.39. C-21.16 - Finite Effectuation Window
A Finite Effectuation Window means a bounded authorization interval
or operation envelope within which one or more specified
consequential operations may be performed.
The window may be limited by:
1. Time. 2. Operation count. 3. Byte count. 4. Destination. 5.
Resource identity. 6. Operation class. 7. Credential-use count. 8.
Protected command sequence. 9. Session generation. 10. Policy
generation. 11. Risk or behavioral state. 12. A combination of
limits.
A window is not an unlimited standing session permission.
Das Expires 25 April 2027 [Page 271]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.40. C-21.17 - Window Descriptor
A representative window descriptor comprises:
WindowID = WINDOW-2101
SessionID = SESSION-2101
SessionGeneration = 71
AuthorityGeneration = 105
OperationClass = NETWORK_SEND
DestinationScope = DOMAIN-A
MaximumOperations = 5
MaximumBytes = 4096
ExpiryReference = TIME-2101
RequiredSinkID = FS-NET-21
WindowStatus = ACTIVE
The numbers are illustrative.
The actual encoded fields and their interpretation must be defined by
the implementation.
7.5.41. PART V - BOUNDED WINDOW AUTHORIZATION
7.5.42. C-21.18 - Window Creation
A PED may establish a bounded window after verifying the required
current session and task conditions.
The protected authorization sequence comprises:
1. Authenticate the current session. 2. Obtain the requested window
scope. 3. Check the initial permission envelope. 4. Obtain current
policy and revocation state. 5. Evaluate applicable runtime
behavioral conditions.
Das Expires 25 April 2027 [Page 272]
Internet-Draft Sandbox Credential Egress Finality October 2026
6. Verify required budget availability. 7. Commit protected
validation evidence. 8. Establish bounded finality enablement. 9.
Register the protected window state. 10. Permit individual
operations only through the applicable Finality Sink.
7.5.43. C-21.19 - Window Authorization Is Not an Unbounded Token
A bounded window grant may be represented by:
(a) an authenticated capability; (b) a protected registry entry; (c)
an internal authorization latch; (d) a secure device register; (e) a
protected queue permission; (f) a sink-local authorization state; or
(g) another suitably bounded representation.
The grant cannot be used outside the specified authority scope.
For example, a window authorizing five transmissions to Domain A does
not authorize a sixth transmission or a transmission to Domain B.
7.5.44. C-21.20 - Window Invariants
A representative implementation enforces:
Invariant W1: Every governed effect must correspond to a current
authorization.
Invariant W2: No operation may exceed the authorized window scope.
Invariant W3: Cumulative protected consumption may not exceed the
permitted budget.
Invariant W4: A window associated with an invalid authority
generation may not authorize
further effects.
Invariant W5: A replayed or consumed operation sequence may not
obtain additional
unauthorized authority.
Invariant W6: The Finality Sink verifies the actual operation at its
controlled effectuation
boundary.
Invariant W7: A window is not extended merely because an agent
continues computing.
Das Expires 25 April 2027 [Page 273]
Internet-Draft Sandbox Credential Egress Finality October 2026
Invariant W8: A required session revalidation failure prevents
further governed effectuation.
These invariants may be implemented in software, protected firmware,
hardware, or a combination thereof.
7.5.45. PART VI - MICRO-VALIDATION RECORDS
7.5.46. C-21.21 - Micro-Validation Record
A Micro-Validation Record means a compact machine-verifiable
representation of a validation outcome, protected state transition,
or authorized operation within the session.
A representative record comprises:
MicroRecordID = MR-2101
SessionID = SESSION-2101
SessionGeneration = 71
SequenceNumber = 1
CandidateActID = CA-2101
OperationDigest = DIGEST-2101
WindowID = WINDOW-2101
AuthorityGeneration = 105
ValidationOutcome = APPROVED
ProtectedTransitionReference = PT-2101
The representation may be internally stored and need not be released
as an external receipt.
7.5.47. C-21.22 - Micro-Validation Chain
Successive authorized operations may be linked through a protected
chain.
For example:
MR-2101 → MR-2102 → MR-2103
Das Expires 25 April 2027 [Page 274]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system may maintain a protected Chain Head representing the
committed session history.
A later authorized Candidate Act may depend upon a validated
representation of preceding operations or state transitions.
This relationship may be used to detect:
(a) operation replay; (b) unauthorized sequence skipping; (c)
operation substitution; (d) invalid session continuation; (e) stale
grant reuse; or (f) rollback to a prohibited earlier sequence.
7.5.48. C-21.23 - Micro-Chain Construction
A representative chain may be constructed as follows:
C0 = H( "SESSION-CHAIN-INIT" || SessionID || SessionGeneration ||
AuthorityGeneration )
For each committed operation i:
Ci = H( "SESSION-CHAIN-STEP" || Ci-1 || SequenceNumber_i ||
CandidateActID_i || OperationDigest_i || WindowID_i ||
ValidationOutcome_i || ProtectedTransitionReference_i )
Here, H represents a selected cryptographic hash function.
The encoding must specify field lengths, ordering, and
canonicalization.
The domain-separation strings distinguish the chain initialization
and update operations.
The chain head must be maintained within or authenticated by an
appropriately protected component.
An attacker who can freely replace both the chain records and the
authoritative chain head could otherwise generate an internally
consistent but unauthorized history.
7.5.49. C-21.24 - Protected Chain State
A representative record comprises:
SessionID
SessionGeneration
Das Expires 25 April 2027 [Page 275]
Internet-Draft Sandbox Credential Egress Finality October 2026
LatestSequenceNumber
LatestChainHead
CurrentAuthorityGeneration
CurrentRevocationGeneration
CurrentWindowID
ProtectedCommitmentGeneration
The authoritative chain head may be stored in a protected registry,
cryptographically authenticated state machine, secure register, or
protected persistent store.
Where rollback resistance is required, a suitable continuity or
generation mechanism is also provided.
7.5.50. C-21.25 - Chain Update Ordering
The chain may be updated when:
(a) validation evidence is committed; (b) an operation authorization
is reserved; (c) an operation is successfully effected; (d) a bounded
grant is consumed;
(e) a denial is recorded; or
(f) another protected state transition occurs.
The implementation defines which event the chain represents.
For example, a validation chain must not be described as proof of
completed external effectuation merely because it records
authorization.
An effectuation chain may additionally record verified dispatch and
outcome state.
7.5.51. C-21.26 - Chain Gaps and Sequence Reuse
A candidate operation may be assigned a sequence before its outcome
is known.
If the operation is denied or canceled, the system may:
Das Expires 25 April 2027 [Page 276]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Commit a protected denial or cancellation event. 2. Preserve an
explicit unused sequence. 3. Advance a chain transition recording
the unsuccessful operation. 4. Apply a defined sequence-allocation
rule.
A sequence number must not be silently reused in a manner permitting
ambiguity between different Candidate Acts.
For concurrent operations, the system may allocate globally ordered
chain positions at protected commit time.
7.5.52. PART VII - RUNTIME BEHAVIORAL DESCRIPTORS
7.5.53. C-21.27 - Runtime Behavioral Descriptor
A Runtime Behavioral Descriptor (RBD) means a machine-verifiable
representation of selected observed agent execution behavior.
A representative descriptor may include:
RBDRecordID
SessionID
ExecutionGeneration
ObservationWindow
ObservedToolClasses
ObservedCommandClasses
ObservedDestinations
ObservedResourceAccesses
ProcessOrWorkerLineage
RelevantSourceTrustState
PolicyGeneration
ObservationCoverageState
The exact features depend upon the selected behavioral validation
policy.
Das Expires 25 April 2027 [Page 277]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.54. C-21.28 - Behavioral Observation
The system may obtain observations through:
(a) controlled tool dispatchers; (b) protected network gateways; (c)
operating-system security hooks; (d) process observation mechanisms;
(e) connector request interfaces; (f) resource-controller events; (g)
authenticated execution records; (h) hardware monitoring interfaces;
or (i) combinations thereof.
The implementation must distinguish actual enforcement-capable
observations from incomplete monitoring.
Missing required telemetry may lead to a restrictive authorization
decision rather than an unsupported assumption that no deviation
occurred.
7.5.55. C-21.29 - Approved Algorithmic Logic Fingerprint
An approved Algorithmic Logic Fingerprint (ALF) may represent
selected authorized computational logic, execution behavior,
instruction characteristics, or policy-relevant operational
structure.
A protected approval record may include:
ApprovedALFReference
ApprovedLogicScope
PermittedExecutionGeneration
PermittedToolGraph
PolicyGeneration
ApprovalStatus
The specific ALF generation and comparison mechanism depends upon the
separately disclosed ALF implementation.
this implementation profile may employ ALF correspondence as an
optional behavioral validation predicate, as required by a selected
implementation of enforcement point(s) corresponding to source
item(s) 23.
An ALF comparison is not presumed to prove all internal semantic
behavior of an arbitrary AI model.
Das Expires 25 April 2027 [Page 278]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.56. C-21.30 - Behavioral Drift
Behavioral Drift means a policy-relevant difference between the
observed runtime descriptor and an approved behavioral envelope.
Representative drift conditions include:
1. Unauthorized tool invocation. 2. New executable class. 3.
Unexpected destination. 4. Restricted file access. 5. Changed
command graph. 6. Unauthorized delegated process. 7. Unexpected
credential-use attempt. 8. A required ALF mismatch. 9. A defined
risk-threshold crossing. 10. Loss of required runtime observation
coverage.
The actual drift conditions must be machine-defined by the selected
protected policy.
7.5.57. C-21.31 - Drift Decision
A representative decision procedure evaluates:
BehavioralState = Compare( CurrentRBD, ApprovedBehavioralEnvelope,
CurrentAuthorityState )
Possible results include:
ACCEPTABLE
REVALIDATION_REQUIRED
RESTRICTED
REVOKED
OBSERVATION_INCOMPLETE
The result determines whether new bounded finality conditions may be
established or existing conditions remain valid.
7.5.58. C-21.32 - Drift-Triggered Restriction
When a material behavioral deviation is detected, the protected
controller may:
Das Expires 25 April 2027 [Page 279]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Advance the session revocation generation. 2. Mark affected
windows invalid. 3. Withhold new finality grants. 4. Restrict
outstanding operations. 5. Disable affected connector paths. 6.
Require renewed protected validation. 7. Suspend or terminate the
session.
Previously completed authorized operations do not confer continued
execution authority.
7.5.59. PART VIII - NARROW SESSION GRANTS AND BUDGETS
7.5.60. C-21.33 - Protected Session Grant
A Narrow Session Grant authorizes a bounded class or quantity of
operations.
A representative grant may constrain:
(a) operation count; (b) network bytes; (c) destination-specific
transmissions; (d) file mutations; (e) credential-bearing requests;
(f) API method; (g) resource class;
(h) time;
(i) execution generation; or
(j) combinations thereof.
The Finality Sink verifies applicable bounds before each admitted
operation.
C-21.34 - Protected Budget State
A representative budget record comprises:
BudgetID = BUDGET-2101
SessionID = SESSION-2101
WindowID = WINDOW-2101
MaximumOperations = 5
RemainingOperations = 5
MaximumNetworkBytes = 4096
RemainingNetworkBytes = 4096
Das Expires 25 April 2027 [Page 280]
Internet-Draft Sandbox Credential Egress Finality October 2026
CredentialUsesRemaining = 2
AuthorityGeneration = 105
BudgetStatus = ACTIVE
The values are illustrative.
7.5.61. C-21.35 - Atomic Budget Reservation
Concurrent operations may attempt to consume the same remaining
budget.
A protected budget controller performs an atomic reservation or
comparison-and-update operation.
For example, if two workers each attempt to reserve three operations
from a remaining budget of five, the controller cannot authorize both
reservations under the same protected budget state.
The implementation may use:
1. Protected database transactions. 2. Atomic hardware operations.
3. Sink-local protected counters. 4. Compare-and-swap operations.
5. Authenticated state-machine transitions. 6. An appropriately
consistent distributed allocation mechanism.
The mechanism must enforce the selected bounded usage guarantee.
7.5.62. C-21.36 - Actual Consumption Versus Reservation
A reserved budget may differ from a completed operation.
A representative state machine is:
AVAILABLE → RESERVED → DISPATCHED → COMPLETED
Alternative states include:
DENIED
CANCELED
INDETERMINATE
The system defines whether budget is consumed at reservation,
dispatch, or verified completion.
Das Expires 25 April 2027 [Page 281]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where external completion is uncertain, the system may conservatively
retain the reservation until reconciliation.
Budget must not be automatically restored merely because an
acknowledgment was not received.
7.5.63. C-21.37 - Byte Budget Enforcement
A network byte budget may be enforced at different boundaries:
1. Application payload bytes. 2. Encoded request bytes. 3.
Transport payload bytes. 4. Actual transmitted bytes.
The implementation identifies which quantity is governed.
Where actual transmission-byte accounting is required, the Finality
Sink or associated protected network controller obtains the relevant
transmitted quantity.
A preliminary payload-size estimate may be used for reservation,
followed by defined actualconsumption reconciliation.
7.5.64. C-21.38 - Time-Bound Grant
A finite authorization window may be associated with a protected
expiration condition.
The expiration mechanism may use:
(a) trusted monotonic time; (b) a protected lease expiration; (c) an
authenticated time source; (d) an operation counter; (e) an epoch
transition; or (f) another machine-enforceable validity condition.
A host-controlled wall clock is not automatically trusted against a
host-level adversary.
The required clock and rollback properties depend upon the chosen
threat model.
7.5.65. PART IX - LOW-LATENCY PROTECTED ENFORCEMENT
7.5.66. C-21.39 - Control-Path and Effectuation-Path Separation
The system may perform full policy evaluation at a control-path rate
different from the rate at which bounded operations are effectuated.
For example:
Das Expires 25 April 2027 [Page 282]
Internet-Draft Sandbox Credential Egress Finality October 2026
Control path: Evaluates task authority, behavioral conditions, policy
state, source
restrictions, and permitted window parameters.
Effectuation path: Performs compact verification of a current window
grant, operation
scope, sequence, usage budget, and sink-local state.
The control path may generate a bounded authorization window.
The Finality Sink subsequently enforces the already committed limits
without repeating every expensive control-path calculation.
7.5.67. C-21.40 - Window Grant Compilation
The PED may compile a validated policy decision into a machine-
verifiable window representation.
A representative compiled grant comprises:
GrantID = GRANT-2101
WindowID = WINDOW-2101
SessionGeneration = 71
PolicyGeneration = 105
RevocationGeneration = 27
AuthorizedOperationClass = NETWORK_SEND
AuthorizedDestination = DOMAIN-A
MaximumOperations = 5
MaximumBytes = 4096
ExpiryReference = TIME-2101
RequiredSinkID = FS-NET-21
The grant may be authenticated or stored in protected state.
Das Expires 25 April 2027 [Page 283]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.68. C-21.41 - Compact Sink Verification
A latency-critical Finality Sink may verify:
1. Grant authenticity or protected reference validity. 2. Current
session generation. 3. Current required authority and revocation
state. 4. Authorized operation class. 5. Actual resource or
destination scope. 6. Current sequence or nonce. 7. Protected
remaining budget. 8. Expiration. 9. Sink identity. 10. Operation-
specific constraints.
The sink does not treat an expired or invalidated grant as valid
merely because it was approved earlier.
7.5.69. C-21.42 - Effectuation Without Repeating Full PED Evaluation
For an operation fully within a current protected window, the
Finality Sink may perform a compact local verification.
For example, the PED authorizes up to five requests to a specified
endpoint.
The Finality Sink verifies each actual request against the grant and
atomically decrements the protected count.
The sink does not need to contact a remote PED for every request,
provided that the architecture implements the required current scope,
revocation, freshness, and budget semantics.
A material condition outside the grant triggers new protected
validation or denial.
7.5.70. C-21.43 - Latency Considerations
The implementation may reduce effectuation-path latency through:
(a) compact capability formats; (b) protected local registries; (c)
prevalidated bounded grants; (d) sink-local counters;
(e) deterministic descriptor comparisons;
(f) cached protected policy summaries;
(g) hardware-assisted comparisons;
(h) batched validation records; or
(i) combinations thereof.
Das Expires 25 April 2027 [Page 284]
Internet-Draft Sandbox Credential Egress Finality October 2026
The actual latency depends upon platform hardware, operation type,
cryptography, cache behavior, network conditions, and synchronization
requirements.
The architecture does not imply a universal timing guarantee.
7.5.71. C-21.44 - Window Grant Revocation
A compact grant must remain subject to its specified revocation
semantics.
A protected policy change may:
1. Advance a revocation generation. 2. Mark the grant invalid. 3.
Update relevant sink-local state. 4. Restrict further operation
admission. 5. Fence affected outstanding operations where required.
A sink without access to current revocation information may use only
a separately defined bounded offline or lease-based policy.
It must not assume revocation has not occurred solely because the
control path is unreachable.
7.5.72. PART X - SESSION FINALITY STATE
7.5.73. C-21.45 - Protected Session Finality Record
A representative protected record comprises:
SessionID
SessionGeneration
ExecutionGeneration
PolicyGeneration
RevocationGeneration
CurrentWindowID
CurrentChainHead
NextSequenceNumber
OutstandingOperationReferences
RemainingBudgetReferences
Das Expires 25 April 2027 [Page 285]
Internet-Draft Sandbox Credential Egress Finality October 2026
BehavioralValidationStatus
RecoveryStatus
The record may be maintained in authenticated persistent storage,
protected memory, a secure transaction service, or another suitable
protected state mechanism.
7.5.74. C-21.46 - Session State Updates
Protected session state may be updated following:
(a) successful validation; (b) grant establishment; (c) Candidate Act
reservation; (d) effectuation; (e) completion; (f) denial;
(g) expiration;
(h) behavioral drift;
(i) policy change;
(j) revocation;
(k) restart; or
(l) recovery.
Each transition may advance a protected state sequence.
The implementation specifies which transitions must be durable before
corresponding external effects are permitted.
7.5.75. C-21.47 - Session Continuation
A continuing agent may retain access to computational resources even
when external effectuation is suspended.
For example, the system may permit:
| x | Analysis of previously acquired information. |
| - | -------------------------------------------- |
| x | Local planning. |
| x | Preparation of a proposed operation. |
| x | User-facing explanations. |
| x | Construction of a new authorization request. |
However, governed external effects remain unavailable until the
required protected authority is restored.
Das Expires 25 April 2027 [Page 286]
Internet-Draft Sandbox Credential Egress Finality October 2026
This distinction permits restricted continuation without converting
computational access into execution authority.
7.5.76. PART XI - SNAPSHOT, RESTART, AND ROLLBACK
7.5.77. C-21.48 - Snapshot Restoration Threat
A sandbox snapshot may capture:
1. Agent memory. 2. Process state. 3. Tool state. 4. Session
identifiers. 5. Previously issued window grants. 6. Local sequence
counters. 7. Cached authorization references. 8. Pending operation
descriptors.
An attacker or ordinary recovery procedure may restore an earlier
snapshot after protected authority has been consumed or revoked.
If the restored state is accepted without checking current protected
authority, the agent may attempt to reuse earlier grants.
7.5.78. C-21.49 - Protected Continuity State
A representative continuity record comprises:
SessionID
CurrentSessionGeneration
CurrentExecutionGeneration
CurrentPolicyGeneration
CurrentRevocationGeneration
CurrentChainHead
LatestCommittedSequence
ConsumedGrantReferences
RecoveryGeneration
The authoritative continuity state is maintained outside the
rollback-controlled snapshot or otherwise protected against the
specified rollback adversary.
Das Expires 25 April 2027 [Page 287]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.79. C-21.50 - Restart Handling
Following a sandbox restart, the protected controller:
1. Authenticates the restarting workload. 2. Obtains the requested
session identity. 3. Determines the new execution generation. 4.
Recovers current protected session state. 5. Compares restored grant
and sequence references. 6. Invalidates prohibited stale grants. 7.
Reconciles outstanding operations. 8. Establishes a permitted
continuation state. 9. Requires fresh authorization where necessary.
A process restart does not automatically reset a consumed budget.
7.5.80. C-21.51 - Snapshot Rollback Detection
An implementation may detect prohibited rollback by comparing the
restored state against:
(a) a protected monotonic generation; (b) an authenticated state
commitment;
(c) a protected current chain head;
(d) a trusted external continuity registry;
(e) a secure device counter; or
(f) another mechanism supplying the required freshness property.
An authenticated snapshot alone may be insufficient when an attacker
can replay an earlier authentic snapshot.
7.5.81. C-21.52 - Migration Handling
An agent may migrate from one execution environment to another.
The migration procedure may:
1. Suspend or fence relevant effectuation paths at the source. 2.
Record outstanding operations. 3. Advance the protected execution
generation. 4. Transfer or reestablish permitted computational
state. 5. Recover authoritative protected session state at the
destination. 6. Invalidate grants not transferable under the
applicable policy. 7. Rebind permitted Finality Sinks. 8. Restore
bounded authorization only after required validation.
The destination must not rely solely on an agent-supplied copy of the
old session state.
Das Expires 25 April 2027 [Page 288]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.82. C-21.53 - Failover
Where a protected Finality Sink fails over to another controller, the
system verifies:
1. Authorized replacement identity. 2. Current authority
generation. 3. Protected grant state. 4. Relevant outstanding
operations. 5. Consumption and sequence state. 6. Current resource
scope. 7. Required effectuation-path coverage.
The replacement sink does not automatically inherit authority from an
unverified local cache.
7.5.83. PART XII - COMPLETE EXECUTION WORKFLOW
7.5.84. C-21.54 - Principal 32-Step Workflow
7.5.85. Step C21-01 - Session initialization
The system establishes the sandboxed agent execution environment.
7.5.86. Step C21-02 - Protected session registration
A protected session identity and generation are allocated.
7.5.87. Step C21-03 - Initial permission envelope establishment
The task's broad operational limits are registered.
7.5.88. Step C21-04 - Effectuation-path restriction
Governed external effects are restricted to controlled Finality
Sinks.
7.5.89. Step C21-05 - Behavioral baseline establishment
Required approved behavioral references or initial RBD conditions are
associated with the session.
7.5.90. Step C21-06 - Agent computation
The agent performs permitted computational operations.
7.5.91. Step C21-07 - Proposed operation generation
The agent generates a consequential operation.
Das Expires 25 April 2027 [Page 289]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.92. Step C21-08 - Operation interception
The controlled interface captures the operation.
7.5.93. Step C21-09 - Candidate classification
The system determines whether individual, grouped, or window
authorization applies.
7.5.94. Step C21-10 - Non-effective staging
The governed effect remains withheld.
7.5.95. Step C21-11 - Descriptor generation
A machine-verifiable operation descriptor is constructed.
7.5.96. Step C21-12 - Current session lookup
The protected controller obtains current session state.
7.5.97. Step C21-13 - Behavioral observation
Required runtime observations are obtained.
7.5.98. Step C21-14 - RBD evaluation
The observed behavior is evaluated against applicable approved
conditions.
7.5.99. Step C21-15 - Protected authority-state retrieval
Current policy, scope, revocation, and budget information are
obtained.
7.5.100. Step C21-16 - Predicate validation
The PED evaluates the required authorization conditions.
7.5.101. Step C21-17 - Grant scope determination
A bounded Candidate Act, group, or window scope is established.
7.5.102. Step C21-18 - Budget reservation
Applicable protected resources or usage quotas are reserved.
Das Expires 25 April 2027 [Page 290]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.103. Step C21-19 - Validation evidence commitment
The PED commits protected validation state.
7.5.104. Step C21-20 - Micro-validation chain update
The applicable protected chain is updated.
7.5.105. Step C21-21 - Scoped finality authorization
A bounded finality-enabling condition is activated.
7.5.106. Step C21-22 - Grant presentation
The applicable authorization is made available to the controlled
Finality Sink.
7.5.107. Step C21-23 - Actual-operation reconstruction
The sink obtains the actual pending operation.
7.5.108. Step C21-24 - Current window verification
The sink verifies required scope, sequence, freshness, generation,
and budget conditions.
7.5.109. Step C21-25 - Protected consumption transition
The sink reserves or consumes the applicable authorization.
7.5.110. Step C21-26 - Controlled effectuation
The authorized operation is performed.
7.5.111. Step C21-27 - Outcome observation
The available completion state is obtained.
7.5.112. Step C21-28 - Protected session-state update
Usage, operation history, and applicable grants are updated.
7.5.113. Step C21-29 - Subsequent operation classification
The next operation is evaluated against the current window.
Das Expires 25 April 2027 [Page 291]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.114. Step C21-30 - Drift or policy-change evaluation
The system checks required behavioral and authority changes.
7.5.115. Step C21-31 - Renewal, restriction, or expiration
The window is retained, renewed through protected validation,
expired, or revoked.
7.5.116. Step C21-32 - Session continuation or termination
The session continues under current protected authorization or is
suspended, recovered, revoked, or terminated.
7.5.117. PART XIII - REFERENCE ALGORITHMS
C-21.55 - Algorithm A: Protected Session Initialization function
InitializeContinuousSession(agent, task, envelope):
identity = AuthenticateAgentExecutionContext(agent)
if identity is invalid:
return DENIED
authority = ProtectedAuthorityRegistry.lookup(
identity, task )
if not ValidateInitialPermissionEnvelope(
envelope, authority ):
return DENIED
session_id = AllocateProtectedSessionID()
session_generation = AdvanceSessionGeneration(
session_id )
chain_head = InitializeProtectedChain({
session_id: session_id, session_generation: session_generation,
authority_generation: authority.generation })
state = ProtectedSessionRegistry.create({
Das Expires 25 April 2027 [Page 292]
Internet-Draft Sandbox Credential Egress Finality October 2026
session_id: session_id, agent_context: identity, task_id: task.id,
session_generation: session_generation, authority_generation:
authority.generation, permission_envelope: envelope, chain_head:
chain_head, next_sequence: 1, status: ACTIVE })
if not VerifyRequiredFinalitySinkCoverage(state):
ProtectedSessionRegistry.suspend(session_id) return DENIED return
state
The initial permission envelope is recorded as session policy
context.
It is not treated as unconditional effectuation authority.
C-21.56 - Algorithm B: Candidate Act and Window Classification
function ClassifySessionOperation(session_id, request):
session = ProtectedSessionRegistry.get(session_id)
if session.status != ACTIVE:
return DENIED
actual_request = CaptureControlledOperation(request)
if not IsGovernedExternalEffect(actual_request):
return EvaluateApplicableOrdinaryPolicy(actual_request)
descriptor = Canonicalize({
session_id: session_id, session_generation: session.generation,
operation: actual_request, authority_generation:
session.authority_generation, required_sink:
ResolveFinalitySink(actual_request) })
if IsHighRiskOrOutsideCurrentWindow(
descriptor, session ):
mode = INDIVIDUAL_CANDIDATE else if IsEligibleForBoundedGroup(
descriptor, session ):
mode = BOUNDED_OPERATION_GROUP else:
Das Expires 25 April 2027 [Page 293]
Internet-Draft Sandbox Credential Egress Finality October 2026
mode = FINITE_EFFECTUATION_WINDOW candidate =
ProtectedOperationRegistry.stage({
descriptor: descriptor, mode: mode })
return candidate
Classification does not itself authorize the operation.
It selects the protected authorization procedure.
C-21.57 - Algorithm C: Establish Bounded Authorization Window
function EstablishProtectedWindow(session_id, requested_scope):
session = ProtectedSessionRegistry.get(session_id)
if session.status != ACTIVE:
return DENIED
if not VerifyCurrentSessionGeneration(session):
return DENIED behavioral_state = EvaluateRequiredRuntimeBehavior(
session )
if behavioral_state != ACCEPTABLE:
ApplyRequiredSessionRestriction(session) return DENIED authority =
ProtectedAuthorityRegistry.lookup(session)
if not EvaluateCurrentAuthorityPredicates(
session, requested_scope, authority ):
return DENIED bounded_scope = IntersectWithPermittedEnvelope(
requested_scope, session.permission_envelope, authority )
if bounded_scope is invalid:
return DENIED budget = ReserveProtectedWindowBudget(
session, bounded_scope )
if budget is invalid:
Das Expires 25 April 2027 [Page 294]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED evidence = CommitProtectedValidationEvidence({
session_id: session_id, session_generation: session.generation,
bounded_scope: bounded_scope, authority_generation:
authority.generation, behavioral_state: behavioral_state,
budget_reference: budget.id })
grant = CreateScopedWindowGrant({
session_id: session_id, evidence_reference: evidence.id,
bounded_scope: bounded_scope,
budget_reference: budget.id, required_sinks: bounded_scope.sinks,
authority_generation: authority.generation })
if not AtomicallyActivateWindow(
session, budget, evidence, grant ):
CancelUncommittedReservation(budget) return DENIED
return grant
The implementation must ensure that failure between budget
reservation and authorization activation does not create inconsistent
reusable authority.
C-21.58 - Algorithm D: Micro-Validation Chain Update
function CommitMicroValidation(session_id, event):
begin protected_atomic_transaction
state = LockProtectedSessionChain(session_id)
if event.expected_sequence != state.next_sequence:
abort return SEQUENCE_MISMATCH
if not VerifyEventBinding(event, state):
abort return DENIED
event_digest = HashCanonical({
Das Expires 25 April 2027 [Page 295]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate_id: event.candidate_id, operation_digest:
event.operation_digest, window_id: event.window_id,
validation_outcome: event.validation_outcome, protected_transition:
event.transition_reference })
next_head = HashCanonical({
domain: SESSION_CHAIN_STEP, previous_head: state.chain_head,
sequence: state.next_sequence, event_digest: event_digest,
session_generation: state.session_generation })
CommitProtectedMicroRecord(
session_id, state.next_sequence, event, next_head )
state.chain_head = next_head state.next_sequence += 1
commit protected_atomic_transaction
return next_head
The authoritative chain head and sequence must be protected against
the attacker specified by the deployment.
C-21.59 - Algorithm E: Finality Sink Window Enforcement
function ExecuteUnderWindow(candidate_id, window_id):
candidate = ProtectedOperationRegistry.get(candidate_id)
if candidate.status != STAGED:
return DENIED
actual_operation = ObtainActualPendingOperation(candidate_id)
if actual_operation is unavailable:
return DENIED
grant = ProtectedWindowRegistry.get(window_id)
if not VerifyProtectedWindowGrant(grant):
return DENIED
if not MatchSessionAndExecutionGeneration(
Das Expires 25 April 2027 [Page 296]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate, grant ):
return DENIED
if not VerifyCurrentAuthorityAndRevocation(grant):
return DENIED
if not VerifyActualOperationWithinScope(
actual_operation, grant ):
return DENIED
if not VerifyWindowFreshness(grant):
return DENIED if not VerifySinkLocalWindowState(grant):
return DENIED
required_units = MeasureOrReserveEffectUnits(
actual_operation, grant )
if not AtomicallyReserveWindowBudget(
grant, candidate_id, required_units ):
return DENIED result =
DispatchThroughControlledEffectuationInterface(
actual_operation )
ReconcileUsageAndOperationOutcome(
candidate_id, grant, result )
return result
The sink may use a compact local grant check.
It must not permit an operation outside the committed protected
authorization scope.
7.5.118. C-21.60 - Algorithm F: Behavioral Drift Detection
function EvaluateSessionBehavior(session_id):
Das Expires 25 April 2027 [Page 297]
Internet-Draft Sandbox Credential Egress Finality October 2026
session = ProtectedSessionRegistry.get(session_id)
observations = CollectRequiredRuntimeObservations(
session
)
if not VerifyRequiredObservationCoverage(observations):
return OBSERVATION_INCOMPLETE current_rbd =
ConstructRuntimeBehavioralDescriptor(
observations )
approved = ProtectedBehaviorRegistry.lookup(session)
if approved.requires_alf:
current_alf = ObtainProtectedCurrentALF(session)
if not VerifyApprovedALFCorrespondence(
current_alf, approved.alf_reference
):
return REVALIDATION_REQUIRED if not VerifyPermittedCommandGraph(
current_rbd, approved ):
return RESTRICTED
if not VerifyPermittedToolAndDestinationScope(
current_rbd, approved ):
return RESTRICTED
if not EvaluateConfiguredRiskPredicates(
current_rbd, approved ):
return REVALIDATION_REQUIRED return ACCEPTABLE
This algorithm applies only those behavioral checks required by the
selected policy.
Das Expires 25 April 2027 [Page 298]
Internet-Draft Sandbox Credential Egress Finality October 2026
The actual ALF and RBD generation procedures must be defined by the
implementation relying upon them.
C-21.61 - Algorithm G: Drift-Triggered Session Restriction
function RestrictSessionForBehavioralDrift(
session_id, drift_record ):
generation = AdvanceProtectedRevocationGeneration(
session_id )
windows = ResolveAffectedSessionWindows(session_id)
for each window in windows:
MarkWindowRevoked(window, generation)
sinks = ResolveAffectedFinalitySinks(session_id)
for each sink in sinks:
ApplyRestrictiveGenerationUpdate(
sink, generation )
outstanding = LoadOutstandingSessionOperations(session_id)
for each operation in outstanding:
ApplyRequiredContinuationOrFencingRule(
operation, generation )
CommitProtectedSessionState({
session_id: session_id, revocation_generation: generation,
drift_reference: drift_record.id, status: REVALIDATION_REQUIRED })
return EvaluateRestrictionConvergence(sinks)
An expired or revoked window cannot authorize additional effects
merely because a previously issued grant remains present in agent
memory.
C-21.62 - Algorithm H: Protected Window Budget Accounting
Das Expires 25 April 2027 [Page 299]
Internet-Draft Sandbox Credential Egress Finality October 2026
function ReserveWindowBudget(window, operation, units):
begin protected_atomic_transaction
current = LockProtectedBudgetState(window\.budget_id)
if current.status != ACTIVE:
abort return DENIED
if not VerifyCurrentWindowGeneration(window):
abort return DENIED if units.operation_count >
current.remaining_operations:
abort return DENIED if units.byte_count > current.remaining_bytes:
abort return DENIED if units.credential_count >
current.remaining_credentials:
abort return DENIED reservation =
CreateProtectedOperationReservation(
window\.id, operation.id, units )
current.remaining_operations -= units.operation_count
current.remaining_bytes -= units.byte_count
current.remaining_credentials -= units.credential_count commit
protected_atomic_transaction
return reservation
Reservation and completion accounting are distinct.
For external effects with uncertain completion, the reservation may
remain consumed pending reconciliation.
7.5.119. C-21.63 - Algorithm I: Session Snapshot Recovery
function RecoverSessionFromSnapshot(snapshot):
claimed_session = ExtractSessionIdentity(snapshot)
authoritative = ProtectedSessionRegistry.get(
claimed_session.session_id
)
Das Expires 25 April 2027 [Page 300]
Internet-Draft Sandbox Credential Egress Finality October 2026
if authoritative is unavailable:
return RECOVERY_REQUIRED
if not VerifySnapshotSessionBinding(
snapshot, authoritative ):
return DENIED
if not VerifyProtectedContinuityState(
snapshot, authoritative ):
InvalidateSnapshotGrants(snapshot) return REVALIDATION_REQUIRED
new_generation = AdvanceExecutionGeneration(
authoritative.session_id )
ReconcileOutstandingOperations(
authoritative.session_id )
InvalidateNonTransferableGrants(
authoritative.session_id, new_generation )
recovered = EstablishPermittedSessionContinuation(
authoritative, new_generation )
return recovered
A restored snapshot is not authoritative merely because it contains a
previously valid session identifier and grant.
C-21.64 - Algorithm J: Low-Latency Grant Verification
function VerifyCompactWindowGrant(
grant, actual_operation, sink_state ):
if not VerifyGrantAuthenticity(grant):
return DENIED
if grant.sink_id != sink_state.sink_id:
Das Expires 25 April 2027 [Page 301]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED
if not VerifyCurrentGenerationLocally(
grant, sink_state ):
return DENIED
if not VerifyOperationClassAndScope(
actual_operation, grant ):
return DENIED if not VerifyGrantExpiration(grant):
return DENIED
if not VerifyCurrentSequenceState(
actual_operation, sink_state ):
return DENIED if not VerifyProtectedRemainingBudget(
actual_operation, sink_state ):
return DENIED
return ELIGIBLE_FOR_ATOMIC_RESERVATION
The fast path makes a bounded determination.
It does not grant new authority beyond the previously committed
window.
7.5.120. PART XIV - WORKED TECHNICAL EXAMPLES
C-21.65 - Example A: Continuous Enterprise Research Agent
The following is a hypothetical implementation example.
An enterprise AI agent is assigned a one-hour research session.
The initial permission envelope permits reading specified research
services and sending bounded summaries to one approved destination.
The agent performs multiple retrieval and summarization operations.
A protected controller authorizes a finite window covering up to five
transmissions to the approved destination.
Das Expires 25 April 2027 [Page 302]
Internet-Draft Sandbox Credential Egress Finality October 2026
The Finality Sink verifies each actual pending transmission.
After five authorized transmissions, the protected count is
exhausted.
A sixth transmission is withheld pending a new permitted protected
authorization.
The original one-hour session approval does not independently
authorize unlimited messages.
7.5.121. C-21.66 - Example B: Micro-Validation Chain
An agent performs three consequential operations during a continuing
session.
Operation 1 modifies Resource A.
Operation 2 transmits a permitted report.
Operation 3 updates Resource B.
The system creates protected micro-validation records:
MR-1
MR-2
MR-3
Each record is associated with the preceding protected chain state.
The current chain head commits the authorized sequence.
An attacker restores an earlier agent snapshot containing the state
before Operation 2.
The protected controller compares the restored sequence with
authoritative continuity state.
The older chain state is rejected where the applicable policy
prohibits reuse.
The session must be revalidated or recovered through a permitted
continuation procedure.
Das Expires 25 April 2027 [Page 303]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.122. C-21.67 - Example C: Runtime Behavioral Drift
An agent initially uses only approved research and reporting tools.
A later instruction causes the agent to invoke an unapproved shell
command.
The protected observation mechanism identifies the unexpected command
class.
The corresponding RBD fails the approved command-graph predicate.
The PED marks the session REVALIDATION_REQUIRED.
Affected window grants are restricted.
The agent may continue permitted internal computation, but further
governed external operations are withheld until authorized
revalidation succeeds.
Previously completed transmissions do not establish continuing
authority.
7.5.123. C-21.68 - Example D: Low-Latency Network Window
A service agent must send frequent small messages to one authorized
endpoint.
The PED evaluates current task authority and behavioral conditions.
It commits a window grant permitting:
| x | Destination: Domain A. |
| - | --------------------------------------- |
| x | Operation class: NETWORK_SEND. |
| x | Maximum operations: 100. |
| x | Maximum bytes: 65536. |
| x | Validity: a specified bounded interval. |
The actual numbers are illustrative.
The network Finality Sink maintains protected remaining budget and
current generation state.
For each request, the sink verifies the effective destination,
permitted operation class, grant validity, and budget.
Das Expires 25 April 2027 [Page 304]
Internet-Draft Sandbox Credential Egress Finality October 2026
It reserves the required units and performs the authorized
transmission.
The sink does not invoke a remote full-policy evaluator for every
packet.
However, a request outside the window is withheld.
7.5.124. C-21.69 - Example E: Credential-Use Budget
An agent is permitted to perform up to three specified credential-
bearing API operations during a protected window.
The credential broker retains the real protected credential.
The PED establishes the bounded authorization.
The Finality Sink verifies each actual request and consumes one
permitted credential-use unit.
After three authorized uses, the window is exhausted.
A fourth request is not permitted under the consumed grant.
The agent's continued possession of an initial service reference does
not restore the spent authority.
7.5.125. C-21.70 - Example F: Snapshot Rollback
An agent completes two authorized external operations.
The protected session state records:
LatestSequence = 2
RemainingOperations = 3
An older sandbox snapshot contains:
LatestSequence = 0
RemainingOperations = 5
The snapshot is restored.
The protected recovery controller obtains current authoritative
session state.
Das Expires 25 April 2027 [Page 305]
Internet-Draft Sandbox Credential Egress Finality October 2026
It detects that the restored state is older than the protected
continuity state.
The earlier grant is not accepted as independently usable.
The session is re-established under current protected state, or fresh
validation is required.
7.5.126. C-21.71 - Example G: Agent Migration
An agent session executes in one cloud region.
A migration controller moves the session to another region.
The source region restricts new governed operations.
Outstanding operation state is recorded.
The destination obtains the protected authoritative session
generation, chain head, and grant state.
A new execution generation is established.
Only grants permitted to continue across migration are rebound to the
destination's controlled effectuation interfaces.
Stale source-region grants do not automatically authorize further
effects.
7.5.127. C-21.72 - Example H: Concurrent Budget Consumption
A session has two remaining authorized file mutations.
Three tool workers concurrently request distinct file changes.
The Finality Sink uses protected atomic reservation.
Two workers successfully reserve one mutation each.
The third worker fails the budget predicate.
Only the first two operations may proceed under the existing window.
The number of workers does not multiply the session's protected
budget.
Das Expires 25 April 2027 [Page 306]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.128. C-21.73 - Example I: Lost External Acknowledgment
An agent performs an authorized credential-bearing API request.
The Finality Sink reserves and dispatches the operation.
The network connection fails before a reliable completion
acknowledgment is received.
The protected registry records an indeterminate outcome.
The system does not automatically refund the usage budget or repeat
the potentially effective operation.
It applies the available destination-specific reconciliation or
idempotency procedure.
A retry is permitted only under the defined authority and duplicate-
effect rules.
7.5.129. C-21.74 - Example J: Mid-Window Policy Revocation
A protected window initially permits ten resource updates.
After four updates, the enterprise revokes the agent's authority.
The protected revocation generation advances.
Affected Finality Sinks receive the restrictive update.
Further operations under the earlier window are denied when its
authority generation is no longer acceptable.
The unused six-operation balance does not override current
revocation.
7.5.130. PART XV - FAILURE AND ADVERSARIAL SCENARIOS
7.5.131. C-21.75 - Representative Failure Cases
7.5.132. F1 - Unlimited Initial Approval
An agent attempts to use session initialization as indefinite
external-effect authorization.
The required Finality Sink enforces bounded current grants.
Das Expires 25 April 2027 [Page 307]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.133. F2 - Expired Window
An operation is submitted after the permitted window expires.
The operation is withheld.
7.5.134. F3 - Exhausted Operation Count
An additional operation exceeds the current protected count.
The budget controller rejects the operation.
7.5.135. F4 - Byte Budget Overrun
A proposed transmission exceeds the remaining permitted byte budget.
The Finality Sink denies or applies a supported bounded transfer
procedure.
7.5.136. F5 - Wrong Destination
An operation targets a destination outside the current grant.
The actual destination comparison fails.
7.5.137. F6 - Wrong Resource
An operation targets a different protected resource than the
authorized scope.
The operation is rejected.
7.5.138. F7 - Wrong Operation Class
An agent substitutes a credential-use operation for an authorized
read operation.
The bounded grant does not authorize the substituted class.
7.5.139. F8 - Micro-Record Replay
A previously committed micro-validation record is presented as a new
authorization event.
The protected sequence or operation identity check rejects
unauthorized replay.
Das Expires 25 April 2027 [Page 308]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.140. F9 - Chain Head Substitution
An attacker substitutes an earlier chain head.
Protected continuity verification detects the invalid state.
7.5.141. F10 - Sequence Gap
An operation attempts to commit under an unexpected sequence.
The protected chain-update procedure applies the defined rejection or
gap-handling policy.
7.5.142. F11 - Concurrent Sequence Allocation
Two operations attempt the same protected chain position.
The atomic state transition prevents conflicting authoritative
commitments.
7.5.143. F12 - Behavioral Drift
Observed runtime behavior deviates from required approved conditions.
Further finality grants are withheld or restricted.
7.5.144. F13 - ALF Mismatch
A required current ALF fails the applicable approved-fingerprint
correspondence check.
The configured behavioral restriction is applied.
7.5.145. F14 - Missing RBD Observation
A required observation cannot be established.
The system treats the coverage failure according to its restrictive
policy.
7.5.146. F15 - Policy Generation Change
A window refers to an unacceptable earlier policy generation.
The grant is invalidated or revalidated.
Das Expires 25 April 2027 [Page 309]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.147. F16 - Revocation Generation Change
The required current revocation state differs from the grant.
Further effectuation is denied where the policy so requires.
7.5.148. F17 - Cached Grant Replay
An agent reuses a cached grant outside its permitted session or
execution generation.
The sink rejects it.
7.5.149. F18 - Grant Used at Wrong Sink
A grant intended for one Finality Sink is presented to another.
The required sink identity binding fails.
7.5.150. F19 - Concurrent Budget Double-Spend
Multiple workers attempt to consume the same remaining budget units.
Atomic protected accounting prevents unauthorized overconsumption.
7.5.151. F20 - Budget Refund After Unknown Completion
An operation's outcome is uncertain.
The controller does not automatically restore spent units.
7.5.152. F21 - Restart With Stale Grant
An agent restarts using a previous execution-generation grant.
The protected continuation procedure verifies whether that grant
remains valid.
7.5.153. F22 - Snapshot Rollback
An earlier authentic snapshot is restored.
Protected continuity state prevents prohibited reactivation of
consumed authority.
Das Expires 25 April 2027 [Page 310]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.154. F23 - Virtual-Machine Migration
A workload moves to another machine.
Required sink and authority bindings are re-established.
7.5.155. F24 - Failover to Unverified Sink
A new Finality Sink attempts to accept an old grant without verified
state transfer.
The corresponding operation is restricted.
7.5.156. F25 - Protected Registry Unavailable
The required protected window or consumption registry cannot be
accessed.
The affected operation remains non-effective.
7.5.157. F26 - PED Unavailable
A new protected authorization cannot be established.
The system may use only an independently valid existing bounded grant
under the applicable offline and revocation semantics.
7.5.158. F27 - Insufficient Clock Trust
A time-based grant relies on a clock that can be reset by the
relevant attacker.
The implementation must use an appropriate protected expiration
mechanism or narrow the claimed freshness guarantee.
7.5.159. F28 - Connector Operation Substitution
A connector materially changes the request after window
authorization.
Actual-operation verification detects the mismatch.
7.5.160. F29 - New Tool Introduction
A previously unknown effect-capable tool becomes available.
The existing window does not automatically authorize the new tool
class or effectuation path.
Das Expires 25 April 2027 [Page 311]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.161. F30 - Window Scope Expansion
A request attempts to enlarge the grant without protected
revalidation.
The expansion is denied.
7.5.162. F31 - Authorization Consumption Crash
A failure occurs after local reservation but before definitive
external completion.
The system retains a recoverable operation state.
7.5.163. F32 - External Duplicate Effect
A worker retries an operation already performed by an external
service.
The system applies the defined protected identity, idempotency, and
reconciliation rules.
7.5.164. F33 - Session Terminated With Queued Operations
Outstanding operations remain after agent termination.
The protected continuation policy determines whether they may still
become effective.
7.5.165. F34 - Protected-State Rollback
A protected registry is restored to an earlier generation.
The relevant continuity mechanism detects or prevents prohibited
stale authority.
7.5.166. F35 - Low-Latency Fast-Path Bypass
A fast-path implementation skips a required current-window, scope,
budget, or generation check.
The implementation fails the applicable bounded finality requirement
until the missing enforcement is provided.
7.5.167. F36 - Invalid Behavioral Revalidation
An agent attempts to restore effectuation authority using an
unauthenticated statement that its behavior is acceptable.
Das Expires 25 April 2027 [Page 312]
Internet-Draft Sandbox Credential Egress Finality October 2026
The PED requires the applicable protected verification before
establishing a new grant.
7.5.168. PART XVI - IMPLEMENTATION VARIATIONS
7.5.169. C-21.76 - Per-Act Protected Finality
Each consequential operation receives individual protected validation
evidence and a separate scoped finality condition.
This variation may be selected for high-risk operations.
7.5.170. C-21.77 - Bounded Multi-Act Finality
A protected window permits multiple operations within a defined
scope.
| The Finality Sink enforces count, resource, destination, and freshness limits for each effect. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-21.78 - Protected Session Micro-Chain Each authorized operation or required state transition updates a protected cryptographic or authenticated chain. The chain detects prohibited sequence reuse or rollback according to the implemented protection mechanism. |
| C-21.79 - ALF/RBD Behavioral Revalidation Successive RBDs are compared against an approved behavioral envelope. An ALF reference may be included when the applicable policy requires approved computational-logic correspondence. Material deviation triggers renewed protected authorization or restriction. |
| C-21.80 - Containerized Continuous Agent A containerized agent performs repeated tool operations. Host-side protected enforcement maintains authoritative session and finality state independently of container restart. |
7.5.171. C-21.81 - Micro-VM Continuous Agent
An agent executes in an ephemeral micro-VM.
A protected external registry retains session identity, consumption
state, outstanding operations, and permitted continuation information
across micro-VM replacement.
7.5.172. C-21.82 - Cloud-Hosted Session
An agent executes in a managed cloud runtime.
A distributed PED establishes bounded windows.
One or more resource-specific Finality Sinks enforce the actual
operation scope.
7.5.173. C-21.83 - Low-Latency Network Gateway
A protected network gateway verifies compact session grants against
current sink-local generation and budget state.
Full control-path validation is performed on grant creation, material
changes, or required renewal.
Das Expires 25 April 2027 [Page 313]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.5.174. C-21.84 - Hardware Counter Implementation
A protected hardware component maintains selected window counters or
authorization generations.
The Finality Sink verifies the corresponding hardware-protected
state.
The exact guarantees depend upon the selected hardware primitive.
7.5.175. C-21.85 - Protected Database Transaction Implementation
A native resource controller maintains session window consumption and
resourceeffectuation state through supported transactional
mechanisms.
Authorization-state consumption and local resource mutation may share
an atomic transaction where the native resource system actually
supports that guarantee.
7.5.176. C-21.86 - Distributed Session Grant Implementation
Multiple Finality Sinks may enforce portions of a session
authorization.
The protected controller may allocate distinct sub-budgets or
coordinate a shared consumption state.
The implementation must prevent the sum of independently authorized
effects from exceeding the permitted aggregate scope.
7.5.177. C-21.87 - Disconnected Operation Variation
A Finality Sink may apply a previously committed bounded grant during
temporary disconnection from the central PED.
The offline scope, expiration, revocation semantics, and usage limits
must be enforceable locally.
A disconnected sink cannot enforcement point immediate awareness of
arbitrary remote revocations without a suitable technical mechanism.
7.5.178. C-21.88 - Hardware-Accelerated Window Verification
A protected device or controller may evaluate compact scope,
generation, sequence, and budget predicates at a hardware or firmware
interface.
Das Expires 25 April 2027 [Page 314]
Internet-Draft Sandbox Credential Egress Finality October 2026
The implementation may avoid a remote authorization exchange for each
permitted operation.
7.5.179. C-21.89 - Integrated Single-Node Controller
One protected computing component may implement session registration,
behavioral validation, evidence commitment, grant establishment,
Finality Sink verification, and protected consumption.
Physical separation is not required unless expressly claimed.
7.5.180. PART XVII - REPRESENTATIVE DATA STRUCTURES
7.5.181. C-21.90 - ProtectedSessionRecord
Fields may include:
1. SessionID. 2. AgentContextID. 3. TaskID.
4. SessionGeneration. 5. ExecutionGeneration. 6. PolicyGeneration.
7. RevocationGeneration. 8. PermissionEnvelopeReference. 9.
CurrentWindowID. 10. CurrentChainHead. 11. SessionStatus.
7.5.182. C-21.91 - InitialPermissionEnvelopeRecord
Fields may include:
1. EnvelopeID. 2. SessionID. 3. PermittedTask. 4.
AllowedOperationClasses. 5. AllowedResources. 6.
AllowedDestinations. 7. PermittedToolClasses. 8.
MaximumSessionDuration. 9. BudgetLimits. 10. RequiredFinalityMode.
7.5.183. C-21.92 - SessionCandidateActRecord
Fields may include:
1. CandidateActID. 2. SessionID. 3. SessionGeneration. 4.
OperationClass. 5. ActualOperationDigest. 6. ResourceReference. 7.
AuthorityGeneration. 8. WindowID. 9. RequiredSinkID. 10.
CandidateStatus.
7.5.184. C-21.93 - ProtectedWindowGrantRecord
Fields may include:
1. GrantID.
Das Expires 25 April 2027 [Page 315]
Internet-Draft Sandbox Credential Egress Finality October 2026
2. WindowID. 3. SessionID. 4. SessionGeneration. 5.
PermittedOperationClasses. 6. PermittedResourceScope. 7.
DestinationScope. 8. MaximumOperations. 9. MaximumBytes. 10.
ExpiryReference. 11. AuthorityGeneration. 12. RevocationGeneration.
13. ProtectedEvidenceReference. 14. RequiredSinkID. 15.
GrantStatus.
7.5.185. C-21.94 - MicroValidationRecord
Fields may include:
1. MicroRecordID. 2. SessionID. 3. SequenceNumber. 4.
CandidateActID. 5. OperationDigest. 6. WindowID. 7.
ValidationOutcome. 8. ProtectedTransitionReference. 9.
PreviousChainHead. 10. NewChainHead. 11. CommitmentStatus.
7.5.186. C-21.95 - ProtectedChainStateRecord
Fields may include:
1. SessionID. 2. SessionGeneration. 3. LatestSequenceNumber. 4.
LatestChainHead. 5. AuthorityGeneration. 6. RevocationGeneration.
7. ContinuityAnchor. 8. RecoveryStatus.
7.5.187. C-21.96 - RuntimeBehavioralDescriptorRecord
Fields may include:
1. RBDRecordID. 2. SessionID. 3. ExecutionGeneration. 4.
ObservationWindow. 5. ObservedToolClasses. 6.
ObservedCommandClasses. 7. ObservedDestinations. 8.
ResourceAccessReferences. 9. BehavioralClassification. 10.
ObservationCoverageStatus. 11. CurrentALFReference, where
applicable.
7.5.188. C-21.97 - ProtectedBudgetRecord
Fields may include:
1. BudgetID. 2. SessionID. 3. WindowID. 4. MaximumOperations. 5.
RemainingOperations. 6. MaximumBytes. 7. RemainingBytes. 8.
CredentialUsesRemaining. 9. ReservedUsageReferences. 10.
AuthorityGeneration. 11. BudgetStatus.
7.5.189. C-21.98 - SinkLocalWindowStateRecord
Fields may include:
Das Expires 25 April 2027 [Page 316]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. SinkID. 2. WindowID. 3. GrantID. 4. SessionGeneration. 5.
AuthorityGeneration. 6. RevocationGeneration. 7.
LastAcceptedSequence. 8. ProtectedRemainingBudget. 9.
ConsumptionState. 10. OutstandingOperationReferences.
7.5.190. C-21.99 - SessionRecoveryRecord
Fields may include:
1. SessionID. 2. RestoredExecutionGeneration. 3.
CurrentProtectedExecutionGeneration. 4. CurrentChainHead. 5.
LatestCommittedSequence. 6. OutstandingOperations. 7.
ConsumedGrantReferences. 8. RecoveryGeneration. 9.
ContinuationAuthorizationStatus. 10. RecoveryStatus.
The records may be implemented in protected databases, authenticated
state stores, secure registers, trusted execution environments, or
other components meeting the applicable protected-state requirements.
7.5.191. PART XVIII - implementer VERIFICATION TESTS
7.5.192. C-21.100 - Representative Engineering Test Matrix
The following tests are proposed rather than completed experiments.
7.5.193. Test Condition
T1 Valid per-act authorization T2 Valid bounded window operation T3
Initial envelope only T4 Window expired T5 Operation count exhausted
T6 Byte budget exhausted T7 Unauthorized destination T8 Unauthorized
resource T9 Current grant at wrong sink T10 Replayed Candidate Act
T11 Replayed micro-validation record T12 Invalid chain head T13 Chain
sequence substitution T14 Concurrent budget consumption T15
Behavioral drift T16 Required ALF mismatch
7.5.194. Expected technical result
Effect permitted Effect permitted within scope Governed effect
withheld Operation denied Further operation denied Transmission
denied or bounded Denied Denied Rejected Rejected Rejected Detected
Detected Atomic limit enforced Further grants restricted Applicable
revalidation triggered
T17 Missing required RBD coverage T18 Revocation during window T19
Policy change during window T20 Protected cache stale T21 Low-latency
compact verification T22 Fast-path operation outside scope T23
Sandbox restart T24 Snapshot rollback T25 Process migration T26
Failover to replacement sink T27 Outstanding operation after
Das Expires 25 April 2027 [Page 317]
Internet-Draft Sandbox Credential Egress Finality October 2026
termination T28 Lost completion acknowledgment T29 Concurrent chain
updates T30 Window renewal after expiration T31 Credential-use quota
consumed T32 Time source rollback T33 PED unreachable T34 Required
sink unavailable T35 Restored stale budget T36 New effect-capable
tool during
session
Restrictive behavior Invalid subsequent operations withheld Required
generation check enforced Grant revalidated or denied Authorized
bounded operation permitted Denied Protected state retained Stale
authorization rejected Grants rebound only when permitted Protected
state verified Continuation rule enforced Indeterminate state
retained Unique protected ordering Fresh protected validation
required Additional use denied Required protected expiration
semantics maintained Bounded offline or fail-closed policy applied No
uncontrolled effect Protected continuity detects invalid reuse New
authority scope required
Each implementation should specify the actual protected state
transitions, operation classes, expected effects, and measurement
procedures used to establish compliance with the selected technical
requirements.
7.5.195. PART XIX - Enforcement-Point Mapping and Technical
Correspondence
7.5.196. C-21.101 - Independent enforcement point(s) corresponding to
source item(s) 21
The embodiment provides implementation support for:
enforcement point(s) corresponding to source item(s) 21(a):
Continuing sandboxed agent session with identity and initial
permission
envelope.
enforcement point(s) corresponding to source item(s) 21(b):
Effectuation-path restrictions preventing an initial envelope from
independently authorizing governed effects.
enforcement point(s) corresponding to source item(s) 21(c):
Successive operation interception.
enforcement point(s) corresponding to source item(s) 21(d): Candidate
Acts, bounded groups, and finite windows.
Das Expires 25 April 2027 [Page 318]
Internet-Draft Sandbox Credential Egress Finality October 2026
enforcement point(s) corresponding to source item(s) 21(e): Machine-
verifiable operation and window descriptors.
enforcement point(s) corresponding to source item(s) 21(f): Protected
validation against current session, behavior, policy, scope, and
freshness.
enforcement point(s) corresponding to source item(s) 21(g):
Protected-state operations and validation-evidence commitment.
enforcement point(s) corresponding to source item(s) 21(h): Scoped
finality-enabling conditions.
enforcement point(s) corresponding to source item(s) 21(i): Finality
Sink verification of actual operations and current window conditions.
enforcement point(s) corresponding to source item(s) 21(j): Protected
session-state updates following effectuation, expiration, denial, and
other material events.
enforcement point(s) corresponding to source item(s) 21(k):
Restriction following drift, revocation, budget exhaustion, policy
change, or
invalid window status.
7.5.197. C-21.102 - Dependent enforcement point(s) corresponding to
source item(s) 22: Micro-Receipt Chain
The embodiment provides:
1. Micro-validation records. 2. Protected chain-head state. 3.
Deterministic chaining. 4. Protected sequence allocation. 5. Replay
detection. 6. Operation-substitution detection. 7. Snapshot-
continuity checks. 8. Protected chain recovery.
C-21.103 - Dependent enforcement point(s) corresponding to source
item(s) 23: Behavioral Drift Revocation
The embodiment provides:
1. Successive Runtime Behavioral Descriptors. 2. Approved
behavioral-envelope comparison. 3. Optional ALF verification. 4.
Permitted command-graph checks. 5. Tool-use and destination-scope
checks. 6. Configurable risk predicates. 7. Protected drift-
triggered revocation. 8. Restriction of further effectuation.
Das Expires 25 April 2027 [Page 319]
Internet-Draft Sandbox Credential Egress Finality October 2026
C-21.104 - Dependent enforcement point(s) corresponding to source
item(s) 24: Narrow Session Grants
The embodiment provides:
1. Bounded operation counts. 2. Network byte budgets. 3.
Destination-specific windows. 4. File-mutation budgets. 5.
Credential-use counts. 6. Duration-limited grants. 7. Atomic
protected reservation. 8. Consumption and outcome reconciliation.
C-21.105 - Dependent enforcement point(s) corresponding to source
item(s) 25: Low-Latency Protected Enforcement
The embodiment provides:
1. Control-path and effectuation-path separation. 2. Protected
compilation of bounded authorization windows. 3. Compact Finality
Sink verification. 4. Sink-local protected registry state. 5.
Sequence and budget checking. 6. Avoidance of repeated full-policy
evaluation for eligible operations. 7. Revalidation after material
state changes. 8. Explicit enforcement of grant limits.
C-21.106 - Dependent enforcement point(s) corresponding to source
item(s) 26: Recovery and Session Rollback
The embodiment provides:
1. Snapshot restoration detection. 2. Protected session
generations. 3. Protected execution generations. 4. Chain-head
continuity checks. 5. Budget and capability reuse prevention. 6.
Restart recovery. 7. Migration fencing and rebinding. 8. Protected
failover verification.
7.5.198. PART XX - IMPLEMENTATION REQUIREMENTS
7.5.199. C-21.107 - implementer Implementation Checklist
For a selected implementation, a person having ordinary skill in the
art identifies:
1. The agent session runtime.
2. The session identifier and execution generation. 3. The initial
permission-envelope schema. 4. The governed external-effect classes.
5. The controlled effectuation paths. 6. The Candidate Act
interception interface. 7. The non-effective staging mechanism. 8.
The individual, group, or window classification policy. 9. The
canonical operation descriptor. 10. The protected session-state
Das Expires 25 April 2027 [Page 320]
Internet-Draft Sandbox Credential Egress Finality October 2026
store. 11. The current policy and revocation information. 12. The
protected authority-validation predicates. 13. The runtime
behavioral observation sources. 14. The RBD schema and collection
procedure. 15. Any required ALF generation and comparison procedure.
16. The approved behavioral envelope. 17. The drift-detection
rules. 18. The protected evidence-commitment mechanism. 19. The
micro-validation record format. 20. The chain-head authentication
procedure. 21. The chain-state update and ordering mechanism. 22.
The bounded grant representation. 23. The protected budget
structure. 24. The atomic budget-reservation algorithm. 25. The
Finality Sink actual-operation reconstruction procedure. 26. The
sink-local grant-verification procedure. 27. The grant expiration
and revocation mechanism. 28. The outcome and consumption accounting
rules. 29. The handling of externally indeterminate operations. 30.
The authoritative continuity-state mechanism. 31. The snapshot
rollback detection procedure. 32. The restart and migration
protocol. 33. The low-latency control-path and effectuation-path
division. 34. The fail-closed or permitted bounded-offline rules.
35. The verification procedures demonstrating the claimed protection
properties.
The chosen implementation must define actual protected state,
enforceable resource boundaries, and consistency guarantees.
A generic statement that an agent session is monitored or
periodically approved does not, by itself, establish the specific
protected finality relationships required by the enforcement points.
7.5.200. C-21.108 - Technical Effect
this implementation profile enables a continuing artificial-
intelligence-agent session to perform multiple consequential
operations without treating the initial session approval as
unconditional execution authority.
Protected Candidate Act descriptors, finite effectuation windows,
micro-validation records, runtime behavioral validation, bounded
grants, and Finality Sink verification constrain the consequential
effects that may occur during the session.
The architecture may reduce repeated control-path processing by
permitting a latency-critical Finality Sink to verify compact current
grants locally.
Protected quotas and sequence state restrict unauthorized
overconsumption or replay.
Das Expires 25 April 2027 [Page 321]
Internet-Draft Sandbox Credential Egress Finality October 2026
Protected behavioral validation permits revocation or renewed
authorization in response to material drift.
Session generations, chain continuity, and authoritative protected
state prevent prohibited reuse of old permissions following restart,
rollback, or migration.
The technical guarantees depend upon the actual controlled
effectuation paths, protected state properties, and implemented
consistency semantics.
7.5.201. C-21.109 - Technical Summary
this implementation profile discloses a continuous artificial-
intelligence-agent executionfinality architecture in which an agent
operates within a sandboxed session associated with a protected
session identity and an initial permission envelope.
The system intercepts successive proposed operations and represents
them as individual Candidate Acts, bounded operation groups, or
finite effectuation windows.
A Protected Enforcement Domain validates the applicable current
session, behavioral, policy, freshness, and operation-specific
conditions.
Protected validation evidence or micro-validation state is committed
before or atomically with availability of the corresponding scoped
finality authorization.
A protected micro-validation chain may bind successive authorized
operations or protected state transitions.
A Finality Sink verifies the actual pending operation against a
current bounded grant, protected sequence state, authorized resource
scope, applicable freshness, and remaining consumption budget.
A control-path rate different from the effectuation-path rate may be
employed, enabling compact protected verification of authorized
operations without unlimited standing permission.
Material behavioral deviation, policy change, revoked authority,
exhausted budget, invalid freshness, or operation-scope mismatch
causes further governed effects to be withheld.
Das Expires 25 April 2027 [Page 322]
Internet-Draft Sandbox Credential Egress Finality October 2026
Protected session generations, chain-head continuity, authoritative
state recovery, and controlled migration prevent unauthorized reuse
of previously authorized conditions following restart, snapshot
restoration, or failover.
The architecture may be implemented using software, protected
transaction controllers, kernels, virtual machines, cloud services,
TEEs, HSMs, hardware controllers, or cooperating distributed
enforcement components.
7.5.201.1. PROTECTED ARTIFICIAL-INTELLIGENCE-AGENT EFFECTUATION-PATH
COMPLETENESS WITH MACHINE-VERIFIABLE PATH COVERAGE, PARENT-
7.5.201.2. SINK DOMINANCE, DYNAMIC BYPASS DETECTION, AND PROTECTED
COVERAGE-STATE COMMITMENTS
7.6. Implementation Profile C-33
Source location: original disclosure pages 631-691. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.6.1. C-33.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, sandbox enforcement, operating-system and cloud security,
protected execution finality, resource mediation, technical
reachability analysis, effectuation-path verification, and prevention
of unauthorized consequential operations.
More particularly, the embodiment discloses a computer-implemented
system configured to identify and maintain machine-verifiable
representations of effect-capable operation paths accessible directly
or indirectly to an artificial-intelligence agent, determine whether
enabled paths are governed by appropriate effectuation controls, and
withhold externally consequential operations when a required path-
coverage condition is not satisfied.
The system may employ:
(a) operating-system security interfaces; (b) process and container
restrictions; (c) virtual-machine or hypervisor enforcement; (d)
protected file-system controllers; (e) credential brokers; (f)
network gateways; (g) API dispatch controllers; (h) browser or
computer-use interfaces; (i) database transaction controllers;
(j) persistent storage controllers;
Das Expires 25 April 2027 [Page 323]
Internet-Draft Sandbox Credential Egress Finality October 2026
(k) protected memory controllers;
(l) peripheral and device controllers;
(m) SmartNICs or DPUs;
(n) protected enforcement domains;
(o) cryptographically isolated enforcement domains; and
(p) cooperating software, firmware, or hardware Finality Sinks.
The system is not limited to a specific cloud provider, operating
system, security-hook framework, virtualization environment, or
hardware manufacturer.
7.6.2. C-33.2 - Technical Problem
An artificial-intelligence agent may generate a consequential
operation through more than one technical path.
For example, a network transmission may be produced through:
1. An approved API connector. 2. An ordinary socket. 3. A
privileged host-side process. 4. An HTTP proxy. 5. A secondary
network adapter. 6. A container host service. 7. A delegated tool
worker. 8. A virtual network device. 9. A directly assigned
hardware interface. 10. An asynchronous job queue.
Likewise, a persistent resource modification may occur through:
(a) an approved database service; (b) a direct file-system write; (c)
a memory-mapped file; (d) a privileged maintenance process; (e) a
storage-controller operation; (f) a transaction-log replay;
(g) a backup restoration interface; or
(h) another resource-modification path.
An authorization mechanism applied to only one of these paths does
not necessarily govern the others.
A further problem arises where an agent or intermediary can select a
different path after an authorization decision.
For example:
Das Expires 25 April 2027 [Page 324]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | A network proxy may fail over to a direct socket. |
| - | ---------------------------------------------------------------------------------------------- |
| x | A connector may invoke a privileged maintenance service. |
| x | A container may acquire a host resource through an exposed mount. |
| x | An agent may transmit data through a delegated worker. |
| x | A virtual machine may use a directly assigned device. |
| x | A resource modification may occur through an asynchronous service after the original approval. |
x A failover controller may activate an alternate interface not
included in the original
authorization.
The existence of one correctly implemented Finality Sink therefore
does not establish that all relevant paths are governed.
this implementation profile addresses this problem by defining an
enforceable coverage relationship among effect-capable paths,
disabling controls, parent Finality Sinks, protected authorization
state, and the actual effectuation interfaces.
7.6.3. C-33.3 - Central Technical Principle
For an applicable class of governed consequential operations:
7.6.4. Every enabled relevant path capable of producing the governed
effect must be
controlled by an applicable Finality Sink or a verified parent
Finality Sink, while paths lacking the required control must remain
technically disabled or unable to produce that effect.
The system maintains a protected representation of this condition.
Authorization of a Candidate Act depends upon both:
1. Successful operation-specific protected authority validation; and
2. Successful verification of the required effectuation-path
coverage predicate.
A Candidate Act is not authorized merely because the intended tool or
preferred execution route possesses a Finality Sink.
The relevant alternate paths must also satisfy the coverage
condition.
7.6.5. PART I - PRINCIPAL SYSTEM ARCHITECTURE
Das Expires 25 April 2027 [Page 325]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.6. C-33.4 - Principal Components
A representative system comprises the following functional
components.
7.6.7. Component A - Agent Execution Environment
One or more computational environments in which artificial-
intelligence agents generate proposed operations.
The environment may comprise a process, container, virtual machine,
browser runtime, cloud agent, managed worker, or delegated execution
service.
7.6.8. Component B - Effectuation-Path Discovery Controller
A component configured to identify effect-capable interfaces
accessible to the agent directly or through reachable intermediaries.
7.6.9. Component C - Effectuation-Path Registry
A machine-readable registry identifying relevant paths, their enabled
states, effect classes, access contexts, and applicable enforcement
relationships.
7.6.10. Component D - Effectuation-Class Controller
A mechanism configured to associate consequential operations with
protected effect classes.
7.6.11. Component E - Path Coverage Verifier
A component configured to evaluate whether every enabled relevant
path satisfies the required coverage predicate.
7.6.12. Component F - Parent Finality Sink Verifier
A component configured to determine whether a protected parent
effectuation controller actually governs a downstream path.
7.6.13. Component G - Path Disablement Controller
A mechanism configured to apply or verify restrictions preventing a
path from producing a governed effect.
Das Expires 25 April 2027 [Page 326]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.14. Component H - Dynamic Topology Controller
A component configured to observe material changes to path
availability, connectivity, routing, delegation, or resource
ownership.
7.6.15. Component I - Protected Enforcement Domain
A PED configured to perform the required operation-specific
authorization and coverage validation.
7.6.16. Component J - Protected Coverage-State Registry
An integrity-protected store maintaining the applicable coverage
generation, approved enforcement state, and protected coverage
commitment.
7.6.17. Component K - Candidate Act Interceptor
A component configured to capture a proposed consequential operation
before its governed effect.
7.6.18. Component L - Non-Effective Operation Holder
A mechanism configured to withhold the Candidate Act while
authorization and coverage conditions are evaluated.
7.6.19. Component M - Protected Validation Evidence Controller
A component configured to commit protected evidence of the required
authorization and coverage checks.
7.6.20. Component N - Scoped Finality Enablement Controller
A mechanism configured to establish bounded non-bearer authorization
for the validated Candidate Act.
7.6.21. Component O - Finality Sink
A controller configured to verify the actual pending operation and
applicable authorization before the designated consequential effect.
7.6.22. Component P - Coverage Recovery Controller
A mechanism configured to restore or restrict execution after
topology changes, failover, enforcement failure, or incomplete path
verification.
Das Expires 25 April 2027 [Page 327]
Internet-Draft Sandbox Credential Egress Finality October 2026
These functions may be integrated or distributed.
7.6.23. C-33.5 - Reference Architecture
A representative execution arrangement comprises:
AGENT EXECUTION
↓
PROPOSED CONSEQUENTIAL OPERATION
↓
CANDIDATE ACT INTERCEPTION
↓
NON-EFFECTIVE STAGING
↓
EFFECT CLASS AND RESOURCE IDENTIFICATION
↓
PROTECTED PATH REGISTRY LOOKUP
↓
COVERAGE PREDICATE VERIFICATION
↓
PED OPERATION-SPECIFIC AUTHORIZATION
↓
PROTECTED EVIDENCE COMMITMENT
↓
SCOPED FINALITY ENABLEMENT
↓
ACTUAL OPERATION VERIFICATION AT FINALITY SINK
Das Expires 25 April 2027 [Page 328]
Internet-Draft Sandbox Credential Egress Finality October 2026
↓
AUTHORIZED EFFECTUATION
The Effectuation-Path Registry is updated when relevant technical
paths change.
The protected coverage commitment is linked to the authorization
under which a Candidate Act may be released.
7.6.24. PART II - EFFECTUATION-PATH DEFINITIONS
7.6.25. C-33.6 - Effectuation Path
An Effectuation Path means a technically reachable sequence of
operation interfaces or resource transitions through which an AI
agent, its delegated components, or its accessible authority may
produce a specified consequential effect.
A path may include:
1. Source execution context. 2. Tool or process invocation. 3.
Intermediary service. 4. Resource interface. 5. Authorization or
security control. 6. Finality Sink. 7. Actual effectuation
boundary.
A path may cross multiple processes, machines, devices,
administrative domains, or services.
7.6.26. C-33.7 - Effect-Capable Interface
An Effect-Capable Interface means a software, firmware, or hardware
interface through which an operation can directly or indirectly
produce a consequential change.
Representative interfaces include:
(a) a network send operation; (b) a protected file write; (c) a
database commit; (d) a credential-use interface; (e) a process-
execution interface; (f) a browser automation action; (g) a
persistent memory modification; (h) an accelerator output release;
(i) a device command; (j) a payment instruction;
(k) a storage-controller operation; or
(l) an equivalent resource transition.
Das Expires 25 April 2027 [Page 329]
Internet-Draft Sandbox Credential Egress Finality October 2026
An interface may be effect-capable even where the agent does not
invoke it directly.
7.6.27. C-33.8 - Governed Effect Class
A Governed Effect Class identifies a category of consequential
operation to which a specified enforcement policy applies.
Representative classes comprise:
NETWORK_TRANSMISSION
FILE_MUTATION
DATABASE_COMMIT
CREDENTIAL_USE
PRIVILEGED_PROCESS_EXECUTION
API_SERVICE_OPERATION
PERSISTENT_MEMORY_WRITE
BROWSER_EXTERNAL_ACTION
DEVICE_COMMAND
DISPLAY_OR_RENDER_RELEASE
DMA_OPERATION
PAYMENT_OR_TRANSACTION_COMMIT
A system may define additional classes.
The meaning of each class must be sufficiently specific to permit
machine-verifiable coverage assessment.
7.6.28. C-33.9 - Path Enablement State
A path may have one of several machine-readable states.
Representative states include:
ENABLED_AND_GOVERNED
ENABLED_WITH_PARENT_SINK
Das Expires 25 April 2027 [Page 330]
Internet-Draft Sandbox Credential Egress Finality October 2026
TECHNICALLY_DISABLED
EFFECT_PREVENTED
PENDING_VERIFICATION
UNKNOWN
INVALID
RESTRICTED
A path recorded as ENABLED_AND_GOVERNED must have a verified
applicable Finality Sink.
A path recorded as TECHNICALLY_DISABLED must have an effective
disabling mechanism.
The UNKNOWN state is not interpreted as proof of coverage.
7.6.29. PART III - EFFECTUATION-PATH REGISTRY
7.6.30. C-33.10 - Path Registry Record
A representative Effectuation-Path Record comprises:
PathID = PATH-3301
OriginExecutionClass = AGENT_PROCESS
EffectClass = NETWORK_TRANSMISSION
InterfaceSequence = PROCESS → CONNECTOR → GATEWAY
TerminalEffectInterface = NETWORK_INTERFACE_1
EnabledState = ENABLED
RequiredSinkID = FS-NET-01
VerifiedParentSinkID = NONE
CoverageGeneration = 620
VerificationStatus = COVERED
The values are illustrative.
Das Expires 25 April 2027 [Page 331]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.31. C-33.11 - Registry Scope
The registry is defined relative to:
1. A protected execution environment. 2. An agent or workload
authority context. 3. A governed effect class. 4. Available tools
and resource interfaces. 5. Applicable privilege or delegation
relationships. 6. Current device and network configuration. 7.
Current enforcement state. 8. A protected coverage generation.
The system need not assert that it has enumerated every conceivable
interface in every possible future computing configuration.
Instead, it establishes the required coverage for the enabled
interfaces available within the defined deployment and trust
boundary.
Where a newly accessible path falls outside that verified scope, the
corresponding effectuation class remains restricted until the path is
resolved.
7.6.32. C-33.12 - Registry Discovery Sources
Effectuation-path information may be obtained from:
(a) executable-interface inventories; (b) process-creation policies;
(c) container configuration; (d) mounted file-system resources; (e)
kernel security policies; (f) service-account permissions; (g)
connector registries;
(h) API routing configurations;
(i) network interface configurations;
(j) hypervisor device assignments;
(k) privileged host services;
(l) hardware resource ownership;
(m) asynchronous worker registrations;
(n) permitted credential-use interfaces; or
(o) protected runtime observations.
The reliability of a registry entry depends upon the integrity and
completeness of the source that establishes it.
Das Expires 25 April 2027 [Page 332]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.33. C-33.13 - Trusted Path Observation
In one implementation, the path registry is populated from protected
deployment configuration and controlled runtime interfaces.
The system distinguishes:
Declared Path: An interface described by application configuration.
Observed Path: An interface exercised or detected through runtime
observation.
Enforceably Restricted Path: An interface whose operation can be
technically prevented.
Verified Covered Path: An interface for which the required Finality
Sink relationship has
been established.
Observation of one path does not establish the absence of all others.
Accordingly, runtime observation may supplement but not replace
enforceable configuration control where complete path coverage is
claimed.
7.6.34. PART IV - MACHINE-VERIFIABLE COVERAGE MODEL
7.6.35. C-33.14 - Bounded Effectuation Graph
A representative implementation constructs a directed graph:
G = (V, E)
where:
V represents execution components, operation interfaces, authority
contexts, enforcement components, and effect-capable resources.
E represents technically permitted or reachable transitions between
those components.
A node may represent:
Das Expires 25 April 2027 [Page 333]
Internet-Draft Sandbox Credential Egress Finality October 2026
| x | Agent process. |
| - | ----------------------- |
| x | Child process. |
| x | Privileged tool worker. |
| x | Connector. |
| x | Proxy. |
| - | ----------------------- |
| x | Kernel interface. |
| x | Credential broker. |
| x | Resource controller. |
| x | Hardware command queue. |
| x | Finality Sink. |
| x | Terminal effect. |
The graph is evaluated under a defined configuration and authority
generation.
7.6.36. C-33.15 - Enabled Relevant Paths
For a governed effect class F and agent context A, the system
determines the set of enabled relevant paths:
P(A,F,G)
Each path begins at an execution or authority context accessible to A
and reaches an interface capable of producing effect F.
A path may be direct or indirect.
A path may include delegated or privileged intermediaries when they
are reachable through the agent's available operation interfaces.
7.6.37. C-33.16 - Coverage Classification
For each enabled relevant path p, the verifier determines whether at
least one required condition holds:
1. The path is governed by an applicable verified Finality Sink.
2. The path is governed by a verified parent Finality Sink. 3. The
path is technically disabled. 4. The path is prevented from
producing the specified governed effect.
An enabled path lacking an applicable condition is classified as
UNCOVERED.
Das Expires 25 April 2027 [Page 334]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.38. C-33.17 - Coverage Predicate
A representative coverage predicate is:
CoverageValid(A,F,G) =
For every relevant path p in P(A,F,G):
Governed(p,F)
OR ParentGoverned(p,F)
OR Disabled(p,F)
OR EffectPrevented(p,F)
The predicate is evaluated according to the selected graph,
configuration, and enforcement semantics.
A protected controller may represent its result by a machine-readable
coverage record.
7.6.39. C-33.18 - Effect-Specific Coverage
Coverage is evaluated relative to the actual governed effect.
For example, a proxy may control outgoing HTTP request submission.
The proxy may therefore provide a Finality Sink for the external
submission effect.
It does not automatically control a destination service's later
internal database mutation.
If the claimed effect is the remote database commit, the system must
identify a suitable controller capable of enforcing that commit.
Coverage of one effect class is not automatically coverage of
another.
7.6.40. PART V - VERIFIED PARENT FINALITY SINK
Das Expires 25 April 2027 [Page 335]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.41. C-33.19 - Parent Finality Sink
A Parent Finality Sink means a technically controlling enforcement
component positioned upstream of one or more effect-capable child
interfaces and capable of preventing a specified governed effect from
being reached through the relevant downstream path unless the
required finality authorization succeeds.
For example, a protected credential broker may control all usable
applications of a particular nonexportable credential.
A downstream API connector may therefore be governed by the broker
for the effect of credential application, provided no alternate
usable credential path exists within the claimed scope.
7.6.42. C-33.20 - Parent-Sink Dominance
For a defined source execution context and governed effect class, an
applicable parent sink must lie on every permitted route from that
source to the relevant downstream effect, or otherwise possess
equivalent technical control preventing unauthorized effectuation.
In a graph-based representation, a parent sink may act as a mandatory
control node dominating the applicable effect node.
The dominance requirement is evaluated under the actual enabled path
conditions.
A parent sink does not provide coverage merely because it appears on
the preferred route.
7.6.43. C-33.21 - Parent-Sink Verification Conditions
A representative parent-sink verification checks:
1. Parent sink identity. 2. Protected enforcement configuration. 3.
Actual control over the relevant downstream operation. 4. Applicable
operation class. 5. Material resource scope. 6. Absence of
uncontrolled alternative routes within the verified deployment. 7.
Current policy and coverage generation. 8. Sink availability. 9.
Relevant delegated or privileged paths. 10. Effectuation-boundary
correspondence.
The selected implementation may evaluate additional conditions.
Das Expires 25 April 2027 [Page 336]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.44. C-33.22 - Parent-Sink Dominance Algorithm
function VerifyParentSinkDominance(
effect_graph, source_nodes, effect_nodes, parent_sink ):
if not VerifyProtectedSinkIdentity(parent_sink):
return FALSE
if not VerifySinkControlsEffectClass(parent_sink):
return FALSE
for each source in source_nodes:
for each effect in effect_nodes:
paths = EnumerateOrSymbolicallyAnalyzeEnabledPaths(
effect_graph, source, effect )
for each path in paths:
if not PathContainsMandatoryProtectedControl(
path, parent_sink ):
return FALSE
if PathPermitsBypassAfterParentValidation(path):
return FALSE
return TRUE
A concrete implementation may use graph-dominance analysis,
constrained reachability, protected configuration rules, or
equivalent methods.
The analysis must account for the actual technical enforcement
semantics of the parent.
7.6.45. C-33.23 - Parent-Sink Delegation
A parent sink may authorize a child service to perform a bounded
operation.
Das Expires 25 April 2027 [Page 337]
Internet-Draft Sandbox Credential Egress Finality October 2026
The child service may receive:
(a) a protected operation descriptor; (b) an authenticated task
reference; (c) a scoped finality capability; (d) a protected
authorization reference; or (e) an internal controller-issued
operation identity.
The child does not receive unrestricted authority merely because the
parent approved one earlier operation.
Where the child can materially alter the operation after parent
authorization, the parent must maintain effective control over the
permitted transformation or require downstream verification.
7.6.46. PART VI - TECHNICAL DISABLEMENT
7.6.47. C-33.24 - Disabled Effectuation Path
A path may satisfy coverage requirements by being technically
disabled.
Representative restrictions include:
1. Denial of a system-call class. 2. Removal of a file write
permission. 3. Restriction of a service identity. 4. Removal of a
device mapping. 5. Disabling a network interface. 6. Blocking an
unauthorized route. 7. Denying credential access. 8. Disabling a
connector. 9. Preventing execution of a privileged program. 10.
Restricting a browser automation operation. 11. Removing access to a
device command queue. 12. Preventing a persistent storage commit.
The restriction must actually prevent the specified governed effect.
7.6.48. C-33.25 - Disablement Verification
A representative disablement record comprises:
DisablementRecordID
PathID
EffectClass
RestrictionMechanism
ProtectedPolicyGeneration
EnforcementPointID
Das Expires 25 April 2027 [Page 338]
Internet-Draft Sandbox Credential Egress Finality October 2026
AppliedState
VerificationStatus
The system may verify that the restriction is installed and currently
effective.
For example, a network path may be classified as disabled only when
its required routing or interface restrictions are enforced under the
selected threat model.
A configuration file stating that the interface should be disabled is
insufficient if the interface remains usable.
7.6.49. C-33.26 - Effect Prevention Without Total Disablement
An interface may remain available for harmless computation while
being prevented from producing a designated external effect.
For example:
| x | A process may execute without possessing protected network egress. |
| - | -------------------------------------------------------------------------------------------------------- |
| x | A file interface may permit reads but prohibit persistent writes. |
| x | A GPU may perform computation while output release remains controlled. |
| x | A browser may render a page while protected form submission remains disabled. |
| x | A credential interface may expose a surrogate reference without revealing reusable credential authority. |
The path registry may classify such interfaces as EFFECT_PREVENTED
for the specified effect class.
7.6.50. PART VII - HOST, CONTAINER, AND KERNEL COVERAGE
7.6.51. C-33.27 - Process-Execution Paths
A process may reach consequential effects through child processes,
command interpreters, dynamically executed programs, or privileged
services.
The path registry may identify:
(a) process creation; (b) executable invocation; (c) privilege
transition; (d) inherited handles; (e) interprocess communication;
(f) delegated execution; and
(g) access to effect-capable host services.
Das Expires 25 April 2027 [Page 339]
Internet-Draft Sandbox Credential Egress Finality October 2026
The deployment must address these paths where they can produce the
governed effect.
7.6.52. C-33.28 - Container Coverage
A containerized agent may access resources through:
1. Container network interfaces. 2. Host-mounted directories. 3.
Shared sockets. 4. Privileged container capabilities. 5. Host
process interfaces. 6. Device mappings. 7. Container runtime APIs.
8. Host-side connectors.
The path registry represents relevant enabled interfaces and their
controls.
A container namespace is not automatically an independent Finality
Sink for every effect reachable through the host.
7.6.53. C-33.29 - Kernel and System-Call Coverage
The system may employ supported kernel security mechanisms to
restrict selected operation classes.
Examples include:
| x | Security module policies. |
| - | ---------------------------------- |
| x | System-call restrictions. |
| x | Controlled file-access interfaces. |
| x | Network enforcement. |
| - | ----------------------------------------- |
| x | Process execution restrictions. |
| x | Protected device access. |
| x | Other supported kernel security controls. |
The implementation distinguishes an enforcement-capable hook from a
tracing or logging
interface.
A monitoring event that occurs after an irreversible effect does not
establish preventive path
control.
Das Expires 25 April 2027 [Page 340]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.54. C-33.30 - Existing Handles and Asynchronous Interfaces
A process may retain a previously opened file descriptor, socket,
memory mapping, or device handle.
The path registry and coverage verification may account for:
(a) inherited handles; (b) duplicated descriptors; (c) shared memory;
(d) preexisting network connections; (e) asynchronous I/O; (f)
memory-mapped writes; (g) queued commands; and (h) delegated worker
continuation.
A restriction applied only to new open or connect operations may be
insufficient when existing handles remain effect-capable.
7.6.55. PART VIII - PROXY, API GATEWAY, AND CONNECTOR COVERAGE
7.6.56. C-33.31 - Network Proxy as Finality Sink
A network proxy may act as a Finality Sink for selected network
transmission effects where:
1. The agent cannot bypass the proxy for those effects. 2. The
proxy controls the actual governed transmission. 3. The proxy
obtains the material pending request information required by policy.
4. The proxy verifies the applicable scoped finality authorization.
5. The proxy applies current protected state and revocation
conditions. 6. Unauthorized requests remain withheld.
The proxy must not rely exclusively on an unverified upstream
approval indication.
7.6.57. C-33.32 - API Gateway as Finality Sink
An API gateway may provide effectuation control for API request
submission.
The system verifies that the gateway is on the mandatory path for the
governed request class.
Where a downstream service independently controls later resource
mutation, the gateway's coverage is not automatically interpreted as
direct control over that later effect.
A resource-commit enforcement point may require destination-side
control.
Das Expires 25 April 2027 [Page 341]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.58. C-33.33 - Connector Gateway Coverage
A connector may translate an abstract agent operation into a concrete
resource request.
The registry may identify:
ConnectorID
AvailableOperationClasses
CredentialScope
PermittedDestinations
UnderlyingResourceInterfaces
RequiredSinkID
ConnectorGeneration
A connector is considered covered when the actual governed effects it
can produce remain subject to applicable protected authorization.
7.6.59. C-33.34 - Credential-Path Coverage
Credential use may create an alternative effect-capable path.
For example, an agent may have:
(a) a protected credential broker; (b) an exposed API token in an
environment variable; and
(c) access to a direct network route.
Even if the broker correctly enforces protected finality, the exposed
token and direct route may provide an uncontrolled alternative
credential-mediated path.
The system must restrict the alternate authority route where it falls
within the claimed effect class.
7.6.60. PART IX - ALTERNATIVE PATHS AND FAILOVER
Das Expires 25 April 2027 [Page 342]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.61. C-33.35 - Alternative Path
An Alternative Path means a technically reachable route capable of
producing the governed effect without using the currently designated
execution interface.
An alternative path may arise from:
1. Fallback. 2. Service failover. 3. Maintenance mode. 4.
Diagnostic mode. 5. Recovery mode. 6. Backup network routing. 7. A
substitute API endpoint. 8. Direct hardware access. 9. A privileged
host command. 10. A newly enabled connector.
7.6.62. C-33.36 - Dynamic Path Activation
Before a newly enabled path becomes available to the agent for
governed effects, the system may require:
1. Registration of the path. 2. Classification of its effect
capabilities. 3. Identification of the relevant Finality Sink. 4.
Verification of required parent-sink relationships. 5. Verification
of disabling restrictions for uncovered effects. 6. Protected
coverage-state update. 7. Applicable authority-generation
transition.
8. Authorization of operations under the updated coverage state.
The path remains restricted until these conditions succeed.
7.6.63. C-33.37 - Failover Barrier
A Failover Barrier means a protected transition preventing a
substitute path from producing governed effects before its required
coverage has been established.
A representative failover sequence comprises:
ACTIVE PRIMARY PATH
↓
PRIMARY PATH FAILURE
↓
RESTRICT GOVERNED EFFECTUATION
↓
Das Expires 25 April 2027 [Page 343]
Internet-Draft Sandbox Credential Egress Finality October 2026
IDENTIFY SUBSTITUTE PATH
↓
VERIFY SUBSTITUTE EFFECTUATION CONTROL
↓
COMMIT NEW COVERAGE GENERATION
↓
INVALIDATE OR REVALIDATE AFFECTED AUTHORIZATIONS
↓
ACTIVATE VERIFIED SUBSTITUTE PATH
The exact ordering may be implemented transactionally or through
equivalent protected barriers.
7.6.64. C-33.38 - Failover Race Protection
A topology change may occur while a Candidate Act is awaiting
effectuation.
The system must prevent authorization established under one coverage
configuration from being improperly applied after a material path
change.
In one implementation, the Candidate Act's scoped finality
authorization is bound to a protected coverage generation.
The Finality Sink verifies that the generation remains acceptable.
If the path or required sink relationship has materially changed, the
operation is withheld or revalidated.
7.6.65. PART X - NON-NETWORK EFFECTUATION COVERAGE
7.6.66. C-33.39 - File-System Mutation
A file may be modified through:
(a) ordinary write operations; (b) file replacement; (c) renaming a
prepared file; (d) memory-mapped writes; (e) privileged helper
processes; (f) file synchronization services; (g) backup restoration;
(h) storage-controller paths.
Das Expires 25 April 2027 [Page 344]
Internet-Draft Sandbox Credential Egress Finality October 2026
The implementation identifies the effects actually governed.
For durable file-commit finality, an early file-open check alone may
be insufficient.
The controlled interface must enforce the required authorization at
an appropriate write or commit boundary.
7.6.67. C-33.40 - Database Commit
A database may receive changes through:
1. 2. 3. 4. 5. 6. 7.
Application APIs. Direct database clients. Privileged
administrative interfaces. Stored procedures. Import services.
Replication or replay mechanisms. Maintenance operations.
Where a enforcement point governs persistent database mutation, the
deployment must identify the interfaces capable of effecting such
mutation and provide the applicable controls.
7.6.68. C-33.41 - Persistent Memory Mutation
A memory-backed or persistent-memory resource may be modified through
native memory writes, mapped storage, controlled commit primitives,
or hardware-supported persistence mechanisms.
The path registry identifies the applicable effectuation boundary and
restrictions.
An operation permitted to write volatile memory does not
automatically possess authority to commit protected persistent state.
7.6.69. C-33.42 - Peripheral and Device Operation
An agent may cause a consequential effect through:
(a) an actuator; (b) a robotic controller; (c) a camera or microphone
control interface; (d) a peripheral command; (e) a hardware
communication device; (f) a storage controller; (g) an accelerator
output channel; or (h) another effect-capable device.
The applicable Finality Sink must control the designated device
effect.
Das Expires 25 April 2027 [Page 345]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.70. C-33.43 - Display and Rendering Release
A rendering operation may expose protected information through a
display, remote interface, browser surface, or media output.
A protected rendering Finality Sink may control the release of
selected information.
The path registry may include screen rendering, remote desktop
streaming, screenshot export, and other relevant output paths where
the claimed effect is disclosure.
7.6.71. C-33.44 - DMA Operation
A DMA-capable device may access protected memory through device-
initiated operations.
A protected coverage configuration may use IOMMU restrictions,
controlled DMA command admission, device isolation, or a suitable
hardware Finality Sink.
An IOMMU address permission is not automatically operation-specific
authority.
The implementation must supply the additional protected validation
mechanism when required by the enforcement point.
7.6.72. PART XI - PROTECTED COVERAGE-STATE COMMITMENT
7.6.73. C-33.45 - Coverage Generation
A Coverage Generation means a machine-verifiable version associated
with the current verified effectuation-path configuration.
A representative record comprises:
CoverageGeneration = 620
AgentContextID = AGENT-42
EffectClass = NETWORK_TRANSMISSION
PathRegistryDigest = DIGEST-620
VerifiedSinkSet = FS-NET-01, FS-NET-02
DisabledPathSet = PATH-04, PATH-05
Das Expires 25 April 2027 [Page 346]
Internet-Draft Sandbox Credential Egress Finality October 2026
CoverageStatus = VERIFIED
The generation is maintained within an appropriately protected
registry.
7.6.74. C-33.46 - Protected Coverage Commitment
A Protected Coverage Commitment means an authenticated or integrity-
protected representation of the applicable path-coverage state.
A representative construction is:
CoverageCommitment = H( CoverageDomainSeparator ||
CoverageGeneration || AgentContextID || EffectClass ||
CanonicalPathRegistry || CanonicalSinkBindings ||
CanonicalDisablementState || VerificationPolicyVersion )
The encoding must specify a deterministic field representation.
The commitment may be maintained in protected software state, an
authenticated log, a CIED, or a hardware-protected registry.
7.6.75. C-33.47 - Coverage Commitment and Candidate Act
A Candidate Act may be bound to:
CandidateActID
OperationDescriptorDigest
CoverageGeneration
CoverageCommitment
RequiredSinkID
AuthorityGeneration
ValidationEvidenceReference
The protected validation procedure verifies the applicable coverage
predicate.
The resulting evidence or scoped finality-enabling condition may
reference the coverage commitment.
Das Expires 25 April 2027 [Page 347]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.76. C-33.48 - Coverage-Aware Finality Capability
A representative capability record comprises:
CapabilityID = CAP-3301
CandidateActID = CA-3301
EvidenceReference = VE-3301
OperationDigest = DIGEST-3301
CoverageGeneration = 620
CoverageCommitment = CC-620
AuthorizedSinkID = FS-NET-01
AuthorityGeneration = 105
UsagePolicy = SINGLE_USE
The Finality Sink verifies the required coverage association before
effectuation.
7.6.77. C-33.49 - Material Coverage Change
A Material Coverage Change means a configuration or state change that
may alter the ability of an agent or accessible intermediary to
produce a governed effect through a relevant path.
Examples include:
1. Enabling a direct network interface. 2. Adding a privileged tool
connector. 3. Modifying a resource mount. 4. Exposing a new
credential. 5. Activating failover routing. 6. Replacing a network
proxy. 7. Changing device assignment. 8. Relaxing a kernel security
policy. 9. Introducing a privileged host service. 10. Adding a new
effect-capable tool. 11. Reconfiguring a resource controller. 12.
Changing a mandatory parent-sink relationship.
A material change may require a new protected coverage generation.
7.6.78. C-33.50 - Coverage Invalidation
When material coverage changes, the system may:
(a) invalidate affected Candidate Act authorizations;
Das Expires 25 April 2027 [Page 348]
Internet-Draft Sandbox Credential Egress Finality October 2026
(b) suspend relevant Finality Sinks;
(c) restrict newly enabled paths;
(d) recompute the required coverage predicate;
(e) establish a new protected coverage commitment;
(f) revalidate affected operations; or
(g) apply a combination thereof.
A stale authorization is not accepted merely because its original
coverage commitment remains cryptographically authentic.
7.6.79. PART XII - PROTECTED VALIDATION AND FINALITY
7.6.80. C-33.51 - Candidate Act Capture
An AI agent generates a proposed consequential operation.
The controlled interface constructs a Candidate Act Descriptor
including:
CandidateActID
AgentContextID
OperationClass
TargetResource
MaterialOperationParameters
RequiredEffectClass
AuthorityGeneration
CoverageGeneration
RequiredSinkID
The operation remains non-effective.
7.6.81. C-33.52 - PED Coverage Predicate Evaluation
The PED obtains the current protected coverage state.
Das Expires 25 April 2027 [Page 349]
Internet-Draft Sandbox Credential Egress Finality October 2026
It determines whether:
1. The relevant effect class is identified. 2. The path registry is
valid. 3. All enabled relevant paths satisfy the coverage condition.
4. Required Finality Sinks are verified. 5. Parent-sink
relationships are valid. 6. Disabled paths remain technically
restricted. 7. No material unresolved topology change exists. 8.
The current coverage generation is acceptable.
If a mandatory condition fails, protected finality authorization is
withheld.
7.6.82. C-33.53 - Protected Validation Evidence
Following successful operation-specific validation and coverage
verification, the PED commits protected evidence.
A representative record comprises:
EvidenceID = VE-3301
CandidateActID = CA-3301
OperationDigest = DIGEST-3301
AuthorityGeneration = 105
CoverageGeneration = 620
CoverageCommitment = CC-620
ValidationResult = APPROVED
RequiredSinkID = FS-NET-01
The evidence may be an authenticated protected record, signed
receipt, transactional state entry, or equivalent protected
commitment.
7.6.83. C-33.54 - Scoped Finality Enablement
The PED establishes bounded non-bearer finality authorization
associated with the validated Candidate Act.
The authorization is bound to the actual effectuation scope and
applicable protected state.
Das Expires 25 April 2027 [Page 350]
Internet-Draft Sandbox Credential Egress Finality October 2026
The capability does not permit arbitrary use of a different path,
resource, sink, or operation class.
7.6.84. C-33.55 - Finality Sink Verification
The Finality Sink obtains or reconstructs the actual pending
operation.
It verifies:
(a) protected evidence validity; (b) capability/evidence
correspondence; (c) operation descriptor correspondence; (d)
authorized resource and effect class; (e) current authority
generation; (f) required coverage generation; (g) applicable coverage
commitment; (h) sink identity; (i) protected usage state; and (j)
applicable freshness and revocation conditions.
Only after successful verification does the sink permit the governed
effect.
7.6.85. PART XIII - PRINCIPAL EXECUTION WORKFLOW
7.6.86. C-33.56 - Complete 30-Step Workflow
7.6.87. Step C33-01 - Execution environment initialization
The agent runtime and relevant enforcement components are
initialized.
7.6.88. Step C33-02 - Effect-class definition
The governed consequential operation classes are identified.
7.6.89. Step C33-03 - Interface inventory
Accessible operation interfaces and resource paths are enumerated.
7.6.90. Step C33-04 - Path registry construction
The system constructs machine-verifiable path records.
7.6.91. Step C33-05 - Enabled-path determination
The current enabled paths are identified.
Das Expires 25 April 2027 [Page 351]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.92. Step C33-06 - Sink association
Each relevant path is associated with an applicable Finality Sink or
protected disabling restriction.
7.6.93. Step C33-07 - Parent-sink verification
Applicable parent-sink control relationships are verified.
7.6.94. Step C33-08 - Coverage predicate evaluation
The system determines whether all enabled relevant paths satisfy
required coverage.
7.6.95. Step C33-09 - Protected coverage commitment
The current verified coverage state is committed.
7.6.96. Step C33-10 - Agent execution
The agent performs permitted computation.
7.6.97. Step C33-11 - Proposed operation generation
The agent creates a consequential operation.
7.6.98. Step C33-12 - Candidate Act interception
The operation is captured at the controlled interface.
7.6.99. Step C33-13 - Non-effective staging
The governed effect is withheld.
7.6.100. Step C33-14 - Candidate descriptor construction
A canonical descriptor is established.
7.6.101. Step C33-15 - Effect-class association
The required effect class is identified.
7.6.102. Step C33-16 - Current registry lookup
The protected controller obtains applicable path and coverage state.
Das Expires 25 April 2027 [Page 352]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.103. Step C33-17 - Coverage revalidation
The required path-coverage predicate is verified.
7.6.104. Step C33-18 - Protected authority-state retrieval
Current task, policy, resource, and revocation information is
obtained.
7.6.105. Step C33-19 - Operation-specific predicate evaluation
The PED evaluates mandatory authorization conditions.
7.6.106. Step C33-20 - Protected state operation
The applicable protected authority-state operation is performed.
7.6.107. Step C33-21 - Validation evidence commitment
Protected validation evidence is committed.
7.6.108. Step C33-22 - Scoped finality authorization
A bounded finality-enabling condition is established.
7.6.109. Step C33-23 - Operation presentation to sink
The staged operation reaches the authorized effectuation controller.
7.6.110. Step C33-24 - Actual pending operation reconstruction
The sink obtains the actual material operation parameters.
7.6.111. Step C33-25 - Coverage-generation verification
The sink verifies the required current coverage state.
7.6.112. Step C33-26 - Capability and authority verification
The sink verifies the required evidence, capability, and current
authorization.
7.6.113. Step C33-27 - Protected consumption transition
The required capability-use state is reserved or consumed.
Das Expires 25 April 2027 [Page 353]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.114. Step C33-28 - Controlled effectuation
The authorized operation is performed.
7.6.115. Step C33-29 - Completion-state update
The operation result is recorded or reconciled.
7.6.116. Step C33-30 - Dynamic coverage maintenance
Relevant topology, interface, or policy changes trigger required
coverage revalidation and authorization updates.
7.6.117. PART XIV - REFERENCE ALGORITHMS
7.6.118. C-33.57 - Algorithm A: Path Registry Construction
function ConstructEffectuationPathRegistry(environment):
contexts = DiscoverAuthorizedExecutionContexts(environment)
interfaces = DiscoverReachableOperationInterfaces(
contexts )
effect_resources = IdentifyEffectCapableResources(
interfaces )
paths = BuildReachabilityRepresentation(
contexts, interfaces, effect_resources )
for each path in paths:
classification = ClassifyEffectuationPath(path)
enforcement = ResolveApplicableEnforcement(path)
RegisterPath({
path_id: path.id, effect_class: classification,
enabled_state: DetermineEnabledState(path), enforcement_reference:
enforcement, configuration_generation:
CurrentConfigurationGeneration() })
return ProtectedPathRegistry.current()
Das Expires 25 April 2027 [Page 354]
Internet-Draft Sandbox Credential Egress Finality October 2026
The discovery mechanism must be appropriate for the selected
deployment.
A discovered inventory is not automatically complete unless the
implementation also restricts unregistered effect-capable interfaces
or otherwise establishes the required closed-world coverage
condition.
7.6.119. C-33.58 - Algorithm B: Coverage Predicate
function VerifyEffectuationCoverage(
agent_context, effect_class, registry ):
if not VerifyProtectedRegistryIntegrity(registry):
return UNCOVERED paths = ResolveEnabledRelevantPaths(
agent_context, effect_class, registry )
if RequiredPathEnumerationIncomplete(paths):
return UNCOVERED for each path in paths:
if VerifyApplicableFinalitySink(path):
continue
if VerifyParentFinalitySink(path):
continue
if VerifyTechnicalDisablement(path):
continue
if VerifyEffectPrevention(path):
continue
return UNCOVERED
return COVERED
An unknown enabled path is not treated as covered.
C-33.59 - Algorithm C: Protected Coverage Commitment
Das Expires 25 April 2027 [Page 355]
Internet-Draft Sandbox Credential Egress Finality October 2026
function CommitVerifiedCoverage(
agent_context, effect_class ):
begin protected_atomic_transaction registry =
LockCurrentPathRegistry(
agent_context, effect_class )
if VerifyEffectuationCoverage(
agent_context, effect_class, registry ) != COVERED:
abort return DENIED
generation = AdvanceProtectedCoverageGeneration()
commitment = HashCanonical({
domain: COVERAGE_COMMITMENT, generation: generation, agent_context:
agent_context.id, effect_class: effect_class, path_registry:
registry, verified_sink_bindings: registry.sink_bindings,
disabled_path_states: registry.disabled_paths })
ProtectedCoverageRegistry.commit({
generation: generation, commitment: commitment, status: VERIFIED })
commit protected_atomic_transaction
return commitment
The commit transaction must prevent inconsistent acceptance of a
simultaneous material coverage change.
7.6.120. C-33.60 - Algorithm D: Parent-Sink Verification
function VerifyParentFinalitySink(path, parent_sink):
if not VerifyProtectedSinkIdentity(parent_sink):
return FALSE
if not VerifySinkEffectClass(
parent_sink, path.effect_class ):
return FALSE
Das Expires 25 April 2027 [Page 356]
Internet-Draft Sandbox Credential Egress Finality October 2026
if not VerifyMandatoryControlRelationship(
path, parent_sink ):
return FALSE
if not VerifyNoUncontrolledBypass(
path, parent_sink ):
return FALSE
if not VerifyCurrentSinkEnforcementState(parent_sink):
return FALSE
return TRUE
Verification must establish actual control over the relevant effect.
An asserted parent-child relationship alone is insufficient.
C-33.61 - Algorithm E: Coverage-Aware Candidate Authorization
function AuthorizeCoverageBoundCandidate(candidate_id):
candidate = ProtectedOperationRegistry.get(candidate_id)
if candidate.status != STAGED:
return DENIED
effect_class = ResolveCandidateEffectClass(candidate)
coverage = ProtectedCoverageRegistry.getCurrent(
candidate.agent_context, effect_class )
if coverage.status != VERIFIED:
return DENIED
if not VerifyCurrentCoverageCommitment(coverage):
return DENIED if not VerifyEffectuationCoverage(
candidate.agent_context, effect_class, coverage.path_registry ):
Das Expires 25 April 2027 [Page 357]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED authority =
ProtectedAuthorityRegistry.lookup(candidate)
if not EvaluateRequiredAuthorityPredicates(
candidate, authority ):
return DENIED
evidence = CommitProtectedValidationEvidence({
candidate_id: candidate_id, operation_digest:
candidate.descriptor_digest, authority_generation:
authority.generation, coverage_generation: coverage.generation,
coverage_commitment: coverage.commitment, validation_result: APPROVED
})
capability = CreateScopedNonBearerCapability({
candidate_id: candidate_id, evidence_reference: evidence.id,
operation_digest: candidate.descriptor_digest, coverage_generation:
coverage.generation, coverage_commitment: coverage.commitment,
required_sink: candidate.required_sink })
if not AtomicallyActivateAuthorization(
candidate_id, evidence, capability
):
return DENIED
return AUTHORIZED
The capability must remain bounded to the selected effectuation
scope.
C-33.62 - Algorithm F: Sink-Side Coverage Verification
function ExecuteCoverageBoundOperation(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED actual_operation =
ObtainActualPendingOperation(candidate_id)
Das Expires 25 April 2027 [Page 358]
Internet-Draft Sandbox Credential Egress Finality October 2026
if actual_operation is unavailable:
return DENIED
evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
current_coverage = ProtectedCoverageRegistry.getCurrent(
record.agent_context, record.effect_class )
if not VerifyProtectedEvidence(evidence):
return DENIED
if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED if not VerifyCoverageGenerationBinding(
capability, current_coverage ):
return DENIED
if not VerifyActualOperationCorrespondence(
actual_operation, capability ):
return DENIED
if not VerifyCurrentAuthorityState(capability):
return DENIED if not VerifySinkLocalProtectedState(capability):
return DENIED if not AtomicallyReserveAuthorization(capability):
return DENIED result =
DispatchThroughControlledEffectuationInterface(
actual_operation )
ReconcileProtectedOperationOutcome(candidate_id, result)
Das Expires 25 April 2027 [Page 359]
Internet-Draft Sandbox Credential Egress Finality October 2026
return result
A material change to required coverage prevents effectuation under an
invalid earlier generation.
7.6.121. C-33.63 - Algorithm G: Dynamic Path Activation
function ActivateNewEffectuationPath(new_path):
RestrictGovernedUse(new_path)
classification = ClassifyEffectCapabilities(new_path)
protected_registry = ProtectedPathRegistry.lock()
RegisterPendingPath(
protected_registry, new_path, classification )
InvalidateAffectedCoverageGenerations(
protected_registry, classification )
if not VerifyApplicableSinkOrDisablement(new_path):
return RESTRICTED if not
VerifyEffectuationCoverageForAffectedClasses():
return RESTRICTED commitment = CommitNewProtectedCoverageGeneration()
if commitment is invalid:
return RESTRICTED
return ActivatePathUnderVerifiedCoverage(
new_path, commitment )
The path remains unable to produce governed effects during the
transition unless a separate valid protected authorization applies.
7.6.122. C-33.64 - Algorithm H: Failover Enforcement
function ExecuteProtectedFailover(primary, replacement):
RestrictAffectedGovernedOperations(primary)
outstanding = IdentifyOutstandingOperations(primary)
Das Expires 25 April 2027 [Page 360]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate_paths = DiscoverReplacementEffectPaths(
replacement )
for each path in candidate_paths:
if not VerifyApplicableSinkOrDisablement(path):
return FAILOVER_RESTRICTED if not
VerifyRequiredCoverageAfterFailover():
return FAILOVER_RESTRICTED
coverage = CommitNewProtectedCoverageGeneration()
if coverage is invalid:
return FAILOVER_RESTRICTED
ReconcileOutstandingOperations(outstanding)
return EnableVerifiedReplacementPaths(
replacement,
coverage )
The recovery procedure distinguishes outstanding operations from new
operations and applies the required finality conditions to each.
C-33.65 - Algorithm I: Material Coverage Change Detection
function ProcessEffectuationTopologyEvent(event):
affected = ClassifyAffectedEffectClasses(event)
if affected is empty:
return NO_RELEVANT_CHANGE
for each effect_class in affected:
MarkCoverageRevalidationRequired(effect_class)
RestrictAffectedEffectuationPaths(effect_class)
UpdateProtectedPathRegistry(event, effect_class)
Das Expires 25 April 2027 [Page 361]
Internet-Draft Sandbox Credential Egress Finality October 2026
if VerifyEffectuationCoverageForClass(
effect_class
) != COVERED:
return COVERAGE_FAILURE
CommitVerifiedCoverageGeneration(effect_class)
return COVERAGE_REESTABLISHED
A material change is not accepted solely because its updated
configuration remains syntactically valid.
The actual enforcement relationships must be verified.
7.6.123. PART XV - WORKED TECHNICAL EXAMPLES
7.6.124. C-33.66 - Example A: Network Proxy Bypass
The following is a hypothetical implementation example.
An AI agent executes inside a container.
The intended network route passes through a protected proxy.
The proxy verifies scoped finality authorization before transmission.
However, the container also possesses an enabled direct network
interface.
The path registry identifies:
PATH-1: AGENT → PROXY → NETWORK
PATH-2: AGENT → DIRECT_SOCKET → NETWORK
PATH-1 is governed by a verified Finality Sink.
PATH-2 is enabled but does not possess equivalent enforcement.
The coverage predicate fails.
The system withholds governed network effects until PATH-2 is
disabled or covered by an appropriate Finality Sink.
Das Expires 25 April 2027 [Page 362]
Internet-Draft Sandbox Credential Egress Finality October 2026
Authorization of PATH-1 alone does not establish complete network
effectuation coverage.
C-33.67 - Example B: Protected Parent Credential Broker
An agent uses multiple API connectors.
Each connector ultimately requires a protected credential held
exclusively by a broker.
The agent does not possess the reusable credential.
The broker controls all permitted applications of the credential
within the verified deployment.
Each connector operation must pass through the broker.
The broker verifies the actual credential-bearing request against
protected finality authorization.
The system establishes that the broker is a mandatory parent Finality
Sink for the specified credential-use effect.
A separate connector-specific Finality Sink need not duplicate the
broker's protected credential-use function where the parent provides
the required control.
If an independently usable credential copy exists outside the broker,
the parent-sink coverage condition must be re-evaluated.
C-33.68 - Example C: Privileged Host Maintenance Interface
An AI coding agent is restricted from directly modifying protected
configuration files.
The agent can nevertheless invoke a privileged host maintenance tool.
The tool can modify the same files through a host-side operation.
The path registry identifies the privileged maintenance tool as an
alternative effectuation path.
The system requires the maintenance operation to pass through an
applicable protected fileoperation Finality Sink.
If the maintenance interface can bypass the required authorization,
the corresponding effect class is classified as uncovered.
Das Expires 25 April 2027 [Page 363]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.125. C-33.69 - Example D: API Gateway Failover
An agent ordinarily sends requests through Gateway A.
Gateway A implements protected finality.
A service outage causes the platform to activate Gateway B.
Before Gateway B accepts governed operations, the system verifies its
protected authorization capability, required effectuation-path
relationship, and current coverage generation.
A new coverage commitment is established.
Outstanding operations are reconciled.
If Gateway B lacks the required Finality Sink verification, it
remains restricted for the governed effect class.
C-33.70 - Example E: Database Mutation Through Alternate Service
An agent is authorized to modify enterprise database records through
a protected application service.
The database also exposes a privileged maintenance interface.
The maintenance interface can modify the same records without using
the application service.
The path registry identifies both mutation paths.
The system either restricts the maintenance route or requires an
appropriate protected database-commit Finality Sink.
The application service's upstream approval is not treated as proof
of complete database effectuation coverage.
7.6.126. C-33.71 - Example F: Hardware DMA Bypass
An agent workload has access to a virtualized accelerator.
The intended resource operation is controlled by a protected device-
command gateway.
However, direct device assignment also permits selected DMA
operations outside the gateway.
Das Expires 25 April 2027 [Page 364]
Internet-Draft Sandbox Credential Egress Finality October 2026
The path registry identifies the DMA interface as a relevant
alternate effectuation path.
The system applies appropriate hardware memory-access restrictions or
a protected DMA effectuation controller.
The path is not classified as covered merely because ordinary command
submission passes through the protected gateway.
C-33.72 - Example G: Browser Automation and Direct API Access
An AI agent performs enterprise operations through a controlled
browser interface.
The browser automation controller verifies protected authority before
submitting a resourcechanging form.
The agent also possesses direct API access to the same enterprise
service.
The path registry identifies the browser submission path and the
direct API path.
The coverage verifier requires each enabled relevant route to satisfy
the applicable effectuation conditions.
If the direct API path is uncontrolled, the system withholds the
governed operation until the gap is resolved.
7.6.127. C-33.73 - Example H: Protected Rendering Release
An agent prepares confidential information for display.
The rendering interface includes a protected disclosure Finality
Sink.
The agent can also invoke a screenshot-export tool.
The system identifies screenshot export as a potential alternative
disclosure path.
The export path is restricted or governed according to the selected
disclosure policy.
The rendering Finality Sink does not automatically cover an
independent export interface.
C-33.74 - Example I: Coverage Commitment Invalidation
Das Expires 25 April 2027 [Page 365]
Internet-Draft Sandbox Credential Egress Finality October 2026
A Candidate Act is validated under Coverage Generation 620.
Before effectuation, a new privileged connector becomes enabled.
The connector provides an alternative route to the same governed
effect.
The protected registry advances to Coverage Generation 621 and marks
the affected coverage state for revalidation.
The Finality Sink receives the Candidate Act associated with
generation 620.
The sink detects that the earlier coverage state is no longer
acceptable.
The operation is withheld until the required protected coverage and
authority conditions are re-established.
7.6.128. PART XVI - FAILURE AND ADVERSARIAL SCENARIOS
7.6.129. C-33.75 - Representative Failure Conditions
7.6.130. F1 - Unregistered Enabled Path
An effect-capable path is enabled but not represented in the required
registry.
The coverage condition is not considered satisfied.
7.6.131. F2 - Invalid Path Registry Entry
A registry entry contains invalid or unauthenticated enforcement
information.
The affected path is treated as unverified.
7.6.132. F3 - Unsupported Parent-Sink Assertion
A controller is described as a parent sink but does not actually
control all relevant downstream routes.
The parent-sink predicate fails.
7.6.133. F4 - Direct Socket Bypass
An agent can use a direct socket outside a protected proxy.
Das Expires 25 April 2027 [Page 366]
Internet-Draft Sandbox Credential Egress Finality October 2026
The direct route must be disabled or mediated.
7.6.134. F5 - Privileged Process Bypass
A host-side process can perform the effect without protected
authorization.
The path remains uncovered until restricted or governed.
7.6.135. F6 - Container Host Interface Exposure
A container gains access to an effect-capable host interface.
The registry and coverage state are updated or the interface remains
disabled.
7.6.136. F7 - Existing File Descriptor
A process retains a descriptor permitting a governed file effect
despite new restrictions on file opening.
The implementation verifies the effective write or commit path.
7.6.137. F8 - Alternative Network Adapter
A newly enabled interface bypasses the original network controller.
Coverage is invalidated until the alternate interface is resolved.
7.6.138. F9 - Credential Copy
An agent obtains a reusable credential outside a protected broker.
The broker may no longer dominate the credential-use effect.
7.6.139. F10 - Connector Replacement
A connector is replaced with an implementation using different
downstream routes.
Affected coverage is revalidated.
7.6.140. F11 - Backup Service Activation
A backup resource service can perform the same effect through an
uncontrolled interface.
The system restricts or governs the backup path.
Das Expires 25 April 2027 [Page 367]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.141. F12 - Maintenance Mode
An administrator enables a privileged maintenance mode.
The path registry identifies the change and applies the required
coverage controls.
7.6.142. F13 - Diagnostic Interface
A diagnostic endpoint can produce a governed effect.
The interface must not bypass the applicable protected restrictions.
7.6.143. F14 - Device Pass-Through
A virtual machine obtains direct access to an effect-capable device.
The hardware route requires appropriate coverage.
7.6.144. F15 - DMA Alternate Path
A DMA-capable device can modify a governed memory resource outside
the intended controller.
The corresponding memory effect requires applicable hardware
restrictions or finality control.
7.6.145. F16 - API Protocol Translation
A gateway translates a request into a different downstream operation.
The actual effect and scope must remain within the authorized
coverage.
7.6.146. F17 - Parent-Sink Failure
A mandatory parent sink becomes unavailable.
The governed downstream effect remains restricted unless an
authorized replacement is verified.
7.6.147. F18 - Failover Race
A substitute path becomes active before its coverage commitment is
established.
The protected activation barrier prevents governed effectuation
during the gap.
Das Expires 25 April 2027 [Page 368]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.148. F19 - Coverage Generation Mismatch
A Candidate Act references an outdated coverage generation.
The Finality Sink withholds effectuation when revalidation is
required.
7.6.149. F20 - Registry Rollback
An earlier coverage registry is restored.
Protected continuity or generation checks detect prohibited stale
state.
7.6.150. F21 - Incomplete Path Discovery
The system cannot establish the required bounded path universe.
The affected effect class remains restricted.
7.6.151. F22 - Telemetry-Only Enforcement
A component records an operation but cannot prevent it.
The observation is not treated as preventive Finality Sink coverage.
7.6.152. F23 - Remote Resource Commit Misclassification
A gateway controls request submission but not the remote service's
internal commit.
The system does not enforcement point direct control of the latter
effect.
7.6.153. F24 - Asynchronous Worker Bypass
A queued worker performs an operation outside the original path.
The worker's effectuation path is registered and governed.
7.6.154. F25 - New Effect-Capable Tool
A newly installed tool creates an additional path.
Coverage is updated before governed effects are permitted through it.
Das Expires 25 April 2027 [Page 369]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.155. F26 - Privilege Escalation
An execution context acquires privileges enabling new resource paths.
The relevant coverage state is re-evaluated.
7.6.156. F27 - Kernel Enforcement Program Removal
A required kernel enforcement component is disabled.
Affected coverage becomes invalid under the applicable threat model.
7.6.157. F28 - Unverified Hardware Controller
A device is assumed to enforce restrictions without establishing its
actual command-control properties.
The corresponding path remains unverified.
7.6.158. F29 - Concurrent Coverage Update
A Candidate Act is authorized while path configuration changes.
Protected generation and synchronization mechanisms prevent
acceptance under an invalid coverage state.
7.6.159. F30 - Finality Sink Substitution
An operation is redirected to an unverified sink.
The required sink-identity and coverage checks fail.
7.6.160. F31 - Non-Network Disclosure Path
An agent exposes protected information through a rendering or file-
export interface.
The relevant non-network effectuation path is evaluated.
7.6.161. F32 - Protected Evidence Missing Coverage Binding
An authorization lacks a coverage reference required by policy.
The Finality Sink withholds the effect.
Das Expires 25 April 2027 [Page 370]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.162. F33 - Unresolved Effectuation Path
A potentially effect-capable interface cannot be classified.
The affected operation class is restricted until the required
coverage is established.
7.6.163. F34 - Stale Path Disablement
A previously disabled interface becomes enabled without an approved
coverage transition.
The protected controller detects or prevents the unauthorized
activation.
7.6.164. F35 - External Completion Uncertain
An authorized operation is dispatched but its outcome is unknown.
The system retains the required recovery and reconciliation state.
7.6.165. F36 - Coverage Registry Compromise
An attacker modifies ordinary registry storage.
The protected integrity mechanism rejects unauthorized changes
according to the selected security model.
| PART XVII - IMPLEMENTATION VARIATIONS C-33.76 - Process-Isolated Implementation A process sandbox maintains a registry of permitted process, file, network, IPC, and privileged resource paths. Protected host-side enforcement verifies the required path coverage. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-33.77 - Container Implementation A containerized agent operates with namespace, file-system, network, and host-resource restrictions. The path registry includes relevant host-exposed interfaces and connector paths. |
| C-33.78 - Virtual-Machine Implementation A guest executes the agent. The hypervisor or controlled host services restrict relevant device and resource paths. Device pass-through and virtual backend routes are included where applicable. |
| C-33.79 - Kernel-Mediated Implementation Supported kernel security controls restrict selected system-call, resource-access, and execution paths. The protected coverage verifier distinguishes actual enforcement from telemetry-only observation. |
7.6.166. C-33.80 - Cloud Gateway Implementation
A cloud-hosted agent accesses services through protected API gateways
and connectors.
The registry includes direct APIs, privileged service identities,
failover routes, and relevant downstream effectuation controls.
7.6.167. C-33.81 - Credential-Broker Implementation
A protected credential broker provides a mandatory parent Finality
Sink for selected credential-use effects.
Das Expires 25 April 2027 [Page 371]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system verifies that independently usable alternative credentials
are unavailable or restricted.
7.6.168. C-33.82 - Hardware Network Implementation
A SmartNIC or DPU controls selected network transmissions.
The path registry includes applicable host networking, device-
assignment, and alternate egress paths.
7.6.169. C-33.83 - Storage and Database Implementation
A protected resource controller verifies persistent modification
authorization.
The registry includes relevant direct writes, privileged maintenance
operations, and other enabled commit paths.
7.6.170. C-33.84 - Peripheral-Control Implementation
A protected device controller governs selected peripheral or actuator
commands.
Alternative command interfaces must be disabled or governed.
7.6.171. C-33.85 - Rendering Finality Implementation
A protected display or media controller governs a selected
information-release effect.
Relevant screenshot, export, or remote-rendering interfaces may also
require coverage.
7.6.172. C-33.86 - Distributed Parent-Sink Implementation
A parent sink controls downstream operations across multiple
services.
The system verifies that the parent maintains the required mandatory
effectuation relationship under current routing and delegation
conditions.
| |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-33.87 - Hardware-Cryptographic Coverage Commitment A TEE, HSM, or other suitable protected component maintains authenticated coverage generations and commitments. Candidate Act authorizations are bound to the applicable protected coverage state. |
| C-33.88 - Integrated Single-Node Implementation One protected resource controller may maintain the path registry, coverage predicate, protected validation evidence, scoped authorization, and Finality Sink. The claimed logical functions remain implemented without requiring multiple physical devices. |
| PART XVIII - REPRESENTATIVE DATA STRUCTURES C-33.89 - EffectuationPathRecord Fields may include: 1. PathID. 2. OriginExecutionContext. 3. EffectClass. 4. InterfaceSequence. 5. TerminalEffectInterface. 6. EnabledState. 7. RequiredSinkID. 8. ParentSinkID. 9. CoverageGeneration. 10. VerificationStatus. |
Das Expires 25 April 2027 [Page 372]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.173. C-33.90 - EffectClassRecord
Fields may include:
1. EffectClassID. 2. GovernedEffectDefinition. 3.
RelevantResourceClasses. 4. ApplicableExecutionContexts. 5.
RequiredEffectuationBoundary. 6. RequiredCoveragePolicy. 7.
CurrentPolicyGeneration.
7.6.174. C-33.91 - FinalitySinkBindingRecord
Fields may include:
1. SinkID. 2. EffectClass. 3. ControlledInterface. 4.
AuthorizedOperationScope. 5. ProtectedEnforcementState. 6.
ParentSinkReference. 7. VerificationGeneration. 8.
AvailabilityStatus.
7.6.175. C-33.92 - ParentSinkCoverageRecord
Fields may include:
1. ParentSinkID. 2. ChildPathReferences. 3.
SourceExecutionContexts. 4. GovernedEffectClasses. 5.
MandatoryControlEvidence. 6. BypassVerificationResult. 7.
CoverageGeneration. 8. CurrentValidityStatus.
7.6.176. C-33.93 - PathDisablementRecord
Fields may include:
1. 2. 3. 4.
DisablementRecordID. PathID. EffectClass. EnforcementMechanism.
5. EnforcementPointID. 6. AppliedPolicyGeneration. 7.
CurrentDisabledState. 8. VerificationReference.
7.6.177. C-33.94 - ProtectedCoverageStateRecord
Fields may include:
1. CoverageStateID. 2. CoverageGeneration. 3. AgentContextID. 4.
EffectClass. 5. PathRegistryDigest. 6. VerifiedSinkSet. 7.
DisabledPathSet. 8. CoverageCommitment. 9. CoverageStatus. 10.
VerificationPolicyVersion.
Das Expires 25 April 2027 [Page 373]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.178. C-33.95 - CoverageBoundCandidateActRecord
Fields may include:
1. CandidateActID. 2. AgentContextID. 3. OperationClass. 4.
EffectClass. 5. OperationDescriptorDigest. 6. CoverageGeneration.
7. CoverageCommitment. 8. AuthorityGeneration. 9. RequiredSinkID.
10. CandidateStatus.
7.6.179. C-33.96 - CoverageValidationEvidenceRecord
Fields may include:
1. EvidenceID. 2. CandidateActID. 3. OperationDescriptorDigest. 4.
AuthorityGeneration. 5. CoverageGeneration.
6. 7. 8. 9.
CoverageCommitment. ValidationOutcome.
ProtectedCommitmentReference. RequiredSinkID.
7.6.180. C-33.97 - CoverageBoundCapabilityRecord
Fields may include:
1. CapabilityID. 2. CandidateActID. 3. EvidenceReference. 4.
OperationDescriptorDigest. 5. CoverageGeneration. 6.
CoverageCommitment. 7. AuthorizedSinkID. 8. PermittedEffectScope.
9. UsagePolicy. 10. CapabilityStatus.
7.6.181. C-33.98 - PathTopologyEventRecord
Fields may include:
1. EventID. 2. EventClass. 3. AffectedPathIDs. 4.
AffectedEffectClasses. 5. PreviousCoverageGeneration. 6.
ProposedCoverageGeneration. 7. RequiredRestrictionState. 8.
VerificationResult. 9. ActivationStatus.
7.6.182. C-33.99 - CoverageRecoveryRecord
Fields may include:
1. RecoveryID. 2. AffectedEffectClass. 3. FailedEnforcementPoint.
4. OutstandingOperationReferences. 5. ReplacementPathReferences. 6.
RequiredSinkVerification.
Das Expires 25 April 2027 [Page 374]
Internet-Draft Sandbox Credential Egress Finality October 2026
7. UpdatedCoverageGeneration. 8. ReconciliationStatus. 9.
RecoveryCompletionStatus.
These records may be implemented using protected databases,
authenticated registries, secure firmware state, TEE-protected
storage, hardware registers, or cooperating distributed services.
7.6.183. PART XIX - implementer VERIFICATION TESTS
7.6.184. C-33.100 - Representative Engineering Test Matrix
The following are proposed verification procedures and not
representations of completed experiments.
7.6.185. Test Condition
T1 All relevant paths governed T2 One enabled path uncovered T3 Path
technically disabled T4 Invalid registry entry T5 Verified parent
sink dominates path T6 Parent sink lacks mandatory control T7 Direct
socket bypass T8 Privileged host command bypass T9 Container host
mount exposes resource T10 Existing descriptor retains write
authority T11 Alternate network adapter enabled T12 Credential
exposed outside broker T13 Connector replaced T14 Backup service
activated T15 Failover begins before coverage approval T16 Coverage
generation changed T17 Protected coverage commitment modified T18
Candidate capability lacks required coverage
binding T19 Wrong Finality Sink T20 Finality Sink unavailable T21
Telemetry-only observation T22 Uncontrolled database maintenance path
T23 File-system alternate write path T24 DMA bypass T25 Rendering
export alternative
7.6.186. Expected technical result
Coverage accepted Coverage rejected Disablement verified Coverage
rejected Parent coverage accepted Parent coverage rejected Detected
or prevented Detected or prevented Relevant path evaluated Write-path
coverage checked Coverage invalidated or revalidated Parent-sink
coverage re-evaluated New effect paths verified Required coverage
established Governed effects withheld Stale authorization rejected
Integrity check fails Effect denied Authorization rejected No
uncontrolled fallback Not classified as preventive coverage Coverage
failure Covered or restricted Hardware path evaluated Disclosure path
evaluated
T26 Browser versus direct API route T27 Asynchronous worker alternate
path T28 New privileged tool installed T29 Concurrent topology update
T30 Registry rollback T31 Invalid parent-sink identity T32 Unknown
Das Expires 25 April 2027 [Page 375]
Internet-Draft Sandbox Credential Egress Finality October 2026
effect-capable interface T33 Protected evidence references outdated
coverage Revalidation required T34 Failover with outstanding
operations T35 Device pass-through enabled T36 Sink verification
succeeds with current coverage Authorized effect permitted T37 Proxy
controls submission but not remote
commit T38 Protected registry unavailable T39 Revocation removes sink
authority T40 Recovered deployment has changed topology
Both routes verified Worker path governed Coverage revalidation
required Invalid coverage generation not accepted Protected
continuity enforced Parent coverage rejected Affected effects
restricted
Recovery policy applied Required device path verified
Boundaries correctly distinguished Required effect withheld Affected
coverage invalidated Coverage rebuilt and verified
The implementation should specify concrete configuration states,
injected bypasses, protected state transitions, and observable
effectuation outcomes.
7.6.187. PART XX - Enforcement-Point Mapping and Technical
Correspondence
7.6.188. C-33.101 - Independent enforcement point(s) corresponding to
source item(s) 33
The embodiment provides corresponding implementation mechanisms for:
enforcement point(s) corresponding to source item(s) 33(a): AI-agent
execution environments generating proposed consequential
operations.
enforcement point(s) corresponding to source item(s) 33(b): Multiple
software, kernel, credential, network, API, browser, storage, memory,
and peripheral effectuation paths.
enforcement point(s) corresponding to source item(s) 33(c): Machine-
verifiable Effectuation-Path Registry.
enforcement point(s) corresponding to source item(s) 33(d)(i):
Verification of applicable Finality Sink coverage.
Das Expires 25 April 2027 [Page 376]
Internet-Draft Sandbox Credential Egress Finality October 2026
enforcement point(s) corresponding to source item(s) 33(d)(ii):
Cryptographic or technical disabling mechanisms.
enforcement point(s) corresponding to source item(s) 33(d)(iii):
Technical prevention of designated external effects.
enforcement point(s) corresponding to source item(s) 33(d)(iv):
Verified parent Finality Sink control.
enforcement point(s) corresponding to source item(s) 33(e): Protected
Candidate Act validation, protected-state operations, evidence
commitment, and coverage-conditioned scoped authorization.
enforcement point(s) corresponding to source item(s) 33(f): Required
coverage of enabled relevant effectuation paths.
enforcement point(s) corresponding to source item(s) 33(g): Finality
Sink verification before the governed consequential effect.
enforcement point(s) corresponding to source item(s) 33(h): Denial or
withholding when required path coverage fails.
C-33.102 - Dependent enforcement point(s) corresponding to source
item(s) 34: Host, Container, and Kernel Path Registry
Implementation support includes:
1. Process-execution paths. 2. Container and host interfaces. 3.
Privileged host commands. 4. Kernel security controls. 5. File-
system and network paths. 6. Browser automation. 7. Connector
paths. 8. Existing descriptors and asynchronous interfaces. 9.
Required verification of corresponding protected Finality Sinks.
C-33.103 - Dependent enforcement point(s) corresponding to source
item(s) 35: Proxy and API Gateway Coverage
Implementation support includes:
1. Protected network proxies. 2. API gateways. 3. Connector
gateways. 4. Actual transmission control. 5. Parent-sink
relationships. 6. Protected capability verification. 7. Distinction
between upstream approval and sink-side effectuation. 8. Explicit
separation of request-submission and remote commit effects.
C-33.104 - Dependent enforcement point(s) corresponding to source
item(s) 36: Alternative Path and Failover Protection
Das Expires 25 April 2027 [Page 377]
Internet-Draft Sandbox Credential Egress Finality October 2026
Implementation support includes:
1. Alternate path detection. 2. Fallback activation barriers. 3.
Maintenance-mode path discovery. 4. Diagnostic-interface controls.
5. Backup routing. 6. Substitute execution interfaces. 7.
Protected coverage-generation transitions.
8. Outstanding-operation reconciliation. 9. Restrictive handling of
unverified replacement paths.
C-33.105 - Dependent enforcement point(s) corresponding to source
item(s) 37: Non-Network Effectuation Coverage
Implementation support includes:
1. File mutations. 2. Database commits. 3. Persistent memory
writes. 4. Peripheral and actuator commands. 5. Display and
rendering releases. 6. DMA operations. 7. Storage-controller
effects. 8. Non-network Finality Sink verification.
C-33.106 - Dependent enforcement point(s) corresponding to source
item(s) 38: Protected Coverage-State Commitment
Implementation support includes:
1. Protected coverage generations. 2. Canonical registry
representation. 3. Machine-verifiable coverage commitments. 4.
Protected validation-evidence binding. 5. Scoped capability coverage
binding. 6. Detection of material topology changes. 7. Invalidation
of stale coverage. 8. Revalidation before effectuation.
7.6.189. PART XXI - implementer IMPLEMENTATION REQUIREMENTS
7.6.190. C-33.107 - Implementation Checklist
For a selected deployment, a person having ordinary skill in the art
identifies:
1. The relevant AI-agent execution environment. 2. The trusted
computing base. 3. The attacker capabilities. 4. The defined
governed effect classes. 5. The actual effectuation boundaries. 6.
The accessible execution contexts. 7. The available tools and
connectors. 8. The relevant native resource interfaces. 9. The
process and privileged host paths.
10. The network and API routes. 11. The credential-use interfaces.
12. The file and storage mutation paths. 13. The applicable device
and DMA paths. 14. The relevant asynchronous operation paths. 15.
Das Expires 25 April 2027 [Page 378]
Internet-Draft Sandbox Credential Egress Finality October 2026
The machine-readable path representation. 16. The path enablement-
state model. 17. The effectuation-path discovery method. 18. The
closed-world or default-deny enforcement assumptions. 19. The
Finality Sink identity and control mechanism. 20. The parent-sink
relationship-verification procedure. 21. The technical disablement
verification method. 22. The coverage predicate. 23. The protected
path registry. 24. The coverage-generation mechanism. 25. The
coverage-commitment format. 26. The Candidate Act descriptor schema.
27. The protected authority-validation procedure. 28. The protected
evidence-commitment mechanism. 29. The scoped non-bearer capability
representation. 30. The Finality Sink coverage-verification
procedure. 31. The topology-change detection mechanism. 32. The
failover activation barrier. 33. The stale-authorization
invalidation procedure. 34. The treatment of unknown or newly
enabled paths. 35. The protected recovery and reconciliation
mechanism. 36. The engineering tests demonstrating the required
coverage properties.
The selected implementation must distinguish a registry of known
paths from enforceable completeness of the relevant path universe.
A system that merely documents its intended security architecture
cannot establish nonbypassable effectuation coverage unless the
applicable alternate routes are technically controlled or excluded.
7.6.191. C-33.108 - Technical Effect
this implementation profile provides a protected mechanism for
evaluating whether externally consequential operations generated
directly or indirectly by an AI agent can bypass the intended
Finality Sink.
The system establishes machine-readable representations of effect-
capable paths and their enforcement states.
It verifies whether each enabled relevant path is governed by an
applicable Finality Sink, a verified parent Finality Sink, or an
effective disabling restriction.
The protected coverage state is associated with a machine-verifiable
generation and commitment.
A PED conditions operation-specific protected authorization upon
satisfaction of the applicable coverage predicate.
A Finality Sink verifies the actual pending operation together with
the required coverage and authority state.
Das Expires 25 April 2027 [Page 379]
Internet-Draft Sandbox Credential Egress Finality October 2026
Material changes to path configuration cause revalidation,
restriction, or invalidation of affected authorization.
The architecture supports direct and indirect effectuation paths
across processes, containers, kernels, gateways, databases, storage
systems, hardware devices, and distributed services.
7.6.192. C-33.109 - Technical Summary
this implementation profile discloses a computer-implemented
effectuation-path completeness architecture comprising an AI-agent
execution environment, an Effectuation-Path Registry, a protected
path-coverage verifier, a Protected Enforcement Domain, Candidate Act
staging, protected validation evidence, scoped non-bearer finality
authorization, and one or more Finality Sinks.
The path registry identifies enabled interfaces through which a
governed consequential operation may become externally effective.
The protected controller evaluates whether those interfaces are
governed by appropriate Finality Sinks, verified parent Finality
Sinks, or effective technical restrictions.
The system distinguishes an intended or preferred operation route
from the full set of relevant enabled effect-capable paths.
The path-coverage state may be represented by an authenticated
commitment associated with a protected coverage generation.
Protected authorization for a Candidate Act is conditioned upon
successful operation-specific authority and coverage validation.
The applicable Finality Sink verifies the actual pending operation
and required protected coverage state before permitting the
designated effect.
Changes to network routes, connectors, credentials, privileged
processes, resource interfaces, devices, maintenance modes, or
failover configurations may trigger protected coverage revalidation.
The system withholds governed effectuation where an enabled relevant
path remains uncovered, an applicable registry entry is invalid, a
mandatory Finality Sink cannot be verified, or a material coverage
change invalidates the earlier authorization.
The architecture may be implemented using protected software,
firmware, hardware, cryptographically isolated components, or
cooperating distributed enforcement services.
Das Expires 25 April 2027 [Page 380]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.6.192.1. PROTECTED ARTIFICIAL-INTELLIGENCE-AGENT PROCESS-LINEAGE
TAINT PROPAGATION WITH EXECUTION-GENERATION IDENTITY,
7.6.192.2. TRANSITIVE AUTHORITY RESTRICTION, REVOCATION-BARRIER
ENFORCEMENT, AND FINALITY SINK VERIFICATION
7.7. Implementation Profile C-42
Source location: original disclosure pages 692-757. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.7.1. C-42.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, process execution isolation, information-flow control,
operating-system security, provenance tracking, protected
authorization, process-lineage attribution, runtime taint
propagation, authority revocation, asynchronous operation control,
and execution-finality enforcement.
More particularly, the embodiment discloses a computer-implemented
system configured to observe selected security-relevant activities of
an AI agent and its associated processes, propagate machine-
verifiable taint or restriction state through defined execution and
information-flow relationships, and prevent affected execution
contexts from continuing to exercise authority that has become
invalid under protected enforcement policy.
The system may be implemented in conjunction with:
(a) ordinary operating-system processes; (b) child processes and
process trees; (c) process-isolated AI agents; (d) containers; (e)
virtual machines; (f) tool servers; (g) privileged connectors; (h)
language-model inference runtimes; (i) retrieval services; (j)
browser and computer-use agents; (k) cloud-hosted execution workers;
(l) kernel security facilities;
(m) protected credential brokers;
(n) network and file effectuation controllers;
(o) protected enforcement domains;
(p) cryptographically isolated enforcement domains; and
(q) controlled Finality Sinks.
Das Expires 25 April 2027 [Page 381]
Internet-Draft Sandbox Credential Egress Finality October 2026
The disclosed mechanisms may execute entirely on one computer or
across multiple computing environments.
No particular operating system, processor, kernel security interface,
or container runtime is required unless expressly specified in a
selected implementation.
7.7.2. PART I - TECHNICAL PROBLEM AND INVENTIVE MECHANISM
7.7.3. C-42.2 - Technical Problem
Artificial-intelligence agents frequently invoke operating-system
processes, command interpreters, scripts, tool workers, connectors,
and delegated execution services.
Such processes may access externally supplied information or
untrusted computational material.
Examples include:
1. Retrieving webpage content. 2. Reading an externally supplied
document. 3. Parsing an email attachment. 4. Executing generated
code. 5. Loading a third-party package. 6. Consuming an untrusted
tool result. 7. Receiving IPC messages. 8. Reading shared files. 9.
Receiving an intermediate result from another agent. 10. Executing a
delegated tool operation.
A process that has encountered untrusted or policy-restricted
information may remain technically capable of using previously
granted credentials, network routes, file permissions, or privileged
connectors.
A conventional process permission may continue unchanged after the
security-relevant exposure.
An attacker or compromised agent may attempt to evade restrictions
by:
(a) creating a child process; (b) launching another interpreter; (c)
changing executable names; (d) delegating execution to a worker; (e)
sending data through interprocess communication; (f) writing data to
a file later read by another process; (g) reusing a previously opened
connection;
(h) restarting a process;
(i) reusing a process identifier;
Das Expires 25 April 2027 [Page 382]
Internet-Draft Sandbox Credential Egress Finality October 2026
(j) moving execution to another container;
(k) retaining an earlier authorization token;
(l) queuing an asynchronous operation; or
(m) using a privileged service with an independent native identity.
Merely assigning a taint label to one process is therefore
insufficient when the tainted process can still produce consequential
effects through related execution contexts.
this implementation profile addresses these problems through machine-
verifiable process lineage, protected taint-state transitions,
transitive propagation, generation-based authority restrictions, and
protected effectuation control.
7.7.4. C-42.3 - Central Technical Principle
The system distinguishes three operations:
Observation: Detecting security-relevant events and associating them
with the correct
execution context.
Taint and lineage computation: Updating machine-verifiable influence
or exposure state
across defined process, communication, and data relationships.
Protected authority enforcement: Determining whether the updated
state requires
reduction, revocation, renewed validation, or denial of specified
consequential operations.
These functions are related but not identical.
A process may be marked tainted without being malicious.
A tainted process may remain permitted to perform some operations.
Das Expires 25 April 2027 [Page 383]
Internet-Draft Sandbox Credential Egress Finality October 2026
However, where a protected policy makes a class of external effects
unavailable following a specified taint transition, neither the
affected process nor a derived execution context can regain that
authority merely by copying instructions, creating a descendant,
changing its execution identity, or using a tool with broader native
permissions.
7.7.5. C-42.4 - Relationship to Protected Execution Finality
In a representative implementation, the process-lineage controller
determines the relevant taint and authority state.
A Protected Enforcement Domain (PED) evaluates the resulting
operation-specific authorization.
A Finality Sink verifies the actual pending consequential operation
against the current protected authorization state.
The arrangement may comprise:
SECURITY-RELEVANT INPUT
→ TRUSTED OBSERVATION
→ EXECUTION-CONTEXT ATTRIBUTION
→ PROTECTED LINEAGE UPDATE
→ TAINT PROPAGATION
→ AUTHORITY-STATE TRANSITION
→ CANDIDATE ACT STAGING
→ PROTECTED VALIDATION
→ SCOPED FINALITY ENABLEMENT
→ CURRENT SINK-SIDE VERIFICATION
→ PERMITTED OR DENIED EFFECT.
A more limited implementation may enforce taint-triggered authority
restriction at a protected effectuation interface without using the
complete receipt-and-capability arrangement, where the applicable
enforcement point does not expressly require that sequence.
Das Expires 25 April 2027 [Page 384]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.6. PART II - PRINCIPAL SYSTEM COMPONENTS
7.7.7. C-42.5 - Agent Execution Environment
An Agent Execution Environment comprises one or more processes or
computational contexts executing an artificial-intelligence agent,
model client, inference runtime, planning component, tool dispatcher,
or generated program.
The environment may have authority to perform internal computation
and may possess access to selected operating-system resources.
Governed consequential operations remain subject to the applicable
protected restrictions.
7.7.8. C-42.6 - Protected Execution Identity Controller
A Protected Execution Identity Controller assigns or verifies a
machine-identifiable identity for each observed execution context.
The identity distinguishes one process instance from another, even
where operating-system identifiers are recycled.
A representative identity comprises:
HostIdentity
BootGeneration
IsolationDomainID
ProcessInstanceID
ProcessCreationSequence
ExecutionGeneration
AgentContextID
TaskID
The implementation may use operating-system process handles, kernel-
assigned generation values, monotonic creation references, protected
process registries, or suitable combinations thereof.
Das Expires 25 April 2027 [Page 385]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.9. C-42.7 - Runtime Observation Controller
A Runtime Observation Controller obtains events relevant to taint
propagation or protected authority restriction.
The controller may observe:
(a) process creation; (b) executable replacement; (c) code loading;
(d) tool invocation; (e) file reads; (f) IPC receipt; (g) network
input; (h) shared-memory access; (i) delegated worker creation; (j)
agent-generated code execution; (k) credential-use requests; (l)
attempted network transmissions; or (m) other policy-defined events.
The controller is configured to supply trustworthy event attribution
for the security properties claimed by the implementation.
7.7.10. C-42.8 - Process-Lineage Registry
A Process-Lineage Registry stores machine-verifiable relationships
among execution contexts and relevant information-flow events.
The registry may be represented as a directed graph, authenticated
event journal, protected database, or equivalent data structure.
The registry is maintained outside the direct modification authority
of the monitored agent.
7.7.11. C-42.9 - Taint-State Controller
A Taint-State Controller assigns, combines, propagates, and changes
taint or restriction classifications according to a defined security
policy.
The controller may maintain separate dimensions for:
1. Untrusted data exposure. 2. Agent-generated instruction
execution. 3. Restricted information access. 4. Unverified tool
output. 5. Delegated execution. 6. Unknown provenance. 7. Policy
violation. 8. Required observation failure.
The state representation is defined by the implementation.
7.7.12. C-42.10 - Protected Authority-State Controller
A Protected Authority-State Controller maintains the permissions or
authority generations applicable to each monitored execution context.
The controller evaluates whether a taint-state transition requires:
Das Expires 25 April 2027 [Page 386]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) removal of an automatic permission; (b) reduction of resource
scope; (c) prohibition of a privileged operation; (d) mandatory
renewed authorization; (e) invalidation of an existing bounded grant;
(f) suspension of a connector; (g) advance of an authority or
revocation generation; or (h) termination of a permitted effectuation
path.
7.7.13. C-42.11 - Effectuation Controller
An Effectuation Controller prevents affected execution contexts from
performing selected consequential operations under invalid authority.
It may comprise:
| x | Tool dispatcher. |
| - | --------------------------- |
| x | Network egress controller. |
| x | Credential broker. |
| x | File-operation controller. |
| x | API gateway. |
| x | Native resource controller. |
| x | Protected kernel hook. |
| x | Hardware device controller. |
| x | Finality Sink. |
The controller must be located at an enforcement-capable technical
boundary.
An event logger that merely observes an operation after its
consequence cannot serve as the preventive enforcement mechanism for
that effect.
7.7.14. C-42.12 - Outstanding Operation Controller
An Outstanding Operation Controller tracks consequential operations
that have been staged, authorized, reserved, dispatched, queued,
partially executed, or completed.
The controller uses current protected authority state to determine
the permitted disposition of such operations following taint-
triggered revocation.
7.7.15. C-42.13 - Recovery Controller
A Recovery Controller maintains the required continuity of process-
lineage, taint, and authority restrictions following:
Das Expires 25 April 2027 [Page 387]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Process restart. 2. Child-process termination. 3. Container
replacement. 4. Execution migration. 5. Kernel observation restart.
6. Protected registry recovery. 7. Hardware or service failover. 8.
Snapshot restoration. 9. Reconnection of a delegated worker.
The recovery procedure must not treat loss of volatile taint records
as independent restoration of unrestricted authority.
7.7.16. PART III - PROCESS INSTANCE IDENTIFICATION
7.7.17. C-42.14 - Process Identity Versus Process Identifier
An operating-system process identifier may be reused after a process
exits.
A protected process instance is therefore identified using additional
information.
For example:
ProcessInstanceKey = ( HostBootID,
PID, KernelStartGeneration, IsolationDomainID )
A newly created process using a recycled PID receives a different
protected ProcessInstanceKey.
This prevents accidental association of current authority with a
terminated process merely because the numeric PID matches.
7.7.18. C-42.15 - Execution Generation
An Execution Generation represents a particular executable or
execution-state instance.
An implementation may advance the execution generation when:
(a) a process performs an executable replacement; (b) a new agent-
generated program is loaded; (c) a tool runtime is reinitialized; (d)
an execution context is restored from a snapshot; (e) a delegated
worker is rebound; or (f) another policy-defined material execution
transition occurs.
The protected controller determines whether previously accumulated
taint remains applicable.
Executable replacement does not automatically erase the security
consequences of earlier information exposure.
Das Expires 25 April 2027 [Page 388]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.19. C-42.16 - Agent and Task Association
A process may belong to an agent-associated task.
The registry may contain:
AgentContextID = AGENT-42
TaskID = TASK-204
ProcessInstanceID = PROC-701
ExecutionGeneration = 19
AuthorityGeneration = 105
ParentProcessInstance = PROC-700
The relationship is established by a trusted process-creation or
delegation interface.
A child process cannot independently select an unrelated privileged
task identity merely by supplying a textual identifier.
7.7.20. PART IV - FORMAL LINEAGE MODEL
7.7.21. C-42.17 - Process-Lineage Graph
A representative lineage graph is:
G = (V, E)
where:
V represents process instances, delegated workers, relevant tool
executions, and optionally information objects.
E represents machine-verifiable relationships that may carry taint or
authority restrictions.
Possible edge classes include:
PARENT_OF
EXEC_REPLACES
INVOKES_TOOL
Das Expires 25 April 2027 [Page 389]
Internet-Draft Sandbox Credential Egress Finality October 2026
DELEGATES_TO
SENDS_IPC_TO
SHARES_DATA_WITH
WRITES_OBJECT
READS_OBJECT
PASSES_DESCRIPTOR_TO
PRODUCES_OUTPUT_FOR
CONTINUES_AS
Each edge has defined security semantics.
7.7.22. C-42.18 - Lineage Edge Record
A representative edge comprises:
LineageEdgeID = EDGE-4201
SourceContext = PROC-701
TargetContext = PROC-702
RelationshipType = PARENT_OF
EventSequence = 810
ObservedBy = KERNEL-MONITOR-01
SourceGeneration = 19
TargetGeneration = 1
AuthenticationReference = EVENT-MAC-810
The values are illustrative.
7.7.23. C-42.19 - Source-to-Descendant Propagation
Where the taint policy specifies inheritance through process
creation, a child process receives the applicable parent taint state.
For example:
Das Expires 25 April 2027 [Page 390]
Internet-Draft Sandbox Credential Egress Finality October 2026
ParentTaint = {UNTRUSTED_WEB}
ChildInitialTaint = Combine( ParentTaint, ChildCreationContext )
The combination function may preserve all relevant parent
restrictions or apply a narrower defined policy where independent
protected authority permits it.
Ordinary process creation does not automatically declassify inherited
taint.
7.7.24. C-42.20 - Transitive Propagation
If process A transfers information to process B and B transfers
derived information to process C, the system may propagate applicable
restrictions to C.
For example:
A → B → C
Where both edges carry the relevant information-flow class:
T(C) = Combine(T(C), T(B))
and:
T(B) = Combine(T(B), T(A))
A downstream execution context cannot evade inherited restrictions
merely because there is no direct A-to-C relationship.
7.7.25. C-42.21 - Propagation Policy
A representative policy may specify:
7.7.26. Relationship
Process fork or spawn Inherit required parent restriction labels
Executable replacement IPC receipt File read Shared-memory read Tool
invocation Remote delegation
Das Expires 25 April 2027 [Page 391]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.27. Representative propagation rule
Preserve required process-instance lineage restrictions Combine
applicable sender and receiver taint Combine applicable file-object
and process taint Propagate applicable object or region taint Bind
delegated worker to originating task and relevant restrictions
Propagate through an authenticated handoff envelope
Preserve relevant downstream records and outstanding-effect Process
termination
restrictions
Not every implementation needs to propagate every label through every
relationship.
The required rule is selected by the claimed security policy.
7.7.28. PART V - TAINT STATE REPRESENTATION
7.7.29. C-42.22 - Taint-State Record
A representative protected record comprises:
TaintRecordID = TAINT-4201
ProcessInstanceID = PROC-701
ExecutionGeneration = 19
TaintLabels = {UNTRUSTED_WEB}
TaintGeneration = 15
AuthorityGeneration = 105
ObservationCoverage = VERIFIED
LastEventSequence = 810
RestrictionProfile = REVALIDATION_REQUIRED
The record may be stored in a protected kernel service, isolated
enforcement process, authenticated database, TEE, or equivalent
protected component.
Das Expires 25 April 2027 [Page 392]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.30. C-42.23 - Taint Label Classes
Representative classes include:
UNTRUSTED_WEB_CONTENT
UNTRUSTED_EMAIL_CONTENT
RETRIEVED_DOCUMENT
UNVERIFIED_TOOL_RESULT
AGENT_GENERATED_CODE
RESTRICTED_ENTERPRISE_DATA
UNVERIFIED_PACKAGE_CONTENT
UNTRUSTED_IPC_MESSAGE
UNVERIFIED_REMOTE_DELEGATION
OBSERVATION_INCOMPLETE
POLICY_VIOLATION
These classes are illustrative.
A taint label represents an observed condition or defined
classification rather than a universal enforcement point of
maliciousness.
7.7.31. C-42.24 - Monotonic Restriction Variation
In one implementation, taint restrictions accumulate monotonically
during a specified execution generation unless an authorized
protected declassification or revalidation event occurs.
If T1 and T2 are taint sets: Combine(T1,T2) = T1 ∪ T2 This provides a
conservative implementation.
For example:
T1 = {UNTRUSTED_WEB}
T2 = {AGENT_GENERATED_CODE}
CombinedTaint = { UNTRUSTED_WEB, AGENT_GENERATED_CODE }
Das Expires 25 April 2027 [Page 393]
Internet-Draft Sandbox Credential Egress Finality October 2026
The policy can map this combined state to a restricted effectuation
profile.
7.7.32. C-42.25 - Trust and Restriction Separation
The system may maintain:
1. Information-source classification. 2. Taint state. 3. Operation
authority. 4. Resource permission. 5. Protected revocation state.
These are separate variables.
For example, a process may consume untrusted webpage content and
remain authorized to summarize that content locally.
The same process may be prohibited from automatically transmitting
enterprise secrets without renewed protected authorization.
The taint condition affects the authority calculation; it does not
automatically equate all computation with unauthorized activity.
7.7.33. PART VI - TRUSTED TAINT ACQUISITION
7.7.34. C-42.26 - Collection-Time Observation
Where the protection requires reliable acquisition of taint state,
the observation mechanism obtains the event at a boundary through
which the relevant data or instruction enters the execution context.
For example, a controlled retrieval interface records:
1. Source classification. 2. Data object identity. 3. Receiving
process instance. 4. Task context. 5. Event generation. 6.
Required object integrity reference.
The taint update is committed in the protected registry.
7.7.35. C-42.27 - Taint Before Use
In one implementation, the observation and taint transition are
ordered so that a process cannot consume a relevant untrusted input
and immediately perform a prohibited effect under an earlier
unrestricted authority state.
A representative order is:
INPUT ARRIVAL
Das Expires 25 April 2027 [Page 394]
Internet-Draft Sandbox Credential Egress Finality October 2026
→ PROTECTED EVENT ATTRIBUTION
→ TAINT-STATE UPDATE
→ AUTHORITY RESTRICTION
→ DATA RELEASE TO PROCESS.
This ordering may be implemented at a controlled read, message-
delivery, or tool-output interface.
7.7.36. C-42.28 - Asynchronous Observation Limitation
A telemetry-only system may report security-relevant events after the
monitored process has already consumed data or performed a subsequent
action.
Such asynchronous observation does not automatically guarantee race-
free preventive taint enforcement.
Where the enforcement point requires prevention of a post-exposure
effect, the implementation must either:
(a) enforce taint acquisition before releasing the input; (b)
maintain a restrictive default state until required observation
completes;
(c) place an additional current-state check at the effectuation
boundary; or
(d) use another mechanism that closes the relevant authorization
race.
7.7.37. C-42.29 - Controlled Tool Results
When an agent invokes an external tool, the controlled dispatcher may
associate the returned result with:
ToolInvocationID
ReturningToolID
ReceivingProcessInstance
SourceTrustClass
ResultDigest
Das Expires 25 April 2027 [Page 395]
Internet-Draft Sandbox Credential Egress Finality October 2026
ObservationEventID
AuthorityGeneration
The protected taint controller applies the specified propagation rule
before the result is made available for effect-capable execution.
7.7.38. PART VII - PROCESS CREATION AND EXECUTABLE REPLACEMENT
7.7.39. C-42.30 - Child Process Creation
A protected process-creation controller observes the creation of a
child execution context.
The controller obtains the authenticated parent process instance.
It creates a new child process-instance identity.
It establishes a PARENT_OF lineage edge.
It assigns the required initial taint and authority restrictions.
The child is then permitted to execute according to the selected
operating-system mechanism.
Where reliable propagation before execution is required, the system
uses appropriate processcreation mediation rather than depending
solely upon delayed observation.
7.7.40. C-42.31 - Process Fork
On a supported operating system, process creation may copy or inherit
execution state.
The protected lineage controller assigns the child the applicable
parent taint.
Inherited file descriptors, credentials, memory mappings, and pending
effect-capable interfaces may be separately evaluated.
Forking does not inherently create a fresh trust boundary.
7.7.41. C-42.32 - Executable Replacement
A process may replace its executable image with another program.
Das Expires 25 April 2027 [Page 396]
Internet-Draft Sandbox Credential Egress Finality October 2026
In one implementation, the new executable image receives a new
execution generation while retaining the protected process-instance
lineage.
Required taint restrictions are carried forward.
The agent cannot remove an applicable inherited restriction merely by
invoking another executable.
7.7.42. C-42.33 - Interpreter and Shell Execution
An agent may launch a shell, Python interpreter, JavaScript runtime,
or command-line tool.
The protected controller associates the new execution context with
the originating agent and applicable taint.
A command interpreter's native ability to execute arbitrary programs
does not independently expand the originating task's protected
effectuation scope.
7.7.43. C-42.34 - Process Identifier Reuse
A terminated process identifier may later be assigned to another
process.
The protected registry uses a process-instance generation or
equivalent unique reference to prevent stale authority and taint
records from attaching incorrectly.
The system also prevents an invalid authorization associated with the
terminated process from being automatically transferred to the new
process.
7.7.44. PART VIII - IPC AND DATA-OBJECT TAINT
7.7.45. C-42.35 - Interprocess Communication
A process may transfer information using:
(a) pipes; (b) local sockets; (c) shared memory; (d) message queues;
(e) RPC interfaces; (f) event streams; (g) file descriptors; or
(h) another operating-system communication mechanism.
A selected implementation may instrument the required interfaces to
establish informationflow relationships.
Das Expires 25 April 2027 [Page 397]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.46. C-42.36 - IPC Taint Propagation
Suppose process A has a restricted taint state.
A sends an information-bearing message to process B.
The trusted IPC controller records the sender, receiver, message
context, and applicable propagation event.
Under a conservative policy:
T(B) ← Combine(T(B), T(A), T(Message))
The update occurs before B can use the received information for an
effect covered by the policy.
Where transport-level mediation is incomplete, the affected coverage
limitations must be accounted for in the guarantee.
7.7.47. C-42.37 - File-Mediated Propagation
A process may write an intermediate file that is later read by
another process.
A representative implementation maintains a file-object taint record.
The writing operation may associate the file with taint derived from
the writing process and relevant input data.
The reading process receives applicable taint when it consumes the
file.
The implementation identifies the file object through a stable
resource reference, not merely an attacker-controlled pathname.
7.7.48. C-42.38 - Shared Memory
Shared-memory regions may be accessible to multiple processes.
A representative implementation can associate taint with a shared-
memory object or selected region.
When a process reads from the region, applicable taint is propagated.
Where byte-level or write-origin tracking is unavailable, a
conservative policy may treat the entire region as tainted following
a relevant write.
Das Expires 25 April 2027 [Page 398]
Internet-Draft Sandbox Credential Egress Finality October 2026
The protection must not enforcement point precise byte-level
information flow unless the necessary instrumentation exists.
7.7.49. C-42.39 - Descriptor Passing
A process may transfer a file descriptor, socket, or device handle to
another process.
The receiving process may gain access to an effect-capable resource.
The protected lineage controller can record the transfer.
The effectuation controller separately verifies whether the receiving
process has current authority to use the resource.
Possession of a transferred descriptor does not automatically restore
a prohibited operation permission under the selected enforcement
policy.
7.7.50. PART IX - DELEGATED AND REMOTE WORKERS
7.7.51. C-42.40 - Delegated Worker
A Delegated Worker means a process or service receiving a task or
operation from an agent or intermediary.
The worker may execute:
1. A browser action. 2. A shell command. 3. A network request. 4.
A database operation. 5. A cloud resource modification. 6. A file
mutation. 7. A credential-bearing service request. 8. An
asynchronous background job.
The worker may have different native permissions from the requesting
agent.
7.7.52. C-42.41 - Protected Delegation Record
A representative record comprises:
DelegationID = DEL-4201
OriginatingProcessInstance = PROC-701
ReceivingWorkerID = WORKER-81
AgentContextID = AGENT-42
Das Expires 25 April 2027 [Page 399]
Internet-Draft Sandbox Credential Egress Finality October 2026
TaskID = TASK-204
InheritedTaintReference = TAINT-4201
PermittedOperationScope = RESOURCE-A
AuthorityGeneration = 105
DelegationGeneration = 72
The worker's effective authority is evaluated independently of its
native service-account privileges.
7.7.53. C-42.42 - Remote Worker Handoff
A remote worker may receive an authenticated handoff envelope
identifying the originating authority and taint context.
The handoff may contain:
OriginContextID
TaskID
ProtectedLineageReference
TaintGeneration
AuthorityGeneration
DelegationScope
OperationReference
AuthenticationProof
The remote service verifies the required references before performing
governed operations.
A missing required lineage record is not silently interpreted as a
clean source.
7.7.54. C-42.43 - Taint Across Administrative Domains
Where processes span different administrative domains, the system
defines which domain is trusted to report the relevant observation.
A receiving enforcement domain may:
Das Expires 25 April 2027 [Page 400]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) verify authenticated remote evidence; (b) apply a conservative
unverified-source classification;
(c) request independent validation;
(d) restrict the permitted operation; or
(e) reject the handoff.
Cryptographic authentication of a report proves the identity of its
signer according to the selected mechanism, not necessarily the truth
of every underlying observation.
7.7.55. PART X - PROTECTED AUTHORITY TRANSITIONS
7.7.56. C-42.44 - Protected Permission State
The protected controller may maintain:
AuthorityStateID
AgentContextID
ProcessInstanceID
ExecutionGeneration
CurrentTaintGeneration
CurrentAuthorityGeneration
PermittedOperationClasses
AutomaticAllowClasses
RestrictedOperationClasses
RevocationGeneration
The record is protected against unauthorized agent modification.
7.7.57. C-42.45 - Taint-Triggered Authority Change
A taint transition may cause a protected authority change.
For example:
BEFORE:
Das Expires 25 April 2027 [Page 401]
Internet-Draft Sandbox Credential Egress Finality October 2026
Taint = NONE_RECORDED
NetworkAutoAllow = LIMITED
CredentialUse = CONDITIONAL
AFTER:
Taint = UNTRUSTED_WEB
NetworkAutoAllow = DISABLED
CredentialUse = FRESH_VALIDATION_REQUIRED
The policy determines the transition.
The system may permit local analysis while restricting higher-risk
external operations.
7.7.58. C-42.46 - Protected Authority Generation
A protected authority generation identifies a current permission-
state version.
A representative transition is:
AuthorityGeneration 105 → 106
The new generation may invalidate grants associated with the previous
state.
The protected controller associates affected processes and delegated
workers with the new authority restrictions.
7.7.59. C-42.47 - Revocation Scope
Revocation may apply to:
(a) one process instance; (b) its descendants; (c) one task; (d) an
agent execution context; (e) one delegated worker; (f) a connector
class;
(g) a particular credential;
(h) a resource scope;
(i) one operation class; or
Das Expires 25 April 2027 [Page 402]
Internet-Draft Sandbox Credential Egress Finality October 2026
(j) a defined group of related execution contexts.
The affected set is derived from protected lineage and policy.
The implementation need not terminate every descendant if the
required security effect can be achieved by restricting relevant
operation interfaces.
7.7.60. C-42.48 - Authorized Declassification
A protected controller may permit a taint or restriction state to be
reduced where an independently authorized declassification or
revalidation procedure succeeds.
A representative procedure requires:
1. Identification of the current taint. 2. Authentication of a
permitted declassification authority. 3. Verification of applicable
policy. 4. Verification of source or data conditions, where
required. 5. Protected commitment of the declassification decision.
6. Generation of a new authority state. 7. Invalidation of any
superseded authorization. 8. Current Finality Sink verification
before later governed effects.
An arbitrary process cannot clear its taint by renaming itself,
replacing its executable, or deleting a local variable.
7.7.61. PART XI - AUTHORITY REVOCATION BARRIER
7.7.62. C-42.49 - Revocation Barrier
A Revocation Barrier means a protected transition ensuring that
affected operation paths do not continue admitting governed effects
under an invalid earlier authority state.
In one implementation, the barrier comprises:
1. Advance of protected revocation generation. 2. Identification of
affected execution contexts. 3. Identification of corresponding
effectuation interfaces. 4. Restriction of new effect admission. 5.
Invalidation of affected grants. 6. Required handling of pending
operations. 7. Protected acknowledgment or convergence tracking. 8.
Commitment of the new enforcement state.
The scope of the barrier is defined by the claimed effectuation
guarantee.
Das Expires 25 April 2027 [Page 403]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.63. C-42.50 - Revocation Ordering
A representative ordering is:
TAINT EVENT ACCEPTED
↓
PROTECTED TAINT STATE UPDATED
↓
REQUIRED AUTHORITY GENERATION ADVANCED
↓
AFFECTED EFFECTUATION PATHS RESTRICTED
↓
OUTSTANDING OPERATIONS CLASSIFIED
↓
REVOCATION COMPLETION STATE RECORDED.
Where immediate enforcement is required, the system must prevent a
window in which a stale authority remains capable of producing a
prohibited new effect.
The implementation may use synchronous gating, protected version
checks at the sink, or an atomic shared enforcement transition.
7.7.64. C-42.51 - Enforcement Convergence
Where multiple Finality Sinks are involved, the protected controller
may track each sink's applied authority generation.
A representative record comprises:
RevocationID
AffectedAgentContext
NewAuthorityGeneration
AffectedSinkIDs
Das Expires 25 April 2027 [Page 404]
Internet-Draft Sandbox Credential Egress Finality October 2026
SinkAppliedGenerations
OutstandingOperationReferences
ConvergenceStatus
The system distinguishes completion of authority-state publication
from completion of actual operation restrictions.
7.7.65. PART XII - FINALITY SINK CONTROL
7.7.66. C-42.52 - Candidate Act Capture
An affected process requests a consequential operation.
A controlled interface creates a Candidate Act.
A representative descriptor comprises:
CandidateActID = CA-4201
ProcessInstanceID = PROC-701
ExecutionGeneration = 19
AgentContextID = AGENT-42
TaskID = TASK-204
OperationClass = NETWORK_SEND
TargetResource = RESOURCE-81
CurrentTaintReference = TAINT-4201
AuthorityGeneration = 106
RequiredSinkID = FS-42
The operation remains non-effective pending authorization.
7.7.67. C-42.53 - PED Taint-Aware Validation
The PED obtains:
1. The actual Candidate Act descriptor. 2. Authenticated process
identity. 3. Protected process-lineage state. 4. Current taint
classification. 5. Required observation-coverage state. 6.
Das Expires 25 April 2027 [Page 405]
Internet-Draft Sandbox Credential Egress Finality October 2026
Applicable task authority. 7. Current policy generation. 8. Current
authority and revocation generations. 9. Resource-specific
permission. 10. Required effectuation-boundary identity.
The PED evaluates whether the proposed operation remains permitted.
7.7.68. C-42.54 - Protected Validation Evidence
When required authorization succeeds, the PED commits protected
validation evidence.
A representative record comprises:
EvidenceID = VE-4201
CandidateActID = CA-4201
ProcessInstanceID = PROC-701
ExecutionGeneration = 19
TaintGeneration = 15
AuthorityGeneration = 106
OperationDigest = DIGEST-4201
ValidationResult = APPROVED
RequiredSinkID = FS-42
The record is committed in protected state.
7.7.69. C-42.55 - Scoped Finality Authorization
The PED may establish a bounded non-bearer capability associated with
the Candidate Act.
A representative capability comprises:
CapabilityID
CandidateActID
EvidenceReference
AuthorizedOperationDigest
Das Expires 25 April 2027 [Page 406]
Internet-Draft Sandbox Credential Egress Finality October 2026
ProcessInstanceID
ExecutionGeneration
AuthorityGeneration
TaintGeneration
AuthorizedSinkID
UsagePolicy
ProtectedConsumptionReference
The capability is not unrestricted portable authority.
The Finality Sink evaluates its required current validity conditions.
7.7.70. C-42.56 - Finality Sink Verification
The Finality Sink obtains or reconstructs the actual pending
operation.
It verifies:
(a) operation identity and material parameters; (b) current execution
context; (c) applicable taint and lineage state; (d) current
authority generation; (e) applicable revocation generation; (f)
protected validation evidence; (g) scoped finality authorization,
where required;
(h) authorized resource scope;
(i) freshness;
(j) sink-local protected usage state; and
(k) applicable outstanding-operation restrictions.
A stale authorization is rejected when current taint-associated
authority no longer permits the operation.
7.7.71. C-42.57 - Non-Bypassability
The protected restrictions apply at the relevant effectuation paths.
Das Expires 25 April 2027 [Page 407]
Internet-Draft Sandbox Credential Egress Finality October 2026
For example, disabling one tool command does not establish complete
network revocation if the process retains a direct socket path
capable of the same prohibited transmission.
The deployment must restrict or mediate the affected routes.
The selected implementation may reuse the effectuation-path coverage
techniques described for a protected agent sandbox, but this
implementation profile independently specifies the required taint-to-
authority enforcement relationship.
7.7.72. PART XIII - OUTSTANDING ASYNCHRONOUS OPERATIONS
7.7.73. C-42.58 - Outstanding Operation States
A representative operation-state machine comprises:
STAGED
VALIDATING
AUTHORIZED
RESERVED
QUEUED
DISPATCHED
COMPLETED
DENIED
CANCELED
INDETERMINATE
The state indicates what has been established about the operation.
Authorization does not necessarily imply completion.
Dispatch does not necessarily imply an externally committed effect.
7.7.74. C-42.59 - Revocation of Queued Operations
If a protected taint transition revokes authority while an operation
is queued, the controller determines whether the queue remains under
an enforceable Finality Sink.
Das Expires 25 April 2027 [Page 408]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where the queued operation has not crossed the governed effectuation
boundary, the sink may reject it under the current revocation
generation.
The earlier queue-admission authorization is not automatically
sufficient.
7.7.75. C-42.60 - Dispatched Operations
An operation may already have been dispatched to an external system
when revocation occurs.
The protected controller cannot necessarily reverse an irreversible
external effect.
The implementation may:
1. Record that dispatch preceded revocation. 2. Prevent subsequent
unauthorized effects. 3. Attempt cancellation where supported.
4. Apply a continuation rule for pending remote operations. 5.
Reconcile the actual result. 6. Record an unresolved state. 7.
Initiate a separately authorized compensating procedure.
The protection claimed must correspond to the actual controlled
effectuation boundary.
7.7.76. C-42.61 - Outstanding Credential Requests
A credential-bearing request may be queued while authority remains
valid.
If taint-associated revocation occurs before protected credential
application, the credential Finality Sink verifies current authority.
The pending request is denied if the required permission has become
invalid.
A previously issued upstream approval does not automatically restore
credential-use authority.
7.7.77. C-42.62 - Outstanding Device or Network Commands
A hardware command may have entered a device queue before revocation.
The controller distinguishes:
Das Expires 25 April 2027 [Page 409]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) commands not yet admitted; (b) admitted but not executing; (c)
executing commands; (d) completed commands; and (e) unresolved
commands.
The implementation uses supported queue fencing, cancellation,
completion-state verification, or another appropriate hardware
mechanism.
A software revocation update does not automatically prove that a
previously admitted device effect has been prevented.
7.7.78. PART XIV - PRINCIPAL 32-STEP WORKFLOW
7.7.79. C-42.63 - Complete Protected Process-Lineage Workflow
7.7.80. Step C42-01 - Agent environment initialization
The agent runtime is created under an applicable sandbox and
authority policy.
7.7.81. Step C42-02 - Process identity registration
The protected controller establishes the process-instance identity.
7.7.82. Step C42-03 - Execution-generation assignment
The process is assigned a current execution-generation reference.
7.7.83. Step C42-04 - Initial authority-state establishment
The protected authority registry records permitted operation classes
and current generations.
7.7.84. Step C42-05 - Observation-boundary activation
Required runtime collection interfaces are activated and their
coverage state verified.
7.7.85. Step C42-06 - Agent computation
The agent performs permitted computation.
7.7.86. Step C42-07 - Security-relevant event occurrence
The agent or one of its processes accesses a policy-relevant
information or execution source.
Das Expires 25 April 2027 [Page 410]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.87. Step C42-08 - Trusted event attribution
The observation controller identifies the affected process instance
and event class.
7.7.88. Step C42-09 - Source classification
The relevant input or operation is assigned its defined security
classification.
7.7.89. Step C42-10 - Protected lineage-event commitment
The required observation and relationship are recorded.
7.7.90. Step C42-11 - Taint-state calculation
The taint controller evaluates the applicable propagation rule.
7.7.91. Step C42-12 - Protected taint-state update
The new taint state is committed.
7.7.92. Step C42-13 - Affected-context computation
The controller identifies descendants, delegated workers, and other
required propagation targets.
7.7.93. Step C42-14 - Transitive propagation
Applicable taint labels are propagated according to protected policy.
7.7.94. Step C42-15 - Authority-policy evaluation
The protected controller determines whether the taint change requires
an authority restriction.
7.7.95. Step C42-16 - Authority-generation transition
The affected protected authority generation is updated.
7.7.96. Step C42-17 - Enforcement-path restriction
The required effectuation interfaces are updated or made subject to
current-generation verification.
Das Expires 25 April 2027 [Page 411]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.97. Step C42-18 - Outstanding-operation identification
Queued, reserved, and dispatched operations are identified.
7.7.98. Step C42-19 - Outstanding-operation restriction
The applicable revocation or continuation rules are applied.
7.7.99. Step C42-20 - Agent operation proposal
The affected process proposes a consequential operation.
7.7.100. Step C42-21 - Candidate Act interception
The operation is captured.
7.7.101. Step C42-22 - Non-effective staging
The governed consequence remains withheld.
7.7.102. Step C42-23 - Actual descriptor construction
The controlled interface obtains the material operation parameters.
7.7.103. Step C42-24 - PED current-state lookup
The PED obtains taint, lineage, authority, and revocation state.
7.7.104. Step C42-25 - Operation-specific validation
The PED evaluates required predicates.
7.7.105. Step C42-26 - Protected evidence commitment
Where authorization succeeds, required validation evidence is
committed.
7.7.106. Step C42-27 - Scoped finality enablement
A bounded finality condition is established where required.
7.7.107. Step C42-28 - Actual operation presentation
The operation reaches the designated Finality Sink.
Das Expires 25 April 2027 [Page 412]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.108. Step C42-29 - Sink-side current-state verification
The sink verifies actual operation binding and applicable current
authority.
7.7.109. Step C42-30 - Effectuation decision
The sink permits or withholds the governed consequence.
7.7.110. Step C42-31 - Protected consumption and outcome update
Required authorization and completion state are updated.
7.7.111. Step C42-32 - Recovery and continuity maintenance
Lineage, taint, revocation, and outstanding-operation records are
maintained across later execution transitions.
7.7.112. PART XV - REFERENCE IMPLEMENTATION ALGORITHMS
C-42.64 - Algorithm A: Process Instance Registration
function RegisterExecutionContext(process_event):
if not VerifyTrustedProcessCreationEvent(process_event):
return DENIED
parent = ResolveAuthenticatedParentInstance(
process_event.parent_reference )
instance_id = AllocateProtectedProcessInstanceID({
host_boot_generation: process_event.boot_generation,
kernel_process_reference: process_event.process_reference,
process_start_sequence: process_event.start_sequence
})
inherited_taint = EmptyTaintState()
inherited_authority = ResolveInitialTaskAuthority(
process_event )
if parent is valid:
Das Expires 25 April 2027 [Page 413]
Internet-Draft Sandbox Credential Egress Finality October 2026
inherited_taint = ReadProtectedTaintState(parent)
inherited_authority = RestrictToPermittedChildScope(
parent, inherited_authority )
protected_record = ProtectedProcessRegistry.create({
process_instance_id: instance_id, parent_instance_id: parent.id if
parent valid else NONE, execution_generation: 1, taint_state:
inherited_taint, authority_state: inherited_authority,
process_status: INITIALIZING })
if not InstallRequiredInitialRestrictions(protected_record):
MarkProcessRestricted(instance_id) return DENIED
ActivateProcessInstance(instance_id)
return protected_record
The selected platform must support the required identity and
creation-time enforcement guarantees.
A post-creation observation event alone may not prevent a child from
executing an effectcapable operation before inherited restrictions
are installed.
7.7.113. C-42.65 - Algorithm B: Trusted Taint Acquisition
function AcquireTaintFromInput(input_event):
process = ResolveProtectedProcessInstance(
input_event.execution_identity )
if process is invalid:
return DENIED
if not VerifyRequiredObservationSource(input_event):
ApplyUnknownProvenanceRestriction(process) return RESTRICTED
classification = ClassifyInputUnderProtectedPolicy(
input_event.source_identity, input_event.operation_class )
begin protected_atomic_transaction
Das Expires 25 April 2027 [Page 414]
Internet-Draft Sandbox Credential Egress Finality October 2026
current = LockProtectedTaintState(process.id)
next_taint = CombineTaint(
current.taint, classification )
event_record = CommitProtectedObservation({
process_instance: process.id, event_class:
input_event.operation_class, source_class: classification,
event_sequence: input_event.sequence, prior_taint_generation:
current.generation })
UpdateProtectedTaintState(
process.id, next_taint, event_record )
required_restriction = EvaluateTaintAuthorityPolicy(
process, next_taint )
CommitRequiredAuthorityTransition(
process, required_restriction )
commit protected_atomic_transaction
ReleaseInputAccordingToUpdatedAuthority(
process, input_event )
return CURRENT_TAINT_STATE
In this implementation the data-release interface must remain
controlled until the required protected update succeeds.
C-42.66 - Algorithm C: Transitive Lineage Propagation
function PropagateTaint(root_context, taint_update):
queue = [root_context] visited = EmptySet()
while queue is not empty:
current = Pop(queue)
identity = (
Das Expires 25 April 2027 [Page 415]
Internet-Draft Sandbox Credential Egress Finality October 2026
current.process_instance_id, current.execution_generation )
if identity in visited:
continue
Add(visited, identity)
relationships = ProtectedLineageRegistry.getOutgoing(
current )
for each relationship in relationships:
if not IsPropagationRelevant(relationship):
continue
target = ResolveProtectedTargetContext(relationship)
if target is invalid:
ApplyRequiredCoverageRestriction(relationship) continue current_taint
= ReadProtectedTaintState(target)
derived_taint = ApplyPropagationRule(
taint_update, relationship, current_taint
)
if derived_taint adds required restrictions:
CommitProtectedTaintTransition(
target, derived_taint )
ApplyRequiredAuthorityRestriction(
target, derived_taint )
Push(queue, target)
return PROPAGATION_COMPLETE_FOR_VERIFIED_GRAPH
A production implementation must coordinate graph updates with
propagation so that a newly created descendant cannot escape required
inherited restrictions during traversal.
Das Expires 25 April 2027 [Page 416]
Internet-Draft Sandbox Credential Egress Finality October 2026
C-42.67 - Algorithm D: Process Executable Replacement
function HandleExecutableReplacement(exec_event):
process = ResolveProtectedProcessInstance(
exec_event.process_identity )
if process is invalid:
return DENIED
previous_taint = ReadProtectedTaintState(process)
previous_authority = ReadProtectedAuthorityState(process)
new_generation = AdvanceExecutionGeneration(process)
next_authority = EvaluateExecutableTransitionPolicy({
prior_authority: previous_authority, prior_taint: previous_taint,
new_executable: exec_event.executable_identity, new_generation:
new_generation })
if not InstallRequiredRestrictions(
process, new_generation,
next_authority ):
return DENIED
CommitProtectedExecutionTransition({
process_instance: process.id, new_generation: new_generation,
preserved_taint: previous_taint, authority_state: next_authority })
return EXECUTION_CONTINUED_WITH_RESTRICTIONS
An executable replacement is not treated as automatic taint
declassification.
7.7.114. C-42.68 - Algorithm E: IPC Taint Propagation
function DeliverProtectedIPC(message, sender, receiver):
if not AuthenticateIPCParticipants(sender, receiver):
Das Expires 25 April 2027 [Page 417]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED
sender_taint = ReadProtectedTaintState(sender)
object_taint = ReadMessageOrObjectTaint(message)
begin protected_atomic_transaction
receiver_state = LockProtectedTaintState(receiver)
next_taint = CombineTaint(
receiver_state.taint, sender_taint, object_taint )
CommitProtectedIPCLineage({
sender: sender.id, receiver: receiver.id, message_reference:
HashCanonical(message), sender_generation:
sender.execution_generation, receiver_generation:
receiver.execution_generation })
UpdateProtectedTaintState(receiver, next_taint)
ApplyRequiredAuthorityRestriction(
receiver,
next_taint )
commit protected_atomic_transaction
DeliverMessageToReceiver(receiver, message)
return DELIVERED
The ordering provides one implementable species for IPC interfaces
whose delivery can be mediated.
C-42.69 - Algorithm F: Taint-Triggered Revocation Barrier
function RevokeAuthorityForTaintedLineage(
originating_context, restriction ):
affected = ComputeAffectedProtectedLineageSet(
originating_context, restriction )
Das Expires 25 April 2027 [Page 418]
Internet-Draft Sandbox Credential Egress Finality October 2026
generation = AdvanceProtectedRevocationGeneration(
affected )
for each context in affected:
BlockNewGovernedEffectAdmission(
context, restriction )
InvalidateAffectedAuthorizationGrants(
context, generation )
affected_sinks = ResolveAffectedFinalitySinks(
affected, restriction )
for each sink in affected_sinks:
InstallRestrictiveAuthorityGeneration(
sink, generation )
outstanding = ResolveOutstandingAffectedOperations(
affected )
for each operation in outstanding:
ApplyRequiredPendingOperationRule(
operation, generation )
if not VerifyRequiredRevocationBarrier(
affected_sinks, outstanding, generation ):
ApplyCompensatingEffectuationRestrictions() return
REVOCATION_INCOMPLETE
CommitProtectedRevocationCompletion(generation)
return REVOKED
If revocation delivery to a remote sink is not immediate, the
implementation must enforce a suitable lease, version check, or other
restriction consistent with the claimed timing guarantee.
Das Expires 25 April 2027 [Page 419]
Internet-Draft Sandbox Credential Egress Finality October 2026
C-42.70 - Algorithm G: Protected Taint-Aware Candidate Validation
function ValidateTaintedContextCandidate(candidate_id):
candidate = ProtectedOperationRegistry.get(candidate_id)
if candidate.status != STAGED:
return DENIED
process = ResolveProtectedProcessInstance(
candidate.process_instance_id )
if not VerifyExecutionGeneration(
process, candidate.execution_generation ):
return DENIED
lineage = ProtectedLineageRegistry.getApplicableLineage(
process )
taint = ProtectedTaintRegistry.getCurrent(process)
authority = ProtectedAuthorityRegistry.getCurrent(
process.agent_context_id )
if not VerifyRequiredObservationCoverage(
process, lineage ):
return DENIED if not EvaluateTaintAssociatedAuthority(
candidate, taint, authority ):
CommitProtectedDenial(candidate_id) return DENIED if not
EvaluateOperationSpecificPredicates(
candidate, authority ):
CommitProtectedDenial(candidate_id) return DENIED evidence =
CommitProtectedValidationEvidence({
Das Expires 25 April 2027 [Page 420]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate_id: candidate_id, actual_descriptor_digest:
candidate.descriptor_digest, process_instance_id: process.id,
execution_generation: process.execution_generation, taint_generation:
taint.generation, authority_generation: authority.generation,
validation_result: APPROVED })
capability = EstablishScopedNonBearerFinality({
candidate_id: candidate_id, evidence_reference: evidence.id,
authorized_operation_digest: candidate.descriptor_digest,
required_sink: candidate.required_sink, authority_generation:
authority.generation, taint_generation: taint.generation
})
if not AtomicallyActivateProtectedAuthorization(
candidate_id, evidence, capability ):
return DENIED
return AUTHORIZED
The evidence and capability must remain bound to the Candidate Act
under the required current-state conditions.
7.7.115. C-42.71 - Algorithm H: Finality Sink Verification
function EffectuateWithTaintAuthority(candidate_id):
record = ProtectedOperationRegistry.get(candidate_id)
if record.status != AUTHORIZED:
return DENIED
actual_operation = ObtainActualPendingOperation(
candidate_id )
if actual_operation is unavailable:
return DENIED
evidence = ProtectedEvidenceRegistry.get(
record.evidence_id )
Das Expires 25 April 2027 [Page 421]
Internet-Draft Sandbox Credential Egress Finality October 2026
capability = ProtectedCapabilityRegistry.get(
record.capability_id )
current_authority = ResolveCurrentProtectedAuthority(
record.agent_context_id )
current_taint = ResolveCurrentProtectedTaint(
record.process_instance_id )
if not VerifyProtectedEvidence(evidence):
return DENIED
if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED
if not VerifyActualOperationBinding(
actual_operation, capability ):
return DENIED if not VerifyCurrentExecutionAndAuthorityGeneration(
record, current_authority ):
return DENIED if not VerifyRequiredTaintStateValidity(
record, current_taint ):
return DENIED
if not VerifySinkLocalProtectedState(capability):
return DENIED if not AtomicallyReserveCapability(capability):
return DENIED result = ExecuteThroughControlledFinalityBoundary(
actual_operation )
ReconcileProtectedOperationOutcome(
candidate_id, result )
Das Expires 25 April 2027 [Page 422]
Internet-Draft Sandbox Credential Egress Finality October 2026
return result
The sink may retrieve current protected state or validate a suitable
protected generation reference with the required freshness guarantee.
C-42.72 - Algorithm I: Missing Observation Handling
function ProcessObservationCoverageFailure(
execution_context, missing_event_class ):
coverage = ProtectedObservationRegistry.get(
execution_context )
if missing_event_class not in coverage.required_classes:
return NONCRITICAL_COVERAGE_CHANGE begin protected_atomic_transaction
MarkObservationIncomplete(
execution_context, missing_event_class )
generation = AdvanceProtectedAuthorityGeneration(
execution_context )
ApplyConfiguredFailClosedRestrictions(
execution_context, generation )
commit protected_atomic_transaction
NotifyAffectedFinalitySinks(
execution_context, generation )
return REVALIDATION_REQUIRED
A system may apply different restrictions depending upon the affected
operation class.
However, a required coverage failure must not be silently treated as
proof that no tainting event occurred.
C-42.73 - Algorithm J: Outstanding Operation Reconciliation
function ReconcileRevokedOutstandingOperations(
Das Expires 25 April 2027 [Page 423]
Internet-Draft Sandbox Credential Egress Finality October 2026
context, revocation_generation ):
outstanding = ProtectedOperationRegistry.getOutstanding(
context )
for each operation in outstanding:
if operation.status in {
STAGED, VALIDATING, AUTHORIZED, RESERVED, QUEUED }:
if CanPreventEffectAtCurrentBoundary(operation):
CancelOrInvalidate(operation) else:
ApplyRequiredEffectuationFence(operation)
else if operation.status == DISPATCHED:
result = QueryAuthoritativeCompletionState(
operation )
if result == NOT_EFFECTED:
MarkCanceled(operation)
else if result == EFFECTED:
RecordCompletedBeforeOrAfterRevocation(
operation )
else:
MarkIndeterminate(operation)
return ProtectedOperationRegistry.getReconciliationStatus(
context )
This algorithm does not assume that an already completed external
effect can be retroactively prevented.
Das Expires 25 April 2027 [Page 424]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.116. PART XVI - WORKED TECHNICAL EXAMPLES
C-42.74 - Example A: Webpage Read Followed by Child Process Execution
The following is a hypothetical implementation example.
An AI agent executes inside a container.
The agent retrieves an untrusted webpage.
The controlled retrieval interface associates the content with the
originating agent process instance.
The protected taint controller marks the process:
UNTRUSTED_WEB_CONTENT.
The agent subsequently launches a command interpreter.
The protected process-creation controller establishes a child lineage
relationship.
The child inherits the applicable taint restriction.
The child attempts a network transmission using an available tool.
The network Finality Sink obtains the current protected authority
state.
Under the selected policy, tainted execution contexts require fresh
operation-specific authorization for the requested transmission.
The operation is withheld unless that authorization succeeds.
Creating the child process does not restore the earlier automatic
network permission.
C-42.75 - Example B: Executable Replacement Does Not Clear Taint
An agent process reads a policy-restricted document.
The process receives a corresponding taint classification.
The process then replaces its executable image with a different
program.
The operating system preserves the process-instance relationship
while the protected controller advances its execution generation.
Das Expires 25 April 2027 [Page 425]
Internet-Draft Sandbox Credential Egress Finality October 2026
The previous taint remains associated with the new execution
generation according to protected policy.
The new program requests credential use.
The credential Finality Sink verifies the current inherited
restriction.
Credential use is denied where the required fresh authorization is
absent.
C-42.76 - Example C: IPC Propagation Between Agents
Agent A receives untrusted external content.
Agent A communicates a derived message to Agent B over a controlled
IPC channel.
The IPC controller records:
Source: Agent A process instance.
Destination: Agent B process instance.
Message identity and digest.
Current source taint.
Applicable task lineage.
Before the message is delivered, the protected taint controller
combines the required restriction labels into Agent B's taint state.
Agent B may still analyze the information.
However, Agent B cannot use an earlier unrestricted authorization to
perform an effect prohibited by the new taint-associated policy.
C-42.77 - Example D: File-Mediated Indirect Propagation
A tool worker receives untrusted package metadata.
The worker writes a structured result to a shared file.
The protected file lineage registry associates the file with the
applicable source restriction.
A second process later reads the file.
Das Expires 25 April 2027 [Page 426]
Internet-Draft Sandbox Credential Egress Finality October 2026
The controlled read interface applies the required file-object taint
to the receiving process.
The second process attempts to modify a privileged deployment
configuration.
The PED evaluates current task authority and provenance-associated
restrictions.
The modification is withheld unless its independent protected
authorization succeeds.
The intermediate file does not erase the source restriction.
C-42.78 - Example E: Privileged Connector With Broader Native
Authority
An AI agent can invoke a host-side enterprise connector.
The connector holds credentials for multiple enterprise resources.
The agent becomes tainted after receiving an untrusted tool result.
The protected authority policy removes a narrow automatic-approval
lane for certain privileged operations.
The agent asks the connector to modify a protected resource.
The connector stages the actual operation.
The PED checks the requesting task, lineage-associated restriction,
resource scope, and current authority generation.
The connector's native credentials do not override the protected
restriction.
The Finality Sink refuses the operation when current authorization is
absent.
C-42.79 - Example F: Revocation During Asynchronous Queue Processing
An agent generates a cloud-resource modification request.
The operation is authorized and queued.
Before the queue worker effects the change, the agent receives
policy-restricted content triggering a protected authority-generation
transition.
Das Expires 25 April 2027 [Page 427]
Internet-Draft Sandbox Credential Egress Finality October 2026
The protected revocation controller updates the applicable
generation.
The asynchronous worker later receives the queued operation.
The Finality Sink verifies the current required generation.
The queued operation is denied if the old authorization is no longer
sufficient.
Queue possession alone does not preserve invalidated authority.
7.7.117. C-42.80 - Example G: Remote Delegated Worker
An agent delegates report preparation to a remote worker.
The handoff includes authenticated originating authority and taint
references.
The remote worker receives additional untrusted information while
performing the task.
The remote protected controller combines the relevant taint states.
The worker subsequently requests external file publication.
The publication Finality Sink verifies the current delegated scope
and applicable taintassociated policy.
The operation is permitted only when independent finality conditions
succeed.
7.7.118. C-42.81 - Example H: Process-ID Recycling
Process A has PID 4132 and is tainted.
Process A terminates.
Later, Process B receives PID 4132.
The protected execution identity includes a distinct creation
generation and process-instance identifier.
Process B is not automatically confused with Process A solely because
the numeric PID matches.
Any applicable inherited restriction for Process B is determined from
its actual creation, task, and provenance context.
Das Expires 25 April 2027 [Page 428]
Internet-Draft Sandbox Credential Egress Finality October 2026
Stale Process A authorization references cannot be reused as Process
B authority.
7.7.119. C-42.82 - Example I: Required Observation Failure
A protected system relies upon a controlled tool-result interface to
classify incoming untrusted information.
The observation interface fails.
The system detects that required collection coverage is unavailable.
It advances the applicable restrictive authority state.
Until observation is restored or a permitted alternative validation
succeeds, affected high-risk operations are withheld.
The system does not infer that the agent remained untainted merely
because the missing interface did not report an event.
7.7.120. C-42.83 - Example J: Authorized Declassification
An agent process has a taint label indicating access to restricted
source data.
An authorized protected review process determines that a specific
derived output satisfies the configured release conditions.
The declassification controller authenticates the reviewing
authority.
It commits a protected declassification record.
The protected authority generation advances.
The Finality Sink verifies that the actual proposed release matches
the approved declassification scope.
The system permits only the authorized release.
The process does not receive unrestricted authority to transmit
unrelated restricted information.
Das Expires 25 April 2027 [Page 429]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.121. PART XVII - FAILURE AND ADVERSARIAL CONDITIONS
7.7.122. C-42.84 - Representative Failure Cases
7.7.123. F1 - Child Process Escape
A tainted process creates a child and attempts a prohibited
operation.
The required taint and authority restrictions propagate to the child.
7.7.124. F2 - Executable Replacement
A tainted process executes another binary.
Required lineage restrictions survive the transition.
7.7.125. F3 - Process-ID Reuse
An attacker attempts to use a recycled PID to invoke stale authority.
Protected process-instance identity prevents unauthorized reuse.
7.7.126. F4 - Shell Indirection
The agent routes an operation through a shell interpreter.
The effectuation controller applies current protected authority
despite the intermediate process.
7.7.127. F5 - IPC Laundering
A tainted process relays information through another process.
Relevant propagation rules preserve applicable restrictions.
7.7.128. F6 - File-Based Laundering
Untrusted information is written to a file and read by another
worker.
The required object and process lineage is maintained.
7.7.129. F7 - Shared Memory Laundering
A process exchanges data through shared memory outside ordinary
message interfaces.
Das Expires 25 April 2027 [Page 430]
Internet-Draft Sandbox Credential Egress Finality October 2026
The claimed enforcement must cover the selected shared-memory access
boundary or apply a conservative restriction.
7.7.130. F8 - Descriptor Transfer
A process passes an effect-capable handle to another process.
The receiving execution context remains subject to current
effectuation authority.
7.7.131. F9 - Untrusted Tool Result
A tool returns untrusted instructions.
The result is classified and propagated according to policy.
7.7.132. F10 - Unverified Remote Delegation
A remote worker receives an unverified taint enforcement point.
The protected controller applies the configured conservative
classification or requires independent validation.
7.7.133. F11 - Process-Lineage Record Tampering
A monitored process attempts to modify protected lineage records.
The applicable integrity mechanism rejects unauthorized modification.
7.7.134. F12 - Forged Parent Identity
An agent supplies a fabricated process ancestry.
The protected registry uses trusted creation or delegation
observations rather than the untrusted assertion.
7.7.135. F13 - Lost Observation
A required event is not collected.
The affected operation receives the configured restrictive treatment.
7.7.136. F14 - Delayed Observation
A taint event is reported only after relevant processing.
An implementation claiming race-free prevention must provide an
effective collectionbefore-use or sink-side restriction mechanism.
Das Expires 25 April 2027 [Page 431]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.137. F15 - Authority Generation Replay
A process presents an authorization from an earlier generation.
Current protected generation validation rejects unauthorized reuse.
7.7.138. F16 - Taint Generation Replay
A stale taint state is substituted for the current protected state.
Protected continuity and generation checks reject prohibited
rollback.
7.7.139. F17 - Taint Clearing by Environment Variable
A process changes local environment variables claiming a clean state.
The protected taint registry remains authoritative.
7.7.140. F18 - Credential Broker Bypass
A process attempts direct credential use outside the governed broker.
The corresponding path must be controlled or restricted.
7.7.141. F19 - Direct Network Bypass
A process uses a direct socket instead of an approved tool.
The required effectuation-path coverage prevents prohibited
transmission.
7.7.142. F20 - Asynchronous Job Continuation
A queued worker attempts an operation after required authority is
revoked.
Current Finality Sink verification prevents invalid new effects.
7.7.143. F21 - Already Dispatched External Operation
An operation was transmitted before revocation.
The system records the timing and reconciles its outcome without
claiming retroactive prevention.
Das Expires 25 April 2027 [Page 432]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.144. F22 - Concurrent Taint Transition
Multiple taint events affect one process simultaneously.
Protected atomic state updates prevent lost required restrictions.
7.7.145. F23 - Concurrent Descendant Creation
A child process is created while a lineage restriction is being
propagated.
The creation boundary obtains the required current ancestor
restriction or remains blocked.
7.7.146. F24 - Registry Unavailability
A protected lineage store is unavailable.
Mandatory lineage-dependent operations are restricted under the
defined policy.
7.7.147. F25 - Invalid Declassification
An unauthorized process attempts to clear taint.
The protected controller rejects the declassification.
7.7.148. F26 - Overly Broad Taint Propagation
A conservative taint policy restricts more processes than necessary.
The system may support authorized declassification while preserving
required restrictions.
7.7.149. F27 - Incomplete IPC Coverage
An unmediated IPC channel bypasses collection.
The claimed coverage must exclude, disable, or mediate that channel.
7.7.150. F28 - Unknown Process Origin
A process has no verifiable originating task or ancestry.
The protected controller applies an unknown-origin authority profile.
Das Expires 25 April 2027 [Page 433]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.151. F29 - Wrong Execution Generation
A capability references an earlier executable instance.
Required current execution-generation verification fails.
7.7.152. F30 - Wrong Agent Context
A worker attempts to use authorization issued to a different agent
context.
The effectuation controller rejects the mismatch.
7.7.153. F31 - Revocation Delivery Failure
One sink does not receive the new restriction.
The system enforces the required convergence, lease, or fallback
policy and does not falsely report universal revocation completion.
7.7.154. F32 - Protected State Rollback
An earlier authority or taint registry state is restored.
The applicable protected continuity mechanism detects prohibited
restoration.
7.7.155. F33 - Tool Replacement
An agent changes the executable tool or connector implementation.
The new execution or effectuation path is evaluated under current
restrictions.
7.7.156. F34 - Partial Effectuation
A command has partially executed before revocation.
The controller distinguishes completed, remaining, cancelable, and
indeterminate effects.
7.7.157. F35 - Malicious Observation Producer
An untrusted component supplies false security events.
The controller verifies required collection-source integrity or
applies an appropriate unverified-source classification.
Das Expires 25 April 2027 [Page 434]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.158. F36 - Excessive Lineage Growth
The lineage graph grows beyond configured resource bounds.
The system uses bounded traversal, protected summarization, or
restrictive fallback without silently discarding required authority
restrictions.
| PART XVIII - IMPLEMENTATION VARIATIONS C-42.85 - Process-Isolated Implementation An AI agent executes as an ordinary operating-system process. A protected host-side controller maintains process-instance identity, lineage, taint state, and effectuation restrictions. Child processes and tool workers are bound to the originating task through trusted process- creation mechanisms. |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-42.86 - Linux Kernel-Assisted Implementation A Linux-based implementation may use available security mechanisms for process identity, controlled execution, file and network access, and selected event observation. Illustrative interfaces may include security module hooks, process-creation mediation, controlled IPC interfaces, and eBPF-based instrumentation where supported. A kernel tracing interface does not automatically provide pre-effect enforcement. The selected configuration must employ actual enforcement-capable controls for the claimed preventive guarantees. |
| C-42.87 - Windows Process and Job Implementation A Windows-based implementation may use suitable process tokens, restricted execution contexts, job objects, protected service identities, and documented access-control or filtering interfaces. A protected controller maintains the corresponding process-instance and lineage records. The implementation must identify which enforcement interfaces can actually restrict the selected effectuation class. |
7.7.159. C-42.88 - macOS Process Implementation
A macOS implementation may employ applicable process, entitlement,
sandbox, and supported system-extension mechanisms.
A protected authority service maintains lineage and taint state
according to the available observation and control guarantees.
7.7.160. C-42.89 - Container-Isolated Implementation
An agent executes inside a container.
Host-side protected components track relevant processes and IPC or
file dependencies.
| The container may be restarted without clearing authoritative task restrictions. The deployment must account for host-exposed resources and direct effectuation paths. |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-42.90 - Virtual-Machine Implementation A virtual-machine agent executes under a protected host or hypervisor arrangement. Lineage events may be collected inside the guest, through protected guest instrumentation, or through appropriately trusted host-side interfaces. The system must distinguish guest-reported observations from independently protected collection. |
| C-42.91 - Cloud-Hosted Worker Implementation An AI agent delegates operations to cloud-hosted workers. Authenticated handoff envelopes convey protected lineage and authority references. The cloud effectuation interface verifies current restrictions before performing governed external operations. |
7.7.161. C-42.92 - TEE-Assisted Taint Registry
A TEE protects selected lineage, taint, authority, or revocation
state.
Controlled observation interfaces supply required events.
The TEE evaluates protected transitions.
The corresponding Finality Sink verifies current authority at the
actual effectuation boundary.
Das Expires 25 April 2027 [Page 435]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.162. C-42.93 - HSM-Assisted Evidence Implementation
An HSM may authenticate protected observation records, taint
transitions, or revocation commitments.
Protected cryptographic evidence does not by itself establish
comprehensive process observation.
| The source of the event must remain trusted for the stated protection. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-42.94 - Hardware Effectuation Sink A hardware network, storage, or accelerator controller may enforce current protected authority generations. The taint controller restricts operation classes through authenticated authority updates. The device must provide appropriate execution-time or command-admission controls for the claimed effect. |
| C-42.95 - Distributed Lineage Registry Multiple execution hosts maintain authenticated lineage references in a protected shared registry. A coordinated authority controller evaluates transitive restrictions across host boundaries. The system defines the required consistency and revocation convergence rules. |
| C-42.96 - Conservative Information-Flow Model A system lacking precise byte-level influence tracing may use process-level or object-level taint. Outputs receive the union of relevant input restrictions. This is an implementable conservative model, not a enforcement point of complete semantic attribution. |
7.7.163. C-42.97 - Integrated Single-Node PED and Sink
One protected host component may maintain taint state, validate
operations, commit evidence, establish bounded authorization, and
control the actual effect.
Physical separation is unnecessary where the enforcement point
permits logical integration and the selected component provides
required protected-state integrity.
7.7.164. PART XIX - TECHNICAL DATA STRUCTURES
7.7.165. C-42.98 - ProcessInstanceRecord
Fields may include:
1. ProcessInstanceID. 2. HostBootGeneration. 3.
KernelProcessReference. 4. ParentProcessInstanceID. 5.
AgentContextID. 6. TaskID. 7. ExecutionGeneration. 8.
CurrentAuthorityGeneration. 9. CurrentTaintGeneration. 10.
ProcessLifecycleState.
7.7.166. C-42.99 - LineageEdgeRecord
Fields may include:
1. EdgeID. 2. SourceContextID. 3. TargetContextID. 4.
RelationshipClass. 5. EventSequence. 6. SourceExecutionGeneration.
7. TargetExecutionGeneration. 8. ObservingComponentID. 9.
AuthenticationReference. 10. EdgeValidityState.
Das Expires 25 April 2027 [Page 436]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.167. C-42.100 - TaintStateRecord
Fields may include:
1. TaintRecordID. 2. ProcessInstanceID. 3. ExecutionGeneration. 4.
TaintLabels. 5. TaintGeneration. 6.
OriginatingObservationReferences. 7. ApplicableAuthorityGeneration.
8. ObservationCoverageStatus. 9. RestrictionProfile. 10.
ProtectedCommitmentReference.
7.7.168. C-42.101 - ObservationEventRecord
Fields may include:
1. EventID. 2. ProcessInstanceID. 3. EventClass. 4.
SourceObjectReference. 5. SourceTrustClass. 6. EventSequence. 7.
ObservationTimeReference. 8. TrustedCollectorID. 9.
AuthenticationReference. 10. CommitmentStatus.
7.7.169. C-42.102 - ProtectedAuthorityRestrictionRecord
Fields may include:
1. RestrictionID. 2. AgentContextID. 3. ProcessInstanceID. 4.
TaintGeneration. 5. AuthorityGeneration. 6. RevocationGeneration.
7. RestrictedOperationClasses. 8. RequiredRevalidationClasses. 9.
AffectedSinkReferences. 10. RestrictionStatus.
7.7.170. C-42.103 - DelegatedWorkerLineageRecord
Fields may include:
1. DelegationID. 2. OriginatingProcessInstance. 3.
ReceivingWorkerID. 4. AgentContextID. 5. TaskID. 6.
ProtectedLineageReference. 7. TaintGeneration. 8.
DelegationGeneration. 9. PermittedOperationScope. 10.
CurrentAuthorityGeneration.
7.7.171. C-42.104 - CandidateActTaintRecord
Fields may include:
1. CandidateActID. 2. ProcessInstanceID. 3. ExecutionGeneration.
4. AgentContextID. 5. OperationDescriptorDigest. 6.
TaintGeneration. 7. AuthorityGeneration. 8. RequiredSinkID. 9.
CandidateStatus. 10. ProtectedEvidenceReference.
Das Expires 25 April 2027 [Page 437]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.172. C-42.105 - TaintValidationEvidenceRecord
Fields may include:
1. EvidenceID. 2. CandidateActID. 3. ProcessInstanceID. 4.
ExecutionGeneration. 5. CurrentTaintReference. 6.
AuthorityGeneration. 7. ValidationOutcome. 8.
OperationDescriptorDigest. 9. RequiredSinkID. 10.
ProtectedCommitment.
7.7.173. C-42.106 - RevocationBarrierRecord
Fields may include:
1. RevocationID. 2. OriginatingContextID. 3. AffectedContextSet.
4. PreviousAuthorityGeneration. 5. NewAuthorityGeneration. 6.
AffectedFinalitySinkSet. 7. SinkAppliedGenerationState. 8.
OutstandingOperationSet. 9. RequiredBarrierCondition. 10.
ConvergenceStatus.
7.7.174. C-42.107 - OutstandingOperationRecord
Fields may include:
1. OperationID. 2. CandidateActID. 3. OriginatingProcessInstance.
4. DelegationReference. 5. AuthorityGeneration. 6.
CurrentOperationState. 7. RequiredFinalitySink. 8.
DispatchReference. 9. CompletionReference. 10. ReconciliationState.
These structures may be implemented using kernel-maintained records,
protected service databases, authenticated event journals, secure
memory, protected registers, or cryptographically authenticated
distributed state.
7.7.175. PART XX - ENGINEERING VERIFICATION
7.7.176. C-42.108 - Proposed Verification Test Matrix
The following are proposed tests rather than representations of
experiments already performed.
7.7.177. Test Condition
T1 Clean process creates a permitted
operation T2 Process reads untrusted webpage T3 Tainted parent
creates child T4 Executable replacement T5 PID recycled
Das Expires 25 April 2027 [Page 438]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.7.178. Expected behavior
Required current authorization evaluated Applicable taint state
updated Required labels inherited Required restrictions retained
Process instances distinguished
T6 Tainted process invokes shell T7 Tainted IPC sender T8 Tainted
file written and read T9 Shared-memory information flow T10 File
descriptor passed to worker T11 Remote delegated worker T12 Forged
process ancestry T13 Protected taint state tampered T14 Taint cleared
in local memory T15 Unauthorized declassification T16 Valid
authorized declassification T17 Taint triggers authority change T18
Stale capability after revocation T19 Wrong execution generation T20
Wrong agent identity T21 Missing required observation T22 Delayed
telemetry T23 Concurrent taint events T24 Concurrent descendant
creation T25 Tool worker with broad credential T26 Direct network
bypass T27 Queued operation after revocation T28 Operation already
dispatched T29 Revocation delivery failure T30 Process restart T31
Container replacement T32 Snapshot rollback T33 Protected registry
unavailable T34 Excessive lineage graph T35 Incomplete IPC coverage
T36 Credential use after taint transition T37 Finality Sink
capability replay T38 Remote worker loses lineage reference T39
Process termination with outstanding work Pending operation policy
enforced T40 Revocation and effectuation race
New context remains subject to restrictions Applicable receiver taint
propagated File-mediated restrictions propagated Configured taint
policy applied Current effectuation authority enforced Required
handoff state verified Untrusted ancestry rejected Integrity
violation detected Protected state remains authoritative Rejected
Defined restriction transition applied Protected generation advanced
Finality Sink rejects Authorization rejected Authorization rejected
Restrictive policy enforced Claimed race protections tested Required
state updates preserved New child receives applicable restrictions
Protected task authority maintained Relevant effectuation path
controlled Current finality checked Outcome classified and reconciled
Required convergence limitation recognized Protected lineage
continuity maintained Restrictions not automatically cleared Stale
state or grants rejected Mandatory operations restricted Defined
bounded behavior Required coverage failure detected Current
authorization required Protected usage-state restriction enforced
Required revalidation or denial
Claimed ordering guarantee verified
Das Expires 25 April 2027 [Page 439]
Internet-Draft Sandbox Credential Egress Finality October 2026
A concrete test harness must specify the trusted observation
boundaries, protected authoritystate implementation, effectuation
interfaces, expected lineage edges, event ordering, and observable
results.
7.7.179. PART XXI - Enforcement-Point Mapping and Technical
Correspondence
7.7.180. C-42.109 - Reconstructed Independent enforcement point(s)
corresponding to source item(s) 42
The embodiment provides technical implementation support for:
enforcement point(s) corresponding to source item(s) 42(a): AI-agent
execution environments containing processes, subprocesses,
generated programs, interpreters, tool workers, and delegated
components.
enforcement point(s) corresponding to source item(s) 42(b): Trusted
observation of untrusted information access, agent-generated code
execution, tool invocation, process creation, delegation, and effect-
capable resource access.
enforcement point(s) corresponding to source item(s) 42(c): Machine-
verifiable process-lineage attribution associated with originating
agent
context, execution-generation identity, and relevant relationship
records.
enforcement point(s) corresponding to source item(s) 42(d): Protected
taint-state assignment, combination, and propagation through defined
lineage relationships.
enforcement point(s) corresponding to source item(s) 42(e): Protected
authority, permission, generation, and revocation state maintained
outside agent-controlled modification authority.
enforcement point(s) corresponding to source item(s) 42(f): Taint-
triggered reduction, suspension, revocation, or required revalidation
of
previously available operation permissions.
Das Expires 25 April 2027 [Page 440]
Internet-Draft Sandbox Credential Egress Finality October 2026
enforcement point(s) corresponding to source item(s) 42(g):
Controlled effectuation interfaces preventing use of invalid earlier
authority.
enforcement point(s) corresponding to source item(s) 42(h):
Prevention of authority restoration through descendant creation,
process-ID
reuse, executable replacement, or delegated execution.
7.7.181. C-42.110 - Reconstructed Dependent enforcement point(s)
corresponding to source item(s) 43
The embodiment provides implementation mechanisms for:
1. Process-creation lineage. 2. Executable invocation. 3. Tool
invocation. 4. Shared-data consumption. 5. IPC information flow. 6.
Delegated worker creation. 7. Information-derived output
propagation. 8. Defined taint combination functions. 9. Transitive
propagation through multi-step relationships. 10. Protected
retention of restrictions across execution-identity changes. 11.
Authorized declassification and revalidation. 12. Prevention of
automatic descendant authority restoration.
7.7.182. C-42.111 - Reconstructed Dependent enforcement point(s)
corresponding to source item(s) 44
The embodiment provides implementation mechanisms for:
1. Taint-triggered authority-generation transition. 2. Protected
revocation state. 3. Tool-dispatcher restrictions. 4. Credential-
broker restrictions. 5. Network-egress controls. 6. File-operation
restrictions. 7. Privileged connector restrictions. 8. Current
Finality Sink state verification. 9. Stale Candidate Act
invalidation. 10. Fail-closed handling of required observation loss.
11. Outstanding asynchronous operation control. 12. Revocation
convergence and reconciliation.
7.7.183. PART XXII - implementer IMPLEMENTATION REQUIREMENTS
7.7.184. C-42.112 - Implementation Checklist
A person having ordinary skill in the art implementing the disclosed
system identifies:
1. The agent and process execution environments. 2. The trusted
computing base. 3. The relevant attacker capabilities. 4. The
process-instance identity mechanism. 5. The process-creation
Das Expires 25 April 2027 [Page 441]
Internet-Draft Sandbox Credential Egress Finality October 2026
observation point. 6. The execution-generation rules. 7. The agent
and task association mechanism. 8. The trusted runtime observation
sources. 9. The taint-triggering event classes. 10. The source
trust-classification procedure. 11. The process-lineage graph
representation. 12. The lineage-edge definitions. 13. The required
IPC and data-object boundaries. 14. The file-object taint mechanism.
15. The shared-memory handling policy. 16. The descriptor-passing
rules. 17. The delegated worker identity procedure. 18. The remote
handoff authentication mechanism. 19. The taint-state schema. 20.
The taint combination function. 21. The transitive propagation
algorithm. 22. The event-ordering and race-prevention mechanism. 23.
The protected authority-state store. 24. The taint-to-authority
policy mapping. 25. The protected generation-transition mechanism.
26. The revocation-barrier procedure. 27. The affected Finality
Sink registry. 28. The applicable effectuation-path restrictions.
29. The Candidate Act descriptor representation. 30. The protected
validation procedure. 31. The validation-evidence commitment
mechanism, where required. 32. The scoped finality authorization
representation, where required. 33. The actual operation
reconstruction procedure. 34. The sink-local current-state
verification mechanism. 35. The outstanding-operation state machine.
36. The queued and dispatched operation rules. 37. The observation
coverage requirements. 38. The handling of missing or delayed
events. 39. The authorized declassification procedure. 40. The
rollback and restart continuity mechanism. 41. The resource limits
for lineage propagation. 42. The tests establishing the claimed
prevention and revocation properties.
The implementation must provide technical controls corresponding to
the claimed observation and enforcement guarantees.
Merely logging child processes, assigning a taint label, or
displaying a warning does not necessarily establish protected
revocation of the authority to perform an actual external effect.
7.7.185. C-42.113 - Technical Effect
The disclosed architecture permits security-relevant information
exposure or execution events to influence protected effectuation
authority across multiple related processes and delegated workers.
The system assigns machine-verifiable process-instance identities,
records relevant execution and information-flow relationships, and
propagates applicable taint or restriction states through defined
lineage edges.
Das Expires 25 April 2027 [Page 442]
Internet-Draft Sandbox Credential Egress Finality October 2026
A protected authority controller converts specified taint transitions
into machine-enforceable permission changes.
A Finality Sink or corresponding effectuation controller verifies the
current authority state before permitting governed consequential
operations.
The system prevents an affected execution context from regaining
restricted authority solely by creating a child process, replacing
its executable, relaying information through IPC, transferring an
operation to a worker, or reusing a stale grant.
The implementation may additionally restrict outstanding asynchronous
operations and preserve protected taint and authority continuity
across restart, migration, or snapshot restoration.
The claimed technical guarantees depend upon the actual observation
coverage, state integrity, event ordering, effectuation-path
controls, and supported revocation semantics.
7.7.185.1. C-42.114 - Technical Summary
this implementation profile discloses a computer-implemented
artificial-intelligence-agent process-lineage control system
comprising an agent execution environment, a trusted runtime
observation component, a protected process-lineage registry, a taint-
state controller, a protected authority-state controller, and one or
more enforcement-capable effectuation interfaces.
Security-relevant information or execution events are associated with
authenticated process instances and execution generations.
The system records selected process creation, executable replacement,
interprocess communication, shared-data access, tool invocation, and
delegated execution relationships.
Applicable taint states are propagated through these relationships
according to defined protected policies.
A taint-state transition may cause a protected authority or
revocation generation to advance and thereby reduce, suspend, revoke,
or require revalidation of previously available operation authority.
A governed Candidate Act remains non-effective until the required
current authorization conditions are satisfied.
Das Expires 25 April 2027 [Page 443]
Internet-Draft Sandbox Credential Egress Finality October 2026
Where protected execution finality is used, validation evidence and a
scoped non-bearer finality capability are associated with the
operation, protected taint state, authority generation, execution
context, and designated Finality Sink.
The Finality Sink verifies the actual pending operation and
applicable current protected state before permitting its designated
consequence.
The system additionally provides protected handling of descendant
inheritance, executable replacement, process-ID reuse, delegated
workers, observation failure, outstanding asynchronous operations,
authorized declassification, and session recovery.
The architecture may be implemented through processes, containers,
virtual machines, cloud services, protected kernels, TEEs, HSMs, or
cooperating hardware and software effectuation controllers.
7.7.185.2. PROTECTED POST-DNS-RESOLUTION ARTIFICIAL-INTELLIGENCE-AGENT
NETWORK-EGRESS FINALITY WITH EFFECTIVE-ENDPOINT
VERIFICATION,
7.7.185.3. DNS REBINDING RESISTANCE, CONNECTION-SCOPED AUTHORITY,
PROXY- ROUTE BINDING, AND NON-BYPASSABLE TRANSMISSION
CONTROL
7.8. Implementation Profile C-45
Source location: original disclosure pages 758-829. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.8.1. C-45.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
security, network access control, protected network egress, domain-
name resolution, destination verification, application-programming-
interface authorization, proxy enforcement, protected credential use,
network connection identity, and execution-finality control.
More particularly, the embodiment discloses a computer-implemented
system in which network operations proposed directly or indirectly by
an artificial-intelligence agent are held in a Non-Effective State,
validated against protected authority and effective-destination
conditions, associated with protected validation evidence and bounded
non-bearer finality authority, and verified by a Finality Sink before
the corresponding governed network transmission becomes effective.
Das Expires 25 April 2027 [Page 444]
Internet-Draft Sandbox Credential Egress Finality October 2026
The embodiment addresses technical circumstances in which a hostname,
service identifier, requested endpoint, effective Internet Protocol
address, transport connection, routing destination, proxy
destination, or application request may differ during the lifetime of
a proposed network operation.
The system may operate with:
(a) network-isolated agent processes; (b) containerized agents; (c)
virtual-machine agents; (d) cloud-hosted autonomous agents; (e)
browser and computer-use agents; (f) API connectors; (g) protected
network proxies; (h) credential brokers; (i) host-side network
workers; (j) secure service gateways; (k) programmable network
devices; (l) SmartNICs or DPUs; (m) kernel or hypervisor network
controls;
(n) protected enforcement domains;
(o) cryptographically isolated enforcement domains; or
(p) combinations thereof.
The implementation is independent of a particular operating system,
DNS resolver, proxy vendor, HTTP library, transport protocol, cloud
provider, or network-device manufacturer.
The selected implementation must provide the actual network
interception, request visibility, endpoint identification, state
protection, and effectuation control required by the applicable
enforcement point.
7.8.2. PART I - TECHNICAL PROBLEM
7.8.3. C-45.2 - Preliminary Destination Authorization Is Insufficient
An AI agent may request transmission to an apparently permitted
network destination.
For example, the agent may request:
An upstream policy controller may inspect the hostname and determine
that it belongs to an authorized service.
However, the actual network operation may later use an endpoint
different from the one anticipated by the preliminary check.
Such differences may arise from:
Das Expires 25 April 2027 [Page 445]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. DNS resolution. 2. DNS cache changes. 3. Repeated hostname
resolution. 4. DNS rebinding. 5. CNAME or alias processing. 6. A/
AAAA address selection. 7. HTTP redirects. 8. Proxy resolution. 9.
Proxy failover. 10. Transport connection reuse. 11. Connection
pooling. 12. Protocol negotiation. 13. HTTP/2 connection
coalescing. 14. QUIC connection migration. 15. Service discovery.
16. Dynamic routing. 17. Alternate network adapters.
18. Direct socket access. 19. Privileged host connectors. 20.
Delegated worker execution.
Accordingly, a determination that a requested hostname is permitted
does not necessarily establish that every later effective endpoint or
transport connection remains within the authorized scope.
7.8.4. C-45.3 - DNS Rebinding Problem
A DNS response associated with a hostname may change between an
authorization check and a subsequent connection attempt.
For example:
Initial resolution:
approved.example → 198.51.100.20
Later resolution:
approved.example → 127.0.0.1
The addresses are illustrative documentation values.
If the network controller authorizes the hostname but permits a later
independent resolution to select a prohibited loopback or internal
address without renewed verification, the agent may obtain a network
route that was not within the protected authorization.
The system therefore distinguishes:
(a) requested hostname; (b) resolved address set; (c) selected
endpoint; (d) actual effective connection target; and (e) permitted
destination scope.
The relevant post-resolution predicate must be evaluated against the
address or endpoint that will actually be used.
Das Expires 25 April 2027 [Page 446]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.5. C-45.4 - Proxy and Connector Transformation Problem
An agent may issue an abstract tool request such as:
SEND_REQUEST(service="approved-service")
A host-side connector may later construct:
POST
The connector may then use a proxy, resolve the destination, choose a
transport endpoint, insert credentials, or transform the request.
A preliminary approval of the abstract tool operation does not
necessarily establish authorization of the concrete network request.
The Finality Sink must obtain or reconstruct the material effective
parameters required by the enforcement point.
7.8.6. C-45.5 - Connection Reuse Problem
A network client may reuse an existing connection for subsequent
operations.
The connection may have been authorized under:
| x | An earlier policy generation. |
| - | ------------------------------- |
| x | A different agent task. |
| x | A different resource scope. |
| x | A different application origin. |
| x | A previous authority lease. |
| x | An earlier session generation. |
A system that checks authorization only when a socket is initially
established may fail to enforce current operation-specific conditions
for later transmissions over the same socket.
The embodiment therefore provides connection-scoped and, where
required, request-scoped authority verification.
7.8.7. C-45.6 - Network Non-Bypassability Problem
An agent may have access to multiple network paths.
For example:
AGENT → CONTROLLED PROXY → INTERNET
Das Expires 25 April 2027 [Page 447]
Internet-Draft Sandbox Credential Egress Finality October 2026
and:
AGENT → DIRECT SOCKET → INTERNET
If only the first path implements protected network finality, the
agent may bypass the intended enforcement through the second.
The claimed network-egress finality therefore requires the actual
governed transmission path to be controlled or a corresponding
enforceable restriction preventing uncontrolled alternate
transmission.
7.8.8. PART II - CENTRAL TECHNICAL PRINCIPLE
7.8.9. C-45.7 - Computation Is Not Network Authority
An agent may compute, construct a URL, perform permitted information
processing, or propose a network request.
These operations do not independently authorize transmission to an
external destination.
The proposed network operation is represented as a Candidate Network
Egress Act.
The operation remains in a Non-Effective State until the required
authorization conditions are satisfied.
A Protected Enforcement Domain (PED) evaluates applicable authority
and destination predicates.
Protected validation evidence is committed.
A scoped non-bearer network-egress capability is established.
The Finality Sink obtains or reconstructs the actual pending network
operation, verifies its effective endpoint and required
authorization, and only then permits the governed transmission.
7.8.10. C-45.8 - Representative Security Relationship
For an operation N, the system may require:
PERMIT_NETWORK_EFFECT(N) =
VALID_CANDIDATE(N)
AND VALID_PROTECTED_AUTHORITY(N)
Das Expires 25 April 2027 [Page 448]
Internet-Draft Sandbox Credential Egress Finality October 2026
AND PERMITTED_EFFECTIVE_DESTINATION(N)
AND PERMITTED_OPERATION_SCOPE(N)
AND VALID_PROTECTED_EVIDENCE(N)
AND VALID_SCOPED_ENABLEMENT(N)
AND CURRENT_AUTHORITY_GENERATION(N)
AND VALID_SINK_LOCAL_STATE(N)
AND CONTROLLED_EGRESS_PATH(N).
The particular predicates are selected according to the enforcement
point and the protected policy.
A valid hostname does not replace a required effective-endpoint
check.
A valid effective IP address does not replace a required operation-
specific credential, method, path, payload, or task-authority check.
7.8.11. PART III - PRINCIPAL SYSTEM COMPONENTS
7.8.12. C-45.9 - Agent Execution Environment
An Agent Execution Environment comprises a computing context in which
one or more artificial-intelligence agents generate proposed network
operations.
The environment may comprise an operating-system process, container,
virtual machine, managed agent runtime, delegated worker, browser
runtime, or associated tool-execution context.
The agent does not have direct modification authority over the
protected network authorization state.
7.8.13. C-45.10 - Network Operation Interceptor
A Network Operation Interceptor captures a proposed governed network
operation before the specified transmission effect.
Possible interception points include:
(a) a controlled API dispatcher; (b) a protected HTTP client
interface; (c) a proxy submission interface;
Das Expires 25 April 2027 [Page 449]
Internet-Draft Sandbox Credential Egress Finality October 2026
(d) a host-side network broker;
(e) a privileged connector;
(f) a kernel-mediated network operation;
(g) a virtual network interface;
(h) a protected device command interface; or
(i) another technically enforceable network boundary.
The interceptor must be positioned so that the designated governed
effect has not already occurred.
7.8.14. C-45.11 - Candidate Network Egress Holder
A Candidate Network Egress Holder maintains the request in a Non-
Effective State.
The holder may use:
1. A protected request buffer. 2. A pending connector operation. 3.
A withheld socket request. 4. A disabled transport send operation.
5. A controlled proxy queue. 6. A protected packet queue. 7. A
staged credential-bearing request. 8. A protected network-device
command descriptor.
The operation remains unable to cause the governed transmission until
the required finality conditions succeed.
7.8.15. C-45.12 - Destination Resolution Controller
A Destination Resolution Controller obtains or verifies effective
endpoint information associated with the proposed operation.
It may process:
(a) requested hostnames; (b) normalized hostnames; (c) canonical
aliases;
(d) DNS answers;
(e) DNSSEC validation status, where used;
(f) service discovery results;
(g) selected IP addresses;
Das Expires 25 April 2027 [Page 450]
Internet-Draft Sandbox Credential Egress Finality October 2026
(h) transport ports;
(i) proxy endpoints;
(j) service identities; or
(k) other endpoint-selection information.
The controller must distinguish resolution data from an actual
established connection.
7.8.16. C-45.13 - Protected Network Authority Registry
A Protected Network Authority Registry maintains the current
authorization governing selected network operations.
A representative record contains:
AuthorityRecordID
AgentContextID
TaskID
PermittedServiceScope
PermittedNetworkZones
PermittedProtocolClasses
PermittedOperations
PermittedDestinationPolicy
PolicyGeneration
RevocationGeneration
ValidityState
The requesting agent cannot independently change the authoritative
contents of this registry.
7.8.17. C-45.14 - Protected Enforcement Domain
The PED evaluates the applicable Candidate Network Egress Act
against:
Das Expires 25 April 2027 [Page 451]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Authenticated requesting context. 2. Task authority. 3.
Requested destination. 4. Effective resolved destination. 5.
Permitted protocol. 6. Operation method or class. 7. Target
resource. 8. Credential scope. 9. Payload or data classification,
where required. 10. Current policy. 11. Revocation state. 12.
Freshness. 13. Network-zone restrictions. 14. Required Finality
Sink identity.
The PED also performs any protected-state operation required by the
selected enforcement point.
7.8.18. C-45.15 - Protected Validation Evidence Controller
The Protected Validation Evidence Controller commits evidence
associating successful validation with the Candidate Network Egress
Act and its authorized scope.
The evidence may be represented by:
(a) an authenticated protected record; (b) a signed receipt; (c) a
protected transaction entry; (d) a CIED-maintained commitment; (e) a
protected state-machine transition; or (f) another suitable machine-
verifiable representation.
7.8.19. C-45.16 - Scoped Network-Egress Capability Controller
The Scoped Network-Egress Capability Controller creates or activates
bounded authority for the validated operation.
The capability may be bound to:
| x | Candidate Act identity. |
| - | ------------------------------------------- |
| x | Authorized operation descriptor. |
| x | Effective destination scope. |
| x | Protected validation evidence. |
| x | Current policy generation. |
| x | Current authority or revocation generation. |
| x | Authorized Finality Sink. |
| x | Connection or request identity. |
| x | Permitted usage count. |
| x | Expiration. |
| x | Protected sink-local state. |
Mere possession of a signed string is not sufficient to establish
non-bearer operation if the string can be copied and used by any
holder.
Das Expires 25 April 2027 [Page 452]
Internet-Draft Sandbox Credential Egress Finality October 2026
A non-bearer implementation therefore employs protected consumption,
authenticated channel binding, protected handle semantics, or another
mechanism preventing unauthorized use based solely on possession.
7.8.20. C-45.17 - Network-Egress Finality Sink
A Network-Egress Finality Sink controls the specified consequential
network transmission.
A representative sink comprises:
(a) a protected network proxy; (b) a network gateway; (c) a
credential-bearing connector gateway; (d) a controlled host network
broker; (e) an enforceable kernel-network component; (f) a SmartNIC
or DPU with suitable inspection and control;
(g) a destination-side service controller for an appropriately
defined effect; or
(h) another enforceable network operation interface.
The sink verifies the actual pending operation before permitting the
governed effect.
Its security enforcement point is limited to the effectuation
boundary it actually controls.
7.8.21. C-45.18 - Connection State Controller
A Connection State Controller maintains protected associations among
network operations, transport connections, effective endpoints,
authorization generations, and allowed request scope.
It may monitor or restrict connection establishment, reuse,
replacement, and permitted migration.
7.8.22. C-45.19 - Alternate Egress Path Controller
An Alternate Egress Path Controller identifies and restricts other
network interfaces or services capable of producing the governed
transmission.
It may coordinate with the path-completeness mechanisms described for
an agent sandbox.
It must not classify an interface as covered merely because the
preferred request route passes through a proxy.
Das Expires 25 April 2027 [Page 453]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.23. PART IV - NETWORK IDENTITY REPRESENTATIONS
7.8.24. C-45.20 - Requested Destination Identity
A Requested Destination Identity identifies the target named or
specified by the requesting agent.
It may comprise:
RequestedScheme
RequestedHostname
RequestedPort
RequestedServiceID
RequestedResourcePath
RequestedProtocol
The system normalizes the representation under a defined parser and
canonicalization policy.
7.8.25. C-45.21 - Hostname Canonicalization
Hostname canonicalization may address:
1. Case normalization. 2. Internationalized domain-name
representation. 3. Trailing-dot handling. 4. Explicit versus
default port representation. 5. Bracketed IPv6 literals. 6. IP-
address literal parsing. 7. Percent-encoding interpretation where
applicable. 8. URL parser consistency. 9. Canonical service
identity. 10. Scheme-specific authority syntax.
The PED and Finality Sink must not rely on inconsistent parsers that
interpret the same textual request as materially different endpoints.
A concrete implementation specifies its canonicalization rules and
rejects ambiguous unsupported representations.
7.8.26. C-45.22 - DNS Answer Representation
A representative DNS result record may comprise:
ResolutionID = DNS-4501
RequestedHostname = approved.example
Das Expires 25 April 2027 [Page 454]
Internet-Draft Sandbox Credential Egress Finality October 2026
CanonicalHostname = approved.example
AddressSet = {198.51.100.20, 2001:db8::20}
ResolverIdentity = RESOLVER-01
ResolutionGeneration = 302
ValidityReference = DNS-CACHE-4501
ResolutionStatus = ACCEPTED
The IP addresses are documentation examples.
The record may also include applicable aliases, address families,
TTL-related information, DNSSEC status, resolver trust properties, or
service discovery metadata.
The policy must not assume that all returned addresses are
necessarily authorized merely because one is permitted.
7.8.27. C-45.23 - Selected Endpoint
A Selected Endpoint means the actual destination candidate chosen for
a particular transport attempt.
A representative endpoint comprises:
AddressFamily
SelectedIPAddress
SelectedPort
TransportProtocol
IntendedServiceIdentity
RouteContext
ResolutionReference
The selected endpoint may be one member of a larger resolution
result.
Das Expires 25 April 2027 [Page 455]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.28. C-45.24 - Effective Transport Endpoint
An Effective Transport Endpoint means the endpoint used by the
transport connection or datagram transmission according to the
selected network architecture.
Where a client connects directly, the effective transport endpoint
may be the selected remote IP address and port.
Where a client connects through a forward proxy, the immediate
transport endpoint may be the proxy itself.
The intended target service must then be represented separately
through an authenticated proxy request or tunnel-control operation.
The system does not conflate the immediate socket peer with the final
application destination.
7.8.29. C-45.25 - Application Service Identity
An Application Service Identity may include:
(a) HTTPS origin; (b) expected DNS hostname;
(c) authenticated server certificate identity;
(d) application service identifier;
(e) API resource scope;
(f) service-mesh identity;
(g) another authenticated service identity.
Application service identity is not identical to IP address.
A service may legitimately use multiple IP addresses.
An IP address may host multiple application services.
The applicable enforcement point may require both endpoint-level and
service-level restrictions.
7.8.30. C-45.26 - Effective Network Operation Descriptor
A representative descriptor comprises:
CandidateActID = CA-4501
Das Expires 25 April 2027 [Page 456]
Internet-Draft Sandbox Credential Egress Finality October 2026
AgentContextID = AGENT-42
TaskID = TASK-204
OperationClass = HTTPS_REQUEST
RequestedHostname = approved.example
RequestedPort = 443
SelectedIPAddress = 198.51.100.20
TransportProtocol = TCP
HTTPMethod = POST
ResourcePath = /v1/resource
PayloadDigest = DIGEST-4501
AuthorityGeneration = 105
ConnectionGeneration = 71
RequiredSinkID = FS-NET-45
CandidateStatus = STAGED
The descriptor may omit fields irrelevant to the selected operation
class.
Material fields are canonically encoded under a specified format.
7.8.31. PART V - DESTINATION POLICY
7.8.32. C-45.27 - Protected Destination Scope
A protected network policy may define permitted destinations by:
1. Named service identity. 2. Hostname. 3. Domain pattern. 4.
Explicit IP address. 5. IP prefix. 6. Network zone. 7. Port. 8.
Protocol. 9. Authenticated service identity. 10. Application
endpoint. 11. A combination of these attributes.
The policy must specify which conditions are mandatory.
For example, a hostname permit rule may additionally require the
selected IP address to be outside restricted network ranges.
Das Expires 25 April 2027 [Page 457]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.33. C-45.28 - Network-Zone Classification
A representative implementation classifies selected effective
endpoints into network zones, including:
PUBLIC_PERMITTED
PUBLIC_RESTRICTED
LOOPBACK
LINK_LOCAL
PRIVATE_NETWORK
ADMINISTRATION_NETWORK
CLOUD_METADATA
LOCAL_SERVICE
UNROUTABLE_OR_SPECIAL_USE
UNKNOWN
The exact classification depends upon the deployment.
Public/private classification alone may be insufficient where an
enterprise has sensitive public-routable infrastructure or permitted
internal services.
The policy therefore supports explicit resource and network-zone
restrictions.
7.8.34. C-45.29 - Destination Allow Rules
A protected rule may require:
ALLOW only if:
(a) the originating task is authorized; (b) the destination service
identity is permitted; (c) the effective selected endpoint is in the
authorized scope; (d) the requested port and protocol are permitted;
(e) the operation class is permitted; (f) the request remains within
allowed resource and payload restrictions; and (g) current protected
authority state is valid.
Das Expires 25 April 2027 [Page 458]
Internet-Draft Sandbox Credential Egress Finality October 2026
Failure of a required condition causes the operation to remain non-
effective.
7.8.35. C-45.30 - Address-Set Versus Selected-Address Policy
A hostname may resolve to multiple addresses.
A selected policy may require:
Option A: Every returned address must be permitted.
Option B: The controller may select only an individually permitted
address.
Option C: The controller requires a specified service identity plus a
permitted address or
route property.
The selected algorithm is defined by policy.
An implementation using Option B must prevent the transport library
from later selecting an unchecked address.
For dual-stack connection attempts, each address actually attempted
must satisfy the applicable effective-endpoint policy.
7.8.36. PART VI - PROTECTED DNS RESOLUTION
7.8.37. C-45.31 - Controlled Resolution
In one implementation, the agent cannot perform an unrestricted
independent DNS lookup and then use the result through an
uncontrolled network interface.
The protected resolution controller performs or obtains the
resolution associated with the Candidate Act.
The controller records a protected reference to the resolution
result.
The selected endpoint is evaluated before the corresponding transport
connection is authorized.
7.8.38. C-45.32 - DNS Rebinding Protection
A representative DNS rebinding protection procedure comprises:
Das Expires 25 April 2027 [Page 459]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Capture the original requested hostname. 2. Obtain a resolution
result. 3. Identify the selected effective IP address. 4. Verify
the address against current protected policy. 5. Bind the
authorization to the selected endpoint or permitted endpoint set. 6.
Prevent an unvalidated independent re-resolution from changing the
effective endpoint. 7. Revalidate a newly selected address when
required. 8. Verify the actual pending connection or transmission
against the binding.
The system does not rely solely on a previous hostname permit
decision.
7.8.39. C-45.33 - DNS Cache State
A cached resolution result may be used only according to the
applicable freshness and destination-binding requirements.
A representative cache record includes:
Hostname
ResolvedAddresses
ResolutionGeneration
ResolverIdentity
ValidityReference
PolicyGeneration
CacheStatus
A valid cached DNS record is not an unrestricted network
authorization.
The Finality Sink still verifies the required current operation and
endpoint conditions.
7.8.40. C-45.34 - Resolver Trust Boundary
DNS information may be obtained from:
(a) a local resolver; (b) a protected resolver service; (c) an
enterprise resolver; (d) a service-discovery system; (e) a controlled
proxy; or (f) a destination-routing component.
The implementation must identify the resolver's trust assumptions.
Das Expires 25 April 2027 [Page 460]
Internet-Draft Sandbox Credential Egress Finality October 2026
DNSSEC validation, where used, may authenticate covered DNS data
according to its protocol semantics, but does not independently prove
that the resulting destination is authorized for the requesting
agent.
The protected policy separately evaluates authorization.
7.8.41. PART VII - CONNECT AND TRANSPORT BINDING
7.8.42. C-45.35 - Connection Establishment
A controlled connection-establishment procedure may include:
1. Authenticated originating execution context. 2. Canonical
requested destination. 3. Selected effective endpoint. 4. Current
network authority generation. 5. Protected validation reference. 6.
Scoped finality authorization. 7. Actual transport connection. 8.
Protected connection-generation identity.
The system must ensure that the connection attempt corresponds to the
authorized endpoint.
7.8.43. C-45.36 - Connection Generation
A Connection Generation distinguishes successive uses or incarnations
of a network connection or connection-control object.
A representative record comprises:
ConnectionID = CONN-4501
ConnectionGeneration = 71
AgentContextID = AGENT-42
SelectedIPAddress = 198.51.100.20
SelectedPort = 443
TransportProtocol = TCP
AuthorityGeneration = 105
PermittedServiceIdentity = approved.example
ConnectionStatus = ESTABLISHED
Das Expires 25 April 2027 [Page 461]
Internet-Draft Sandbox Credential Egress Finality October 2026
A recycled file descriptor or socket identifier does not
automatically inherit a stale authorization.
7.8.44. C-45.37 - Socket Peer Verification
Where the operating system provides a reliable mechanism to obtain
the connected remote peer, the Finality Sink may compare the actual
socket peer with the previously validated endpoint.
The implementation must distinguish:
(a) the requested hostname; (b) the address supplied to a connect
operation; (c) the address that is actually connected; (d) the proxy
peer, where applicable; and (e) the final application service
destination.
A protected socket-peer check is one implementable verification step.
It is not universally sufficient for higher-layer service
authorization.
7.8.45. C-45.38 - Connection Binding
A protected connection binding may associate:
CandidateActID
ConnectionID
ConnectionGeneration
SelectedEndpoint
PermittedServiceIdentity
PolicyGeneration
AuthorityGeneration
AuthorizedRequestScope
SinkID
The binding may be maintained in protected connection state.
A request presented on a reused connection must satisfy the currently
applicable scope rather than inheriting unconditional authorization
from the connection's initial establishment.
Das Expires 25 April 2027 [Page 462]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.46. PART VIII - TLS AND AUTHENTICATED SERVICE IDENTITY
7.8.47. C-45.39 - TLS Identity
For an HTTPS operation, the system may consider:
1. Requested HTTPS origin. 2. TLS server-name indication, where
applicable. 3. Authenticated certificate identity. 4. Actual
transport endpoint. 5. HTTP authority or Host field. 6. Permitted
application request target.
These identities serve different functions.
For example, TLS SNI alone is not proof that the server possesses the
expected authenticated identity.
The relevant protected policy may require successful server-
certificate verification or another authenticated service-identity
mechanism.
7.8.48. C-45.40 - Encrypted Payload Visibility
A network device may observe the destination IP address, transport
port, and selected connection metadata while being unable to inspect
the encrypted HTTP method, path, or body.
Where authorization requires application-layer fields, the
implementation must place the corresponding verification at a
component with trusted access to those fields or use an appropriately
authenticated operation representation.
A SmartNIC that cannot inspect encrypted request content cannot
automatically be described as verifying the actual application
payload.
7.8.49. C-45.41 - TLS-Terminating Finality Sink
In one implementation, a trusted network proxy terminates or
originates the TLS connection.
The proxy may obtain the actual application request before
transmission.
It verifies:
(a) permitted service identity;
(b) effective endpoint;
Das Expires 25 April 2027 [Page 463]
Internet-Draft Sandbox Credential Egress Finality October 2026
(c) actual request method;
(d) actual resource path;
(e) required content or payload binding;
(f) current authorization; and
(g) protected capability state.
The proxy constructs or transmits the authorized request only after
required verification succeeds.
This arrangement must preserve applicable confidentiality and
service-authentication properties.
7.8.50. C-45.42 - End-to-End TLS Variation
In another implementation, an agent or protected connector maintains
end-to-end TLS to the destination service.
A protected pre-encryption controller verifies the actual application
request.
A protected transport controller verifies the permitted endpoint or
connection.
The system associates the two verification results through a
protected request or connection identity.
The implementation must prevent an untrusted component from modifying
the request after application-level verification or redirecting it to
a different unverified connection.
7.8.51. PART IX - REDIRECTS AND CONNECTION CHANGES
7.8.52. C-45.43 - HTTP Redirect
An HTTP server may return a redirect to another origin or resource.
A redirect may change:
1. 2. 3. 4. 5.
Scheme. Hostname. Port. Effective IP address. HTTP method, under
applicable protocol rules.
Das Expires 25 April 2027 [Page 464]
Internet-Draft Sandbox Credential Egress Finality October 2026
6. Resource path. 7. Credential-disclosure conditions. 8.
Application security context.
The system evaluates the redirect according to the applicable
protected authorization.
7.8.53. C-45.44 - Redirect Revalidation
A representative controlled redirect procedure:
1. Receive the redirect response. 2. Parse the proposed destination
using the approved canonicalization procedure. 3. Determine whether
the new destination is within the current authorization. 4. Perform
required destination resolution. 5. Evaluate the selected endpoint.
6. Validate required service identity and credential rules. 7.
Establish a new connection or request binding. 8. Apply current
Finality Sink verification before transmitting the redirected
request.
An authorization for one origin does not automatically authorize
arbitrary cross-origin
redirects.
7.8.54. C-45.45 - Redirect Loop and Resource Limits
A protected redirect controller may maintain:
RedirectCount
VisitedOriginSet
CurrentAuthorityGeneration
CurrentConnectionBinding
CurrentCandidateActReference
A redirect chain exceeding the configured bound, containing a
prohibited destination, or producing an unsupported transformation is
rejected or subjected to fresh authorization.
7.8.55. C-45.46 - HTTP/2 Connection Coalescing
Where an HTTP/2 client uses one connection for requests associated
with multiple origins, the system distinguishes authorization of the
physical transport connection from authorization of each application
request.
Das Expires 25 April 2027 [Page 465]
Internet-Draft Sandbox Credential Egress Finality October 2026
A permitted TLS connection to one server does not itself authorize
every origin that a client may address over that connection.
For the selected policy, the Finality Sink verifies the effective
request authority or service identity and relevant operation
parameters.
7.8.56. C-45.47 - HTTP/3 and QUIC Migration
A QUIC connection may change network paths or remote transport
addresses under supported protocol behavior.
Where the applicable enforcement point requires effective-endpoint
restrictions, the system identifies migration or path-change events
relevant to the governed network effect.
A new effective endpoint is checked against the current permitted
destination scope before further governed transmission through that
path.
Where the selected enforcement device cannot observe or control
required connectionmigration semantics, the implementation must use a
suitable cooperating endpoint, transport library, proxy, or
controller.
7.8.57. C-45.48 - Reused HTTP Connection
A client may send multiple HTTP requests over one connection.
Each governed request remains subject to its applicable operation-
specific authorization.
The system may use a bounded multi-request capability, provided that:
(a) the authorized operation class is defined; (b) the permissible
service and resource scope are bounded; (c) current required
authority remains valid; (d) protected usage limits are enforced; and
(e) the Finality Sink verifies each actual request within the grant.
An earlier connection permit is not unlimited request authority.
7.8.58. PART X - PROXY AND ROUTING SEMANTICS
7.8.59. C-45.49 - Forward Proxy
In a forward-proxy arrangement, the agent may connect only to an
authorized proxy address.
Das Expires 25 April 2027 [Page 466]
Internet-Draft Sandbox Credential Egress Finality October 2026
The immediate transport peer is the proxy.
The eventual service destination may be selected through an HTTP
request, CONNECT operation, or another proxy protocol.
The protected policy must distinguish these two destinations.
A rule permitting connection to the proxy does not automatically
authorize every external service reachable through the proxy.
7.8.60. C-45.50 - CONNECT Tunnel
A controlled CONNECT tunnel may identify:
RequestedTargetHostname
RequestedTargetPort
ResolvedTargetEndpoint
ProxyIdentity
AuthorizedTunnelScope
AuthorityGeneration
FinalitySinkID
The proxy verifies the permitted target according to its enforcement
capabilities.
If the proxy cannot inspect the encrypted application request inside
the tunnel, it may enforce tunnel-destination finality but cannot
enforcement point full application-request verification solely from
CONNECT metadata.
7.8.61. C-45.51 - Transparent Proxy
A transparent proxy or interception gateway may control selected
network operations without explicit application proxy configuration.
The implementation determines the actual original or effective
destination through reliable network or system metadata.
It verifies that the traffic being released corresponds to the
authorized operation.
Das Expires 25 April 2027 [Page 467]
Internet-Draft Sandbox Credential Egress Finality October 2026
The proxy must account for address translation or interception
semantics relevant to the actual connection.
7.8.62. C-45.52 - Remote DNS Resolution Through Proxy
A proxy may resolve the destination hostname remotely.
In such an arrangement, the agent's local resolver may not know the
selected effective endpoint.
The protected policy may require the proxy, rather than the agent-
side interface, to perform the post-resolution address check.
The resulting authorization must be enforced before the proxy
establishes or uses the governed destination connection.
A local hostname approval alone does not satisfy a required remote
effective-endpoint verification.
7.8.63. C-45.53 - Network Address Translation
Network address translation may modify packet addresses or ports
along a route.
The implementation identifies the network identity that matters to
its protected authorization.
Where a enforcement point concerns the actual destination service,
the relevant controller must preserve or authenticate the
relationship between the original request and the translated or
effective destination.
Ordinary NAT rewriting is not assumed to be malicious.
The security condition concerns whether the effective endpoint
remains within the authorized scope.
7.8.64. C-45.54 - Service Mesh
A service mesh may route requests through sidecars, gateways, or
service proxies.
The system may associate authorization with:
(a) workload identity; (b) service identity;
(c) authenticated upstream and downstream endpoints;
Das Expires 25 April 2027 [Page 468]
Internet-Draft Sandbox Credential Egress Finality October 2026
(d) routing policy;
(e) operation scope;
(f) current authority generation; and
(g) required Finality Sink.
The existence of service-mesh authentication does not independently
establish the taskspecific authority of the requesting AI agent.
7.8.65. PART XI - NETWORK CREDENTIAL USE
7.8.66. C-45.55 - Credential-Bearing Request
A network request may require a protected API key, access token,
client certificate, signed request, or other authority-bearing
credential.
A credential broker may retain the real credential outside the agent
environment.
The broker or protected connector performs credential application
only after the applicable Candidate Act has satisfied protected
finality.
7.8.67. C-45.56 - Credential-to-Endpoint Binding
A credential-use authorization may specify:
1. Authorized service. 2. Authorized target resource. 3. Permitted
request method. 4. Permitted payload scope. 5. Authorized
credential class. 6. Effective network destination requirements. 7.
Current policy and revocation generation. 8. Required sink identity.
This prevents a protected credential from being applied to a
materially different network request simply because the original
agent request was approved.
7.8.68. C-45.57 - Credential Substitution Ordering
A representative protected operation follows:
CANDIDATE REQUEST STAGED
↓
REQUEST AND DESTINATION VALIDATED
Das Expires 25 April 2027 [Page 469]
Internet-Draft Sandbox Credential Egress Finality October 2026
↓
PROTECTED EVIDENCE COMMITTED
↓
SCOPED CAPABILITY ACTIVATED
↓
ACTUAL EFFECTIVE REQUEST RECONSTRUCTED
↓
CURRENT ENDPOINT AND AUTHORITY VERIFIED
↓
PROTECTED CREDENTIAL APPLIED
↓
CONTROLLED TRANSMISSION.
In some implementations, the credential may be inserted into a
protected request buffer before the final network authorization
check, provided that the resulting request remains noneffective and
the agent cannot obtain the reusable credential.
The required invariant is that unauthorized credential application or
external transmission does not occur.
7.8.69. PART XII - PROTECTED VALIDATION AND FINALITY
7.8.70. C-45.58 - Candidate Network Egress Act
A Candidate Network Egress Act represents the proposed governed
network operation.
A representative record comprises:
CandidateActID
AgentContextID
TaskID
RequestedDestination
Das Expires 25 April 2027 [Page 470]
Internet-Draft Sandbox Credential Egress Finality October 2026
SelectedEndpoint
EffectiveOperationDescriptor
ProtectedAuthorityReference
ResolutionReference
ConnectionReference
RequiredFinalitySink
CandidateStatus
The Candidate Act remains non-effective until required authorization
succeeds.
7.8.71. C-45.59 - PED Authorization
The PED obtains the Candidate Act and current protected authority.
It verifies the required destination, operation, task, protocol,
credential, freshness, policy, and revocation predicates.
Where the selected policy requires post-resolution verification, the
PED validates the effective selected destination or an enforceable
bounded endpoint set.
The PED performs the applicable protected-state operation.
7.8.72. C-45.60 - Protected Validation Evidence
A representative evidence record comprises:
EvidenceID = VE-4501
CandidateActID = CA-4501
CanonicalOperationDigest = DIGEST-4501
ResolutionReference = DNS-4501
AuthorizedEndpointScope = ENDPOINT-SCOPE-A
AuthorityGeneration = 105
PolicyGeneration = 105
Das Expires 25 April 2027 [Page 471]
Internet-Draft Sandbox Credential Egress Finality October 2026
ValidationResult = APPROVED
RequiredSinkID = FS-NET-45
ProtectedCommitment = COMMIT-4501
The values are illustrative.
The evidence is integrity-protected against unauthorized
modification.
7.8.73. C-45.61 - Scoped Non-Bearer Network Capability
A representative capability comprises:
CapabilityID = CAP-4501
CandidateActID = CA-4501
EvidenceReference = VE-4501
OperationDescriptorDigest = DIGEST-4501
AuthorizedEndpointScope = ENDPOINT-SCOPE-A
ConnectionBinding = CONN-4501
AuthorityGeneration = 105
AuthorizedSinkID = FS-NET-45
UsagePolicy = SINGLE_USE
CapabilityStatus = ACTIVE
The Finality Sink verifies the required operation and protected usage
conditions.
The capability does not authorize arbitrary requests to unrelated
endpoints.
7.8.74. C-45.62 - Finality Sink Effective-Endpoint Verification
Before the governed effect, the Finality Sink obtains or
reconstructs:
(a) effective destination endpoint; (b) actual protocol; (c) actual
request method or operation class, where relevant;
Das Expires 25 April 2027 [Page 472]
Internet-Draft Sandbox Credential Egress Finality October 2026
(d) service identity;
(e) resource path or target;
(f) material payload or protected digest;
(g) connection or transport identity;
(h) current authority generation; and
(i) applicable sink-local state.
The sink verifies correspondence with the protected validation
evidence and scoped authorization.
An effective destination outside the approved scope causes
withholding or renewed authorization.
7.8.75. C-45.63 - Finality Sink Consumption
For a single-use operation, the sink may transition:
UNUSED → RESERVED → CONSUMED
The protected transition may use a transactional registry, protected
register, or suitable atomic state mechanism.
If the network operation is dispatched but its external completion is
unknown, the system retains an appropriate indeterminate or
reconciliation state.
The system must not equate local authorization consumption with
verified remote application completion.
7.8.76. PART XIII - ALTERNATE EGRESS PATHS
7.8.77. C-45.64 - Egress Path Registry
A representative egress path registry includes:
PathID
OriginatingExecutionContext
EffectClass
NetworkInterfaceID
Das Expires 25 April 2027 [Page 473]
Internet-Draft Sandbox Credential Egress Finality October 2026
ProxyOrConnectorReference
TransportCapability
RequiredFinalitySinkID
EnabledState
CoverageGeneration
VerificationStatus
The registry supports determination of whether the agent can produce
a governed transmission through another interface.
7.8.78. C-45.65 - Direct Socket Restriction
An agent may attempt to bypass a protected proxy through an ordinary
socket interface.
The system must restrict or mediate that interface where it can
produce the claimed governed network effect.
Possible implementations include:
1. Network namespace restrictions. 2. Kernel network-access
controls. 3. Hypervisor network mediation. 4. Host networking
policy. 5. Protected service routing. 6. Hardware-controlled
network transmission. 7. Removal of direct socket authority. 8.
Another technically enforceable mechanism.
7.8.79. C-45.66 - Existing Connection Restriction
An agent may retain an already established socket.
A newly imposed restriction on connection establishment does not
automatically prevent further sends over that socket.
The network Finality Sink therefore controls the relevant send,
request, or transmission effectuation boundary.
Where the deployment enforcement points revocation of outstanding
network effects, it must address already established and queued
operations.
Das Expires 25 April 2027 [Page 474]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.80. C-45.67 - Alternate Proxy and Failover
A network failover controller may replace one proxy with another.
The replacement interface must satisfy current protected
authorization and coverage requirements.
A grant issued for the original Finality Sink cannot automatically be
applied to a replacement with different enforcement properties.
7.8.81. PART XIV - NETWORK OPERATION STATE MACHINE
7.8.82. C-45.68 - Principal Operation States
A representative network operation may have the following states:
CREATED
STAGED
RESOLVING
RESOLVED
ENDPOINT_SELECTED
VALIDATING
AUTHORIZED
CONNECTION_PENDING
CONNECTED
READY_FOR_SEND
RESERVED
TRANSMITTED
COMPLETED
DENIED
REVALIDATION_REQUIRED
INDETERMINATE
Das Expires 25 April 2027 [Page 475]
Internet-Draft Sandbox Credential Egress Finality October 2026
The selected implementation defines which transitions may occur
before protected validation.
7.8.83. C-45.69 - Connection Versus Request Finality
Connection authorization and request authorization are distinct where
the policy requires both.
A permitted connection may carry multiple requests.
Each request may have different:
| x | Method. |
| - | ------------------------- |
| x | Resource path. |
| x | Payload. |
| x | Credential scope. |
| x | Authorization generation. |
| x | Recipient semantics. |
The Finality Sink verifies the relevant level of authority before the
designated effect.
7.8.84. C-45.70 - Authorization State Following Endpoint Change
If the selected effective endpoint changes materially, the system
may:
1. Withhold transmission. 2. Invalidate the current Candidate Act
capability. 3. Create a new endpoint-binding record. 4. Reevaluate
protected destination predicates. 5. Commit new protected evidence.
6. Establish a new bounded authorization. 7. Verify the updated
actual operation at the sink.
The operation does not inherit unrestricted endpoint authority from
the earlier resolution.
7.8.85. PART XV - COMPLETE PRINCIPAL EXECUTION WORKFLOW
7.8.86. C-45.71 - Principal 36-Step Workflow
7.8.87. Step C45-01 - Agent execution context registration
The system establishes the authenticated agent and task identity.
Das Expires 25 April 2027 [Page 476]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.88. Step C45-02 - Network authority initialization
The protected network policy and current generations are obtained.
7.8.89. Step C45-03 - Egress path restriction
Relevant uncontrolled alternate transmission interfaces are disabled
or governed.
7.8.90. Step C45-04 - Agent request creation
The agent proposes a network operation.
7.8.91. Step C45-05 - Request interception
A controlled interface captures the proposed operation.
7.8.92. Step C45-06 - Candidate Act creation
The operation receives a unique Candidate Act identity.
7.8.93. Step C45-07 - Non-effective staging
The governed transmission remains withheld.
7.8.94. Step C45-08 - Requested destination parsing
The system obtains the requested hostname, service, scheme, and port.
7.8.95. Step C45-09 - Canonicalization
The destination representation is normalized under the selected
parser policy.
7.8.96. Step C45-10 - Preliminary authority classification
The system determines the applicable protected destination and
operation restrictions.
7.8.97. Step C45-11 - Controlled destination resolution
The selected resolver obtains effective address or service
information.
7.8.98. Step C45-12 - Resolution result recording
The returned destination information is associated with a protected
resolution reference.
Das Expires 25 April 2027 [Page 477]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.99. Step C45-13 - Endpoint selection
An actual candidate endpoint is selected for the transport attempt.
7.8.100. Step C45-14 - Network-zone classification
The selected endpoint is classified according to current protected
network policy.
7.8.101. Step C45-15 - Post-resolution destination validation
The endpoint is checked against the permitted scope.
7.8.102. Step C45-16 - Effective operation descriptor construction
The system constructs the canonical Candidate Act descriptor.
7.8.103. Step C45-17 - PED submission
The Candidate Act and relevant resolution information are submitted
for protected validation.
7.8.104. Step C45-18 - Protected authority-state retrieval
The PED obtains task, destination, protocol, credential, policy, and
revocation state.
7.8.105. Step C45-19 - Authority predicate evaluation
The required protected predicates are evaluated.
7.8.106. Step C45-20 - Protected authorization-state operation
The required protected reservation, sequence, quota, or generation
operation is performed.
7.8.107. Step C45-21 - Validation evidence commitment
The corresponding protected validation evidence is committed.
7.8.108. Step C45-22 - Scoped capability activation
A bounded network-egress capability is established.
7.8.109. Step C45-23 - Connection selection
The controlled transport service identifies a permitted connection or
creates a new connection attempt.
Das Expires 25 April 2027 [Page 478]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.110. Step C45-24 - Actual endpoint verification
The effective transport endpoint and relevant service identity are
verified.
7.8.111. Step C45-25 - Transformation validation
Any connector, proxy, redirect, or request transformation is checked
against the authorized scope.
7.8.112. Step C45-26 - Actual pending request reconstruction
The Finality Sink obtains the material request parameters that will
be transmitted.
7.8.113. Step C45-27 - Evidence verification
The sink verifies the required protected validation evidence.
7.8.114. Step C45-28 - Capability verification
The sink verifies scoped finality authority and sink-local protected
state.
7.8.115. Step C45-29 - Current destination verification
The sink confirms that the effective endpoint remains within the
permitted scope.
7.8.116. Step C45-30 - Current authority verification
The sink checks the applicable authority generation, policy,
freshness, and revocation state.
7.8.117. Step C45-31 - Protected consumption reservation
The relevant single-use or bounded operation permission is reserved.
7.8.118. Step C45-32 - Credential application
Where required, the protected credential is applied through the
controlled path.
7.8.119. Step C45-33 - Governed transmission
The network operation is transmitted through the controlled
effectuation interface.
Das Expires 25 April 2027 [Page 479]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.120. Step C45-34 - Completion observation
The available transport or application acknowledgment is obtained.
7.8.121. Step C45-35 - Protected outcome reconciliation
Consumption, dispatch, and completion state are updated or marked
indeterminate.
7.8.122. Step C45-36 - Connection and authorization maintenance
Connection reuse, redirects, failover, revocation, and later requests
remain subject to current protected authorization.
7.8.123. PART XVI - REFERENCE ALGORITHMS
C-45.72 - Algorithm A: Canonical Network Request Capture function
CaptureCandidateNetworkOperation(request, context):
origin = AuthenticateExecutionContext(context)
if origin is invalid:
return DENIED
stable_request = CaptureControlledRequestSnapshot(request)
parsed = ParseUnderApprovedNetworkGrammar(stable_request)
if parsed is ambiguous or unsupported:
return DENIED
normalized = Canonicalize({
scheme: parsed.scheme, hostname: parsed.hostname, port: parsed.port,
operation_class: parsed.operation_class, method: parsed.method,
resource_path: parsed.resource_path, payload_digest:
HashRequiredPayloadFields(stable_request) })
candidate_id = AllocateCandidateActID()
ProtectedNetworkRegistry.stage({
candidate_id: candidate_id, agent_context: origin, canonical_request:
normalized, authority_generation: CurrentAuthorityGeneration(origin),
candidate_status: STAGED })
Das Expires 25 April 2027 [Page 480]
Internet-Draft Sandbox Credential Egress Finality October 2026
return candidate_id
The staged request must remain non-effective until the required
protected conditions succeed.
7.8.124. C-45.73 - Algorithm B: Controlled DNS Resolution
function ResolveCandidateDestination(candidate_id):
candidate = ProtectedNetworkRegistry.get(candidate_id)
if candidate.status != STAGED:
return DENIED
hostname = candidate.canonical_request.hostname
resolution = TrustedResolutionInterface.resolve(hostname)
if resolution is unavailable:
return DENIED
addresses = CanonicalizeAndValidateAddresses(
resolution.answers )
if addresses is empty:
return DENIED selected = SelectEndpointUnderPolicy(
addresses, candidate.canonical_request.port,
CurrentProtectedNetworkPolicy() )
if selected is invalid:
return DENIED record = ProtectedResolutionRegistry.commit({
candidate_id: candidate_id, requested_hostname: hostname,
address_set: addresses, selected_endpoint: selected,
resolver_reference: resolution.resolver_id, resolution_generation:
AllocateResolutionGeneration() })
return record
The selected endpoint must subsequently remain bound to the
connection attempt or be revalidated if another endpoint is chosen.
Das Expires 25 April 2027 [Page 481]
Internet-Draft Sandbox Credential Egress Finality October 2026
C-45.74 - Algorithm C: Protected Endpoint Classification
function ValidateEffectiveEndpoint(
selected_endpoint, requested_service, authority ):
if not IsValidEndpointRepresentation(selected_endpoint):
return DENIED zone = ClassifyNetworkZone(
selected_endpoint.ip_address )
if zone in authority.prohibited_network_zones:
return DENIED
if not VerifyPermittedEndpointScope(
selected_endpoint, authority ):
return DENIED
if not VerifyPermittedTransport(
selected_endpoint.protocol, selected_endpoint.port, authority ):
return DENIED if not VerifyRequestedServiceRelationship(
requested_service, selected_endpoint, authority ):
return DENIED
return ENDPOINT_PERMITTED
The address and service relationship may involve authenticated
transport or application identity where required.
7.8.125. C-45.75 - Algorithm D: PED Network Authorization
function AuthorizeNetworkCandidate(candidate_id):
candidate = ProtectedNetworkRegistry.get(candidate_id)
if candidate.status != STAGED:
return DENIED
resolution = ProtectedResolutionRegistry.get(
Das Expires 25 April 2027 [Page 482]
Internet-Draft Sandbox Credential Egress Finality October 2026
candidate.resolution_reference )
if not VerifyProtectedResolutionRecord(resolution):
return DENIED authority =
ProtectedAuthorityRegistry.lookup(candidate)
if not VerifyCurrentAuthorityGeneration(authority):
return DENIED
if not EvaluateRequiredNetworkAuthorityPredicates(
candidate, resolution, authority ):
CommitProtectedDenial(candidate_id) return DENIED
descriptor = BuildCanonicalEffectiveOperationDescriptor(
candidate, resolution )
evidence = CommitProtectedValidationEvidence({
candidate_id: candidate_id, descriptor_digest:
HashCanonical(descriptor), resolution_reference: resolution.id,
endpoint_scope: descriptor.permitted_endpoint_scope,
authority_generation: authority.generation, validation_result:
APPROVED })
capability = CreateScopedNonBearerNetworkCapability({
candidate_id: candidate_id, evidence_reference: evidence.id,
descriptor_digest: HashCanonical(descriptor), endpoint_scope:
descriptor.permitted_endpoint_scope, required_sink:
descriptor.required_sink, authority_generation: authority.generation,
usage_policy: SINGLE_USE })
if not AtomicallyActivateProtectedAuthorization(
candidate_id, evidence, capability ):
return DENIED
return AUTHORIZED
The required state operation and protected evidence ordering must
satisfy the applicable enforcement point.
Das Expires 25 April 2027 [Page 483]
Internet-Draft Sandbox Credential Egress Finality October 2026
C-45.76 - Algorithm E: Connection Establishment and Endpoint Binding
function EstablishBoundNetworkConnection(candidate_id):
candidate = ProtectedNetworkRegistry.get(candidate_id)
if candidate.status != AUTHORIZED:
return DENIED
resolution = ProtectedResolutionRegistry.get(
candidate.resolution_reference )
endpoint = resolution.selected_endpoint
if not ValidateEndpointAgainstCurrentPolicy(endpoint):
return DENIED connection =
ControlledTransport.connectToExactEndpoint(
endpoint )
if connection failed:
return DENIED actual_peer = ControlledTransport.getVerifiedPeer(
connection )
if not VerifyActualPeerMatchesAuthorizedEndpoint(
actual_peer, endpoint ):
ControlledTransport.close(connection) return DENIED
connection_binding = ProtectedConnectionRegistry.commit({
candidate_id: candidate_id, connection_id: connection.id,
connection_generation: AllocateConnectionGeneration(), actual_peer:
actual_peer, authorized_endpoint: endpoint, authority_generation:
CurrentAuthorityGeneration(candidate) })
return connection_binding
For proxied or tunneled connections, the controller must separately
bind the proxy peer and intended target service according to the
actual routing architecture.
C-45.77 - Algorithm F: Protected Redirect Processing
Das Expires 25 April 2027 [Page 484]
Internet-Draft Sandbox Credential Egress Finality October 2026
function ProcessNetworkRedirect(
candidate_id, redirect_response ):
current = ProtectedNetworkRegistry.get(candidate_id)
redirect_target = ParseApprovedRedirectGrammar(
redirect_response )
if redirect_target is invalid:
return DENIED
if ExceedsConfiguredRedirectLimit(candidate_id):
return DENIED
next_request = ConstructRedirectedRequest(
current, redirect_target )
if not VerifyRedirectTransformationPolicy(
current, next_request ):
return DENIED if not IsWithinExistingAuthorizationEnvelope(
next_request, current ):
MarkCandidateRevalidationRequired(candidate_id) return
NEW_PROTECTED_VALIDATION_REQUIRED next_resolution =
ResolveAndValidateNewEndpoint(
next_request )
if next_resolution is invalid:
return DENIED
return BindRedirectToPermittedEndpoint(
candidate_id, next_request, next_resolution )
Cross-origin redirects and method or credential changes must satisfy
the relevant protected policy.
C-45.78 - Algorithm G: Finality Sink Network Verification
Das Expires 25 April 2027 [Page 485]
Internet-Draft Sandbox Credential Egress Finality October 2026
function EffectuateProtectedNetworkOperation(candidate_id):
candidate = ProtectedNetworkRegistry.get(candidate_id)
if candidate.status != AUTHORIZED:
return DENIED
actual_request = ObtainActualPendingNetworkRequest(
candidate_id )
actual_endpoint = DetermineEffectiveTransmissionEndpoint(
actual_request )
evidence = ProtectedEvidenceRegistry.get(
candidate.evidence_id )
capability = ProtectedCapabilityRegistry.get(
candidate.capability_id )
if not VerifyProtectedValidationEvidence(evidence):
return DENIED
if not VerifyCapabilityEvidenceBinding(
capability, evidence ):
return DENIED
if not VerifyActualRequestCorrespondence(
actual_request, capability ):
return DENIED
if not VerifyEffectiveEndpointBinding(
actual_endpoint, capability ):
return DENIED if not VerifyCurrentNetworkAuthority(capability):
return DENIED
Das Expires 25 April 2027 [Page 486]
Internet-Draft Sandbox Credential Egress Finality October 2026
if not VerifySinkLocalProtectedUsageState(capability):
return DENIED
if not AtomicallyReserveFinalityCapability(capability):
return DENIED
result = TransmitThroughControlledNetworkBoundary(
actual_request )
ReconcileNetworkOperationOutcome(
candidate_id, result )
return result
The final transmission interface must not allow an untrusted
component to replace the already verified effective operation or
endpoint.
C-45.79 - Algorithm H: Connection Reuse Authorization
function AuthorizeRequestOnExistingConnection(
request, connection ):
binding = ProtectedConnectionRegistry.get(connection.id)
if not VerifyCurrentConnectionGeneration(binding):
return DENIED if not VerifyActualConnectionPeer(connection, binding):
return DENIED
candidate = CreateOrResolveCandidateAct(request)
if not VerifyRequestServiceIdentity(
request, connection, binding ):
return DENIED
if not VerifyCurrentRequestAuthority(
candidate, binding ):
Das Expires 25 April 2027 [Page 487]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED
if not VerifyApplicationRequestScope(
request, candidate ):
return DENIED
return PROCEED_TO_FINALITY_SINK_VERIFICATION
Reusing the transport connection does not bypass request-level
authorization.
C-45.80 - Algorithm I: Alternate Egress Path Verification
function VerifyNetworkEgressCoverage(agent_context):
registry = ProtectedEgressPathRegistry.get(agent_context)
if not VerifyRegistryIntegrityAndGeneration(registry):
return UNCOVERED
paths = ResolveEnabledNetworkEffectuationPaths(
agent_context, registry )
if RequiredPathDiscoveryIncomplete(paths):
return UNCOVERED
for each path in paths:
if VerifyApplicableNetworkFinalitySink(path):
continue
if VerifyMandatoryParentSink(path):
continue
if VerifyTechnicalDisablement(path):
continue
return UNCOVERED
return COVERED
Das Expires 25 April 2027 [Page 488]
Internet-Draft Sandbox Credential Egress Finality October 2026
An unknown or newly enabled relevant route does not count as covered
solely because a preferred proxy remains available.
C-45.81 - Algorithm J: Authority Revocation on Existing Connections
function RevokeNetworkAuthority(context, restriction):
generation = AdvanceProtectedRevocationGeneration(
context )
connections = ResolveAffectedConnections(
context, restriction )
for each connection in connections:
MarkConnectionAuthorityRestricted(
connection, generation )
BlockNewGovernedRequests(
connection, restriction )
pending = ResolvePendingNetworkOperations(context)
for each operation in pending:
if OperationHasNotCrossedFinalityBoundary(operation):
InvalidateOrRevalidate(operation, generation) else:
ApplyOutcomeReconciliation(operation)
return EvaluateRequiredEgressRestrictionConvergence(
context, generation )
The system distinguishes restriction of future requests from effects
already transmitted.
7.8.126. C-45.82 - Algorithm K: Proxy-Target Verification
function VerifyProxiedNetworkOperation(
proxy_connection, target_request ):
Das Expires 25 April 2027 [Page 489]
Internet-Draft Sandbox Credential Egress Finality October 2026
if not VerifyAuthorizedProxyIdentity(proxy_connection):
return DENIED
target = CanonicalizeProxyTarget(target_request)
if target is invalid:
return DENIED
resolution = ProtectedProxyResolver.resolve(target.hostname)
selected = SelectPermittedEndpoint(resolution)
if selected is invalid:
return DENIED
if not VerifyTargetServiceAndOperationAuthority(
target_request, selected ):
return DENIED
if not BindProxyOutboundConnectionToEndpoint(
target_request, selected ):
return DENIED
return ELIGIBLE_FOR_PROTECTED_FINALITY
The proxy must actually control the outbound connection used for the
governed target operation.
7.8.127. C-45.83 - Algorithm L: Network Outcome Recovery
function RecoverPendingNetworkOperation(candidate_id):
record = ProtectedNetworkRegistry.get(candidate_id)
if record.status == COMPLETED:
return COMPLETED
if record.status == DENIED:
return DENIED
Das Expires 25 April 2027 [Page 490]
Internet-Draft Sandbox Credential Egress Finality October 2026
if record.status == STAGED:
return REQUIRE_CURRENT_VALIDATION
if record.status in {RESERVED, TRANSMITTED, INDETERMINATE}:
authoritative_result = QueryAvailableOperationOutcome(
record )
if authoritative_result == CONFIRMED_COMPLETED:
CommitProtectedCompletion(record) return COMPLETED if
authoritative_result == CONFIRMED_NOT_EFFECTED:
ApplyPermittedRetryPolicy(record) return RECOVERABLE
MarkOperationIndeterminate(record) return RECONCILIATION_REQUIRED
return DENIED
The system does not automatically retransmit a potentially
consequential request merely because a response was lost.
7.8.128. PART XVII - WORKED TECHNICAL EXAMPLES
C-45.84 - Example A: DNS Rebinding Against an Authorized Hostname
The following is a hypothetical implementation example.
An agent is permitted to retrieve information from a designated
public service.
The initial DNS result identifies an external public endpoint.
The protected controller validates the selected endpoint.
Before connection establishment, the hostname is resolved again by
another client component.
The second result identifies a prohibited loopback or internal
address.
The controlled transport path does not accept this second address
under the original authorization.
The Finality Sink verifies the selected effective endpoint.
Das Expires 25 April 2027 [Page 491]
Internet-Draft Sandbox Credential Egress Finality October 2026
The operation is denied or subjected to renewed protected validation.
The original hostname authorization does not authorize access to the
prohibited address.
7.8.129. C-45.85 - Example B: Multiple DNS Addresses
A hostname resolves to several addresses, including IPv4 and IPv6
candidates.
The network policy permits certain endpoints and prohibits others.
The connection manager evaluates each endpoint actually attempted.
The authorization is bound to the selected permitted endpoint or an
approved endpoint set.
A transport library cannot silently replace the selected endpoint
with an unchecked prohibited address.
This example applies to ordinary dual-stack connection selection as
well as repeated connection attempts.
C-45.86 - Example C: HTTP Redirect to Internal Resource
An agent requests a public HTTPS resource.
The public service returns a redirect to an internal administrative
endpoint.
The redirect controller parses the new destination.
The effective endpoint is classified under the protected network-zone
policy.
The new destination is not authorized.
The redirected request is withheld.
The system does not treat the initial permitted public hostname as
authorization to follow the redirect to the internal resource.
7.8.130. C-45.87 - Example D: Forward Proxy With Remote DNS
An agent communicates through a protected forward proxy.
The agent submits an HTTPS target hostname.
Das Expires 25 April 2027 [Page 492]
Internet-Draft Sandbox Credential Egress Finality October 2026
The proxy performs DNS resolution.
The proxy selects an outbound IP address.
The protected proxy-side Finality Sink evaluates the actual selected
endpoint before establishing the governed target connection.
A prohibited effective destination causes the operation to be denied.
The agent-side approval of the target hostname does not replace the
proxy-side endpoint check.
C-45.88 - Example E: Credential-Bearing API Request
An AI agent requests a credential-bearing API operation.
The agent holds a surrogate credential reference.
The real credential is retained by a protected broker.
The request is staged.
The PED validates the permitted service, method, resource, and
destination scope.
Protected evidence and scoped finality authority are established.
The connector constructs the concrete request.
The Finality Sink verifies the effective endpoint and actual request
parameters.
The broker applies the protected credential only through the
controlled authorized operation.
A change to an unauthorized target resource or destination causes
denial or fresh validation.
7.8.131. C-45.89 - Example F: HTTP/2 Connection Reuse
A client maintains an existing HTTP/2 connection.
The agent proposes a new request using that connection.
The current connection peer is permitted.
However, the new request targets a different application origin or
resource scope.
Das Expires 25 April 2027 [Page 493]
Internet-Draft Sandbox Credential Egress Finality October 2026
The Finality Sink verifies the effective request authority and
current protected operation permission.
The request is not automatically authorized because the physical
connection was previously permitted.
7.8.132. C-45.90 - Example G: QUIC Network-Path Change
An agent-associated service uses a QUIC connection.
The transport attempts to move traffic through a new remote endpoint
or path.
The protected network controller identifies the relevant effective-
endpoint change.
The controller verifies the new path against current network
authorization.
Further governed transmission through the new path is permitted only
if the required restrictions are satisfied.
The implementation uses an endpoint or network controller capable of
observing and enforcing the claimed migration semantics.
7.8.133. C-45.91 - Example H: Direct Socket Bypass
An agent is configured to use a protected API gateway.
The gateway validates endpoint, method, and resource scope.
The agent also has an enabled direct socket path.
The effectuation-path registry identifies the direct socket route.
The protected controller restricts or mediates that route.
The gateway's correct authorization process is not treated as
sufficient while an uncontrolled route to the governed effect remains
available.
7.8.134. C-45.92 - Example I: Connection Revocation
An agent has an established connection to an authorized service.
A protected authority controller revokes permission for a particular
request class.
Das Expires 25 April 2027 [Page 494]
Internet-Draft Sandbox Credential Egress Finality October 2026
The authority generation advances.
The agent attempts another request over the existing connection.
The Finality Sink verifies the current required generation and
request scope.
The operation is denied.
Keeping the connection open does not preserve the revoked operation
permission.
7.8.135. C-45.93 - Example J: Proxy Failover
A primary proxy fails.
The platform activates a replacement proxy.
The replacement proxy uses a different destination-resolution and
routing path.
The protected controller verifies the replacement's required
enforcement capabilities and path coverage.
A new protected coverage generation is established where necessary.
Pending operations associated with stale proxy or connection bindings
are revalidated or reconciled.
The system does not route governed requests through an unverified
replacement merely because the primary proxy is unavailable.
7.8.136. C-45.94 - Example K: TLS Service Identity Mismatch
An agent requests an approved HTTPS service.
The effective IP address is within the permitted network range.
However, the server does not authenticate as the service required by
the protected policy.
The controller rejects the request under the required service-
identity predicate.
A permitted IP address alone is not sufficient when an authenticated
application service identity is mandatory.
C-45.95 - Example L: Lost Acknowledgment After Transmission
Das Expires 25 April 2027 [Page 495]
Internet-Draft Sandbox Credential Egress Finality October 2026
An authorized network request crosses the controlled Finality Sink.
The remote application may process the request.
The local client loses the response.
The protected operation registry marks the request as indeterminate.
The system uses the available idempotency reference or destination-
specific reconciliation procedure.
It does not automatically treat absence of a response as proof that
no consequential remote effect occurred.
7.8.137. PART XVIII - FAILURE AND ADVERSARIAL SCENARIOS
7.8.138. C-45.96 - Representative Failure Conditions
7.8.139. F1 - DNS Rebinding
A hostname changes from a permitted address to a prohibited endpoint.
The effective-endpoint validation rejects the new unauthorized
destination.
7.8.140. F2 - DNS Answer Substitution
An untrusted component replaces a protected resolution result.
The required integrity or operation-binding verification fails.
7.8.141. F3 - Multiple-Address Selection
A DNS response contains both permitted and prohibited addresses.
Only a policy-permitted selected endpoint may be used.
7.8.142. F4 - IPv6 Bypass
An IPv4 restriction is implemented, but an IPv6 path remains
unrestricted.
The relevant dual-stack path coverage must address the IPv6 route.
7.8.143. F5 - Loopback Destination
A requested public service resolves or redirects to loopback.
Das Expires 25 April 2027 [Page 496]
Internet-Draft Sandbox Credential Egress Finality October 2026
The required network-zone restriction rejects it.
7.8.144. F6 - Link-Local Destination
A request attempts to use a prohibited link-local endpoint.
The current destination policy prevents the governed transmission.
7.8.145. F7 - Private-Network Pivot
An apparently public request targets a prohibited private network
after resolution or redirection.
The effective-endpoint check rejects the pivot.
7.8.146. F8 - Cloud Metadata Access
A request attempts access to a restricted metadata or infrastructure
service.
The corresponding network-zone and resource policy prevents
unauthorized access.
7.8.147. F9 - Hostname Parser Ambiguity
Two components interpret a textual hostname differently.
The selected canonicalization policy rejects the ambiguous or
unsupported representation.
7.8.148. F10 - URL Authority Confusion
A URL parser and network client disagree on the actual target host or
port.
The Finality Sink uses the approved canonical representation of the
effective request.
7.8.149. F11 - Redirect Destination Change
A redirect changes the destination outside the permitted scope.
Fresh protected validation or denial is required.
7.8.150. F12 - Redirect Method Transformation
A redirect changes the effective operation method or semantics.
Das Expires 25 April 2027 [Page 497]
Internet-Draft Sandbox Credential Egress Finality October 2026
The resulting request must remain within the authorized operation
envelope.
7.8.151. F13 - Excessive Redirect Chain
An operation exceeds the configured redirect limit.
Further automatic transmission is withheld.
7.8.152. F14 - Proxy Remote-Resolution Bypass
A proxy resolves a target to a destination not checked locally.
The required proxy-side protected endpoint verification is applied.
7.8.153. F15 - Proxy Identity Substitution
Traffic is directed to an unauthorized proxy.
The protected proxy identity or route binding fails.
7.8.154. F16 - CONNECT Tunnel Scope Expansion
An authorized tunnel target is replaced with another target.
The protected tunnel-destination binding rejects the unauthorized
operation.
7.8.155. F17 - Direct Socket Escape
An agent bypasses the configured proxy through a direct socket.
The alternative path must be technically restricted or governed.
7.8.156. F18 - Existing Socket Reuse
An agent reuses an existing socket after authority is revoked.
The current request or transmission Finality Sink rejects the
unauthorized effect.
7.8.157. F19 - HTTP/2 Origin Coalescing
A connection is used for a new application origin.
The required request-origin and operation-scope checks apply.
Das Expires 25 April 2027 [Page 498]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.158. F20 - QUIC Path Migration
A transport path changes to an unauthorized effective endpoint.
The relevant network-effectuation controller restricts the new path.
7.8.159. F21 - TLS Identity Failure
The destination endpoint is permitted but the required service
identity is invalid.
The operation is denied under the service-authentication policy.
7.8.160. F22 - SNI Substitution
An untrusted component changes the TLS server-name indication.
The protected service-identity and request-binding checks detect the
mismatch where applicable.
7.8.161. F23 - HTTP Host Mismatch
The effective application authority differs from the validated
service scope.
The request is denied or revalidated.
7.8.162. F24 - Encrypted Payload Invisibility
A network device cannot inspect application-layer request fields
required by policy.
The system uses a trusted application boundary or authenticated
descriptor rather than falsely claiming full payload visibility.
7.8.163. F25 - Request Body Substitution
A connector modifies the payload after protected validation.
The final request digest or permitted-transformation check detects
the mismatch.
7.8.164. F26 - Credential Scope Mismatch
A credential is applied to a request outside its authorized service
or resource scope.
The credential Finality Sink denies the use.
Das Expires 25 April 2027 [Page 499]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.165. F27 - Capability Replay
A previously consumed single-use capability is presented again.
Sink-local protected usage state rejects replay.
7.8.166. F28 - Capability Used at Wrong Sink
A capability intended for one protected proxy is presented to
another.
The required sink identity check fails.
7.8.167. F29 - Stale Authority Generation
The request references authority invalidated by later policy or
revocation.
Further governed transmission is denied.
7.8.168. F30 - Network Interface Failover
An alternate route becomes active without corresponding coverage
validation.
The operation remains restricted until the route is verified.
7.8.169. F31 - VPN or Tunnel Bypass
A process uses a tunnel outside the approved network enforcement
path.
The relevant effectuation-path coverage must control or restrict the
tunnel.
7.8.170. F32 - Host Connector Bypass
A privileged host worker can transmit without current protected
authorization.
The worker's operation path must be governed or disabled.
7.8.171. F33 - Redirect Through Another Connector
A request is routed through a different connector following an
application redirect.
Das Expires 25 April 2027 [Page 500]
Internet-Draft Sandbox Credential Egress Finality October 2026
The new concrete operation remains subject to actual endpoint and
authority verification.
7.8.172. F34 - DNS Cache Rollback
An earlier cached resolution record is restored.
The system applies its current protected generation and freshness
requirements rather than treating the earlier result as unconditional
authorization.
7.8.173. F35 - Connection Identifier Reuse
A socket identifier is recycled for a different connection.
The protected connection generation prevents authorization confusion.
7.8.174. F36 - Resolver Failure
The required destination resolution cannot be completed.
The governed operation remains non-effective or follows a separately
authorized bounded fallback policy.
7.8.175. F37 - PED Unavailability
The protected authorization service is unavailable.
No new unrestricted authority is inferred.
7.8.176. F38 - Finality Sink Unavailability
The designated network controller fails.
The system does not permit uncontrolled failover for governed
transmissions.
7.8.177. F39 - Protected State Rollback
An older authorization or capability-consumption record is restored.
The required protected state-continuity mechanism detects or prevents
prohibited reuse.
7.8.178. F40 - Concurrent Request Double-Spend
Two workers attempt to use one single-use network capability.
Das Expires 25 April 2027 [Page 501]
Internet-Draft Sandbox Credential Egress Finality October 2026
Atomic protected consumption prevents unauthorized duplication.
7.8.179. F41 - Transmitted Request With Lost Response
An externally consequential operation may have completed.
The system retains an indeterminate state and reconciles rather than
blindly retrying.
7.8.180. F42 - Application Service Change
The same IP address begins serving a different application identity.
Current service-identity verification prevents unauthorized reliance
solely on the prior IP authorization.
7.8.181. PART XIX - IMPLEMENTATION VARIATIONS
7.8.182. C-45.97 - Host-Side Protected Proxy
A host-side proxy intercepts agent network requests.
The proxy performs destination resolution, current protected
authorization, concrete request verification, and controlled
transmission.
The agent's direct network routes are restricted where required.
7.8.183. C-45.98 - Container Network Namespace
An agent executes within a restricted container network namespace.
A protected host gateway controls permitted egress.
The deployment may restrict the container's direct routing capability
while providing controlled DNS and proxy access.
The namespace configuration itself must be verified under the actual
host threat model.
7.8.184. C-45.99 - Virtual-Machine Network Enforcement
An agent executes within a virtual machine.
A protected hypervisor or host network controller mediates selected
egress operations.
Das Expires 25 April 2027 [Page 502]
Internet-Draft Sandbox Credential Egress Finality October 2026
The system verifies relevant guest network interfaces, virtual
devices, direct device assignments, and alternate paths.
7.8.185. C-45.100 - Kernel-Mediated Network Finality
A kernel-supported mechanism restricts selected network operations.
The applicable protected component validates current authorization
and effective endpoint information.
The implementation distinguishes connection-admission enforcement
from per-request application authorization.
7.8.186. C-45.101 - SmartNIC/DPU Network Sink
A programmable network device controls the governed transmission.
The device verifies effective destination scope and applicable
protected capability state.
Where policy depends on encrypted application fields that the device
cannot inspect, a trusted cooperating application controller provides
the required binding.
7.8.187. C-45.102 - API Gateway Finality
An API gateway receives concrete resource requests and verifies the
protected authorization before forwarding.
The gateway identifies the effect it controls, such as API request
submission, and does not automatically enforcement point control over
later destination-internal effects.
7.8.188. C-45.103 - Credential-Broker Integration
A protected credential broker retains the real API credential.
A network Finality Sink verifies endpoint, resource, operation and
credential scope.
The broker applies the credential only through the permitted
controlled path.
7.8.189. C-45.104 - Browser-Agent Egress
A browser automation agent proposes navigation, form submission, or
API-related operations.
Das Expires 25 April 2027 [Page 503]
Internet-Draft Sandbox Credential Egress Finality October 2026
| The protected controller verifies the actual destination and applicable request parameters. Redirects, browser-origin behavior, and alternate network capabilities are addressed according to the selected policy. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-45.105 - Service-Mesh Implementation A service mesh associates workload identity and service identity with permitted network operations. A protected authority controller evaluates agent-specific task scope. The mesh gateway or resource-owning service performs the required finality verification. |
| C-45.106 - Remote DNS Proxy A proxy performs DNS resolution and selected endpoint verification on behalf of an agent. The protected authorization binds the original requested destination and actual proxy-selected outbound endpoint. The proxy prevents unauthorized destination substitution. |
7.8.190. C-45.107 - HTTP/2 or HTTP/3 Application Enforcement
A trusted application-layer controller verifies each governed request
within an existing multiplexed or migratable transport connection.
The controller maintains the required origin, endpoint, connection-
generation, and authority bindings.
7.8.191. C-45.108 - TEE-Assisted Network Authority
A TEE maintains protected policy, validation state, or scoped
finality authorization.
A controlled proxy or network controller enforces the resulting
authority at the actual network effectuation boundary.
7.8.192. C-45.109 - Integrated Protected Network Controller
One protected component performs request capture, resolution,
authorization, evidence commitment, capability activation, endpoint
verification, and governed transmission.
The logical protected-finality relationships remain implemented
without requiring separate physical services.
7.8.193. C-45.110 - Distributed Network Enforcement
A PED and Finality Sink operate on different machines or security
domains.
Authenticated communication binds the operation descriptor, protected
evidence, capability, and effective endpoint.
The Finality Sink verifies current required authorization before
transmission.
The implementation must define revocation and state-consumption
consistency under network partitions.
7.8.194. PART XX - REPRESENTATIVE DATA STRUCTURES
Das Expires 25 April 2027 [Page 504]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.195. C-45.111 - CandidateNetworkEgressRecord
Fields may include:
1. CandidateActID. 2. AgentContextID. 3. TaskID. 4.
RequestedDestination. 5. OperationClass. 6. CanonicalRequestDigest.
7. ResolutionReference. 8. AuthorityGeneration. 9. RequiredSinkID.
10. CandidateStatus.
7.8.196. C-45.112 - DNSResolutionRecord
Fields may include:
1. ResolutionID. 2. RequestedHostname. 3. CanonicalHostname. 4.
ResolvedAddressSet. 5. SelectedEndpoint. 6. ResolverIdentity. 7.
ResolutionGeneration. 8. ValidityReference. 9. PolicyGeneration.
10. ResolutionStatus.
7.8.197. C-45.113 - EffectiveEndpointRecord
Fields may include:
1. EndpointRecordID. 2. AddressFamily. 3. SelectedIPAddress. 4.
SelectedPort. 5. TransportProtocol. 6. RequestedServiceIdentity. 7.
NetworkZoneClassification. 8. RouteContext. 9. ResolutionReference.
10. EndpointValidationStatus.
7.8.198. C-45.114 - NetworkAuthorityRecord
Fields may include:
1. 2. 3. 4. 5. 6. 7. 8.
AuthorityRecordID. AgentContextID. TaskID.
AuthorizedDestinationScope. PermittedNetworkZones.
PermittedOperationClasses. PermittedProtocolClasses.
CredentialScope.
9. PolicyGeneration. 10. RevocationGeneration. 11.
AuthorityStatus.
7.8.199. C-45.115 - ConnectionBindingRecord
Fields may include:
Das Expires 25 April 2027 [Page 505]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. ConnectionID. 2. ConnectionGeneration. 3. AgentContextID. 4.
EffectiveTransportPeer. 5. IntendedServiceIdentity. 6.
AuthorizedEndpointScope. 7. AuthorityGeneration. 8.
AuthorizedRequestScope. 9. RequiredSinkID. 10. ConnectionStatus.
7.8.200. C-45.116 - NetworkValidationEvidenceRecord
Fields may include:
1. EvidenceID. 2. CandidateActID. 3. OperationDescriptorDigest. 4.
ResolutionReference. 5. AuthorizedEndpointScope. 6.
PolicyGeneration. 7. AuthorityGeneration. 8. ValidationResult. 9.
RequiredSinkID. 10. ProtectedCommitment.
7.8.201. C-45.117 - NetworkFinalityCapabilityRecord
Fields may include:
1. 2. 3. 4. 5. 6.
CapabilityID. CandidateActID. EvidenceReference.
OperationDescriptorDigest. AuthorizedEndpointScope.
ConnectionBinding.
7. AuthorizedOperationClass. 8. AuthorizedSinkID. 9.
AuthorityGeneration. 10. UsagePolicy. 11.
ProtectedConsumptionReference. 12. CapabilityStatus.
7.8.202. C-45.118 - ProxyTargetRecord
Fields may include:
1. ProxyRequestID. 2. ProxyIdentity. 3. RequestedTargetHostname.
4. RequestedTargetPort. 5. EffectiveTargetEndpoint. 6.
AuthorizedTunnelScope. 7. ResolutionReference. 8.
AuthorityGeneration. 9. FinalitySinkID. 10. VerificationStatus.
7.8.203. C-45.119 - RedirectStateRecord
Fields may include:
1. CandidateActID. 2. CurrentRequestReference. 3. RedirectCount.
4. PreviousOrigin. 5. ProposedOrigin. 6.
ProposedEffectiveEndpoint. 7. TransformationClass. 8.
RequiredRevalidationState. 9. AuthorityGeneration. 10.
RedirectStatus.
Das Expires 25 April 2027 [Page 506]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.204. C-45.120 - EgressPathCoverageRecord
Fields may include:
1. PathID. 2. AgentContextID. 3. NetworkInterfaceID.
4. ProxyOrConnectorReference. 5. TransportCapability. 6.
RequiredSinkID. 7. EnabledState. 8. CoverageGeneration. 9.
VerificationStatus.
7.8.205. C-45.121 - NetworkOperationRecoveryRecord
Fields may include:
1. CandidateActID. 2. ConnectionID. 3. FinalityCapabilityID. 4.
ProtectedConsumptionState. 5. NetworkDispatchState. 6.
RemoteOperationReference. 7. AcknowledgmentState. 8.
RecoveryGeneration. 9. ReconciliationStatus.
The records may reside in protected databases, authenticated service
registries, kernelassociated state, trusted execution environments,
hardware-protected state, or cooperating protected controllers.
7.8.206. PART XXI - implementer VERIFICATION TESTS
7.8.207. C-45.122 - Proposed Engineering Test Matrix
The following tests are proposed procedures rather than
representations of completed experiments.
7.8.208. Test Technical condition
T1 Authorized hostname and effective endpoint Required operation
permitted T2 Authorized hostname resolves to prohibited
IP T3 DNS rebinding after preliminary check T4 Mixed permitted and
prohibited DNS
addresses T5 IPv6 destination outside permitted scope T6 Loopback
effective endpoint T7 Link-local effective endpoint T8 Prohibited
private-network endpoint T9 Restricted metadata-service endpoint
7.8.209. Expected result
Denied New endpoint rejected or revalidated Only permitted selected
endpoint used Denied Required restriction enforced Required
restriction enforced Denied Denied
Das Expires 25 April 2027 [Page 507]
Internet-Draft Sandbox Credential Egress Finality October 2026
T10 Ambiguous hostname syntax T11 Request authority and URL parser
mismatch Rejected T12 Redirect to prohibited service T13 Redirect
method change T14 Excessive redirect chain T15 Proxy resolves
prohibited endpoint T16 CONNECT target substitution T17 Unauthorized
proxy selected T18 Direct socket bypass T19 Existing socket after
revocation T20 HTTP/2 different-origin request T21 QUIC path
migration T22 TLS certificate identity mismatch T23 HTTP Host outside
permitted service scope Denied T24 SNI and service identity
inconsistency T25 Encrypted payload unavailable to network
device T26 Request body changed after validation T27 Credential
applied to wrong endpoint T28 Wrong credential-use scope T29 Invalid
protected validation evidence T30 Missing scoped finality capability
T31 Capability replay T32 Concurrent capability use T33 Capability at
wrong sink T34 Stale authority generation T35 Connection identifier
reuse T36 Proxy failover without verification T37 Alternate network
interface enabled T38 VPN/tunnel alternate route T39 DNS resolver
unavailable T40 PED unavailable T41 Finality Sink unavailable T42
Lost response after authorized request T43 Unauthorized service
identity at permitted IP Service policy enforced T44 Protected
resolution state rollback
Rejected by canonicalization policy
Denied Revalidated where required Restricted Proxy-side check denies
Target binding rejected Proxy identity check fails Restricted or
governed New governed request denied Request-level authorization
enforced New effective endpoint evaluated Required service identity
check fails
Required binding enforced Application enforcement used where required
Operation mismatch rejected Denied Denied Finality denied Effect
withheld Rejected Atomic consumption enforced Rejected Denied
Generation mismatch detected Effect withheld Coverage revalidation
required Governed or disabled Required restrictive behavior No
permissive fallback No uncontrolled transmission Reconciliation state
retained
Required continuity check enforced
Each implementation must identify the actual interception boundary,
DNS resolver behavior, effective endpoint, application identity,
protected state, test packet or request, and observable result.
7.8.210. PART XXII - Enforcement-Point Mapping and Technical
Correspondence
Das Expires 25 April 2027 [Page 508]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.211. C-45.123 - Reconstructed Independent enforcement point(s)
corresponding to source item(s) 45
this implementation profile provides corresponding technical
mechanisms for:
enforcement point(s) corresponding to source item(s) 45(a): An AI-
agent execution environment generating proposed network operations.
enforcement point(s) corresponding to source item(s) 45(b):
Interception of a Candidate Network Egress Act before its governed
external
transmission.
enforcement point(s) corresponding to source item(s) 45(c): A
machine-verifiable network operation descriptor including requesting
context, intended destination, protocol, material parameters,
authority generation, and required Finality Sink.
enforcement point(s) corresponding to source item(s) 45(d): A
controlled destination-resolution component obtaining an effective
endpoint.
enforcement point(s) corresponding to source item(s) 45(e)(i):
Protected validation of a Sandbox Egress Authority Object or
equivalent
network authority.
enforcement point(s) corresponding to source item(s) 45(e)(ii):
Evaluation of requested destination, resolved endpoint, protocol,
operation
scope, and current network restrictions.
enforcement point(s) corresponding to source item(s) 45(e)(iii):
Protected authorization-state operations.
enforcement point(s) corresponding to source item(s) 45(e)(iv):
Commitment of protected validation evidence.
enforcement point(s) corresponding to source item(s) 45(e)(v): A
scoped non-bearer network-egress capability associated with the
validated
operation and permitted endpoint scope.
Das Expires 25 April 2027 [Page 509]
Internet-Draft Sandbox Credential Egress Finality October 2026
enforcement point(s) corresponding to source item(s) 45(f)(i):
Finality Sink reconstruction of the actual pending network operation
and
effective endpoint.
enforcement point(s) corresponding to source item(s) 45(f)(ii):
Correspondence verification against protected authorization.
enforcement point(s) corresponding to source item(s) 45(f)(iii):
Protected evidence, capability, authority-generation, and sink-local
state
verification.
enforcement point(s) corresponding to source item(s) 45(f)(iv):
Controlled transmission only after required verification succeeds.
enforcement point(s) corresponding to source item(s) 45(g):
Prevention of preliminary hostname or policy approval from becoming
independent authority for an unvalidated effective endpoint.
7.8.212. C-45.124 - Reconstructed Dependent enforcement point(s)
corresponding to source item(s) 46
The embodiment provides:
1. Original and canonical hostname representations.
2. DNS alias and address-set handling. 3. Selected effective
endpoint validation. 4. Restricted network-zone classification. 5.
Loopback restrictions. 6. Link-local restrictions. 7. Private or
administrative network restrictions. 8. DNS rebinding detection. 9.
Redirect revalidation. 10. Proxy resolution handling. 11.
Connection replacement and effective-endpoint changes. 12. Denial or
renewed protected authorization upon destination change.
7.8.213. C-45.125 - Reconstructed Dependent enforcement point(s)
corresponding to source item(s) 47
The embodiment provides:
1. Protected connection identity. 2. Connection-generation
tracking. 3. Actual transport-peer verification. 4. Application
service identity binding. 5. Connection reuse authorization. 6.
HTTP/2 origin distinctions. 7. QUIC path-change treatment. 8. Proxy
and connector path controls. 9. Direct socket restrictions. 10.
Das Expires 25 April 2027 [Page 510]
Internet-Draft Sandbox Credential Egress Finality October 2026
Alternative network interface restrictions. 11. Failover path
coverage. 12. Current authority-generation verification. 13.
Protected effectuation-path completeness. 14. Prevention of
additional authority through connection reuse or path substitution.
7.8.214. PART XXIII - IMPLEMENTATION REQUIREMENTS
7.8.215. C-45.126 - implementer Implementation Checklist
A person having ordinary skill in the art implementing this
implementation profile identifies:
1. The AI-agent execution environment. 2. The trusted computing
base. 3. The attacker capabilities. 4. The controlled network-
effectuation classes. 5. The network operation interception point.
6. The Non-Effective State staging mechanism. 7. The approved URL
or service parser. 8. The hostname canonicalization rules. 9. The
network operation descriptor.
10. The protected source execution identity. 11. The destination-
resolution architecture. 12. The DNS result representation. 13. The
resolver trust assumptions. 14. The selected endpoint policy. 15.
The IP-address and network-zone classification. 16. The IPv4 and
IPv6 handling procedures. 17. The permitted transport and port
restrictions. 18. The endpoint-to-service-identity relationship. 19.
The transport connection binding. 20. The TLS service-authentication
requirements. 21. The actual request reconstruction mechanism. 22.
The HTTP redirect handling procedure. 23. The connection reuse
restrictions. 24. The HTTP/2 or HTTP/3 semantics where used. 25.
The proxy and CONNECT target handling. 26. The remote DNS resolution
restrictions. 27. The service-mesh or gateway relationship where
present. 28. The protected network authority registry. 29. The
applicable Sandbox Egress Authority Object. 30. The PED operation-
specific predicates. 31. The protected authorization-state
transition. 32. The validation-evidence commitment mechanism. 33.
The scoped non-bearer finality capability. 34. The sink-local
protected state. 35. The required Finality Sink. 36. The actual
effective-endpoint verification procedure. 37. The controlled
credential-use mechanism. 38. The alternate egress path registry.
39. The direct socket or network bypass restrictions. 40. The
revocation-generation and connection-state update rules. 41. The
concurrent request and usage-consumption rules. 42. The network-
operation outcome reconciliation. 43. The handling of unknown remote
completion. 44. The protective behavior following resolver or sink
failure. 45. The engineering tests establishing the claimed
properties.
Das Expires 25 April 2027 [Page 511]
Internet-Draft Sandbox Credential Egress Finality October 2026
The implementation must specify which component can reliably observe
or reconstruct each material request and endpoint field.
Where an operation is encrypted, tunneled, proxied, migrated, or
redirected, the selected enforcement architecture must supply the
visibility and control necessary for the guarantee.
A hostname allowlist, DNS lookup, packet log, or TLS connection by
itself does not establish the complete protected-finality
relationship unless the applicable operation-specific and
effectuation-boundary requirements are also implemented.
7.8.216. C-45.127 - Technical Effect
this implementation profile provides protected network operation
control in which an AI agent's proposed destination and the endpoint
actually used for transmission are treated as separate machine-
verifiable attributes.
The system obtains the effective destination through a controlled
resolution or endpointselection procedure.
It evaluates the selected endpoint under current protected task,
resource, network-zone, and operation policy.
Protected validation evidence is committed, and bounded non-bearer
finality authorization is established.
A Finality Sink verifies the actual pending network operation,
effective endpoint, current authority generation, protected evidence,
capability, and applicable sink-local state before permitting the
governed transmission.
The system may prevent unauthorized effects arising from DNS
rebinding, unvalidated redirects, connection reuse, proxy destination
changes, credential misuse, or alternate network routing.
The security guarantee depends upon the actual network interception,
service-identity verification, cryptographic protection, and
effectuation-path controls implemented by the selected platform.
Das Expires 25 April 2027 [Page 512]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.217. C-45.128 - Technical Summary
this implementation profile discloses a computer-implemented
protected post-DNS-resolution network-egress architecture comprising
an AI-agent execution environment, a controlled network operation
interceptor, a Candidate Network Egress Act held in a Non-Effective
State, a destination-resolution controller, a Protected Enforcement
Domain, protected validation evidence, scoped non-bearer finality
enablement, and a network-egress Finality Sink.
The destination-resolution controller obtains effective network
destination information associated with the proposed operation.
The PED verifies applicable task authority, requested destination,
selected effective endpoint, protocol, operation scope, current
network policy, and protected authorization state.
Protected validation evidence is committed and bounded authorization
is established for the validated operation and effective destination
scope.
The Finality Sink obtains or reconstructs the actual pending network
request and endpoint, verifies correspondence with the protected
evidence and scoped authorization, and permits the governed
transmission only when the required conditions are satisfied.
The architecture additionally provides DNS rebinding resistance,
redirect revalidation, proxy target authorization, connection reuse
controls, service-identity binding, credential-toendpoint
restrictions, current authority-generation verification, and
alternate egress-path coverage.
A connection to an approved hostname, a permitted transport endpoint,
or an existing socket does not independently grant unrestricted
authority to perform subsequent network operations.
The system may be implemented through protected network proxies, API
gateways, credential brokers, kernel controls, service meshes,
virtual-machine interfaces, container networking, SmartNICs, DPUs,
TEEs, or cooperating software and hardware effectuation controllers.
Das Expires 25 April 2027 [Page 513]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.8.217.1. COMPILATION OF EFFECT-PATH REACHABILITY RESTRICTIONS FOR
ARTIFICIAL-INTELLIGENCE-AGENT SANDBOXES USING DIRECTED
7.8.217.2. INTERFACE GRAPHS, AUTHORIZED-EFFECT ENVELOPES, WEIGHTED PATH
SEPARATION, RUNTIME INTERFACE QUARANTINE, AND VERIFIED
7.8.217.3. CONFIGURATION INSTALLATION
7.9. Implementation Profile C-48
Source location: original disclosure pages 830-899. Source technical
content is presented here for implementation analysis; numbering
reflects the original profile family rather than a requirement to
implement every profile.
7.9.1. C-48.1 - Technical Field
this implementation profile relates to artificial-intelligence-agent
sandbox security, program and interface analysis, graph-based
reachability, operating-system confinement, capability and permission
reduction, resource isolation, access-control compilation, software
supply-chain changes, and verification of effect-restricted computing
environments.
More particularly, the embodiment discloses a computer-implemented
system configured to discover interfaces available directly or
indirectly to an artificial-intelligence agent, construct a directed
graph representing effect-capable operation paths, identify paths
leading to effects outside a task-specific authorization envelope,
compute enforceable interface restrictions interrupting those paths,
install the restrictions, and verify the resulting technical
separation before permitting agent execution.
The embodiment additionally provides mechanisms for identifying
alternate effect routes through individually permitted interfaces,
quarantining newly introduced runtime capabilities, and selecting
restrictions that preserve required task functionality.
The invention may be implemented using:
(a) operating-system processes; (b) process namespaces; (c)
containers;
(d) virtual machines;
(e) micro-virtual machines;
(f) kernel security interfaces;
Das Expires 25 April 2027 [Page 514]
Internet-Draft Sandbox Credential Egress Finality October 2026
(g) file-system and mount restrictions;
(h) network namespaces;
(i) service-account permissions;
(j) API connector registries;
(k) controlled tool dispatchers;
(l) privileged host services;
(m) cloud resource policies;
(n) hypervisor-mediated resource interfaces;
(o) hardware-assisted isolation; or
(p) combinations thereof.
this implementation profile is not limited to any particular agent
framework, cloud platform, operating system, kernel, graph
optimization solver, or enforcement substrate.
7.9.2. PART I - TECHNICAL PROBLEM
7.9.3. C-48.2 - Problem of Indirect Effectuation
An artificial-intelligence agent may have access to multiple
computational tools.
A task may legitimately require some tools while prohibiting
particular consequential effects.
For example, an agent may require permission to read technical
documentation and execute a local compiler, but must not transmit
confidential source files outside a designated enterprise network.
A restriction imposed only on an explicitly named transmission tool
may be ineffective.
The agent may reach a prohibited transmission through:
1. A shell. 2. An interpreter. 3. A browser automation interface.
Das Expires 25 April 2027 [Page 515]
Internet-Draft Sandbox Credential Egress Finality October 2026
4. A package-installed program. 5. A local service connector. 6. A
delegated worker. 7. A privileged host service. 8. A file-system
alias. 9. A helper process. 10. A network-enabled plugin. 11. A
queued background task. 12. A cloud service identity.
A prohibited effect can therefore be reachable through combinations
of interfaces even when each interface appears individually
permissible.
7.9.4. C-48.3 - Problem of Overly Broad Isolation
One approach to preventing prohibited effects is to disable all tools
or external interfaces.
However, this may prevent the agent from completing legitimate tasks.
For example, disabling every network interface may prevent both:
(a) prohibited direct internet transmission; and (b) permitted access
to a protected internal documentation service.
Similarly, disabling all process execution may prevent legitimate
compilation or testing.
The technical problem therefore includes identifying restrictions
that eliminate prohibited effect paths without unnecessarily
eliminating authorized task functionality.
7.9.5. C-48.4 - Problem of Configuration Drift
A sandbox may initially contain a limited tool and resource
inventory.
During execution, the environment may acquire:
(a) a new package; (b) a dynamically loaded plugin; (c) a new
executable; (d) a mounted directory; (e) a privileged connector;
(f) an alternate network route;
(g) a new service identity;
(h) a browser extension;
(i) a delegated worker; or
(j) another effect-capable interface.
Das Expires 25 April 2027 [Page 516]
Internet-Draft Sandbox Credential Egress Finality October 2026
A restriction configuration previously found sufficient may become
incomplete.
The embodiment therefore provides runtime interface-expansion
detection, quarantine, recompilation, and re-verification.
7.9.6. C-48.5 - Central Technical Principle
The architecture separates five technical functions:
Discovery: Determine which effect-capable interfaces are reachable
within a defined
execution environment.
Graph construction: Represent direct and indirect operational
transitions through a
machine-readable graph.
Restriction compilation: Compute restrictions that interrupt
prohibited paths while retaining
required authorized functionality.
Installation: Apply the restrictions to actual enforceable
interfaces.
Verification: Establish that the installed configuration interrupts
the identified prohibited
paths.
The agent is permitted to execute only under an installed and
sufficiently verified restriction configuration.
A natural-language instruction asking the agent to avoid prohibited
operations is not a substitute for the compiled technical
restrictions.
7.9.7. C-48.6 - Distinction From Per-Act Finality
This embodiment may operate as a preventive sandbox-construction
mechanism.
It does not necessarily require:
1. A separate validation receipt for every authorized operation.
Das Expires 25 April 2027 [Page 517]
Internet-Draft Sandbox Credential Egress Finality October 2026
2. A scoped non-bearer capability for each ordinary permitted
action. 3. A distinct Finality Sink for every effect already made
unreachable through effective technical isolation. 4. A
cryptographic approval exchange for every system call.
Such mechanisms may be combined with this technical arrangement in
other embodiments.
However, the primary inventive sequence here is:
DISCOVER
→ REPRESENT
→ CLASSIFY
→ ANALYZE REACHABILITY
→ OPTIMIZE RESTRICTIONS
→ COMPILE
→ INSTALL
→ VERIFY
→ EXECUTE UNDER RESTRICTIONS.
7.9.8. PART II - PRINCIPAL COMPONENTS
7.9.9. C-48.7 - Tool-and-Resource Discovery Engine
The Discovery Engine identifies executable programs, interfaces,
resource handles, service connectors, and authority relationships
that may be accessible to the agent.
Discovery sources may include:
(a) executable inventories; (b) process execution policies; (c)
installed packages; (d) container images; (e) file-system mounts; (f)
kernel permissions;
(g) operating-system identities;
(h) connector registries;
(i) cloud service-account permissions;
Das Expires 25 April 2027 [Page 518]
Internet-Draft Sandbox Credential Egress Finality October 2026
(j) browser tool capabilities;
(k) tool schemas;
(l) host-side worker configurations;
(m) network routing rules;
(n) privileged helper interfaces; and
(o) available device interfaces.
The discovery engine creates a versioned representation of the
available technical environment.
7.9.10. C-48.8 - Effect-Path Graph Generator
The Graph Generator constructs a directed graph of executable
components, authority contexts, interfaces, operation transitions,
and effect-capable resources.
The graph may contain typed nodes and edges.
It may also contain predicates describing the conditions under which
an edge is technically reachable.
7.9.11. C-48.9 - Effect Classification Engine
The Effect Classification Engine determines whether a graph node or
edge can contribute to one or more consequential effect classes.
Representative classes comprise:
EXTERNAL_TRANSMISSION
PERSISTENT_STATE_MODIFICATION
CREDENTIAL_USE
PROCESS_EXECUTION
SERVICE_INVOCATION
PRIVILEGED_RESOURCE_MODIFICATION
FILE_EXPORT
DATABASE_COMMIT
Das Expires 25 April 2027 [Page 519]
Internet-Draft Sandbox Credential Egress Finality October 2026
DEVICE_COMMAND
PERSISTENT_MEMORY_MUTATION
An interface may belong to multiple classes.
7.9.12. C-48.10 - Authorized Effect Envelope Controller
The Authorized Effect Envelope Controller obtains a task-specific
representation of effects permitted for the agent.
The envelope may define:
1. Authorized operations. 2. Authorized destinations. 3.
Authorized resource classes. 4. Authorized credential use. 5.
Permitted process-execution classes. 6. Required task-completion
interfaces. 7. Prohibited effects. 8. Policy conditions. 9.
Relevant authority generations.
The envelope is an input to restriction compilation.
7.9.13. C-48.11 - Restriction Compiler
The Restriction Compiler analyzes the graph to identify prohibited
paths and derives enforceable restrictions that interrupt those
paths.
The compiler may use:
(a) graph traversal; (b) dominator analysis; (c) path separation;
(d) minimum cut;
(e) weighted hitting-set optimization;
(f) mixed-integer optimization;
(g) constraint programming;
(h) bounded symbolic reachability;
(i) satisfiability solving;
(j) counterexample-guided refinement; or
(k) combinations thereof.
Das Expires 25 April 2027 [Page 520]
Internet-Draft Sandbox Credential Egress Finality October 2026
The chosen method depends upon the graph structure, path constraints,
optimization objective, and available computational resources.
7.9.14. C-48.12 - Enforcement Capability Catalog
The Enforcement Capability Catalog identifies technical restrictions
actually supported by the deployment.
A restriction may comprise:
(a) denial of an executable; (b) removal of a file-system write
permission; (c) removal of a network route; (d) restriction of a
destination; (e) revocation of a service entitlement; (f) removal of
a mount; (g) limitation of an API operation; (h) disabling of a
connector; (i) restriction of a privileged host interface; (j)
separation of a resource into another authority domain; (k) disabling
of a device interface; or
(l) another enforceable restriction.
The compiler does not assume that an arbitrary graph edge can be
disabled without a corresponding enforcement mechanism.
7.9.15. C-48.13 - Configuration Installer
The Configuration Installer translates the selected restrictions into
machine-enforceable sandbox configuration.
It may apply:
1. Process restrictions. 2. Container namespace configuration. 3.
File-system access rules. 4. Network filtering. 5. Kernel security
policies. 6. Connector allowlists. 7. Service-account restrictions.
8. Cloud-resource permissions. 9. Protected host-operation
policies. 10. Device-assignment restrictions.
The installer records the applied state and installation result.
7.9.16. C-48.14 - Configuration Verification Engine
The Verification Engine checks whether the installed restrictions
correspond to the compiled configuration and interrupt the identified
prohibited paths.
Verification may use:
Das Expires 25 April 2027 [Page 521]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) read-back of effective policy state; (b) graph reachability
recomputation; (c) controlled negative tests; (d) protected
configuration inspection; (e) resource-identity comparison; (f)
enforcement-state queries; (g) authenticated deployment measurements;
or
(h) combinations thereof.
A successful configuration file write alone does not establish that
the restrictions have become effective.
7.9.17. C-48.15 - Execution Controller
The Execution Controller starts or continues an agent only when the
required restrictions have been installed and verified.
It may establish execution-state transitions:
QUARANTINED
COMPILED
INSTALLING
VERIFYING
ACTIVE
REVALIDATION_REQUIRED
SUSPENDED
TERMINATED
An unverified configuration does not qualify for unrestricted ACTIVE
execution.
7.9.18. C-48.16 - Runtime Expansion Monitor
A Runtime Expansion Monitor detects newly introduced tools or
resource interfaces.
The monitor may observe:
(a) package installation; (b) executable addition; (c) plugin
registration; (d) connector changes; (e) new mounts;
(f) new privileged services;
Das Expires 25 April 2027 [Page 522]
Internet-Draft Sandbox Credential Egress Finality October 2026
(g) network interface changes;
(h) device reassignment;
(i) dynamic library loading;
(j) service-account modification; or
(k) delegated execution registration.
The system prevents an effect-capable interface from becoming
accessible before required graph and configuration revalidation.
7.9.19. PART III - GRAPH REPRESENTATION
7.9.20. C-48.17 - Directed Effect-Path Graph
The effect-path graph may be represented as:
G = (V, E)
where:
V is a set of nodes; and
E is a set of directed edges.
Each node has a type and associated metadata.
Each edge represents a technically reachable or conditionally
permitted operation transition.
7.9.21. C-48.18 - Node Classes
Representative node classes include:
AGENT_CONTEXT
EXECUTABLE_COMPONENT
INTERPRETER
SHELL_WRAPPER
BROWSER_INTERFACE
CONNECTOR
Das Expires 25 April 2027 [Page 523]
Internet-Draft Sandbox Credential Egress Finality October 2026
DELEGATED_WORKER
FILE_SYSTEM_INTERFACE
NETWORK_INTERFACE
CREDENTIAL_INTERFACE
KERNEL_RESOURCE_INTERFACE
AUTHORITY_CONTEXT
PRIVILEGED_HOST_SERVICE
PERSISTENT_RESOURCE
EXTERNAL_SERVICE
TERMINAL_EFFECT
A node may represent an abstract interface class or a concrete
instance.
The graph generator must specify its abstraction granularity.
7.9.22. C-48.19 - Edge Classes
Representative edge classes include:
EXECUTES
INVOKES
READS
WRITES
CONNECTS_TO
CALLS_API
DELEGATES_TO
INHERITS_AUTHORITY
RESOLVES_ALIAS
ACCESSES_CREDENTIAL
Das Expires 25 April 2027 [Page 524]
Internet-Draft Sandbox Credential Egress Finality October 2026
USES_SOCKET
OPENS_RESOURCE
SUBMITS_COMMAND
COMMITS_RESOURCE
REACHES_EFFECT
Each edge may have a guard predicate indicating when it is enabled.
7.9.23. C-48.20 - Conditional Edge
An edge may be represented by:
EdgeID
SourceNodeID
DestinationNodeID
OperationClass
RequiredAuthorityContext
GuardPredicate
EnforcementReference
CurrentEnabledState
ConfigurationGeneration
A conditional edge is considered reachable when the relevant guard
and authority conditions are satisfied under the analyzed
configuration.
Unknown guard conditions may be conservatively treated as potentially
enabled.
7.9.24. C-48.21 - Authority Context Nodes
Authority Context Nodes represent permissions or capabilities
available to a process or service.
Examples include:
Das Expires 25 April 2027 [Page 525]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) operating-system user identity; (b) service account; (c)
delegated cloud role; (d) API credential; (e) file-system permission;
(f) container capability;
(g) process token;
(h) privileged host-service permission;
(i) device-assignment capability.
An interface may become effect-capable only when combined with a
particular authority context.
The graph therefore represents technical reachability rather than
relying exclusively upon executable names.
7.9.25. C-48.22 - Terminal Effect Nodes
A Terminal Effect Node represents a specified externally
consequential result.
Examples include:
EXTERNAL_NETWORK_TRANSMISSION
PROTECTED_FILE_MODIFICATION
CREDENTIAL_DISCLOSURE
DATABASE_WRITE_COMMIT
PRIVILEGED_PROCESS_START
CLOUD_RESOURCE_MODIFICATION
DEVICE_ACTUATION
The effect class and resource identity may be incorporated into the
terminal node.
7.9.26. C-48.23 - Task-Specific Graph Scope
The graph is constructed for a defined deployment state.
A representative scope includes:
Das Expires 25 April 2027 [Page 526]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Agent identity. 2. Assigned task. 3. Current tool inventory. 4.
Current resource mounts. 5. Current process and service permissions.
6. Accessible connectors. 7. Available network routes. 8. Relevant
privileged interfaces. 9. Authorized effect envelope. 10.
Configuration generation.
The graph is not required to represent every theoretically possible
program in every computing environment.
However, the implementation must control the introduction of new
effect-capable interfaces outside the verified graph if it
enforcement points complete restriction of the relevant reachable
effects.
7.9.27. PART IV - AUTHORIZED EFFECT ENVELOPE
7.9.28. C-48.24 - Envelope Representation
A representative Authorized Effect Envelope comprises:
EnvelopeID = ENV-4801
AgentContextID = AGENT-42
TaskID = TASK-204
PermittedEffectClasses = { LOCAL_COMPUTATION, APPROVED_INTERNAL_API }
PermittedDestinations = { DOCUMENTATION_SERVICE_A }
ProhibitedEffects = { UNRESTRICTED_EXTERNAL_TRANSMISSION,
PRIVILEGED_HOST_MODIFICATION }
RequiredTaskInterfaces = { COMPILER, INTERNAL_DOCUMENTATION_CLIENT }
PolicyGeneration = 105
The values are illustrative.
7.9.29. C-48.25 - Permitted Task-Execution Paths
A Permitted Task-Execution Path means a graph path or permitted
execution sequence required to achieve a specified authorized task
function.
For example:
Das Expires 25 April 2027 [Page 527]
Internet-Draft Sandbox Credential Egress Finality October 2026
AGENT
→ CONTROLLED_DOCUMENTATION_CLIENT
→ APPROVED_INTERNAL_SERVICE
may be a permitted path.
Likewise:
AGENT
→ LOCAL_COMPILER
→ LOCAL_OUTPUT_BUFFER
may be permitted.
The compiler may preserve at least one required permitted task-
execution path under enforcement point(s) corresponding to source
item(s) 48.
For enforcement point(s) corresponding to source item(s) 51, the
compiler additionally optimizes restriction selection to reduce
removal of task-required interfaces.
7.9.30. C-48.26 - Required Task Function Set
A deployment may define:
T = {T1, T2, ..., Tn}
where each Ti represents a task function that should remain
available.
For example:
T1 = local source compilation.
T2 = internal documentation retrieval.
T3 = local unit testing.
The task envelope may associate each function with one or more
acceptable technical implementation paths.
Das Expires 25 April 2027 [Page 528]
Internet-Draft Sandbox Credential Egress Finality October 2026
The restriction compiler need not preserve every possible
implementation of a function if a permitted alternative remains
available.
7.9.31. PART V - REACHABILITY ANALYSIS
7.9.32. C-48.27 - Prohibited Reachability
A prohibited path exists when the agent can reach an effect node
outside the authorized effect envelope.
Let:
S = the set of agent-accessible source nodes.
F = the set of prohibited terminal effect nodes.
A prohibited reachability condition exists when an enabled path
connects a node in S to a node in F.
7.9.33. C-48.28 - Reachability Predicate
A representative predicate is:
ProhibitedReachable(G, S, F) = TRUE
if at least one permitted or technically reachable edge sequence
leads from S to F.
Otherwise:
ProhibitedReachable(G, S, F) = FALSE.
The graph analysis may account for conditional authority guards,
effect classes, and current policy.
7.9.34. C-48.29 - Direct Reachability
A direct prohibited path may comprise:
AGENT
→ NETWORK_SOCKET
→ UNAUTHORIZED_EXTERNAL_DESTINATION.
The compiler identifies an available enforceable restriction that
interrupts the path.
Das Expires 25 April 2027 [Page 529]
Internet-Draft Sandbox Credential Egress Finality October 2026
For example, direct socket access may be restricted within the agent
namespace while a separately controlled gateway remains available.
7.9.35. C-48.30 - Indirect Reachability
An indirect prohibited path may comprise:
AGENT
→ SHELL
→ PYTHON_INTERPRETER
→ NETWORK_LIBRARY
→ UNAUTHORIZED_EXTERNAL_DESTINATION.
Blocking a named network tool does not interrupt this path if the
interpreter retains network authority.
The compiler evaluates the combination of reachable interfaces.
7.9.36. C-48.31 - Delegated Reachability
A delegated prohibited path may comprise:
AGENT
→ SERVICE_CONNECTOR
→ PRIVILEGED_WORKER
→ ADMINISTRATIVE_API
→ PROHIBITED_RESOURCE_CHANGE.
The graph represents the worker's reachable operations and relevant
delegated authority.
The path may be interrupted by removing the connector invocation,
restricting the worker's permission, or limiting the privileged API
scope.
7.9.37. C-48.32 - File-System Alias Reachability
A protected resource may be accessible through multiple pathnames,
symbolic links, bind mounts, or other aliases.
Das Expires 25 April 2027 [Page 530]
Internet-Draft Sandbox Credential Egress Finality October 2026
A graph node representing a pathname may not uniquely identify the
underlying resource.
The compiler may therefore use canonical resource identities such as:
(a) file-object identifiers; (b) mount identities; (c) device
identifiers; (d) resolved resource handles; (e) storage object
identities; or (f) other stable protected references.
The selected representation must prevent an alias from bypassing an
intended resource restriction.
7.9.38. C-48.33 - Cyclic Reachability
The graph may contain cycles.
For example:
AGENT → TOOL A → TOOL B → TOOL A.
A standard worklist or fixed-point graph traversal can evaluate
reachability without infinite recursive enumeration.
A concrete implementation maintains visited graph states, including
relevant authority or guard state when necessary.
7.9.39. C-48.34 - Unknown Reachability
An interface may invoke an external service whose effect capabilities
are not fully described.
The graph may classify the interface as:
UNKNOWN_EFFECT_CAPABILITY.
A conservative policy may treat the interface as potentially reaching
a prohibited effect until its behavior is sufficiently constrained or
verified.
The system does not assume that an undocumented connector is
harmless.
7.9.40. PART VI - RESTRICTION CANDIDATES
Das Expires 25 April 2027 [Page 531]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.41. C-48.35 - Restriction Candidate
A Restriction Candidate means an enforceable action capable of
interrupting one or more graph edges or eliminating an authority
condition required for a prohibited effect.
A representative record comprises:
RestrictionID = RESTRICT-4801
TargetInterface = DIRECT_NETWORK_SOCKET
RestrictionType = NETWORK_NAMESPACE_DENY
CoveredEdges = {EDGE-12, EDGE-18}
EnforcementInterface = HOST_NETWORK_POLICY
TaskImpactCost = 2
InstallationCost = 1
VerificationStatus = SUPPORTED
The costs are illustrative optimization weights.
7.9.42. C-48.36 - Restriction Categories
Representative restriction categories include:
1. Interface disablement. 2. Executable restriction. 3. Authority
reduction. 4. Resource separation. 5. Network-route removal. 6.
Mount removal. 7. File-system access reduction. 8. Connector
disabling. 9. API-method reduction. 10. Credential-access removal.
11. Service-role contraction. 12. Privileged operation restriction.
13. Namespace separation. 14. Device-access restriction.
A restriction is considered only where the selected deployment has a
corresponding enforceable primitive.
7.9.43. C-48.37 - Restriction Coverage Relation
Let R be a set of available restriction candidates.
For each restriction r in R, define:
EdgesDisabled(r)
Das Expires 25 April 2027 [Page 532]
Internet-Draft Sandbox Credential Egress Finality October 2026
as the graph edges or authority transitions made unavailable when r
is effectively installed.
For a set of restrictions X:
G_X = ApplyRestrictions(G, X).
The compiler analyzes prohibited reachability on G_X.
7.9.44. C-48.38 - Restriction Feasibility
A proposed restriction is feasible when:
1. The applicable enforcement mechanism exists. 2. The relevant
process or service is within its control. 3. The restriction can be
installed. 4. The installed restriction can be verified. 5. The
restriction does not violate a mandatory deployment constraint. 6.
Its technical effect is represented accurately in the graph.
An optimization solver's selection of an abstract graph cut is
insufficient if no actual enforcement mechanism can implement it.
7.9.45. PART VII - MINIMAL RESTRICTION OPTIMIZATION
7.9.46. C-48.39 - Optimization Objective
enforcement point(s) corresponding to source item(s) 51 introduces an
optimization criterion minimizing removal of interfaces required for
authorized tasks.
A representative objective is:
Minimize:
TotalRestrictionCost(X)
subject to:
1. No prohibited effect node is reachable after applying X. 2.
Required task functionality remains available. 3. Every selected
restriction is technically enforceable. 4. The resulting
configuration satisfies applicable policy constraints.
The cost may account for:
Das Expires 25 April 2027 [Page 533]
Internet-Draft Sandbox Credential Egress Finality October 2026
(a) loss of task functionality; (b) number of disabled interfaces;
(c) loss of authorized paths; (d) installation complexity; (e)
runtime overhead; (f) maintenance impact; or (g) combinations
thereof.
7.9.47. C-48.40 - Weighted Restriction Cost
One representative objective is:
Cost(X) =
Σ over r in X of:
α · TaskDisruption(r)
| x | β · InstallationCost(r) |
| - | -------------------------- |
| x | γ · OperationalOverhead(r) |
| x | δ · RestrictionBreadth(r). |
The weights α, β, γ, and δ are deployment-specific.
The objective is illustrative.
An implementation may prioritize task preservation lexicographically
before secondary operational costs.
7.9.48. C-48.41 - Path-Separation Constraint
Let P_bad be the set of prohibited source-to-effect paths represented
under the current graph.
For every prohibited path p:
Σ over restrictions r interrupting p of x_r ≥ 1,
where:
x_r = 1 if restriction r is selected;
x_r = 0 otherwise.
This requires each identified prohibited path to be interrupted by at
least one selected restriction.
In graphs containing many paths, the implementation need not
enumerate every path in advance.
Das Expires 25 April 2027 [Page 534]
Internet-Draft Sandbox Credential Egress Finality October 2026
A counterexample-guided procedure may iteratively identify remaining
prohibited paths and add corresponding constraints.
7.9.49. C-48.42 - Task-Preservation Constraint
Let RequiredTaskFunctions be the set of task functions required by
the selected envelope.
For each required function, the compiler determines whether at least
one acceptable taskexecution path remains available.
A representative constraint is:
For each required task function Ti:
ExistsPermittedPath(Ti, G_X) = TRUE.
Where the enforcement point requires preservation of only one task-
execution path, the applicable implementation may use a corresponding
weaker constraint.
Where several task functions are designated mandatory by policy, the
compiler applies the stronger condition.
7.9.50. C-48.43 - Exact and Approximate Solutions
A restriction compiler may use an exact optimization method such as
mixed-integer linear programming or branch-and-bound.
For larger graphs, it may use a heuristic or approximation algorithm.
The implementation must distinguish:
Feasible solution: Satisfies the specified security and task-
preservation constraints.
Optimal solution: Minimizes the selected objective under the formal
model.
A greedy or heuristic result is not automatically globally minimal.
Regardless of the solver, the configuration verifier independently
checks the required security constraints before activation.
7.9.51. C-48.44 - Infeasible Restriction Problem
Some environments may not contain a restriction set that both blocks
prohibited effects and preserves the specified task functionality.
Das Expires 25 April 2027 [Page 535]
Internet-Draft Sandbox Credential Egress Finality October 2026
For example, a required tool may be inseparable from a privileged
capability through the available enforcement primitives.
The compiler may return:
INFEASIBLE_UNDER_AVAILABLE_ENFORCEMENT.
The execution controller does not remove the prohibited-path
requirement to force a successful optimization.
It may:
(a) deny execution; (b) request an alternative task implementation;
(c) relocate the tool to a separately restricted environment;
(d) introduce another enforceable gateway;
(e) reduce task scope through authorized policy changes; or
(f) select another permitted technical configuration.
7.9.52. PART VIII - CONCRETE GRAPH-CUT EXAMPLE
7.9.53. C-48.45 - Example Graph
Consider an agent assigned two tasks:
T1: Compile source code locally.
T2: Retrieve information from an approved internal documentation
service.
Unauthorized public network transmission is prohibited.
The graph contains:
AGENT → SHELL
SHELL → LOCAL_COMPILER
LOCAL_COMPILER → LOCAL_OUTPUT
SHELL → PYTHON_INTERPRETER
PYTHON_INTERPRETER → DIRECT_SOCKET
AGENT → CURL_EXECUTABLE
Das Expires 25 April 2027 [Page 536]
Internet-Draft Sandbox Credential Egress Finality October 2026
CURL_EXECUTABLE → DIRECT_SOCKET
DIRECT_SOCKET → PUBLIC_NETWORK
AGENT → APPROVED_DOC_CONNECTOR
APPROVED_DOC_CONNECTOR → PROTECTED_GATEWAY
PROTECTED_GATEWAY → INTERNAL_DOC_SERVICE.
7.9.54. C-48.46 - Prohibited Paths
The graph reveals two prohibited paths:
P1:
AGENT → SHELL → PYTHON_INTERPRETER → DIRECT_SOCKET → PUBLIC_NETWORK.
P2:
AGENT → CURL_EXECUTABLE → DIRECT_SOCKET → PUBLIC_NETWORK.
7.9.55. C-48.47 - Permitted Paths
The required permitted paths are:
T1:
AGENT → SHELL → LOCAL_COMPILER → LOCAL_OUTPUT.
T2:
AGENT → APPROVED_DOC_CONNECTOR → PROTECTED_GATEWAY →
INTERNAL_DOC_SERVICE.
7.9.56. C-48.48 - Restriction Alternatives
Possible restrictions include:
R1: Disable the shell.
R2: Disable the Python interpreter.
R3: Disable the curl executable.
R4: Remove direct network socket authority from the agent execution
domain.
Das Expires 25 April 2027 [Page 537]
Internet-Draft Sandbox Credential Egress Finality October 2026
R5: Disable all networking, including the approved documentation
gateway.
R6: Move the approved documentation connector into a separately
controlled service domain and restrict direct agent networking.
The compiler evaluates actual enforcement capabilities and task
impact.
7.9.57. C-48.49 - Selected Restriction
In one illustrative deployment, R4 is feasible because the agent
process namespace can be denied direct external network access while
the approved documentation gateway operates in a separately
controlled authority domain.
R4 interrupts both prohibited paths.
The permitted compiler path remains usable.
The protected documentation connector remains accessible through the
defined controlled interface.
The compiler may select R4 as a lower-cost feasible restriction under
the chosen objective.
If the documentation connector shares the same unrestricted socket
authority inside the agent namespace, this restriction must be
modeled differently.
The compiler cannot assume that disabling direct sockets leaves the
connector functional without examining the actual authority and
execution boundaries.
7.9.58. C-48.50 - Verification Result
After installing R4, the verifier checks:
1. The agent cannot reach PUBLIC_NETWORK through DIRECT_SOCKET. 2.
The local compiler remains reachable. 3. The approved documentation
connector remains reachable. 4. The gateway is subject to the
intended independent policy. 5. No relevant alternate socket or
privileged path remains enabled. 6. The installed effective
configuration corresponds to the compiled restriction.
Only after required verification succeeds may the execution
controller mark the sandbox
Das Expires 25 April 2027 [Page 538]
Internet-Draft Sandbox Credential Egress Finality October 2026
ACTIVE.
7.9.59. PART IX - CONFIGURATION COMPILATION
7.9.60. C-48.51 - Restriction Configuration Object
A representative compiled configuration comprises:
ConfigurationID = CONFIG-4801
AgentContextID = AGENT-42
TaskID = TASK-204
GraphGeneration = 620
EnvelopeGeneration = 105
SelectedRestrictions = { DENY_DIRECT_NETWORK_SOCKET,
ALLOW_CONTROLLED_DOC_CONNECTOR, RESTRICT_PRIVILEGED_HOST_INTERFACE }
RequiredTaskPathReferences = { LOCAL_COMPILER_PATH,
INTERNAL_DOCUMENTATION_PATH }
VerificationPolicy = VERIFY_EFFECTIVE_STATE
ConfigurationStatus = COMPILED.
7.9.61. C-48.52 - Installation Plan
The compiler may generate an ordered installation plan.
For example:
1. Create restricted process namespace. 2. Establish read-only
resource view. 3. Remove prohibited native network routes. 4.
Assign restricted service identity. 5. Register approved connector
interface. 6. Disable unauthorized privileged host commands. 7.
Apply required kernel policy. 8. Verify the installed effective
configuration. 9. Start the agent.
The order may differ according to deployment.
The execution controller must not expose the agent to prohibited
interfaces during installation.
Das Expires 25 April 2027 [Page 539]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.62. C-48.53 - Enforcement Mapping
Each selected graph restriction is mapped to a concrete enforcement
action.
For example:
Graph Restriction:
DENY_DIRECT_EXTERNAL_NETWORK
Possible Enforcement:
Agent network namespace with no unrestricted external route.
Graph Restriction:
DENY_PRIVILEGED_HOST_WRITE
Possible Enforcement:
Remove the relevant host service permission and protected file-write
interface.
Graph Restriction:
DISABLE_UNAUTHORIZED_CONNECTOR
Possible Enforcement:
Remove connector registration and deny its invocation at the
controlled dispatcher.
The mapping is verified for the actual platform.
7.9.63. C-48.54 - Configuration Installation Barrier
An Installation Barrier prevents agent execution under a partially
installed configuration.
A representative sequence is:
QUARANTINE AGENT
→ APPLY ALL REQUIRED RESTRICTIONS
→ VERIFY EFFECTIVE RESTRICTIONS
Das Expires 25 April 2027 [Page 540]
Internet-Draft Sandbox Credential Egress Finality October 2026
→ RECOMPUTE PROHIBITED REACHABILITY
→ VERIFY REQUIRED TASK PATHS
→ COMMIT CONFIGURATION GENERATION
→ ACTIVATE EXECUTION.
If installation or verification fails, the agent remains restricted.
7.9.64. C-48.55 - Effective-State Verification
The installer may report that a configuration operation succeeded.
The verifier independently determines whether the effective operating
state corresponds to the intended restriction.
For example, a network route removal request may succeed while
another route remains available.
The verifier therefore checks the effective routing and access
configuration relevant to the analyzed graph.
A successful installer return code alone is insufficient.
7.9.65. PART X - ALTERNATE-ROUTE CLOSURE
7.9.66. C-48.56 - Shell and Interpreter Chains
A shell may invoke an interpreter.
An interpreter may load a network library.
A library may use a system call capable of external transmission.
The compiler represents these reachable transitions.
Disabling a named upload command is insufficient if another
interpreter or library can produce the same prohibited effect.
7.9.67. C-48.57 - Browser Automation Chains
An agent may reach an external effect through:
AGENT
→ BROWSER TOOL
Das Expires 25 April 2027 [Page 541]
Internet-Draft Sandbox Credential Egress Finality October 2026
→ PAGE SCRIPT
→ NETWORK REQUEST.
The compiler identifies the browser's actual permitted network and
service interfaces.
A browser automation wrapper does not inherently remove the browser's
effect capabilities.
7.9.68. C-48.58 - Connector Chains
An agent may invoke Connector A.
Connector A may invoke Connector B.
Connector B may use privileged resource credentials.
The graph represents this chain.
The compiler may restrict Connector A, the delegation edge, Connector
B's authority, or the terminal resource interface.
The selected restriction must interrupt the prohibited path while
retaining required permitted connector functions.
7.9.69. C-48.59 - File-System Alias Chains
A protected file may be reachable through:
(a) its primary pathname; (b) a symbolic link; (c) a bind mount; (d)
an alternate mounted view; (e) an open descriptor; or (f) a
privileged helper.
The compiler uses stable resource identity and applicable handle
semantics where necessary to prevent a pathname-only restriction from
being bypassed.
7.9.70. C-48.60 - Existing Resource Handles
An agent may possess existing:
1. Network connections. 2. Open file descriptors. 3. Directory
handles. 4. Credential handles. 5. Mapped memory.
6. Device handles. 7. Queued jobs.
Das Expires 25 April 2027 [Page 542]
Internet-Draft Sandbox Credential Egress Finality October 2026
A restriction on new resource acquisition may not revoke an already
usable handle.
The compiler therefore identifies inherited or preexisting effect-
capable authority and includes it in the graph and installation
procedure.
7.9.71. PART XI - RUNTIME INTERFACE EXPANSION
7.9.72. C-48.61 - New Interface Event
A New Interface Event identifies the introduction of a previously
unavailable or materially changed operation interface.
Examples include:
NEW_EXECUTABLE
NEW_PACKAGE
NEW_PLUGIN
NEW_CONNECTOR
NEW_MOUNT
NEW_NETWORK_INTERFACE
NEW_PRIVILEGED_SERVICE
NEW_SERVICE_ROLE
NEW_DEVICE_MAPPING
NEW_DELEGATED_WORKER.
7.9.73. C-48.62 - Default Quarantine
A newly introduced effect-capable interface is not made available to
the agent until the required graph update and restriction
verification succeed.
A representative state machine comprises:
DISCOVERED
QUARANTINED
Das Expires 25 April 2027 [Page 543]
Internet-Draft Sandbox Credential Egress Finality October 2026
CLASSIFIED
GRAPH_UPDATED
RESTRICTIONS_COMPILED
INSTALLING
VERIFIED
ACTIVE
REJECTED.
A tool may be installed as inert content without becoming available
for effect-capable execution.
7.9.74. C-48.63 - Runtime Expansion Barrier
The runtime controller prevents an expansion event from creating an
unverified permitted path.
A representative ordering is:
DETECT NEW INTERFACE
→ RESTRICT ACCESS
→ UPDATE DISCOVERY INVENTORY
→ UPDATE EFFECT-PATH GRAPH
→ CLASSIFY NEW EFFECT CAPABILITIES
→ RECOMPILE RESTRICTIONS
→ INSTALL UPDATED CONFIGURATION
→ VERIFY PROHIBITED PATH CLOSURE
→ ACTIVATE IF PERMITTED.
The same principle may apply to connector replacement or service-
account expansion.
Das Expires 25 April 2027 [Page 544]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.75. C-48.64 - Tool Package Installation
An agent may request installation of a package.
The package may introduce executable files, dynamic libraries, new
services, network helpers, or plugin interfaces.
The system may permit downloading or storing package content under an
appropriate restriction while withholding execution or privileged
access until the updated graph has been analyzed.
The package's stated metadata is not automatically proof of its
complete effect capabilities.
7.9.76. C-48.65 - Dynamic Interface Update
If an existing connector acquires a new API method, the system may
treat the new method as an interface-expansion event.
The relevant connector graph edges are updated.
The compiler determines whether the new method introduces a
prohibited effect path.
If so, it derives an enforceable restriction.
7.9.77. C-48.66 - Revocation of Old Configuration
When a new configuration becomes active, the protected controller may
advance a configuration generation.
Previously approved interfaces or cached execution permissions
associated with an invalid earlier generation are not automatically
accepted.
The execution controller maintains the appropriate relationship
between the active graph, installed restrictions, and actual agent
environment.
7.9.78. PART XII - GRAPH CONSISTENCY AND CONCURRENCY
7.9.79. C-48.67 - Graph Generation
A Graph Generation represents the discovered interface and authority
state on which restriction compilation was performed.
A representative record comprises:
Das Expires 25 April 2027 [Page 545]
Internet-Draft Sandbox Credential Egress Finality October 2026
GraphGeneration
InventoryDigest
AuthorityContextDigest
ToolRegistryDigest
MountConfigurationDigest
NetworkConfigurationDigest
ConnectorConfigurationDigest
PolicyGeneration
The graph is associated with a bounded deployment configuration.
7.9.80. C-48.68 - Configuration Generation
A Configuration Generation identifies the installed restriction set
derived from a particular graph and authorized effect envelope.
The relationship may be represented as:
ConfigurationGeneration
→ GraphGeneration
→ EnvelopeGeneration
→ SelectedRestrictionSet
→ VerifiedEffectiveState.
The controller verifies that the active environment has not
materially diverged from the configuration being enforced.
7.9.81. C-48.69 - Concurrent Interface Changes
Multiple changes may occur during compilation.
For example, a new connector may be installed while the compiler
analyzes the prior inventory.
The implementation may:
Das Expires 25 April 2027 [Page 546]
Internet-Draft Sandbox Credential Egress Finality October 2026
1. Lock the relevant configuration state. 2. Use a versioned
snapshot. 3. Record interface-change events occurring during
compilation. 4. Detect generation mismatch before activation. 5.
Recompute against the current state. 6. Keep new interfaces
quarantined until verified.
The compiled configuration is not activated as current when it was
derived from an obsolete material graph state.
7.9.82. C-48.70 - Graph Completeness and Enforcement Assumptions
The reachability analysis is performed over the graph actually
constructed.
A proof that no prohibited path exists in that graph is not, by
itself, proof that all real-world effect-capable interfaces have been
modeled.
A stronger guarantee requires:
(a) sufficiently complete trusted interface discovery; or (b)
technical default-deny enforcement preventing unregistered interfaces
from becoming available; or (c) a combination thereof.
The enforcement point's required closed-path property must correspond
to the actual deployment's enforcement assumptions.
7.9.83. PART XIII - COMPLETE 34-STEP WORKFLOW
7.9.84. C-48.71 - Principal Workflow
7.9.85. Step C48-01 - Task definition
Obtain the authorized task and its required functional capabilities.
7.9.86. Step C48-02 - Authority-envelope establishment
Establish the authorized effect envelope.
7.9.87. Step C48-03 - Agent execution-context identification
Identify the agent, isolation domain, and relevant delegated
authority.
7.9.88. Step C48-04 - Quarantine initialization
Keep the agent from accessing unverified effect-capable interfaces.
Das Expires 25 April 2027 [Page 547]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.89. Step C48-05 - Tool inventory
Discover reachable executable programs and tools.
7.9.90. Step C48-06 - Resource inventory
Discover file, network, service, credential, and privileged resource
interfaces.
7.9.91. Step C48-07 - Authority inventory
Obtain relevant process, service-account, and delegated permissions.
7.9.92. Step C48-08 - Graph node construction
Create typed graph nodes.
7.9.93. Step C48-09 - Graph edge construction
Create operation-transition and authority edges.
7.9.94. Step C48-10 - Effect classification
Associate applicable effect classes with nodes and edges.
7.9.95. Step C48-11 - Graph-generation commitment
Record the analyzed inventory and graph generation.
7.9.96. Step C48-12 - Prohibited terminal identification
Identify effects outside the authorized envelope.
7.9.97. Step C48-13 - Permitted task-path identification
Identify required authorized task functions and acceptable paths.
7.9.98. Step C48-14 - Reachability analysis
Determine whether prohibited effect paths are reachable.
7.9.99. Step C48-15 - Counterexample extraction
Identify representative prohibited paths.
Das Expires 25 April 2027 [Page 548]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.100. Step C48-16 - Restriction candidate discovery
Identify available enforceable restrictions.
7.9.101. Step C48-17 - Restriction feasibility verification
Exclude unsupported restriction mechanisms.
7.9.102. Step C48-18 - Optimization model construction
Create path-separation and task-preservation constraints.
7.9.103. Step C48-19 - Restriction optimization
Compute a feasible or optimized restriction set.
7.9.104. Step C48-20 - Post-restriction graph evaluation
Verify that the proposed restrictions interrupt prohibited paths in
the model.
7.9.105. Step C48-21 - Permitted-path verification
Verify that required task functionality remains available.
7.9.106. Step C48-22 - Machine-enforceable configuration generation
Compile the selected restrictions into deployment-specific
configuration.
7.9.107. Step C48-23 - Protected installation staging
Prepare the required operating-system or service controls.
7.9.108. Step C48-24 - Restriction installation
Apply the machine-enforceable configuration.
7.9.109. Step C48-25 - Effective-state inspection
Read back or otherwise verify installed enforcement state.
7.9.110. Step C48-26 - Post-installation reachability verification
Check the graph under the verified effective configuration.
Das Expires 25 April 2027 [Page 549]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.111. Step C48-27 - Negative enforcement testing
Where required, test representative prohibited access attempts.
7.9.112. Step C48-28 - Configuration-generation commitment
Record the successfully verified configuration.
7.9.113. Step C48-29 - Agent activation
Start or continue agent execution under the installed configuration.
7.9.114. Step C48-30 - Runtime interface monitoring
Detect relevant changes to the available interface set.
7.9.115. Step C48-31 - Expansion quarantine
Prevent new unverified interfaces from becoming effect-capable.
7.9.116. Step C48-32 - Incremental graph update
Recompute affected reachability relationships.
7.9.117. Step C48-33 - Configuration recompilation and verification
Derive and install updated restrictions.
7.9.118. Step C48-34 - Continued execution or suspension
Continue under verified restrictions or keep the affected execution
context restricted.
7.9.119. PART XIV - REFERENCE ALGORITHMS
7.9.120. C-48.72 - Algorithm A: Tool-and-Resource Discovery
function DiscoverAgentEffectInterfaces(environment):
inventory = NewProtectedInventory()
contexts = EnumerateAgentAccessibleContexts(environment)
for each context in contexts:
inventory.add(
DiscoverExecutables(context) )
Das Expires 25 April 2027 [Page 550]
Internet-Draft Sandbox Credential Egress Finality October 2026
inventory.add(
DiscoverFilesystemInterfaces(context) )
inventory.add( DiscoverNetworkInterfaces(context) )
inventory.add( DiscoverServiceConnectors(context)
)
inventory.add(
DiscoverCredentialAndAuthorityContexts(context) )
inventory.add(
DiscoverPrivilegedHostInterfaces(context) )
inventory.add(
DiscoverDelegatedWorkers(context) )
inventory.add(
DiscoverRelevantExistingHandles(context)
)
if not VerifyRequiredDiscoveryCoverage(inventory):
return DISCOVERY_INCOMPLETE return
CommitVersionedInventory(inventory)
The actual collection mechanisms depend upon the selected execution
platform.
C-48.73 - Algorithm B: Effect-Path Graph Construction
function BuildEffectPathGraph(inventory):
graph = DirectedTypedGraph()
for each interface in inventory.interfaces:
graph.addNode({
Das Expires 25 April 2027 [Page 551]
Internet-Draft Sandbox Credential Egress Finality October 2026
id: interface.id, type: ClassifyNodeType(interface), effect_classes:
ClassifyEffectCapabilities(interface), authority_context:
interface.authority_reference })
for each relationship in inventory.relationships:
graph.addEdge({
source: relationship.source, destination: relationship.destination,
transition_type: relationship.operation_class, guard:
relationship.authority_conditions, enforcement_reference:
relationship.enforcement_id
})
graph.resolveAliasesByStableResourceIdentity()
graph.attachConfigurationGeneration(
inventory.generation )
return graph
The graph constructor must define how unknown transitions and
unsupported effect classes are represented.
7.9.121. C-48.74 - Algorithm C: Prohibited Reachability
function FindProhibitedEffectPath(
graph, agent_sources, prohibited_effects, current_restrictions ):
effective_graph = ApplyRestrictionModel(
graph, current_restrictions )
queue = InitializeReachabilityWorklist(agent_sources) visited =
EmptySet()
while queue is not empty:
state = Pop(queue)
if state in visited:
continue
Add(visited, state)
Das Expires 25 April 2027 [Page 552]
Internet-Draft Sandbox Credential Egress Finality October 2026
if ReachesProhibitedEffect(
state, prohibited_effects ):
return ReconstructPath(state)
for each edge in EnabledOutgoingEdges(
effective_graph, state
):
next_state = ApplyEdgeAuthoritySemantics(
state, edge )
if next_state is not invalid:
Push(queue, next_state)
return NO_PROHIBITED_PATH_FOUND
Where authority guards require richer state, the traversal state
includes the relevant authorization context instead of merely the
graph node identifier.
C-48.75 - Algorithm D: Restriction Candidate Generation
function GenerateRestrictionCandidates(
prohibited_path, enforcement_catalog ):
candidates = EmptySet()
for each edge in prohibited_path:
mechanisms = enforcement_catalog.lookup(edge)
for each mechanism in mechanisms:
if not mechanism.is_enforceable:
continue
candidate = BuildRestrictionCandidate({
Das Expires 25 April 2027 [Page 553]
Internet-Draft Sandbox Credential Egress Finality October 2026
target_edge: edge, enforcement_mechanism: mechanism, task_impact:
EstimateTaskImpact(mechanism), installation_cost:
mechanism.installation_cost })
candidates.add(candidate)
return candidates
A selected restriction must map to an actual enforceable interface.
C-48.76 - Algorithm E: Counterexample-Guided Restriction Compilation
function CompileEffectPathRestrictions(
graph, authorized_envelope, enforcement_catalog ):
constraints = InitializePolicyConstraints(
authorized_envelope )
restriction_candidates = BuildAvailableRestrictions(
graph, enforcement_catalog )
while true:
selected = SolveWeightedRestrictionProblem(
restriction_candidates, constraints )
if selected == INFEASIBLE:
return INFEASIBLE if not PreservesRequiredTaskPaths(
graph, selected, authorized_envelope ):
constraints.add(
ExplainRequiredPathViolation(selected) ) continue prohibited_path =
FindProhibitedEffectPath(
graph, authorized_envelope.agent_sources,
authorized_envelope.prohibited_effects, selected )
if prohibited_path == NO_PROHIBITED_PATH_FOUND:
return selected blockers = GenerateRestrictionCandidates(
prohibited_path, enforcement_catalog
Das Expires 25 April 2027 [Page 554]
Internet-Draft Sandbox Credential Egress Finality October 2026
)
if blockers is empty:
return INFEASIBLE
constraints.add(
AtLeastOneRestrictionFrom(blockers) )
The optimization may use exact or heuristic solving.
A practical implementation uses iteration limits and returns a
restrictive outcome if the solver cannot establish the required
feasible solution within the configured resource budget.
7.9.122. C-48.77 - Algorithm F: Task-Preservation Verification
function PreservesRequiredTaskPaths(
graph, restrictions, authorized_envelope ):
effective_graph = ApplyRestrictionModel(
graph, restrictions )
for each task_function in authorized_envelope.required_functions:
permitted_paths = ResolveAcceptableTaskPaths(
task_function, effective_graph )
if permitted_paths is empty:
return FALSE
if not ExistsPolicyValidTaskPath(permitted_paths):
return FALSE
return TRUE
Task preservation is evaluated under the same effective restriction
model used for prohibited reachability.
Das Expires 25 April 2027 [Page 555]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.123. C-48.78 - Algorithm G: Configuration Compilation
function CompileMachineEnforceableConfiguration(
graph, selected_restrictions, enforcement_catalog ):
configuration = NewSandboxConfiguration()
for each restriction in selected_restrictions:
mechanism = enforcement_catalog.resolve(
restriction )
if mechanism is unavailable:
return COMPILATION_FAILED
native_rule = TranslateToNativeEnforcementRule(
restriction, mechanism )
if not VerifyNativeRuleSemantics(native_rule):
return COMPILATION_FAILED
configuration.add(native_rule)
configuration.bind({
graph_generation: graph.generation, restriction_digest:
HashCanonical(selected_restrictions) })
return configuration
The compiler must not silently translate a required denial into a
weaker logging-only control.
C-48.79 - Algorithm H: Atomic or Quarantined Installation
function InstallAndVerifySandboxConfiguration(
agent_context, configuration ):
QuarantineAgentEffectuation(agent_context)
if not VerifyConfigurationGeneration(configuration):
Das Expires 25 April 2027 [Page 556]
Internet-Draft Sandbox Credential Egress Finality October 2026
return DENIED
install_result = ApplyNativeRestrictions(
agent_context, configuration )
if install_result != SUCCESS:
MaintainQuarantine(agent_context) return DENIED effective_state =
ReadBackEffectiveEnforcementState(
agent_context )
if not VerifyInstalledRuleCorrespondence(
configuration, effective_state ):
MaintainQuarantine(agent_context) return DENIED
if not VerifyProhibitedPathClosure(
agent_context, effective_state ):
MaintainQuarantine(agent_context) return DENIED
if not VerifyRequiredTaskAvailability(
agent_context, effective_state ):
MaintainQuarantine(agent_context) return DENIED
CommitProtectedConfigurationGeneration(
agent_context, configuration )
ActivateAgentWithinVerifiedSandbox(agent_context)
return ACTIVE
Quarantine prevents an unsafe partial-installation state from
becoming effect-capable.
7.9.124. C-48.80 - Algorithm I: Runtime Interface Expansion
function ProcessNewInterfaceEvent(
agent_context, interface_event ):
Das Expires 25 April 2027 [Page 557]
Internet-Draft Sandbox Credential Egress Finality October 2026
if not VerifyTrustedInterfaceEvent(interface_event):
SuspendAffectedExecution(agent_context) return DENIED
QuarantineNewInterface(interface_event)
current_generation = ReadCurrentGraphGeneration(
agent_context )
updated_inventory = UpdateProtectedInterfaceInventory(
interface_event )
updated_graph = RebuildAffectedGraphRegion(
updated_inventory )
compilation = CompileEffectPathRestrictions(
updated_graph, CurrentAuthorizedEffectEnvelope(agent_context),
AvailableEnforcementCatalog() )
if compilation == INFEASIBLE:
KeepNewInterfaceQuarantined(interface_event) return DENIED if
CurrentGraphGeneration(agent_context) != current_generation:
return RECOMPILE_REQUIRED configuration =
CompileMachineEnforceableConfiguration(
updated_graph, compilation, AvailableEnforcementCatalog() )
if not InstallAndVerifyUpdatedConfiguration(
agent_context, configuration ):
KeepNewInterfaceQuarantined(interface_event) return DENIED
ActivateNewInterfaceUnderVerifiedPolicy(interface_event)
return ACTIVE
The implementation must coordinate concurrent interface changes so
that a stale graphgeneration comparison cannot authorize an unsafe
configuration.
Das Expires 25 April 2027 [Page 558]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.125. C-48.81 - Algorithm J: Alternate-Route Verification
function VerifyAlternateRouteClosure(
graph, restrictions, prohibited_effects ):
effective_graph = ApplyRestrictionModel(
graph, restrictions )
for each source in AgentAccessibleSources(effective_graph):
result = FindProhibitedEffectPath(
effective_graph, {source}, prohibited_effects, EmptyRestrictionSet()
)
if result != NO_PROHIBITED_PATH_FOUND:
return {
status: UNCOVERED, counterexample_path: result }
return COVERED_FOR_ANALYZED_GRAPH
The result is limited to the modeled graph and applicable discovery
and enforcement assumptions.
C-48.82 - Algorithm K: Restriction Optimization With Costs
function OptimizeRestrictionSet(
graph, candidate_restrictions, authorized_envelope ):
variables = CreateBinaryRestrictionVariables(
candidate_restrictions )
objective = WeightedSum(
variables, TaskImpactAndEnforcementCosts(candidate_restrictions) )
constraints = CreateMandatoryPolicyConstraints()
constraints.add(
PreserveAuthorizedTaskFunctions(authorized_envelope) )
Das Expires 25 April 2027 [Page 559]
Internet-Draft Sandbox Credential Egress Finality October 2026
solution = SolveOptimizationModel(
variables, objective, constraints )
while solution is feasible:
witness = FindRemainingProhibitedPath(
graph, solution, authorized_envelope )
if witness is NONE:
return solution
constraints.add(
RequireCutOfPath(witness) )
solution = ResolveOptimizationModel(
variables, objective, constraints )
return INFEASIBLE
A solver that exhausts its configured resource budget must return an
appropriately restrictive result rather than activating an unverified
configuration.
C-48.83 - Algorithm L: Configuration Drift Detection
function VerifyActiveSandboxConfiguration(agent_context):
committed = ProtectedConfigurationRegistry.get(
agent_context )
actual = ReadCurrentEffectiveEnforcementState(
agent_context )
if not VerifyConfigurationCorrespondence(
committed, actual ):
RestrictAgentEffectuation(agent_context) return CONFIGURATION_DRIFT
if DetectUnregisteredEffectCapableInterface(
Das Expires 25 April 2027 [Page 560]
Internet-Draft Sandbox Credential Egress Finality October 2026
agent_context ):
RestrictAgentEffectuation(agent_context) return INTERFACE_EXPANSION
if not VerifyCurrentAuthorityAndPolicyGeneration(
agent_context, committed ):
RestrictAgentEffectuation(agent_context) return
POLICY_REVALIDATION_REQUIRED
return VERIFIED
The verification frequency and trigger events depend upon the
selected threat model and enforcement architecture.
7.9.126. PART XV - WORKED TECHNICAL EXAMPLES
7.9.127. C-48.84 - Example A: Shell-Based Network Bypass
The following is a hypothetical implementation example.
An AI coding agent must compile a local software project.
The agent may execute a shell and compiler.
The agent must not transmit source code to unauthorized external
services.
The Discovery Engine identifies that the shell can invoke an
interpreter with network access.
The graph reveals:
AGENT → SHELL → INTERPRETER → NETWORK_SOCKET → PUBLIC_NETWORK.
The compiler determines that removing the agent's direct external
network authority interrupts the prohibited path while preserving
shell-based compilation.
The compiled restriction is installed and verified.
The agent can compile the project but cannot use the interpreter to
transmit source code through the prohibited route.
C-48.85 - Example B: Browser Automation Indirect Effect
An agent is permitted to browse an internal knowledge service.
Das Expires 25 April 2027 [Page 561]
Internet-Draft Sandbox Credential Egress Finality October 2026
The browser automation interface also permits navigation to
unauthorized external destinations.
The graph represents the browser's network and navigation
capabilities.
The compiler determines that an origin-restricted browser gateway or
equivalent enforced navigation policy can preserve approved knowledge
access while preventing the prohibited external route.
The installation verifier checks the effective browser or network
policy.
7.9.128. C-48.86 - Example C: Privileged Connector Chain
An agent can invoke Connector A.
Connector A can invoke a privileged Connector B.
Connector B can modify cloud administrator roles.
The assigned task does not authorize administrator-role modification.
The graph identifies the indirect prohibited path.
The compiler may restrict Connector B's administrator operation while
retaining Connector A's ordinary read operations.
The enforcement configuration is installed at the relevant connector
or resource permission interface.
The prohibited cloud-administration path is no longer reachable under
the verified configuration.
7.9.129. C-48.87 - Example D: File-System Alias
An agent is prohibited from modifying a protected configuration file.
The file is accessible under two pathnames through separate mounts.
A pathname-only rule blocks the first path but not the second.
The graph generator resolves both paths to a common underlying
resource identity.
The compiler identifies the remaining modification path and selects a
restriction applying to the appropriate underlying resource or both
aliases.
Das Expires 25 April 2027 [Page 562]
Internet-Draft Sandbox Credential Egress Finality October 2026
The verifier confirms that the protected file cannot be modified
through either represented route.
C-48.88 - Example E: New Package Installed During Runtime
An agent is operating within a previously verified sandbox.
The agent installs a package containing a network-capable executable.
The Runtime Expansion Monitor detects the new executable.
The executable remains unavailable for agent execution.
The graph is updated to include the executable and its potential
network transitions.
The compiler determines whether existing restrictions already
interrupt the prohibited paths.
If the restrictions remain sufficient, the executable may be made
available under the verified policy.
Otherwise, updated restrictions are installed before activation.
7.9.130. C-48.89 - Example F: New API Connector
An enterprise agent receives access to a newly registered API
connector.
The connector includes read-only and resource-modification methods.
Only read operations are authorized for the current task.
The graph identifies the connector's method-level effects.
The compiler restricts the resource-modification methods while
retaining the permitted read methods.
The updated configuration is verified.
The agent gains the new permitted capability without receiving
unrestricted connector authority.
7.9.131. C-48.90 - Example G: Minimal Restriction Selection
An agent requires local compilation, test execution, and approved
documentation access.
Das Expires 25 April 2027 [Page 563]
Internet-Draft Sandbox Credential Egress Finality October 2026
The graph reveals three prohibited routes sharing one direct network
authority.
Disabling all interpreters would interrupt the routes but prevent
compilation or testing.
Disabling direct agent network authority interrupts the prohibited
routes while leaving protected documentation access available through
a separate approved gateway.
Under the selected weights, the solver chooses the lower-disruption
network restriction.
The verifier confirms both prohibited-path closure and required task-
path preservation.
7.9.132. C-48.91 - Example H: Infeasible Restriction Set
An agent is required to run a legacy tool that performs both an
authorized local operation and an unauthorized external transmission
through inseparable code.
The available platform cannot restrict the tool's network function
without preventing the required local operation.
The compiler determines that no feasible restriction set preserves
the designated task path and interrupts the prohibited effect.
The system reports infeasibility and withholds unrestricted
execution.
The operator may provide a replacement tool or move the legacy tool
behind a separate enforced service boundary.
7.9.133. C-48.92 - Example I: Container Mount Expansion
A running container receives a new host directory mount.
The directory contains a protected resource.
The mount is initially quarantined from the agent's accessible file-
system view.
The graph is updated.
The compiler identifies whether the mount creates a prohibited
persistent-modification path.
Das Expires 25 April 2027 [Page 564]
Internet-Draft Sandbox Credential Egress Finality October 2026
The updated restrictions are installed and verified before the mount
becomes available.
C-48.93 - Example J: Cloud Service-Account Privilege Change
An agent uses a cloud service identity with limited resource
permissions.
An administrative change grants an additional privileged API action.
The discovery controller detects the changed entitlement.
The graph acquires new authority edges.
The compiler identifies a newly reachable prohibited resource
operation.
The service-account policy or connector interface is restricted.
The agent continues operating only after the current configuration is
verified.
7.9.134. C-48.94 - Example K: Existing Open Network Socket
An agent previously opened a network connection before a new
restriction was installed.
A configuration change removes permission to create new sockets.
However, the existing socket remains capable of transmitting.
The graph includes the existing connection as an effect-capable
handle.
The compiler identifies that new-socket denial alone is insufficient.
The installation procedure applies a suitable existing-connection
restriction or blocks the associated send path.
The verifier confirms the prohibited transmission is no longer
reachable.
7.9.135. C-48.95 - Example L: Delegated Worker Bypass
An AI agent delegates computation to a privileged worker.
The worker possesses native access to a prohibited persistent
resource.
Das Expires 25 April 2027 [Page 565]
Internet-Draft Sandbox Credential Egress Finality October 2026
The graph includes the delegation edge and the worker's resource
authority.
The compiler may restrict the delegated operation interface, reduce
the worker's resource entitlement, or place the worker behind a
controlled gateway.
A restriction applied only to the original agent process is not
treated as sufficient.
7.9.136. PART XVI - FAILURE AND ADVERSARIAL CASES
7.9.137. C-48.96 - Representative Failure Conditions
7.9.138. F1 - Unknown Executable
An effect-capable executable is absent from the discovered inventory.
Required closed-world or default-deny enforcement prevents unverified
execution.
7.9.139. F2 - Shell Wrapper Bypass
An agent invokes a prohibited effect through a shell wrapper.
The graph represents indirect invocation and the compiled restriction
interrupts the path.
7.9.140. F3 - Interpreter Bypass
A permitted interpreter reaches a prohibited resource.
The relevant authority or resource edge is restricted.
7.9.141. F4 - Browser Automation Bypass
A browser can produce an unauthorized external operation.
The browser's actual effect-capable interface is represented and
restricted.
7.9.142. F5 - Connector Chain
A permitted connector delegates to a privileged connector.
Indirect effect reachability is evaluated.
Das Expires 25 April 2027 [Page 566]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.143. F6 - File-System Alias
A protected resource is reachable through another pathname or mount.
Stable resource identity prevents an alias-only omission.
7.9.144. F7 - Privileged Host Worker
A delegated worker possesses more native authority than the
requesting agent.
The graph represents the privileged authority transition.
7.9.145. F8 - Existing File Descriptor
An earlier file handle permits a prohibited write.
The handle is included in the reachable effect-path model.
7.9.146. F9 - Existing Socket
A previously established connection remains capable of transmission.
The compiler addresses the existing effect-capable route.
7.9.147. F10 - New Package
Package installation introduces executable capabilities.
Activation is withheld pending graph update and verification.
7.9.148. F11 - New Plugin
A plugin expands tool functionality.
The plugin remains quarantined until restrictions are verified.
7.9.149. F12 - New Connector
A connector registration adds a resource-modifying operation.
The compiler recomputes affected path restrictions.
7.9.150. F13 - New Mount
A mount exposes a previously unavailable resource.
The new path is evaluated before access is enabled.
Das Expires 25 April 2027 [Page 567]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.151. F14 - New Network Interface
A network interface creates an alternate route.
The updated reachability model includes the route.
7.9.152. F15 - Service-Role Expansion
A delegated identity receives additional resource permissions.
The graph and restriction configuration are re-evaluated.
7.9.153. F16 - Unsupported Restriction Primitive
The solver selects a restriction that the platform cannot enforce.
The compiler rejects the candidate and recomputes or reports
infeasibility.
7.9.154. F17 - Telemetry-Only Rule
A proposed native enforcement mapping merely logs the effect.
The mapping is rejected where preventive control is required.
7.9.155. F18 - Stale Graph Generation
The configuration was compiled before a material interface change.
The activation controller rejects the stale generation.
7.9.156. F19 - Partial Installation
Some restrictions are installed while others fail.
The agent remains quarantined.
7.9.157. F20 - Enforcement Policy Removed
A required native restriction is disabled after activation.
Configuration-drift detection restricts the affected execution
context.
7.9.158. F21 - Incorrect Task-Preservation Model
A selected restriction disables a mandatory task path.
Das Expires 25 April 2027 [Page 568]
Internet-Draft Sandbox Credential Egress Finality October 2026
The verifier rejects the configuration under the required task-
preservation condition.
7.9.159. F22 - Optimization Timeout
The solver cannot complete within its configured resource limit.
The system does not activate an unverified restriction set.
7.9.160. F23 - Infeasible Task Envelope
No enforceable restriction set satisfies both security and required
task constraints.
The system reports infeasibility.
7.9.161. F24 - Graph Cycle
The reachable graph contains loops.
Fixed-point or visited-state traversal prevents nontermination.
7.9.162. F25 - Unknown Connector Effects
A connector's effect capabilities are not sufficiently specified.
The conservative policy restricts the interface or requires
verification.
7.9.163. F26 - Resource Identity Confusion
Two aliases identify the same underlying resource.
The graph canonicalizes the applicable resource identity.
7.9.164. F27 - Concurrent Interface Addition
A new interface appears during optimization.
Generation coordination prevents activation under a stale graph.
7.9.165. F28 - Concurrent Permission Change
A service-account permission changes while configuration installation
proceeds.
The final effective state is reverified.
Das Expires 25 April 2027 [Page 569]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.166. F29 - Restriction Rollback
An earlier permissive sandbox configuration is restored.
Protected configuration-generation checks reject prohibited stale
activation.
7.9.167. F30 - Direct Hardware Access
An agent obtains a device route not represented by its software tool
graph.
The discovery and authority model includes the relevant device
capability or restricts unregistered device access.
7.9.168. F31 - Privilege Escalation
An execution context acquires new authority edges.
The current configuration becomes subject to revalidation.
7.9.169. F32 - Asynchronous Job Path
A queued worker can produce a prohibited effect later.
The graph and restrictions include the applicable delegated execution
route.
7.9.170. F33 - Dynamic Library Loading
A permitted process loads a library with new effect-capable
interfaces.
The selected policy determines whether the interface requires
expansion verification.
7.9.171. F34 - False Configuration Readback
An untrusted component enforcement points restrictions are installed.
The verifier uses appropriately protected effective-state evidence.
7.9.172. F35 - Sandbox Escape
An agent reaches a host-level effectuation interface outside the
selected isolation boundary.
Das Expires 25 April 2027 [Page 570]
Internet-Draft Sandbox Credential Egress Finality October 2026
The implementation must provide appropriate host isolation or
restrict the relevant escape path.
7.9.173. F36 - Unmodeled Cross-Service Effect
An apparently read-only service call triggers a downstream side
effect.
The implementation must classify the known indirect effect or use a
conservative policy when the relevant behavior is uncertain.
7.9.174. F37 - Optimization Cost Manipulation
An untrusted component supplies manipulated restriction-cost weights.
Protected policy controls the optimization objective and mandatory
security constraints.
7.9.175. F38 - Incorrect Graph Edge Removal
A restriction is modeled as removing an edge but does not actually
prevent the transition.
Post-installation verification detects the inconsistency.
7.9.176. F39 - Task Path Exists Only Abstractly
A permitted path exists in the graph but fails under actual deployed
permissions.
Effective-state and functional verification reject the incorrect
configuration.
7.9.177. F40 - Newly Accessible Credential
A credential becomes available through a new environment variable,
file, or broker interface.
The authority graph is updated before governed use is permitted.
| PART XVII - IMPLEMENTATION VARIATIONS C-48.97 - Process Sandbox The compiler derives restrictions for process execution, file access, network interfaces, IPC, and privileged operations. The configuration is installed using supported operating-system enforcement mechanisms. |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-48.98 - Container Sandbox The compiler uses container images, mounts, namespaces, capabilities, and connector configurations as graph inputs. It produces restrictions affecting the container's accessible resources. |
| C-48.99 - Micro-VM Sandbox The agent executes inside a micro-VM. The compiler identifies guest-to-host, virtual device, network, file, and delegated service paths. The configuration installer applies guest and host restrictions within the selected architecture. |
Das Expires 25 April 2027 [Page 571]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.178. C-48.100 - Cloud-Hosted Sandbox
The graph includes cloud identities, API connectors, service
entitlements, storage interfaces, and delegated functions.
The compiler produces cloud permissions and connector restrictions.
7.9.179. C-48.101 - Kernel-Enforced Sandbox
Selected graph restrictions are mapped to kernel-supported
enforcement primitives.
The verifier checks actual policy installation and the relevant
supported enforcement semantics.
7.9.180. C-48.102 - Browser-Agent Sandbox
The graph includes browser navigation, extensions, downloads,
uploads, automation interfaces, and service connectors.
| |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The compiler restricts unauthorized effects while retaining permitted browsing functions. |
| C-48.103 - Enterprise Connector Sandbox The graph includes tool schemas, connector identities, API methods, service accounts, and downstream resources. The compiler removes prohibited connector operations and authority paths. |
| C-48.104 - Hybrid Software-Hardware Sandbox The graph includes effect-capable device assignments, hardware queues, DMA interfaces, network adapters, and relevant software control paths. The installer uses appropriate device restrictions where supported. |
| C-48.105 - Multi-Agent Delegation Sandbox The graph includes multiple agents and delegated workers. The compiler evaluates indirect paths through task delegation and shared privileged services. Restrictions may be applied to the originating agent, worker, connector, or resource controller. |
7.9.181. C-48.106 - Integrated Protected Finality Variation
The compiled sandbox restrictions may be combined with operation-
specific PED and Finality Sink controls.
In this optional variation, permitted effect paths remain subject to
additional protected finality authorization.
This combined arrangement is not a mandatory requirement of the
independent static restriction-compilation enforcement point.
7.9.182. PART XVIII - REPRESENTATIVE DATA STRUCTURES
7.9.183. C-48.107 - ToolResourceInventoryRecord
Fields may include:
1. InventoryID. 2. AgentContextID. 3. TaskID. 4.
ExecutionEnvironmentID. 5. ToolReferences. 6. ResourceReferences.
7. ConnectorReferences. 8. AuthorityReferences. 9.
ConfigurationGeneration. 10. InventoryDigest.
Das Expires 25 April 2027 [Page 572]
Internet-Draft Sandbox Credential Egress Finality October 2026
7.9.184. C-48.108 - EffectGraphNodeRecord
Fields may include:
1. NodeID. 2. NodeType. 3. ResourceOrInterfaceID. 4.
EffectClasses. 5. AuthorityContext. 6. ExecutionDomain. 7.
ConfigurationGeneration. 8. NodeValidityStatus.
7.9.185. C-48.109 - EffectGraphEdgeRecord
Fields may include:
1. EdgeID.
2. 3. 4. 5. 6. 7. 8. 9.
SourceNodeID. DestinationNodeID. TransitionClass. GuardPredicate.
AuthorityRequirements. CurrentEnabledState. EnforcementReference.
ConfigurationGeneration.
7.9.186. C-48.110 - AuthorizedEffectEnvelopeRecord
Fields may include:
1. EnvelopeID. 2. AgentContextID. 3. TaskID. 4.
PermittedEffectClasses. 5. PermittedDestinations. 6.
ProhibitedEffectClasses. 7. RequiredTaskFunctions. 8.
AuthorizedResourceScopes. 9. PolicyGeneration. 10. EnvelopeStatus.
7.9.187. C-48.111 - RestrictionCandidateRecord
Fields may include:
1. RestrictionID. 2. TargetNodeOrEdge. 3. RestrictionType. 4.
NativeEnforcementInterface. 5. CoveredGraphTransitions. 6.
TaskDisruptionCost. 7. InstallationCost. 8. RuntimeOverheadCost. 9.
FeasibilityStatus. 10. VerificationProcedure.
7.9.188. C-48.112 - RestrictionOptimizationRecord
Fields may include:
1. OptimizationID.
Das Expires 25 April 2027 [Page 573]
Internet-Draft Sandbox Credential Egress Finality October 2026
2. GraphGeneration. 3. EnvelopeGeneration. 4.
CandidateRestrictionSet. 5. SecurityConstraints. 6.
TaskPreservationConstraints. 7. ObjectiveWeights. 8.
SelectedRestrictionSet. 9. OptimizationStatus. 10.
CounterexampleReferences.
7.9.189. C-48.113 - CompiledSandboxConfigurationRecord
Fields may include:
1. ConfigurationID. 2. AgentContextID. 3. GraphGeneration. 4.
EnvelopeGeneration. 5. SelectedRestrictionDigest. 6.
NativePolicyRules. 7. InstallationPlan. 8.
RequiredVerificationChecks. 9. ConfigurationGeneration. 10.
ConfigurationStatus.
7.9.190. C-48.114 - ConfigurationVerificationRecord
Fields may include:
1. VerificationID. 2. ConfigurationID. 3.
InstalledEffectiveStateDigest. 4. ProhibitedReachabilityResult. 5.
RequiredTaskPathResult. 6. NativeEnforcementStatus. 7.
NegativeTestReferences. 8. VerificationGeneration. 9.
VerificationOutcome.
7.9.191. C-48.115 - RuntimeExpansionEventRecord
Fields may include:
1. EventID.
2. AgentContextID. 3. InterfaceClass. 4. NewInterfaceIdentity. 5.
PreviousGraphGeneration. 6. ProposedGraphGeneration. 7.
QuarantineStatus. 8. RequiredRecompilationStatus. 9.
VerificationResult. 10. ActivationStatus.
7.9.192. C-48.116 - ProtectedConfigurationStateRecord
Fields may include:
1. AgentContextID. 2. ActiveConfigurationID. 3. GraphGeneration.
4. EnvelopeGeneration. 5. InstalledRestrictionDigest. 6.
VerifiedEffectiveStateDigest. 7. CurrentPolicyGeneration. 8.
RuntimeExpansionGeneration. 9. ExecutionState. 10.
ContinuityReference.
Das Expires 25 April 2027 [Page 574]
Internet-Draft Sandbox Credential Egress Finality October 2026
These records may be implemented in protected databases,
authenticated registries, privileged configuration services, secure
execution monitors, or other deployment-specific components.
7.9.193. PART XIX - ENGINEERING TESTS
7.9.194. C-48.117 - Proposed Verification Matrix
The following tests are proposed procedures, not representations of
completed experiments.
7.9.195. Test Condition
T1 Direct prohibited effect path T2 Indirect shell path T3
Interpreter-mediated effect path T4 Browser-mediated prohibited
effect T5 Multi-connector privileged path T6 Delegated worker effect
path T7 File-system alias T8 Existing socket T9 Existing file
descriptor
7.9.196. Expected result
Identified Identified Identified Identified Identified Identified
Underlying resource recognized Included in effect model Included in
effect model
T10 Unknown effect-capable interface T11 Graph cycle T12 Authority-
dependent edge T13 Feasible restriction set T14 Infeasible security/
task constraints T15 Restriction candidate unsupported T16 Multiple
prohibited paths T17 Required task path T18 Overly broad restriction
T19 Weighted optimization T20 Solver timeout T21 Machine
configuration generated T22 Native policy installation T23 Partial
installation failure T24 Installed rule is logging-only T25
Prohibited path remains after installation T26 Required task path
lost T27 New package T28 New executable T29 New plugin T30 New
connector method T31 New mount T32 New network interface T33 Service-
account expansion T34 Privileged host command introduced T35
Concurrent interface update T36 Configuration-generation rollback T37
Enforcement rule removed T38 Connector replacement T39 Protected
resource alias changed T40 New delegated worker T41 Existing
connection survives policy change Relevant send effect restricted T42
Unverified graph discovery coverage T43 Dynamic tool removed T44
Privilege escalation T45 Approved internal service preserved T46
Prohibited direct external network T47 Installer falsely reports
success T48 New prohibited path introduced at runtime Quarantine and
recompilation
Das Expires 25 April 2027 [Page 575]
Internet-Draft Sandbox Credential Egress Finality October 2026
Restricted or classified conservatively Reachability algorithm
terminates Correct conditional reachability Computed Infeasibility
reported Not selected All interrupted Preserved Optimization
evaluates task impact Objective calculated correctly Unverified
configuration not activated Supported native rules Effective-state
verification Agent remains quarantined Not accepted as preventive
restriction Activation denied Configuration rejected or recompiled
Interface quarantined Graph updated before activation Required
verification Effect graph updated Resource reachability re-evaluated
Alternate route analyzed New authority edges considered Prohibited
paths checked Stale configuration rejected Invalid state detected
Drift detected Updated graph compiled New reachability analyzed
Indirect authority evaluated
Activation withheld Restrictions re-evaluated where appropriate
Configuration requires revalidation Task function remains available
Effect technically unavailable Effective-state check detects mismatch
A test harness should establish the precise graph, interface
inventory, native permissions, candidate restrictions, expected
reachable effects, and observable enforcement outcomes.
The verifier should distinguish modeled reachability correctness from
the separate correctness of the inventory and platform enforcement
configuration.
7.9.197. PART XX - Enforcement-Point Mapping and Technical
Correspondence
7.9.198. C-48.118 - Independent enforcement point(s) corresponding to
source item(s) 48
The embodiment provides corresponding implementation mechanisms for:
enforcement point(s) corresponding to source item(s) 48(a): Tool-and-
resource discovery across executables, system calls, file systems,
network interfaces, connectors, delegation, and privileged host
services.
enforcement point(s) corresponding to source item(s) 48(b): Directed
graph construction with typed executable, resource, authority,
interface, and effect nodes.
enforcement point(s) corresponding to source item(s) 48(c): Effect
classification covering external transmission, persistent
modification,
Das Expires 25 April 2027 [Page 576]
Internet-Draft Sandbox Credential Egress Finality October 2026
credential use, execution, service invocation, and privileged
resource modification.
enforcement point(s) corresponding to source item(s) 48(d)(i): Task-
specific authorized effect envelope.
enforcement point(s) corresponding to source item(s) 48(d)(ii): Graph
analysis identifying paths to prohibited effects.
enforcement point(s) corresponding to source item(s) 48(d)(iii):
Derivation of interface restrictions, resource separations, and
authority
reductions interrupting prohibited paths while preserving required
task execution.
enforcement point(s) corresponding to source item(s) 48(d)(iv):
Compilation into machine-enforceable sandbox restrictions.
enforcement point(s) corresponding to source item(s) 48(e):
Configuration installation in process, file-system, network, kernel,
connector,
service-identity, and privileged-host enforcement interfaces.
enforcement point(s) corresponding to source item(s) 48(f):
Verification of installed restrictions and prohibited-path closure.
enforcement point(s) corresponding to source item(s) 48(g): Agent
activation or continuation only under the verified installed
configuration.
Final requirement: Technical restriction of prohibited interfaces
rather than reliance solely
upon an agent's instructions.
Dynamic requirement: Updated restriction compilation following
introduction of new
prohibited effect paths.
7.9.199. C-48.119 - Dependent enforcement point(s) corresponding to
source item(s) 49: Alternate-Route Closure
The embodiment provides:
1. Shell wrapper paths. 2. Interpreter chains.
Das Expires 25 April 2027 [Page 577]
Internet-Draft Sandbox Credential Egress Finality October 2026
3. Browser automation paths. 4. Plugin-mediated effects. 5. File-
system aliases. 6. Service connector chains. 7. Delegated
processes. 8. Authority-context transitions. 9. Multi-interface
reachability. 10. Detection of prohibited effects reachable through
individually permitted interfaces.
C-48.120 - Dependent enforcement point(s) corresponding to source
item(s) 50: Runtime Interface Expansion
The embodiment provides:
1. New-tool detection. 2. Package expansion detection. 3. Plugin
registration detection. 4. Connector additions. 5. New executable
discovery. 6. Mounted-resource changes. 7. New service interfaces.
8. Interface quarantine. 9. Graph-generation updates. 10.
Restriction recompilation. 11. Effective configuration installation.
12. Verification before activation.
C-48.121 - Dependent enforcement point(s) corresponding to source
item(s) 51: Minimal Restriction Set
The embodiment provides:
1. Enforceable restriction candidates. 2. Restriction coverage of
graph paths. 3. Task-disruption cost. 4. Weighted objective
functions. 5. Mandatory prohibited-path separation. 6. Preservation
of required task paths. 7. Exact or approximate optimization
methods. 8. Counterexample-guided refinement. 9. Infeasibility
handling. 10. Independent verification of the resulting restricted
graph. 11. Post-installation validation. 12. Distinction between
feasible and globally optimal solutions.
7.9.200. PART XXI - IMPLEMENTATION REQUIREMENTS
7.9.201. C-48.122 - implementer Implementation Checklist
For a concrete implementation, a person having ordinary skill in the
art identifies:
1. The agent execution environment. 2. The applicable trusted
computing base. 3. The attacker capabilities. 4. The authorized
task. 5. The task-specific effect envelope. 6. The effect classes
requiring restriction. 7. The tool discovery interfaces. 8. The
executable inventory method. 9. The system-call and kernel resource
inventory. 10. The file-system identity and alias model. 11. The
network interface and routing inventory. 12. The connector registry.
13. The delegated-worker inventory. 14. The privileged-host
interface inventory. 15. The authority-context representation. 16.
Das Expires 25 April 2027 [Page 578]
Internet-Draft Sandbox Credential Egress Finality October 2026
The graph node schema. 17. The graph edge schema. 18. The
conditional reachability predicates. 19. The graph generation and
continuity mechanism. 20. The prohibited terminal-effect
definitions. 21. The permitted task-function constraints. 22. The
graph traversal or symbolic reachability algorithm. 23. The
treatment of cycles. 24. The treatment of unknown transitions. 25.
The enforcement capability catalog. 26. The restriction candidate
schema. 27. The restriction feasibility checks. 28. The cost and
optimization criteria. 29. The path-separation constraints. 30. The
task-preservation constraints. 31. The optimization solver or
heuristic. 32. The infeasibility and solver-timeout policy. 33. The
native restriction compiler. 34. The configuration installation
barrier. 35. The effective-state readback. 36. The prohibited-path
verification procedure. 37. The permitted-task-path verification
procedure. 38. The negative enforcement tests. 39. The runtime
expansion detection mechanism. 40. The new-interface quarantine
method. 41. The incremental graph update procedure. 42. The
configuration-generation transition. 43. The protection against
concurrent interface changes. 44. The configuration-drift detection
procedure. 45. The state recovery and rollback rules. 46. The
platform-specific enforcement guarantees.
47. The verification tests demonstrating the required enforcement
point properties.
The implementation must use actual supported platform primitives for
the selected restrictions.
A formal graph-cut solution alone is insufficient when the native
sandbox cannot enforce the selected cut.
7.9.202. C-48.123 - Technical Effect
this implementation profile enables construction of an artificial-
intelligence-agent execution environment in which prohibited
consequential effects are made technically unreachable through
compiled sandbox restrictions.
The system identifies direct and indirect effect-capable operation
paths, including combinations of executables, interpreters,
connectors, resource interfaces, and delegated authority contexts.
A restriction compiler derives an enforceable configuration
interrupting identified prohibited paths while preserving authorized
task functionality.
An optimization procedure may reduce unnecessary loss of useful tools
or interfaces.
Das Expires 25 April 2027 [Page 579]
Internet-Draft Sandbox Credential Egress Finality October 2026
The configuration installer applies the selected restrictions to
actual supported enforcement components.
A configuration-verification mechanism checks that the installed
effective state interrupts prohibited paths represented in the
analyzed graph.
Runtime interface-expansion controls prevent newly installed tools,
connectors, mounts, or resource permissions from becoming available
before required recompilation and verification.
The architecture can therefore reduce reliance upon agent self-
restraint while preserving selected permitted computational
capabilities.
The strength of the guarantee depends upon the completeness of the
relevant interface inventory, accuracy of the graph abstraction, and
enforceability of the installed restrictions.
7.9.203. C-48.124 - Technical Summary
this implementation profile discloses a computer-implemented system
for constructing and enforcing an effect-restricted execution
environment for artificial-intelligence agents.
A Tool-and-Resource Discovery Engine identifies executable programs,
resource interfaces, network capabilities, file-system resources,
service connectors, delegated execution components, and privileged
host interfaces accessible directly or indirectly to an agent.
An Effect-Path Graph Generator constructs a directed representation
of the relevant operation transitions and authority relationships.
An Effect Classification Engine identifies effects comprising
external transmission, persistent-state modification, credential use,
process execution, service invocation, and privileged-resource
modification.
A Restriction Compiler obtains a task-specific Authorized Effect
Envelope and determines whether prohibited effect-capable resources
remain reachable.
The compiler derives enforceable restrictions interrupting prohibited
paths while preserving authorized task-execution paths.
A machine-enforceable configuration is installed through available
operating-system, kernel, namespace, connector, service-account, or
privileged host controls.
Das Expires 25 April 2027 [Page 580]
Internet-Draft Sandbox Credential Egress Finality October 2026
A Configuration Verification Engine establishes whether the installed
restrictions interrupt the represented prohibited paths.
An Execution Controller starts or continues the agent only under the
verified restriction configuration.
The system further supports alternate-route closure, runtime
interface quarantine, incremental graph recompilation, optimization
of restriction sets, and configuration-drift detection.
In contrast to operation-specific protected finality embodiments,
this technical arrangement may prevent selected prohibited effects by
eliminating their reachable technical paths before agent execution,
without requiring a new protected validation receipt or scoped
finality capability for every otherwise permitted action.
7.9.203.1. DEFERRED-EFFECT-AWARE IDENTITY AUTHORIZATION FOR AUTONOMOUS
ARTIFICIAL-INTELLIGENCE AGENTS USING OUTSTANDING-
7.9.203.2. OPERATION LIABILITY REGISTERS, PROJECTED RESOURCE EXPOSURE,
HIERARCHICAL DELEGATION ACCOUNTING, ENTITLEMENT
7.9.203.3. CONTRACTION, AND REVOCATION-SAFE ASYNCHRONOUS EXECUTION
8. Security Considerations
Threats include compromised agent workloads, mutation or replay of
candidate operations, stale policy generations, incomplete
enforcement-path coverage, hardware in-flight operations after host
termination, direct resource access, incomplete queue fencing, and
false assertions of containment completion. Each deployment profile
must state which interfaces it can actually control and which effects
may remain unresolved. Sandbox isolation and credential hiding do
not on their own prove operation-specific authorization.
9. Privacy Considerations
Protected receipts, lineage records, operation descriptors, access
histories, and observation streams may themselves reveal sensitive
details. Implementations should apply data minimization,
confidentiality controls, retention limits, and explicit
authorization to the disclosure of such evidence.
10. IANA Considerations
This document requests no IANA actions.
11. Informative References
Das Expires 25 April 2027 [Page 581]
Internet-Draft Sandbox Credential Egress Finality October 2026
[I-D.das-agent-execution-finality]
Das, S., "Protected Execution-Finality Architecture for AI
and Autonomous Systems: Act-Bound Capabilities and
Effectuation-Boundary Verification", Work in Progress,
Internet-Draft, draft-das-agent-execution-finality-00,
October 2026, .
[I-D.das-distributed-agent-authority-finality]
Das, S., "Distributed Authority and Execution-Finality for
Multi-Agent Systems, Delegated Operations, and Cross-
Domain Gateways", Work in Progress, Internet-Draft, draft-
das-distributed-agent-authority-finality-00, October 2026,
.
[I-D.das-kernel-hardware-execution-finality]
Das, S., "Protected Execution-Finality Enforcement for
Autonomous AI Agents Across Kernel, Hypervisor, Hardware,
and Native-Resource Boundaries", Work in Progress,
Internet-Draft, draft-das-kernel-hardware-execution-
finality-00, October 2026,
.
Author's Address
Sangam Kumar Das
Independent Inventor
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 25 April 2027 [Page 582]