Internet-Draft Kernel-Hardware Execution Finality October 2026
Das Expires 25 April 2027 [Page]
Workgroup:
Individual Submission
Internet-Draft:
draft-das-kernel-hardware-execution-finality-00
Published:
Intended Status:
Informational
Expires:
Author:
S. Das
Independent Inventor

Protected Execution-Finality Enforcement for Autonomous AI Agents Across Kernel, Hypervisor, Hardware, and Native-Resource Boundaries

Abstract

This document describes a proposed execution-finality architecture for autonomous agent workloads at kernel, hypervisor, device, and native-resource effectuation boundaries. It distinguishes computation from authority to commit consequential effects, and documents protected validation, operation-bound evidence, scoped authorization, independent finality verification, revocation, and containment, alongside deployment profiles and illustrative algorithms and tests.

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.

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/.

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.

▲

Table of Contents

1. Introduction

Autonomous AI agents may produce operations that invoke operating-system services, hypervisor interfaces, network devices, native resource engines, and accelerator queues. Isolation of computation does not in itself establish authorization for each consequential resource effect. This document examines execution-finality enforcement across these interfaces. It is offered for technical discussion as an individual informational architecture, not as a claim that any identified industry product implements the full model.

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 7; 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.
  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 (S-1 in draft-das-sandbox-credential-egress-finality), 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:

This document (draft-das-kernel-hardware-execution-finality) concentrates on the kernel, hypervisor, device, and native-resource boundary: the point at which an operation becomes effective inside an operating-system interface, a resource engine, a hardware queue, a DMA or accelerator path, or device memory. 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/. 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.

Table 1
Profile Subject Published in
S-1 Virtual-machine-isolated agent sandbox with protected execution authority draft-das-sandbox-credential-egress-finality
S-2 Micro-VM-isolated execution with lifecycle-bound authority and asynchronous continuity draft-das-sandbox-credential-egress-finality
S-3 Container-isolated execution with tool-dispatch control, credential mediation, and egress finality draft-das-sandbox-credential-egress-finality
S-4 Process-isolated execution with process-lineage control and handle mediation draft-das-sandbox-credential-egress-finality
S-5 Kernel- and hypervisor-mediated enforcement with non-bypassable effectuation control this document
S-6 Cloud-hosted, API-gateway-mediated, and distributed execution with cross-domain authority binding draft-das-distributed-agent-authority-finality
S-7 Hardware-rooted, cryptographically isolated execution with attested validation this document
S-8 SmartNIC, DPU, GPU, and accelerator sandbox with DMA isolation, cross-device epoch fencing, and memory sanitization this document
C-09 Inline transaction finality with atomic authorization-state transitions this document
C-15 Multi-agent influence-lineage governance draft-das-distributed-agent-authority-finality
C-21 Continuous sandbox execution with bounded finality windows draft-das-sandbox-credential-egress-finality
C-33 Effectuation-path completeness and coverage-state commitment draft-das-sandbox-credential-egress-finality
C-42 Process-lineage taint propagation and transitive authority restriction draft-das-sandbox-credential-egress-finality
C-45 Post-DNS-resolution network-egress finality draft-das-sandbox-credential-egress-finality
C-48 Compilation of effect-path reachability restrictions draft-das-sandbox-credential-egress-finality
C-52 Deferred-effect-aware identity authorization draft-das-distributed-agent-authority-finality
C-56 Transitive effect-closure admission for API requests draft-das-distributed-agent-authority-finality
C-60 Atomic projected-state authorization in native resource engines this document
C-64 Post-effect causal containment and selective remediation draft-das-distributed-agent-authority-finality
C-68 Source-separated human transaction reconstruction draft-das-distributed-agent-authority-finality
C-72 Cross-protocol authorization-semantics preservation draft-das-distributed-agent-authority-finality
C-76 Hardware-resident deferred-effect budget accounting this document
C-80 Memory-class authority isolation for persistent agents draft-das-distributed-agent-authority-finality
C-84 Coordinated kernel and hardware containment this document
C-88 Distributed authority contraction with convergence barriers draft-das-distributed-agent-authority-finality
C-89 Independence-verified guardian-agent supervision draft-das-distributed-agent-authority-finality
C-90 Observation-coverage attestation draft-das-distributed-agent-authority-finality
C-91 Side-effect-suppressed model migration draft-das-distributed-agent-authority-finality
C-92 Partition-safe governance across disconnected domains draft-das-distributed-agent-authority-finality
C-94 Live agent-tool replacement with differential validation draft-das-distributed-agent-authority-finality
C-95 Cross-agent effect-collision detection and scheduling draft-das-distributed-agent-authority-finality
C-96 Task-preserving context minimization across providers draft-das-distributed-agent-authority-finality
C-98 Counterfactual policy deployment with canary rollout draft-das-distributed-agent-authority-finality
C-99 Selective erasure and non-revival of derived memory draft-das-distributed-agent-authority-finality

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/) 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 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:

1.4.2. What This Draft Set Discloses

This draft set extends earlier mechanisms in the following ways:

It also introduces the following mechanism families, which are not the subject of the earlier drafts listed above:

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.

3. Problem Statement and Security Objectives

The governed operation may leave an isolated workload via file operations, host system calls, IPC, native database or payment engines, virtual devices, GPU output paths, DMA, accelerator queues, or other effect-capable boundaries. A security decision made exclusively at planning time may not bind the actual pending operation at the later effectuation point. In-flight operations, caching, stale versions, shared hardware, and concurrent activity complicate containment.

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.

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 S-1 in draft-das-sandbox-credential-egress-finality, Section 7.4.
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 Section 7.4, C-45 in draft-das-sandbox-credential-egress-finality.
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 C-33 in draft-das-sandbox-credential-egress-finality, C-48 in draft-das-sandbox-credential-egress-finality.
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 S-3 in draft-das-sandbox-credential-egress-finality, C-21 in draft-das-sandbox-credential-egress-finality.
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-bearing instructions. Addressed in C-15 in draft-das-distributed-agent-authority-finality, C-42 in draft-das-sandbox-credential-egress-finality, C-80 in 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, C-56 in 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 Section 7.5, C-95 in 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, Section 7.3.
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 and reduce authority when coverage is insufficient. Addressed in C-90 in 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.
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 Section 7.7, Section 7.6.
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 Section 7.3.
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.
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 effects and activate it only under compatible conditions. Addressed in C-91 in draft-das-distributed-agent-authority-finality, C-94 in 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.
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.
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.
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.
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, failed, and indeterminate outcomes using stable operation identities and resource-side evidence. Addressed in C-21 in draft-das-sandbox-credential-egress-finality, C-92 in draft-das-distributed-agent-authority-finality, C-95 in 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.
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, Section 7.7, Section 7.3.

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 kernel, hypervisor, device, and native-resource boundary: the point at which an operation becomes effective inside an operating-system interface, a resource engine, a hardware queue, a DMA or accelerator path, or device memory, which corresponds principally to problems P1, P7, P11, P12, and P21.

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;
  • 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 attestation of the enforcement substrate and of device state (related to RATS), hardware and device-level authority generations, containment signalling across queues, and verification results reported by native resource engines.

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:

  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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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:

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.

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.

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:

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.

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.

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:

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.

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-5, S-7, S-8, C-09, C-60, C-76, C-84. 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.

7.1. Implementation Profile S-5

Source location: original disclosure pages 234-278. 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-5.1 - Technical Field

this implementation profile relates to operating-system security, kernel-mediated execution control, hypervisor-mediated resource protection, artificial-intelligence-agent security, protected authorization, hardware-assisted isolation, system-call interception, resource-access mediation, and enforcement of consequential operations.

More particularly, the embodiment describes a computing architecture in which one or more artificial-intelligence agents execute within an operating-system or virtualized execution environment while security-critical operations are intercepted, restricted, or authorized by one or more kernel, hypervisor, firmware, hardware, or cooperating protected enforcement components.

In representative protected-finality implementations, a proposed consequential operation is prevented from producing its specified effect until the applicable protected authorization conditions have been evaluated and a Finality Sink verifies the required authorization state for the actual pending operation.

The enforcement mechanism may be implemented using:

(a) operating-system kernel security mechanisms; (b) system-call mediation; (c) mandatory access-control interfaces; (d) kernel security hooks; (e) Linux Security Modules; (f) supported eBPF enforcement mechanisms; (g) hypervisor-level interception; (h) virtual-machine device mediation; (i) memory protection mechanisms;

(j) hardware security modules;

(k) trusted execution environments;

(l) programmable network devices;

(m) storage and input/output controllers; or

(n) combinations thereof.

The architecture is not limited to a particular operating system, hypervisor, CPU instruction set, virtualization vendor, processor manufacturer, or hardware security product.

7.1.2. S-5.2 - Technical Problem

An artificial-intelligence agent may execute through ordinary processes, containers, virtual machines, generated code, tool workers, browser automation, or delegated software services.

Such execution may ultimately produce consequential operations through operating-system and hardware interfaces.

Examples include:

| x | System calls.                   |
| - | ------------------------------- |
| x | File writes.                    |
| x | Network transmissions.          |
| x | Process creation.               |
| x | Credential access.              |
| x | Shared-memory modifications.    |
| x | Device-control commands.        |
| x | Database transactions.          |
| x | Storage operations.             |
| x | Accelerator command submission. |
| x | Hardware input/output.          |
| x | External service invocations.   |

Operating-system access controls may restrict particular operations according to identities, security labels, resource permissions, or kernel policies.

However, an operating-system permission does not necessarily establish that an operation is authorized under a particular agent task, protected resource state, transaction context, or execution-finality requirement.

Furthermore, an operation may cross several technical boundaries before producing its consequential effect.

For example, an agent may issue a write system call to a local buffer, a privileged service may later read the buffer, and the service may then transmit data to an external endpoint.

Blocking only the initial write operation may not enforce authorization of the eventual transmission.

Conversely, allowing the initial write operation need not authorize the subsequent external effect.

A related problem arises when kernel or hypervisor components observe an operation but do not control the interface through which the final consequential effect occurs.

this implementation profile addresses these distinctions by establishing a protected relationship between the intercepted operation, applicable authorization state, protected validation evidence, scoped finality enablement, and the actual effectuation boundary.

7.1.3. S-5.3 - Technical Objectives

The embodiment provides representative mechanisms for:

1. Intercepting specified operations at kernel or hypervisor enforcement interfaces. 2. Identifying the originating agent, workload, and execution context. 3. Distinguishing observation from enforceable authorization control. 4. Establishing non-effective staging for governed consequential operations. 5. Performing protected authorization independently of untrusted agent-controlled code. 6. Maintaining protected authority and revocation state. 7. Committing protected validation evidence. 8. Establishing a scoped non-bearer finality capability. 9. Verifying the actual pending operation at a controlled Finality Sink. 10. Preventing unauthorized effectuation through alternative kernel, device, or virtualized interfaces. 11. Coordinating authorization with hardware and firmware enforcement where necessary. 12. Addressing stale process state, asynchronous execution, resource aliasing, and timeof-check/time-of-use races. 13. Preserving required enforcement guarantees during policy updates, restart, suspension, migration, and recovery. 14. Supporting kernel-only, hypervisor-assisted, hardware-backed, and distributed enforcement arrangements.

The exact mechanisms required in any implementation depend upon the applicable enforcement points and the selected consequential effects.

7.1.4. PART I - PRINCIPAL SYSTEM ARCHITECTURE

7.1.5. S-5.4 - Principal Components

A representative system comprises the following functional components.

7.1.6. Component A - Computing Platform

A computing device including one or more processors, memory resources, storage interfaces, device controllers, and communication interfaces.

The platform may comprise a physical server, workstation, cloud computing node, edge computer, mobile device, embedded platform, or cyber-physical controller.

7.1.7. Component B - Operating-System Kernel

A privileged software component responsible for managing processes, memory, input/output, resource access, and selected security decisions.

7.1.8. Component C - Optional Hypervisor

A virtualization component configured to supervise guest execution, virtual processors, memory mappings, virtual devices, or selected privileged operations.

7.1.9. Component D - Artificial-Intelligence-Agent Execution Context

A process, group of processes, container, virtual machine, delegated worker, generated executable, model runtime, or other computational workload operating under an agentassociated task context.

7.1.10. Component E - Kernel Enforcement Interface

An operating-system enforcement point configured to inspect, restrict, deny, redirect, or otherwise control a specified class of operations.

7.1.11. Component F - Hypervisor Enforcement Interface

A virtualization-level enforcement component capable of controlling specified guest operations, virtual devices, memory accesses, or privileged execution transitions.

7.1.12. Component G - Execution-Context Attribution Controller

A mechanism configured to associate operations with authenticated agent, workload, process, virtual-machine, delegation, or task contexts.

7.1.13. Component H - Candidate Act Interceptor

A component configured to identify a consequential operation subject to the applicable protected-finality procedure.

7.1.14. Component I - Non-Effective Operation Holder

A staging mechanism configured to withhold the specified consequential effect while the required authorization procedure is performed.

7.1.15. Component J - Protected Enforcement Domain

A PED configured to evaluate the required authority predicates and maintain or access protected authorization state.

7.1.16. Component K - Protected Validation Evidence Controller

A mechanism configured to generate or commit the validation evidence required by the applicable enforcement point.

7.1.17. Component L - Scoped Finality Enablement Controller

A protected mechanism configured to establish bounded non-bearer finality authority for the validated operation.

7.1.18. Component M - Finality Sink

An enforcement component having effective control over the specified consequential operation.

7.1.19. Component N - Protected State Registry

A registry configured to maintain authority generations, revocation states, operation identities, authorization references, and applicable consumption states.

7.1.20. Component O - Effectuation-Path Coverage Controller

A mechanism configured to identify and restrict alternative paths capable of producing the same governed effect without the required authorization.

7.1.21. Component P - Operation Recovery Controller

A component configured to maintain or reconcile operation state during crashes, concurrent execution, asynchronous dispatch, device failure, or authority revocation.

The listed roles may be implemented by one component, multiple protected components, or cooperating software and hardware elements when the applicable enforcement point permits such arrangements.

7.1.22. S-5.5 - Representative Kernel-Mediated Architecture

In one implementation, an artificial-intelligence agent operates as an ordinary user-space process.

The agent generates a consequential operation, such as a request to modify a protected file or transmit data through a controlled network interface.

A kernel-mediated enforcement interface intercepts the operation.

The system obtains the authenticated execution context and determines whether the requested operation requires protected finality.

If protected finality is required, the system prevents the operation from producing the governed effect and constructs a Candidate Act Descriptor.

The PED evaluates the applicable authorization predicates.

Following successful validation, protected evidence is committed and bounded finality enablement is established.

The Finality Sink verifies the actual operation and required authorization before permitting effectuation.

The Finality Sink may reside within a kernel-controlled interface, host-side service, protected device driver, hypervisor backend, dedicated security processor, or controlled hardware resource.

7.1.23. PART II - KERNEL ENFORCEMENT

7.1.24. S-5.6 - Kernel Enforcement Boundary

A Kernel Enforcement Boundary means an operating-system-controlled interface or operation transition at which the kernel can enforce a restriction on a specified operation before the governed consequence occurs.

Such a boundary may include:

(a) an access-control decision associated with opening a file;

(b) a permission decision associated with a resource object;

(c) a controlled network operation;

(d) a process-execution permission decision;

(e) a protected credential-use interface;

(f) an applicable memory-management operation;

(g) a supported device-access restriction; or

(h) another enforceable kernel-mediated resource operation.

The boundary is defined by the effect it controls rather than merely by the existence of a hook or instrumentation point.

A kernel hook that observes a network connection attempt does not necessarily control every subsequent application message sent through an established connection.

Similarly, permission to open a file does not necessarily amount to independent authorization of every future modification performed through an existing descriptor.

7.1.25. S-5.7 - System-Call Mediation

The system may identify consequential operations through selected system-call interfaces.

Examples include system calls relating to:

| x | File access.                |
| - | --------------------------- |
| x | File modification.          |
| x | Network connection.         |
| x | Network transmission.       |
| x | Process creation.           |
| x | Privilege modification.     |
| x | Device control.             |
| x | Memory mapping.             |
| x | Interprocess communication. |
| x | Resource configuration.     |

A system-call mediation mechanism may deny an operation, restrict permitted parameters, require use of a protected broker, or impose a supported authorization decision.

7.1.26. S-5.7.1 - System-call limitation

A system call may represent only part of a higher-level operation.

For example, a permitted socket write may form part of a larger application transaction whose exact resource semantics are not visible at the selected kernel interface.

Accordingly, the system must use an enforcement interface capable of verifying the material attributes required by the applicable enforcement point.

Where an application-specific transaction must be authorized, the system may require a controlled application-level broker or resource Finality Sink.

7.1.27. S-5.8 - Linux Security Module Implementation

In a Linux implementation, an applicable Linux Security Module may enforce selected access-control decisions.

The LSM may restrict operations according to:

(a) process security identity; (b) resource security identity; (c) permitted operation class; (d) security label; (e) task-associated restriction; (f) protected policy state; or (g) other information available to the supported enforcement interface.

In one variation, an LSM policy prevents an agent process from directly modifying a protected resource and requires the operation to be performed through a controlled host-side service.

In another variation, a suitable LSM enforcement hook participates directly in the authorization procedure for an operation class it can actually control.

7.1.28. S-5.8.1 - Protected-domain relationship

An LSM does not automatically constitute a PED merely because it performs a permission check.

Where the kernel and its security state are protected from the defined attacker, a kernel enforcement component may implement PED functions consistent with the selected trust model.

Where the enforcement point requires additional cryptographic isolation or protection against a compromised host kernel, an LSM alone may be insufficient.

7.1.29. S-5.8.2 - Authorization state

The kernel enforcement component may maintain:

| x | Current policy generation.                  |
| - | ------------------------------------------- |
| x | Agent-associated security context.          |
| x | Resource permission state.                  |
| x | Revocation generation.                      |
| x | Operation-specific authorization reference. |
| x | Resource-state version.                     |
| x | Protected operation status.                 |

The implementation must specify which of these fields are relied upon and how unauthorized processes are prevented from modifying them.

7.1.30. S-5.9 - eBPF Observation and Enforcement

An implementation may employ eBPF programs to observe or, at supported attachment points, enforce selected kernel security decisions.

eBPF-based observations may contribute to:

1. Process attribution. 2. Runtime behavioral descriptors. 3. Network activity characterization. 4. Resource-access histories. 5. Process-lineage information. 6. Detection of security-relevant execution events.

A supported enforcement-capable attachment point may also permit a program to deny or restrict particular operations.

7.1.31. S-5.9.1 - Observation is not enforcement

An eBPF tracepoint or tracing program that records an event after or during execution does not inherently prevent the consequential effect.

The implementation must distinguish between a telemetry mechanism and a control path capable of enforcing a decision.

7.1.32. S-5.9.2 - Application semantic limitation

A kernel-level eBPF program may observe socket addresses, process attributes, or selected packet information without possessing a reliable representation of an application's final resource request.

Where authorization depends on an HTTP body, cloud resource identity, payment beneficiary, or other application-specific field, the system must provide a trustworthy mechanism for obtaining and verifying that field.

7.1.33. S-5.9.3 - Configuration integrity

The security architecture may restrict unauthorized detachment, replacement, or modification of enforcement programs.

If the assumed attacker can disable the enforcement mechanism, the claimed protection property may fail.

The corresponding embodiment must identify the protection against such interference.

7.1.34. S-5.10 - Kernel-Controlled Protected State

A software-only implementation may maintain protected state in kernel memory or in a privileged service whose modification is restricted by the operating system.

A representative protected state structure includes:

KernelAuthorityStateID

AgentExecutionContextID

CurrentAuthorityGeneration

CurrentRevocationGeneration

PermittedOperationClass

ProtectedEvidenceReference

AuthorizedSinkReference

ConsumptionState

StateTransitionSequence

The protection is evaluated relative to the defined threat model.

Kernel-memory residency does not automatically establish resistance to a kernel-level attacker.

A stronger implementation may move selected security-critical state into hardware-protected storage or a cryptographically isolated enforcement component.

7.1.35. PART III - HYPERVISOR ENFORCEMENT

7.1.36. S-5.11 - Hypervisor-Mediated Execution

A hypervisor may control one or more guest virtual machines executing agent workloads.

The hypervisor may enforce restrictions using:

(a) virtualization of privileged processor operations; (b) guest memory protection; (c) virtual device emulation or mediation; (d) controlled virtual network interfaces; (e) protected virtual storage interfaces;

(f) device assignment restrictions;

(g) selected virtual-machine exits; and

(h) other virtualization mechanisms supported by the platform.

The hypervisor may act as a trusted enforcement component relative to a less-trusted guest.

7.1.37. S-5.11.1 - Trust separation

A guest operating-system administrator may be treated as untrusted relative to the hypervisor.

The architecture may therefore prevent the guest from directly modifying hypervisorcontrolled authorization state.

However, a hypervisor is not automatically protected against compromise of its own privileged execution components.

Hardware-backed protection may be required for stronger adversarial assumptions.

7.1.38. S-5.12 - Hypervisor Interception

The hypervisor may control selected guest operations through virtualized interfaces.

1. 2. 3. 4. 5. 6. 7. 8.

Examples include:

Virtual network-device transmission. Virtual storage-device requests. Protected memory-mapping changes. Device-assignment operations. Virtual peripheral command submission. Selected privileged instruction transitions. Hypervisor-controlled service calls. Access to emulated hardware resources.

A hypervisor-controlled backend may capture a proposed operation before permitting its specified consequential effect.

The resulting Candidate Act can be associated with the guest identity, workload execution generation, and protected task context.

7.1.39. S-5.12.1 - Actual effect boundary

A hypervisor may observe a guest issuing a command without necessarily controlling every subsequent physical effect.

For example, if a device has been assigned directly to a guest through a hardware passthrough arrangement, some commands may bypass ordinary hypervisor device emulation.

Where the selected enforcement point requires non-bypassable finality, the deployment must account for such direct device access.

7.1.40. S-5.13 - Second-Stage Memory Protection

A hypervisor may employ second-stage address translation or another supported memory protection mechanism to restrict guest access to selected physical-memory regions.

Such protection may separate:

| x | Guest memory.                        |
| - | ------------------------------------ |
| x | Hypervisor memory.                   |
| x | Protected authorization records.     |
| x | Device-control memory.               |
| x | Shared-memory communication regions. |

An implementation may use memory access restrictions to protect security-critical authorization state from guest modification.

Memory protection alone does not establish that all external operations satisfy task-specific authorization.

The protected-finality mechanism may therefore operate in addition to memory isolation.

7.1.41. S-5.14 - Hypervisor-Controlled Device Backend

In one implementation, a virtual device backend acts as a controlled effectuation interface.

A guest submits a device operation through a virtualized command queue.

The hypervisor or backend captures the operation and prevents the governed physical effect while authorization is pending.

The operation is converted into a Candidate Act Descriptor.

The PED evaluates the required predicates.

After protected evidence commitment and scoped authorization, the Finality Sink verifies the actual device operation.

Only an authorized command is transmitted to the underlying physical device.

7.1.42. S-5.14.1 - Alternative backend

A virtual device may have multiple backends, failover routes, or physical interfaces.

The implementation must ensure that the authorized effectuation path cannot be bypassed by redirecting the operation to an uncontrolled backend.

7.1.43. PART IV - HARDWARE-ASSISTED PROTECTION

7.1.44. S-5.15 - Hardware-Assisted PED

A PED may be implemented partly or entirely in hardware.

Examples include:

| x | A trusted execution environment.                  |
| - | ------------------------------------------------- |
| x | A secure enclave.                                 |
| x | A hardware security module.                       |
| x | A protected coprocessor.                          |
| x | A secure firmware controller.                     |
| x | A programmable network security device.           |
| x | A protected storage controller.                   |
| x | A hardware-enforced authorization register.       |
| x | A combination of protected hardware and software. |

A hardware PED may perform selected authority checks, maintain protected state, generate authenticated evidence, or activate scoped authorization conditions.

7.1.45. S-5.15.1 - Hardware protection requirements

The implementation must identify:

1. What security-critical data is protected. 2. Which entity is permitted to modify it. 3. Which adversary is excluded. 4. How authorization state is updated. 5. How rollback or replay is addressed where required. 6. How the effectuation controller verifies the resulting authorization. 7. How failure and recovery preserve the required security property.

A general assertion that hardware provides trust is insufficient to describe the corresponding technical mechanism.

7.1.46. S-5.16 - Hardware Finality Sink

A hardware or firmware controller may serve as a Finality Sink where it controls the specified consequential effect.

Possible examples include:

(a) a SmartNIC controlling network transmission; (b) a DPU controlling selected I/O operations; (c) a storage controller governing persistent writes; (d) a DMA controller governing memory transfer; (e) an accelerator command controller; (f) a secure cryptographic signing interface; (g) a hardware-controlled communication interface; and (h) an industrial or robotic actuator controller.

The Finality Sink verifies the applicable bounded authorization condition before releasing the corresponding operation.

7.1.47. S-5.16.1 - Queue admission versus physical execution

Authorization of command-queue admission and authorization of physical command execution may correspond to different effectuation boundaries.

The implementation must identify which effect is governed.

If a command already admitted to a hardware queue can execute after authority revocation, a control applied only to future queue admissions may be insufficient to prevent that outstanding effect.

A stronger implementation may require command fencing, protected cancellation, queue quiescence, or operation-specific state reconciliation.

7.1.48. S-5.17 - CIED Variation

A CIED may protect authority-critical operations through cryptographic isolation and protected state handling.

In one implementation, a CIED:

1. Receives a validated Candidate Act Descriptor. 2. Obtains protected authority state. 3. Evaluates the required predicates. 4. Commits authenticated validation evidence. 5. Establishes scoped non-bearer finality authority. 6. Protects the capability from unauthorized modification. 7. Supplies verifiable authorization information to the Finality Sink.

A CIED need not occupy the same physical component as the Finality Sink.

Where the two are separated, their communication and state references must preserve the relevant authorization bindings.

Where they are colocated, their distinct claimed functions must remain identifiable.

7.1.49. PART V - CANDIDATE ACT AND NON-EFFECTIVE STAGING

7.1.50. S-5.18 - Candidate Act Formation

A governed operation may originate from:

(a) an agent process; (b) a child process; (c) a container; (d) a guest virtual machine; (e) a host-side connector; (f) a delegated worker; (g) a hardware command producer; (h) an asynchronous service; or (i) another agent-associated execution component.

The interceptor creates a Candidate Act record before the specified consequential effect.

A representative record includes:

CandidateActID = CA-0501

AgentContextID = AGENT-42

ExecutionContextID = EXEC-17

OperationClass = NETWORK_TRANSMIT

TargetResource = RESOURCE-81

AuthorityGeneration = 105

InterceptionPoint = KERNEL-NET-02

IntendedSink = FS-NET-05

CandidateStatus = STAGED

The values are illustrative.

7.1.51. S-5.19 - Non-Effective Holding

A kernel or hypervisor implementation may maintain an operation in a Non-Effective State through a controlled mechanism such as:

1. A pending resource request. 2. A withheld network message. 3. A staged storage operation. 4. A controlled virtual-device queue. 5. A broker-owned operation buffer. 6. A disabled device-admission entry. 7. An uncommitted resource transaction. 8. A protected pending-command record.

The staging mechanism must actually prevent the specified effect.

A logging mechanism that records the operation after it has already occurred does not establish NES.

7.1.52. S-5.19.1 - Non-blocking enforcement variation

Some operating-system hooks cannot suspend an operation while an external authorization service performs an arbitrary-length validation.

For such a platform, the embodiment may use a protected broker that receives and stages the operation outside the restricted kernel hook.

Alternatively, the kernel may make a bounded decision using already available protected authorization state.

The implementation must avoid assuming that every kernel hook supports synchronous remote authorization.

7.1.53. S-5.20 - Candidate Act Descriptor

A representative descriptor includes:

| x | Candidate Act identifier.        |
| - | -------------------------------- |
| x | Authenticated execution context. |
| x | Process or workload generation.  |
| x | Operation class.                      |
| - | ------------------------------------- |
| x | Actual or proposed resource identity. |
| x | Material operation parameters.        |
| x | Canonical payload digest.             |
| x | Authority generation.                 |
| x | Resource-state version.               |
| x | Intended Finality Sink.               |
| x | Replay-control reference.             |
| x | Applicable expiration.                |
| x | Canonicalization profile.             |

The material fields must be selected according to the operation class.

A file operation may require stable object identity.

A network operation may require destination and application-request correspondence.

A device operation may require command parameters and hardware target identity.

7.1.54. PART VI - PROTECTED VALIDATION

7.1.55. S-5.21 - PED Authorization Procedure

The PED obtains the Candidate Act Descriptor and applicable protected authority state.

It evaluates the predicates required for the relevant operation.

Such predicates may include:

1. Agent identity. 2. Workload identity. 3. Task authorization. 4. Resource identity. 5. Operation class. 6. Delegation context. 7. Purpose or policy scope. 8. Authority generation. 9. Revocation state. 10. Runtime security condition. 11. Resource-state precondition. 12. Quota or usage constraint. 13. Hardware device security state. 14. Required human approval. 15. Effectuation-boundary identity.

The predicate set may be selected according to the resource and effect being governed.

7.1.56. S-5.22 - Protected Validation Evidence

Following successful validation, the PED creates or commits protected validation evidence.

A representative record comprises:

EvidenceID = VE-0501

CandidateActID = CA-0501

DescriptorDigest = DIGEST-0501

PEDIdentity = PED-KERNEL-01

PolicyGeneration = 105

ValidationResult = APPROVED

AuthorizedSink = FS-NET-05

EvidenceGeneration = 910

The evidence may be implemented as a protected registry entry, authenticated record, signed receipt, sealed state transition, or hardware-backed commitment.

Where the applicable enforcement point requires evidence commitment before capability release, that ordering is enforced.

7.1.57. S-5.23 - Scoped Non-Bearer Finality Capability

The PED establishes or activates bounded finality authority associated with the validated operation.

A representative capability contains or references:

CapabilityID = CAP-0501

CandidateActID = CA-0501

EvidenceReference = VE-0501

AuthorizedSinkID = FS-NET-05

AuthorizedResource = RESOURCE-81

AuthorizedOperation = NETWORK_TRANSMIT

AuthorityGeneration = 105

UsagePolicy = SINGLE_USE

CapabilityStatus = ACTIVE

The capability may be represented by:

(a) a protected authorization-table entry; (b) a signed or authenticated object; (c) an integrity-protected state-machine transition; (d) a secure register;

(e) a hardware authorization latch;

(f) a protected queue permission; or

(g) another technically enforced bounded authorization condition.

The capability need not be a portable bearer token.

7.1.58. PART VII - FINALITY SINK VERIFICATION

7.1.59. S-5.24 - Finality Sink Positioning

A kernel, hypervisor, or hardware implementation places the Finality Sink at a point capable of controlling the designated consequential effect.

The Finality Sink may be:

1. A protected kernel-controlled resource operation. 2. A privileged broker. 3. A hypervisor-controlled device backend. 4. A protected network gateway. 5. A storage-commit controller. 6. A secure credential-use interface. 7. A hardware device-admission controller. 8. A firmware-controlled actuator interface.

The sink's authority is determined by its control over the actual effectuation path.

A component is not a Finality Sink for a given effect merely because it can observe the operation.

7.1.60. S-5.25 - Actual Pending Operation Reconstruction

The Finality Sink obtains or reconstructs the material properties of the operation it is about to effectuate.

For a network operation, this may include:

| x | Effective source execution context.                 |
| - | --------------------------------------------------- |
| x | Intended or final destination.                      |
| x | Network protocol.                                   |
| x | Destination address and port.                       |
| x | Application-level request identity where available. |
| x | Payload digest or trustworthy equivalent.           |
| x | Actual output interface.                            |

For a storage operation, this may include:

| x | Actual resource object.         |
| - | ------------------------------- |
| x | Intended modification.          |
| x | Current resource-state version. |
| x | Write scope.                    |
| x | Commit interface.               |

For a hardware command, this may include:

| x | Target device.               |
| - | ---------------------------- |
| x | Command class.               |
| x | Relevant command parameters. |
| x | Execution queue.             |
| x | Device authority generation. |
| x | Applicable hardware state.   |

7.1.61. S-5.25.1 - Independent source of operation information

The sink does not rely exclusively on an agent's unverified statement describing what it intends to perform.

The actual operation may be derived from a controlled kernel object, immutable command buffer, protected backend queue, resource controller, or other trustworthy representation.

Where the operation is transformed after initial validation, the final material parameters must remain within the permitted authorization scope.

7.1.62. S-5.26 - Sink-Local Protected State

A representative sink-local state record contains:

SinkID

CandidateActID

CapabilityID

ExpectedDescriptorDigest

AuthorityGeneration

RevocationGeneration

ConsumptionState

ResourceStateReference

DispatchStatus

CompletionStatus

A single-use capability may transition:

UNUSED → RESERVED → CONSUMED

The protected transition must prevent unauthorized concurrent use.

Where a local authorization is consumed before a remote operation's result becomes known, an INDETERMINATE state may be maintained until the external outcome is reconciled.

7.1.63. PART VIII - EFFECTUATION-PATH COMPLETENESS

7.1.64. S-5.27 - Effectuation-Path Enumeration

A system asserting non-bypassable enforcement identifies the technical paths through which the governed effect can occur.

For example, a network effect may be produced through:

(a) ordinary socket transmission; (b) an existing connected socket; (c) a host-side proxy; (d) a privileged service; (e) a directly assigned network device; (f) a virtual-device backend; (g) a kernel tunneling mechanism;

(h) an asynchronous service worker; or

(i) another available egress path.

A protected-finality deployment must ensure that the relevant paths are restricted, mediated, or excluded according to the guarantee.

7.1.65. S-5.28 - Enforcement-Path Coverage State

The system may maintain an Effectuation Path Coverage Record including:

EffectClass

SourceExecutionClass

KnownEffectuationPaths

RequiredEnforcementPoints

CurrentPolicyGeneration

DeviceAssignmentState

ApplicableBypassRestrictions

CoverageStatus

VerificationSequence

A coverage verification may be performed during initialization and following relevant configuration changes.

7.1.66. S-5.28.1 - Configuration changes

Coverage may need to be re-evaluated following:

1. Network-interface creation. 2. Device pass-through. 3. Kernel module changes. 4. Hypervisor backend replacement. 5. Installation of a new privileged tool service. 6. Creation of a new IPC route. 7. Resource mount changes. 8. Policy changes. 9. Runtime migration. 10. Hardware reconfiguration.

An earlier coverage result does not automatically prove continued coverage after a material configuration change.

7.1.67. PART IX - PRINCIPAL EXECUTION WORKFLOW

7.1.68. S-5.29 - Complete 24-Step Workflow

7.1.69. Step S5-01 - Execution environment initialization

The system establishes the operating-system, optional hypervisor, and relevant protected enforcement components.

7.1.70. Step S5-02 - Trust-boundary configuration

The system identifies which execution contexts are trusted to maintain the required protected state.

7.1.71. Step S5-03 - Kernel or hypervisor enforcement activation

The required interception and restriction mechanisms are configured.

7.1.72. Step S5-04 - Effectuation-path coverage verification

The system checks that designated consequential effects cannot occur through prohibited alternative paths.

7.1.73. Step S5-05 - Agent execution-context registration

The agent, workload, task, and applicable authority generation are associated with authenticated execution state.

7.1.74. Step S5-06 - Agent computation

The agent performs ordinary computation.

7.1.75. Step S5-07 - Consequential operation generation

The agent generates a governed operation.

7.1.76. Step S5-08 - Operation interception

The operation reaches the controlled kernel, hypervisor, or broker interface.

7.1.77. Step S5-09 - Origin authentication

The system establishes the actual originating workload context.

7.1.78. Step S5-10 - Candidate Act construction

The system assigns the operation a Candidate Act identity.

7.1.79. Step S5-11 - Non-effective staging

The governed effect is withheld.

7.1.80. Step S5-12 - Descriptor canonicalization

The operation is represented using the applicable deterministic descriptor format.

7.1.81. Step S5-13 - Protected-domain submission

The descriptor and authenticated context are supplied to the PED.

7.1.82. Step S5-14 - Protected authority-state retrieval

The PED obtains current required authority and revocation information.

7.1.83. Step S5-15 - Predicate evaluation

The PED evaluates all mandatory authorization conditions.

7.1.84. Step S5-16 - Evidence commitment

The PED commits protected validation evidence.

7.1.85. Step S5-17 - Bounded capability activation

A scoped non-bearer finality capability is established.

7.1.86. Step S5-18 - Finality Sink presentation

The staged operation is presented to the authorized effectuation controller.

7.1.87. Step S5-19 - Actual-operation reconstruction

The sink obtains the actual material operation parameters.

7.1.88. Step S5-20 - Finality verification

The sink verifies the required evidence, capability bindings, current state, and operation correspondence.

7.1.89. Step S5-21 - Protected authorization-state transition

The sink reserves or consumes the applicable bounded authorization.

7.1.90. Step S5-22 - Controlled effectuation

The authorized operation is performed.

7.1.91. Step S5-23 - Completion-state observation

The resulting operation status is obtained where available.

7.1.92. Step S5-24 - Recovery-state reconciliation

Protected operation state is updated or retained for reconciliation if the external outcome is uncertain.

7.1.93. PART X - REPRESENTATIVE ALGORITHMS

7.1.94. S-5.30 - Algorithm A: Enforcement Initialization

function InitializeKernelHypervisorEnforcement(profile):

trusted_components = ResolveTrustedComputingBase(profile)

protected_domains = InitializeProtectedDomains(profile)

enforcement_points = InstallSupportedEnforcementControls(

profile.operation_classes )

if not VerifyEnforcementControlIntegrity(enforcement_points):

return DENIED effect_paths = EnumerateGovernedEffectuationPaths(profile)

if not VerifyRequiredPathCoverage(

effect_paths, enforcement_points ):

return DENIED

generation = AllocateAuthorityGeneration()

CommitProtectedConfigurationState({

profile: profile.id, authority_generation: generation, enforcement_points: enforcement_points, effect_paths: effect_paths })

return ACTIVE

The implementation must define the control-integrity and path-coverage tests for the selected operating system or hypervisor.

A generic statement that all relevant paths have been verified is not a substitute for actual configuration-specific coverage checking.

S-5.31 - Algorithm B: Kernel or Hypervisor Candidate Act Capture

function CaptureGovernedOperation(source, request):

context = AuthenticateExecutionContext(source)

if context is invalid:

return DENIED

operation = CaptureControlledOperationRepresentation(request)

if not IsGovernedEffect(operation):

return EvaluateApplicableNonFinalityPolicy(operation)

candidate_id = AllocateCandidateActID()

descriptor = Canonicalize({

candidate_id: candidate_id, execution_context: context, operation: operation, authority_generation: CurrentAuthorityGeneration(context), target_sink: ResolveRequiredSink(operation) })

StageWithoutEffectuation(candidate_id, operation, descriptor)

return PED.Validate(candidate_id, descriptor)

The selected interception point must support the required holding semantics.

If an operating-system hook cannot safely stage the operation, the request may instead be redirected to a controlled broker that performs the staging.

7.1.95. S-5.32 - Algorithm C: Protected Validation

function ValidateCandidate(candidate_id, descriptor):

record = ProtectedOperationRegistry.get(candidate_id)

if record.status != STAGED:

return DENIED

if not VerifyAuthenticatedContextBinding(descriptor, record):

return DENIED

authority = ProtectedAuthorityRegistry.lookup(descriptor)

if not EvaluateRequiredPredicates(descriptor, authority):

ProtectedOperationRegistry.deny(candidate_id) return DENIED evidence = CommitProtectedValidationEvidence(

candidate_id, descriptor, authority )

capability = CreateScopedFinalityCapability({

candidate_id: candidate_id, descriptor_digest: Hash(descriptor), evidence_reference: evidence.id, authorized_sink: descriptor.target_sink, authorized_scope: authority.permitted_scope, authority_generation: authority.generation })

if not AtomicallyActivateAuthorization(

candidate_id, evidence, capability ):

DisableCapability(capability) return DENIED

return AUTHORIZED

The corresponding protected state transition must ensure that a failed activation does not leave an independently usable capability.

7.1.96. S-5.33 - Algorithm D: Finality Sink Enforcement

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

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 VerifyActualOperationBinding(

actual_operation, capability ):

return DENIED

if not VerifyCurrentAuthorityState(capability):

return DENIED

if not VerifySinkLocalConsumptionState(capability):

return DENIED

if not AtomicallyReserveAuthorization(capability):

return DENIED result = DispatchThroughControlledEffectuationInterface(

actual_operation )

ReconcileOperationOutcome(candidate_id, result)

return result

For an external resource lacking atomic integration with the protected authorization registry, dispatch and completion may require separate durable states.

S-5.34 - Algorithm E: Revocation and Enforcement Generation

function RevokeAgentAuthority(agent_context, restricted_scope):

new_generation = AdvanceProtectedAuthorityGeneration(

agent_context )

affected_paths = ResolveAffectedEffectuationPaths(

agent_context, restricted_scope )

for each path in affected_paths:

ApplyRestrictiveEnforcementUpdate(

path, new_generation, restricted_scope )

acknowledgments = CollectEnforcementState(

affected_paths, new_generation )

if not VerifyRequiredConvergence(acknowledgments):

ApplyCompensatingRestrictions(affected_paths)

MarkPriorAuthorizationsAccordingToRevocationPolicy(

agent_context, new_generation )

return EvaluateRestrictiveConvergence(

affected_paths, new_generation )

The system must not declare a restriction fully converged merely because a central policy record has been updated.

Where already queued hardware or asynchronous operations are included in the governed scope, the corresponding in-flight state must also be addressed.

S-5.35 - Algorithm F: Kernel/Hypervisor State Recovery

function RecoverProtectedEnforcementState():

generation = LoadCurrentProtectedAuthorityGeneration()

registry = RecoverProtectedOperationRegistry()

sinks = EnumerateRequiredFinalitySinks()

for each sink in sinks:

recovered_state = RecoverOrVerifySinkState(sink)

if recovered_state is invalid:

RestrictAffectedEffectuationPaths(sink) continue

ReconcileOutstandingOperations(

sink, registry, recovered_state )

if not VerifyRequiredEnforcementCoverage():

return RESTRICTED

return ACTIVE

Recovery must preserve applicable protected consumption and revocation state.

Restoring an older software configuration must not silently reactivate authority that has already been revoked or consumed.

7.1.97. PART XI - WORKED TECHNICAL EXAMPLES

S-5.36 - Example A: Kernel-Mediated Protected File Modification

The following is a hypothetical example.

An enterprise AI coding agent executes as a restricted process.

The agent requests modification of a protected application configuration file.

An applicable operating-system security control prevents direct modification of the protected file.

The request is submitted to a controlled file-operation broker.

The broker creates a Candidate Act identifying:

| x | Originating agent.      |
| - | ----------------------- |
| x | Task identity.          |
| x | Actual target resource. |
| x | Requested modification. |
| x | Content digest.                         |
| - | --------------------------------------- |
| x | Current policy generation.              |
| x | Required storage effectuation boundary. |

The PED evaluates whether the agent is authorized to make the specified modification.

Protected validation evidence is committed.

A scoped non-bearer capability is established.

The file-commit Finality Sink verifies the actual selected file object and the authorized modification.

The protected authorization is consumed.

The controlled interface performs the permitted modification.

The example does not require every ordinary file write performed by the agent to undergo this procedure; it applies to the selected governed resource class.

S-5.37 - Example B: Hypervisor-Controlled Network Transmission

A virtual-machine-isolated agent generates a network request.

The request reaches a hypervisor-controlled virtual network backend.

The backend captures the request before external transmission.

The request is placed in a controlled holding buffer.

The PED evaluates its authorized destination, resource scope, and applicable execution context.

Protected validation evidence is committed.

A bounded finality capability is established.

A protected network Finality Sink verifies the actual pending transmission and required authorization.

The authorized request is transmitted.

If the guest attempts to use a directly assigned network device that bypasses the protected backend, the deployment must either prevent the route or use an additional protected enforcement mechanism.

S-5.38 - Example C: Kernel Observation Without Finality Enforcement

An AI agent executes a process that sends confidential information through an otherwise permitted network connection.

A kernel tracing mechanism records the network activity.

The information has already been transmitted before the monitoring service analyzes the event.

This represents observation or retrospective detection, not preventive finality enforcement for the transmitted information.

In a protected-finality variation, the controlled network or application interface must withhold the governed transmission pending the required authorization and sink verification.

The distinction depends on the actual technical enforcement position, not the presence of a kernel event record.

7.1.98. S-5.39 - Example D: Hardware Command Queue

An agent requests a hardware operation through a virtualized device interface.

The operation is staged before admission to the device execution queue.

The PED validates the permitted command class, target device, resource scope, and current authority generation.

Protected validation evidence is committed.

A scoped capability is established.

The hardware or firmware Finality Sink verifies the actual command descriptor.

If authorization succeeds, the command is admitted according to the permitted queue-control procedure.

If the applicable security policy requires revocation of commands already admitted to the queue, additional fencing, cancellation, or queue-state mechanisms are employed.

Authorization of new admissions alone does not automatically cancel previously admitted commands.

S-5.40 - Example E: Kernel Policy Revocation During Agent Execution

An agent has previously obtained authority for a bounded class of network operations.

A protected risk or security controller reduces the agent's authority.

The system advances the applicable authority generation.

Affected kernel, gateway, or device enforcement points receive the restrictive update.

A pending operation attempts effectuation using an authorization associated with the earlier generation.

The Finality Sink checks the applicable revocation and generation conditions.

If the earlier authorization is no longer valid, effectuation is denied.

Where the security requirement includes already queued asynchronous operations, those operations are also restricted or reconciled under the applicable revocation procedure.

7.1.99. PART XII - FAILURE AND ADVERSARIAL SCENARIOS

7.1.100. S-5.41 - Representative Failure Cases

7.1.101. F1 - Uncontrolled System-Call Path

A proposed operation reaches an allowed system call that bypasses the intended protected resource interface.

The deployment must identify and mediate or restrict the relevant effectuation path.

7.1.102. F2 - Kernel Hook Not Supporting Required Mediation

A selected kernel hook cannot safely defer a request while external authorization occurs.

The implementation must employ supported bounded kernel-side authorization or redirect the operation through a controlled staging broker.

It must not assume unsupported blocking behavior.

7.1.103. F3 - eBPF Observation Without Enforcement

An eBPF program records an unauthorized operation but does not prevent it.

The observation does not satisfy the claimed preventive finality condition.

7.1.104. F4 - Unauthorized Enforcement-Program Removal

An attacker disables or replaces a required enforcement program.

The selected protection architecture must prevent, detect, or fail safely upon that change according to the threat model.

7.1.105. F5 - Kernel-Level Compromise

An attacker compromises the trusted operating-system kernel.

A kernel-only protected-state implementation may lose the required isolation.

Stronger enforcement points require additional protection suited to that adversary.

7.1.106. F6 - Guest Kernel Compromise

An attacker compromises the guest operating system.

A properly protected hypervisor-side enforcement arrangement continues to apply its restrictions where the corresponding hypervisor and device-control components remain trustworthy.

7.1.107. F7 - Device Pass-Through

A guest gains direct access to an effect-capable device bypassing the virtual device backend.

The system restricts the pass-through path or enforces the required authorization at an appropriate downstream controller.

7.1.108. F8 - Memory Modification After Validation

An agent modifies command or payload memory after initial authorization.

The Finality Sink uses a stable representation or reconstructs the actual pending operation.

7.1.109. F9 - Resource Identifier Substitution

The operation targets a different effective resource than the one previously authorized.

The mismatch is detected before effectuation.

7.1.110. F10 - Authority Generation Mismatch

The capability refers to a superseded authority generation.

The Finality Sink applies the required generation and revocation rule.

7.1.111. F11 - Capability Replay

A previously consumed single-use authorization is presented again.

Protected sink-local state denies replay.

7.1.112. F12 - Concurrent Capability Use

Two workers attempt to use the same single-use capability.

An atomic protected transition prevents unauthorized duplicate consumption.

7.1.113. F13 - Hardware Queue Already Contains Commands

A restrictive policy update occurs after a command has been admitted.

The system must account for the outstanding command when the claimed restriction requires prevention of its effect.

7.1.114. F14 - Hypervisor Backend Replacement

A virtual device backend is replaced or reconfigured.

The effectuation-path coverage state is re-evaluated before unrestricted governed operation resumes.

7.1.115. F15 - Kernel Policy Reload

A security policy is replaced or reloaded.

The system preserves required restrictions during the transition and avoids a permissive enforcement gap.

7.1.116. F16 - PED Unavailability

The protected authorization service becomes unavailable.

The governed operation remains withheld, denied, or canceled according to its fail-closed policy.

7.1.117. F17 - Finality Sink Failure

The designated effectuation controller becomes unavailable.

The system does not release the governed effect through an uncontrolled alternative path.

7.1.118. F18 - Protected State Rollback

A recovery process restores stale authorization state.

A protected generation, authenticated state reference, or equivalent mechanism detects or prevents prohibited rollback.

7.1.119. F19 - Asynchronous Worker Continuation

A queued operation is executed after the originating agent loses authority.

The relevant continuation or finality authorization is verified before the governed effect.

7.1.120. F20 - Indeterminate External Completion

The sink transmits an authorized operation but does not receive a definitive completion acknowledgment.

The system preserves an unresolved outcome and applies the defined reconciliation mechanism.

7.1.121. F21 - Kernel Resource Exhaustion

The kernel enforcement mechanism encounters resource exhaustion or insufficient processing capacity.

The system applies a defined restriction or denial policy rather than silently treating incomplete verification as authorization.

7.1.122. F22 - Hypervisor Migration

A guest is migrated to another physical host.

The destination enforcement environment verifies the applicable authority context, protected state, and effectuation-path controls before continuing governed operations.

7.1.123. F23 - Protected Credential Path Bypass

A privileged credential remains accessible through an unmediated kernel or device interface.

The deployment must constrain the credential-use path or enforce the applicable finality condition at a suitable protected boundary.

7.1.124. F24 - Inconsistent Multi-Sink Revocation

A policy update reaches one Finality Sink but not another.

The authority-convergence mechanism must identify the inconsistency and apply the restrictions required by the claimed distributed revocation semantics.

7.1.125. PART XIII - SOFTWARE, FIRMWARE, HARDWARE, AND DISTRIBUTED VARIATIONS

7.1.126. S-5.42 - Kernel-Only Software Implementation

The agent executes on a conventional operating system.

Kernel security mechanisms restrict direct resource access.

A protected host-side service performs authorization.

A kernel-controlled or broker-controlled resource interface acts as the Finality Sink.

The trust model assumes the integrity of the relevant kernel and privileged components.

7.1.127. S-5.43 - Hypervisor-Only Enforcement Implementation

One or more agents execute within guest virtual machines.

The hypervisor controls selected guest device and resource interfaces.

Protected authorization state is maintained within a hypervisor-controlled domain.

A virtual device backend or equivalent protected interface verifies authorization before releasing the governed effect.

This variation assumes the integrity of the relevant hypervisor components.

7.1.128. S-5.44 - Kernel and Hypervisor Cooperative Implementation

The guest kernel performs preliminary operation classification.

The hypervisor independently controls an applicable effectuation interface.

The PED evaluates protected authorization predicates.

The Finality Sink verifies the actual operation.

The cooperation may reduce the number of operations requiring expensive protected authorization while preserving required enforcement for consequential operations.

The applicable implementation must ensure that a guest kernel cannot disable required hypervisor-level restrictions.

7.1.129. S-5.45 - TEE-Backed PED Implementation

A TEE maintains selected protected authorization state or validation logic.

A kernel or hypervisor component submits Candidate Acts.

The TEE validates the required conditions and establishes protected evidence and bounded finality enablement.

A controlled effectuation interface verifies the corresponding authorization.

The technical mechanism must prevent an untrusted component from simply bypassing the Finality Sink.

7.1.130. S-5.46 - HSM-Backed Enforcement Implementation 

| An HSM maintains protected keys, state commitments, or authorization logic. The host or hypervisor submits protected operation representations. The HSM performs the required protected functions. The effectuation controller verifies the resulting authorization before executing the governed operation. Merely requesting an HSM signature without operation-specific enforcement does not necessarily satisfy the relevant protected-finality requirements.                                               |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-5.47 - SmartNIC/DPU Finality Implementation The agent executes on a host or virtual machine. A SmartNIC or DPU controls selected network transmissions. A PED validates the intended operation and establishes bounded authorization. The protected device verifies the relevant authorization before transmission. Where the authorization concerns application-specific parameters, the implementation must provide trustworthy access to those parameters.                                                 |
| S-5.48 - Storage-Controller Finality Implementation The agent requests a persistent storage modification. A protected storage controller or equivalent commit interface receives the pending operation. The controller verifies the required authorization state. The operation becomes persistent only according to the authorized storage procedure. The implementation must address relevant caching, writeback, journal, and crash-recovery behavior when the claimed effect is durable storage commitment. |

7.1.131. S-5.49 - Accelerator and DMA Enforcement Implementation

The agent submits work to an accelerator or requests memory transfer through a DMAcapable interface.

A protected controller associates the command with the originating execution context and applicable authority generation.

The controller verifies authorization before the governed admission or execution boundary.

The implementation may employ an IOMMU, protected device queue, command-context tag, secure register, or equivalent hardware-supported control.

The required protection must be established for the actual selected hardware operations.

7.1.132. S-5.50 - Distributed PED and Finality Sink

The PED executes on one computing node.

The Finality Sink controls a resource on another node.

The nodes exchange protected authorization references and operation descriptors through an authenticated communication mechanism.

The Finality Sink verifies the required protected authorization against the actual pending operation.

The distributed implementation must address replay, network partitions, stale authority, incomplete state transitions, and recovery.

7.1.133. S-5.51 - Colocated PED and Finality Sink

A kernel component, protected hypervisor service, hardware controller, or secure processing module may implement both PED and Finality Sink roles.

The implementation preserves the distinct logical functions required by the applicable enforcement point.

No physically separate authorization server is required merely because the enforcement point names multiple functional stages, unless physical separation is expressly required.

7.1.134. PART XIV - TECHNICAL DATA STRUCTURES

7.1.135. S-5.52 - ExecutionContextRecord

The record may contain:

1. 2. 3. 4. 5. 6. 7. 8. 9.

ExecutionContextID. AgentContextID. TaskID. ProcessOrVMGeneration. SecurityDomainID. AuthorityGeneration. PermittedOperationClasses. TrustedOriginReference. LifecycleStatus.

7.1.136. S-5.53 - EnforcementPointRecord

The record may contain:

1. EnforcementPointID. 2. KernelOrHypervisorInterface. 3. ControlledOperationClass. 4. ControlledEffectuationPath. 5. PolicyGeneration. 6. ProtectionState. 7. RequiredPEDReference. 8. RequiredSinkReference. 9. CurrentCoverageStatus.

7.1.137. S-5.54 - CandidateActRecord

The record may contain:

1. CandidateActID. 2. ExecutionContextID. 3. OperationClass. 4. TargetResource. 5. ActualOperationReference. 6. DescriptorDigest. 7. AuthorityGeneration. 8. IntendedSinkID. 9. CandidateStatus.

7.1.138. S-5.55 - ProtectedValidationEvidenceRecord

The record may contain:

1. EvidenceID. 2. CandidateActID. 3. DescriptorDigest. 4. PEDIdentity. 5. PolicyGeneration. 6. ValidationResult. 7. EvidenceCommitment. 8. EvidenceGeneration.

9. AuthorizedSinkID.

7.1.139. S-5.56 - ScopedFinalityCapabilityRecord

The record may contain:

1. 2. 3. 4. 5. 6. 7. 8. 9.

CapabilityID. CandidateActID. EvidenceReference. AuthorizedOperationScope. AuthorizedResource. AuthorizedSinkID. AuthorityGeneration. UsagePolicy. CapabilityStatus.

7.1.140. S-5.57 - SinkLocalStateRecord

The record may contain:

1. SinkID. 2. CandidateActID. 3. CapabilityID. 4. ExpectedOperationDigest. 5. AuthorityGeneration. 6. RevocationGeneration. 7. ConsumptionState. 8. DispatchState. 9. CompletionReference.

7.1.141. S-5.58 - EffectuationPathCoverageRecord

The record may contain:

1. EffectClass. 2. SourceExecutionClass. 3. KnownEffectuationPaths. 4. RequiredEnforcementPoints. 5. CoverageGeneration. 6. DeviceAssignmentState. 7. AlternatePathRestrictionState. 8. CoverageVerificationResult.

7.1.142. S-5.59 - HardwareOperationRecord

The record may contain:

1. HardwareCommandID. 2. OriginatingExecutionContext. 3. DeviceIdentity.

4. CommandClass. 5. CommandDescriptorDigest. 6. QueueIdentity. 7. AuthorityGeneration. 8. AdmissionStatus. 9. CompletionStatus. 10. RevocationOrFencingState.

7.1.143. S-5.60 - RecoveryStateRecord

The record may contain:

1. RecoveryGeneration. 2. LastProtectedAuthorityGeneration. 3. RequiredEnforcementPointReferences. 4. OutstandingOperationReferences. 5. ProtectedConsumptionReferences. 6. UnresolvedExternalOperationReferences. 7. CoverageVerificationStatus. 8. RecoveryCompletionStatus.

These records may be implemented using protected kernel memory, hypervisor state, authenticated storage, protected databases, hardware registers, secure-controller memory, or cooperating distributed state components.

7.1.144. PART XV - implementer VERIFICATION TESTS

7.1.145. S-5.61 - Representative Engineering Verification Procedures

The following are proposed test procedures, not representations of tests already conducted.

7.1.146. Test Technical condition

T1 Authorized kernel-mediated

operation T2 Unauthorized operation T3 Missing finality capability T4 Replayed single-use capability T5 Altered command descriptor T6 Guest attempts hypervisor bypass T7 Device pass-through path T8 eBPF observational-only event T9 Kernel hook unavailable T10 Enforcement program removed T11 Kernel state rollback

7.1.147. Expected behavior

Effectuation permitted Effectuation denied Governed effect withheld Rejected Mismatch detected Restricted or mediated Governed path coverage enforced Not falsely treated as preventive enforcement Required control fails safely Protection loss prevented or detected according to threat model Stale authority rejected

T12 Concurrent capability consumption Atomic usage restriction enforced T13 Authority generation revoked T14 Hardware command already queued Required fencing or continuation rule applied T15 Hypervisor device backend changed Coverage reverified T16 File object substituted T17 Mutable payload altered T18 PED unavailable T19 Sink unavailable T20 Kernel enforcement resource

exhaustion

T21 Hypervisor migration T22 Remote external result uncertain T23 Multiple Finality Sinks inconsistent Required convergence restrictions applied T24 Host-kernel compromise T25 Guest kernel compromise T26 Hardware device control failure T27 Credential-use interface bypass T28 Recovery following protected

service restart

Invalid authorization withheld

Effective resource checked Actual operation reverified No permissive fallback No uncontrolled effectuation Defined restrictive behavior Enforcement state re-established Reconciliation required

Trust-model limitations verified Protected hypervisor control evaluated Defined restriction or containment state Protected effectuation path maintained Consumption and revocation state preserved

The actual implementation must identify supported kernel, hypervisor, and hardware primitives appropriate to the selected platform.

7.1.148. PART XVI - Enforcement-Point Mapping and Technical Correspondence

7.1.149. S-5.62 - Enforcement-Point Mapping and Technical Correspondence

this implementation profile may support technical limitations relating to:

(a) protected AI-agent execution; (b) kernel and hypervisor enforcement; (c) operating-system security hooks; (d) protected Candidate Act staging; (e) non-effective operation control; (f) protected PED or CIED validation; (g) protected validation evidence; (h) scoped non-bearer finality capabilities;

(i) Finality Sink verification;

(j) actual pending operation reconstruction;

(k) kernel and device effectuation-path restrictions;

(l) process and workload attribution;

(m) hardware-assisted authority enforcement;

(n) cross-device authority generations;

(o) revocation and protected-state consistency;

(p) runtime behavioral observations;

(q) hardware command control;

(r) recovery and asynchronous operation management; and

(s) software, firmware, and hardware deployment alternatives.

In particular, the embodiment provides representative implementation material relevant to the sandbox-finality, effectuation-path completeness, atomic inline finality, process-lineage, hardware containment, and cross-device enforcement enforcement point families.

The exact correspondence must be established through a limitation-by-limitation mapping against the finalized enforcement points.

7.1.150. PART XVII - implementer IMPLEMENTATION REQUIREMENTS

7.1.151. S-5.63 - Complete Implementation Checklist

For an actual implementation, a person having ordinary skill in the art identifies:

1. The computing platform and processor architecture. 2. The operating system and supported kernel version. 3. The selected hypervisor, where applicable. 4. The trusted computing base. 5. The attacker capabilities against which protection is required. 6. The consequential operation classes being governed. 7. The actual effectuation boundaries. 8. The supported kernel interception interfaces. 9. The supported hypervisor interception interfaces. 10. The enforcement limitations of each selected hook. 11. The effectuation paths available to the agent. 12. The method of restricting unauthorized alternate paths. 13. The authenticated execution-context binding.

14. The Candidate Act construction procedure. 15. The non-effective staging mechanism. 16. The descriptor schema and canonicalization algorithm. 17. The PED implementation. 18. The protected authority-state representation. 19. The required predicate-evaluation procedure. 20. The validation-evidence format and commitment ordering. 21. The scoped finality capability format and lifecycle. 22. The Finality Sink's actual-operation reconstruction procedure. 23. The required protected state transitions. 24. The concurrency semantics of authorization consumption. 25. The revocation-generation update procedure. 26. The behavior of already queued operations. 27. The handling of asynchronous dispatch. 28. The recovery and rollback-protection mechanism. 29. The treatment of device or virtual-machine migration. 30. The handling of resource exhaustion and unavailable enforcement components. 31. The hardware or firmware primitives used where additional protection is required. 32. The verification tests demonstrating the claimed protection properties.

The selected implementation must provide technical detail sufficient to carry out the features required by the applicable enforcement point.

Merely identifying a kernel, hypervisor, eBPF program, SmartNIC, or TEE without explaining its actual role and enforcement properties does not establish complete enablement of the claimed function.

7.1.152. S-5.64 - Technical Effect

The representative embodiment separates artificial-intelligence computation from protected authority to produce designated consequential effects.

Kernel or hypervisor mechanisms may restrict direct resource access and intercept effectcapable operations.

A PED evaluates the authorization conditions for a governed Candidate Act and establishes the required protected validation evidence and bounded finality authority.

A Finality Sink verifies the actual pending operation before permitting the specified consequence.

The architecture can be implemented through operating-system components, hypervisor services, protected firmware, dedicated hardware, or cooperating distributed components.

Its security properties depend upon the actual trust boundaries, protected state, interception coverage, and effectuation interfaces of the selected implementation.

7.1.152.1. S-5.65 - Technical Summary

this implementation profile discloses a kernel- and hypervisor-mediated artificial-intelligenceagent execution architecture comprising an agent execution context, enforceable operation interception, Candidate Act staging, a Protected Enforcement Domain, protected validation evidence, scoped non-bearer finality enablement, and a Finality Sink configured to control a designated consequential effect.

The architecture may employ operating-system access-control mechanisms, supported kernel hooks, Linux Security Modules, eBPF observation or enforcement, hypervisor-controlled device interfaces, trusted execution environments, hardware security modules, programmable network devices, storage controllers, accelerator interfaces, and other protected enforcement components.

The system distinguishes observation from actual effectuation control and distinguishes initial access permission from authorization of a particular consequential operation.

It further provides representative mechanisms for operation correspondence, protected state consumption, authority revocation, hardware command handling, effectuation-path completeness, and recovery.

The embodiment does not require physical separation of all named functional roles where the applicable enforcement points permit co-location.

Nor does it impose the protected execution-finality sequence on other independently architectures that expressly use different enforcement mechanisms.

7.1.152.2. CLOUD-HOSTED, API-GATEWAY-MEDIATED, AND DISTRIBUTED ARTIFICIAL-INTELLIGENCE-AGENT EXECUTION WITH CROSS-DOMAIN
7.1.152.3. AUTHORITY BINDING, PROTECTED CREDENTIAL USE, AND FINALITY SINK VERIFICATION

7.2. Implementation Profile S-7

Source location: original disclosure pages 341-396. 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-7.1 - Technical Field

this implementation profile relates to artificial-intelligence-agent security, hardware-rooted trust, cryptographically isolated execution, protected computing, secure key management, protected mutable state, cryptographic attestation, anti-replay control, rollback resistance, and enforcement of consequential operations.

More particularly, the embodiment describes a computing architecture in which one or more artificial-intelligence agents execute within, outside, or in cooperation with a hardwareprotected or cryptographically isolated computing arrangement, while specified consequential operations remain subject to independently enforceable authorization conditions.

The architecture may employ:

(a) a Trusted Execution Environment (TEE); (b) a Hardware Security Module (HSM);

(c) a secure enclave;

(d) a secure element;

(e) a hardware security coprocessor;

(f) a confidential-computing virtual machine;

(g) hardware-assisted memory isolation;

(h) hardware-rooted measurement or attestation;

(i) protected firmware;

(j) authenticated state storage;

(k) protected cryptographic keys;

(l) a secure execution controller;

(m) a programmable network or storage device;

(n) a secure accelerator or device partition; or

(o) combinations thereof.

The components may be colocated, distributed, physically separated, or integrated within one protected device.

In the representative protected-finality implementation, a Candidate Act remains noneffective until the required protected authorization conditions are satisfied and an appropriately controlled Finality Sink permits the specified consequential effect.

The disclosure is not limited to any particular processor architecture, cryptographic chip, TEE implementation, HSM vendor, confidential-computing product, or cloud provider.

7.2.2. S-7.2 - Technical Problem

Artificial-intelligence agents may process untrusted instructions, retrieve information, generate executable code, invoke tools, operate through privileged connectors, and request consequential changes to external resources.

A software authorization mechanism may rely upon the integrity of a host operating system or privileged software service.

Where the intended threat model includes compromise of that software, ordinary software controls may not provide the required separation between an agent's ability to request an operation and the authority required to make the operation effective.

Hardware-supported isolation can protect certain execution and cryptographic functions.

However, hardware isolation alone does not necessarily provide complete operation-specific authorization.

For example:

(a) a TEE may execute an approved program but receive an unauthorized operation request;

(b) an HSM may protect a signing key while signing arbitrary operation data supplied by a compromised caller;

(c) remote attestation may establish selected workload measurements without establishing authorization of a specific payment, network request, file modification, or device command;

(d) sealed storage may protect confidentiality and integrity without independently preventing restoration of a previously valid but stale state;

(e) a cryptographic authorization artifact may be copied, replayed, or redirected unless its permitted use is appropriately constrained;

(f) an authorization generated inside an enclave may be used by an untrusted host to perform a materially different operation;

(g) a host may bypass an enclave-controlled validation interface by accessing an alternate device, credential, storage, or network path;

(h) an authorization service and a downstream resource controller may disagree about the current revocation or authority generation;

(i) an operation may be approved before its target resource changes;

(j) a system may lose protected state during restart or device replacement;

(k) a hardware command may already be queued when authorization is revoked; and

(l) an attacker may attempt rollback, replay, resource substitution, attestation substitution, or unauthorized cryptographic signing.

this implementation profile addresses these problems through explicit separation of protected computation, protected authority, validation evidence, bounded finality enablement, and actual effectuation control.

7.2.3. S-7.3 - Technical Objectives

The representative system is configured to provide:

1. Identification of an agent-associated execution context.

2. Hardware-supported or cryptographically protected authorization functions. 3. Separation of agent-controlled computation from protected authority state. 4. Protection of required validation logic against unauthorized modification. 5. Protected storage or derivation of cryptographic keys. 6. Authenticated association of protected components with their actual execution state. 7. Staging of governed Candidate Acts in a Non-Effective State. 8. Protected evaluation of operation-specific authority predicates. 9. Machine-verifiable evidence of successful validation. 10. Scoped non-bearer finality enablement. 11. Independent verification at a controlled Finality Sink. 12. Prevention of unauthorized capability replay or substitution. 13. Controlled transition of protected mutable authorization state. 14. Detection or prevention of prohibited rollback. 15. Binding of an actual pending operation to the authorized effectuation scope. 16. Secure handling of revocation, restart, state recovery, and migration. 17. Support for co-located and distributed PED/CIED/Finality Sink implementations. 18. Support for software-only components cooperating with hardware-protected components. 19. Explicit handling of hardware security limitations and unsupported protection enforcement points.

Not every independently claimed alternative architecture requires all of these functions.

The selected protected-finality enforcement point determines the required combination.

7.2.4. PART I - PRINCIPAL ARCHITECTURE

7.2.5. S-7.4 - Principal Components

A representative system comprises the following components.

7.2.6. Component A - Computing Platform

A physical or virtualized computing platform containing one or more processors, memory resources, storage interfaces, communication interfaces, and effect-capable devices.

7.2.7. Component B - Agent Execution Environment

A computing context executing an artificial-intelligence agent, model runtime, tool dispatcher, generated application, delegated worker, or other agent-associated workload.

The Agent Execution Environment may be less trusted than the protected enforcement components.

7.2.8. Component C - Hardware Root of Trust

A hardware-backed security foundation configured to supply one or more protected identity, key, measurement, verification, isolation, or state-management functions.

The available properties depend upon the actual hardware.

7.2.9. Component D - Protected Execution Controller

A component configured to create, initialize, measure, and manage protected execution contexts.

7.2.10. Component E - Protected Enforcement Domain

A PED providing the enforcement integrity required by the applicable embodiment.

7.2.11. Component F - Cryptographically Isolated Enforcement Domain

A CIED configured to provide the additional cryptographic protection required for specified authority-critical operations or state.

7.2.12. Component G - Protected Key Custody Controller

A mechanism configured to generate, store, derive, use, rotate, disable, or destroy cryptographic key material according to specified access and authorization rules.

7.2.13. Component H - Attestation and Measurement Controller

A mechanism configured to produce or evaluate trustworthy evidence concerning selected protected execution or device state.

7.2.14. Component I - Candidate Act Interceptor

A component configured to identify an operation requiring protected-finality authorization.

7.2.15. Component J - Non-Effective Operation Holder

A mechanism configured to retain a governed operation without permitting its designated consequential effect.

7.2.16. Component K - Protected Authority-State Controller

A component configured to maintain policy, authorization, revocation, quota, generation, consumption, or other security-critical state.

7.2.17. Component L - Protected Validation Controller

A component configured to evaluate the required authority predicates.

7.2.18. Component M - Validation Evidence Commitment Controller

A protected mechanism configured to establish the evidence of successful validation required by the selected finality protocol.

7.2.19. Component N - Scoped Finality Enablement Controller

A mechanism configured to create or activate a bounded non-bearer finality capability.

7.2.20. Component O - Finality Sink

A component controlling the actual designated effectuation boundary and performing or enforcing the required authorization verification.

7.2.21. Component P - Protected State Continuity Controller

A component configured to manage freshness, anti-replay information, state generations, rollback detection, and recovery.

7.2.22. Component Q - Controlled Communication Interface

A mechanism configured to transport authenticated requests, evidence references, bounded authorization, or operation representations between cooperating protected components.

7.2.23. Component R - Recovery and Revocation Controller

A component configured to restrict or reconcile authority following revocation, component restart, device failure, protected-state loss, or migration.

The listed components describe logical functions and need not correspond to separate physical devices.

7.2.24. S-7.5 - Reference Deployment

In one representative implementation:

1. An artificial-intelligence agent executes in an ordinary process, container, or virtual machine. 2. The agent has no direct authority to modify protected finality-enforcement state. 3. A controlled interface captures a proposed consequential operation. 4. The operation is held in a Non-Effective State. 5. A CIED verifies the required authorization predicates using protected authority state. 6. The CIED commits protected validation evidence. 7. A scoped non-bearer finality capability is established. 8. A Finality Sink obtains the actual pending operation. 9. The Finality Sink verifies its required binding to the authorization, evidence, and current state. 10. The authorized operation is performed through the controlled effectuation interface. 11. The system records or reconciles the resulting effectuation state.

The CIED may be implemented using a TEE, HSM, secure controller, or combination of protected hardware and software.

The Finality Sink may be physically separate from the CIED.

Alternatively, both may reside within one appropriately protected component, provided that the required validation, evidence, enablement, and verification functions remain implemented.

7.2.25. PART II - HARDWARE ROOT OF TRUST

7.2.26. S-7.6 - Hardware Root of Trust

A Hardware Root of Trust means one or more hardware-supported mechanisms providing an initial basis for selected security guarantees.

Such guarantees may concern:

(a) device identity; (b) protected key custody; (c) measured initialization; (d) secure boot verification; (e) hardware-supported isolation; (f) authenticated state; (g) protected counter or generation state; (h) cryptographic operations; or (i) access to selected protected device interfaces.

A Hardware Root of Trust does not necessarily provide all listed properties.

Each implementation must identify the actual supported mechanisms and the protections that follow from them.

A device capable of cryptographic signing does not automatically provide secure execution, rollback resistance, or non-bypassable effectuation control.

7.2.27. S-7.7 - Hardware-Rooted Identity

A protected component may possess a hardware-rooted or hardware-associated identity.

The identity may be represented through:

x A protected private key.

| x | A hardware-protected credential.        |
| - | --------------------------------------- |
| x | An attestation key.                     |
| x | A device identity certificate.          |
| x | A derived device identity.              |
| x | A protected device registration record. |

The identity may authenticate a particular device, module, protected execution instance, or security domain.

An authenticated device identity is not itself authorization to perform every operation requested by that device.

The relevant operation must satisfy the applicable protected authority predicates.

7.2.28. S-7.8 - Secure Boot and Measured Boot

In one implementation, a computing platform performs authenticated verification or measurement of selected firmware, bootloader, operating-system, hypervisor, or protected execution components.

Secure boot may restrict loading of unauthorized executable components.

Measured boot may record measurements for subsequent appraisal.

Such procedures may support an assessment of the computing platform's state.

They do not independently establish that an AI-agent operation is authorized.

Where a enforcement point requires runtime logic correspondence, protected authority validation, or sinkside operation verification, the corresponding mechanisms remain separately required.

7.2.29. PART III - TRUSTED EXECUTION ENVIRONMENTS

7.2.30. S-7.9 - TEE Execution Domain

A Trusted Execution Environment comprises a hardware-rooted or hardware-assisted execution arrangement providing specified isolation and protection properties.

Depending upon the selected platform, the TEE may protect:

1. Execution memory. 2. Selected code integrity. 3. Cryptographic key material. 4. Protected input or output buffers. 5. Attestation measurements. 6. Secure execution state.

7. Selected storage or sealing operations. 8. Access to protected device or service interfaces.

The precise guarantees depend upon the TEE design and its configuration.

A TEE does not automatically protect every peripheral, host-controlled I/O path, untrusted service, or external resource.

7.2.31. S-7.10 - TEE-Resident PED

In one implementation, the PED executes within a TEE.

The agent operates outside the TEE.

The TEE receives a Candidate Act Descriptor through a controlled interface.

The TEE obtains protected authority state and evaluates the required predicates.

It commits the applicable validation evidence and establishes bounded finality authorization.

The TEE does not release unrestricted authority to the requesting agent.

7.2.32. S-7.10.1 - Protected executable logic

The TEE may maintain or verify a measurement associated with its validation logic.

The measurement may be compared with an approved state or class.

The implementation must distinguish:

(a) validation of the protected enforcement program itself; and (b) authorization of the actual operation requested through that program.

Approval of the enforcement program does not necessarily imply approval of every request submitted to it.

7.2.33. S-7.11 - TEE-Resident Agent

In another implementation, the AI agent itself executes within a TEE or confidentialcomputing environment.

The TEE may protect selected agent memory, model data, or execution state against specified software adversaries.

However, the agent's protected execution does not automatically confer unrestricted external authority.

The system may therefore employ:

1. 2. 3. 4. 5. 6.

A separate PED. A separate CIED. A distinct protected authorization compartment. A protected resource controller. A downstream Finality Sink. An integrated protected controller with distinct logical functions.

The protected agent may propose an operation while the protected authorization service independently determines whether the operation may be made effective.

7.2.34. S-7.12 - Compartmentalized TEE

A TEE may contain logically separated functions or protected compartments where the selected platform supports such separation.

For example:

Compartment A: Agent computation.

Compartment B: Protected authority-state evaluation.

Compartment C: Validation evidence commitment.

Compartment D: Finality enablement.

Compartment E: Effectuation control.

The compartments may share hardware while preserving the access and authorization restrictions required by the applicable enforcement point.

The embodiment must specify which components can access or modify protected authority state.

Merely using separate software modules within one enclave does not necessarily establish independent security domains if all modules possess unrestricted access to the same protected keys and mutable state.

7.2.35. PART IV - HARDWARE SECURITY MODULES

7.2.36. S-7.13 - HSM-Based Protected Authority

In an HSM implementation, selected security-critical operations are performed by a hardware-backed cryptographic or protected-state controller.

The HSM may:

(a) maintain protected authorization keys; (b) authenticate authority objects; (c) verify operation descriptors; (d) evaluate protected authorization parameters; (e) maintain protected usage state; (f) generate authenticated validation evidence; (g) establish bounded finality authorization; or (h) control cryptographic effectuation.

These functions depend upon the programming interfaces and protected execution capabilities of the selected HSM.

A generic HSM that exposes only an unrestricted signing operation does not thereby implement the entire described CIED.

7.2.37. S-7.14 - Protected Key Custody

The HSM or secure controller may maintain private keys or other secrets without exporting their raw values into agent-controlled memory.

Possible keys include:

| x | Authority-signing keys.          |
| - | -------------------------------- |
| x | Evidence-authentication keys.    |
| x | Attestation keys.                |
| x | State-sealing keys.              |
| x | Capability-authentication keys.  |
| x | Credential-use keys.             |
| x | Inter-domain communication keys. |

The key policy determines which operations may be performed using each key.

7.2.38. S-7.14.1 - Separation of key purposes

In one implementation, keys used for evidence authentication, capability generation, state sealing, and external credential use are logically or cryptographically separated.

Such separation may be implemented through distinct keys, derived subkeys, hardware key slots, or permitted-use restrictions.

The use of a signing key for one purpose must not automatically authorize its use for unrelated operations.

7.2.39. S-7.15 - Protection Against Unrestricted Signing

An attacker may attempt to use an HSM as an unrestricted signing oracle.

For example, the attacker may submit an unauthorized transaction descriptor to an HSM that possesses a valid signing key.

A protected-finality HSM implementation therefore does not sign or activate a finality authorization merely because a syntactically valid request was received.

Instead, the HSM performs or enforces the applicable protected authorization procedure.

The HSM may require:

1. An authenticated requesting context. 2. An accepted operation descriptor. 3. Valid protected authority state. 4. Successful predicate evaluation. 5. Required protected validation evidence. 6. Permitted operation scope. 7. Freshness or nonce validity. 8. Applicable revocation state. 9. Authorized target boundary. 10. Protected usage-state conditions.

Only after required conditions are satisfied does the HSM establish the corresponding bounded authorization.

7.2.40. S-7.16 - HSM-Based Cryptographic Finality Sink

A cryptographic signing interface may itself constitute a consequential effectuation boundary.

For example, a signature may enable:

| x | Acceptance of a financial instruction.       |
| - | -------------------------------------------- |
| x | Authentication of an infrastructure command. |
| x | Approval of a software deployment.           |
| x | Issuance of a privileged credential.         |
| x | Activation of an authorization artifact.     |
| x | Acceptance of a protected transaction.       |

Where signing is the governed consequential effect, an HSM may serve as the Finality Sink when it controls whether the signature is generated and verifies the required operationspecific authorization before doing so.

Where the signature merely precedes an independently controlled downstream effect, the implementation must distinguish the signing boundary from the later effectuation boundary.

7.2.41. PART V - PED AND CIED RELATIONSHIP

7.2.42. S-7.17 - PED as Functional Enforcement Domain

A PED comprises one or more components whose implemented protection properties are sufficient to maintain the enforcement integrity required by the applicable embodiment.

A PED may be implemented in protected software, firmware, hardware, or a hybrid arrangement.

The PED designation does not require a particular cryptographic primitive or physical device unless expressly claimed.

7.2.43. S-7.18 - CIED as Cryptographically Protected PED

A CIED is a PED providing the additional cryptographic isolation and protected-state properties required by the relevant embodiment.

In one representative CIED implementation, protected hardware controls:

(a) executable validation logic; (b) authorization-state integrity; (c) protected key use; (d) authenticated validation evidence; (e) bounded capability activation; (f) permitted protected-state transitions; (g) applicable replay protection; and (h) applicable state-continuity rules.

Cryptographic isolation must correspond to a defined adversary.

A CIED may be designed to resist specified unauthorized application processes, operatingsystem processes, privileged software components, or other adversaries according to the protection capabilities of the selected hardware.

A universal enforcement point of resistance to all physical, side-channel, firmware, supply-chain, or hardware-compromise attacks is not implied.

7.2.44. S-7.19 - PED/CIED Physical Co-Location

A PED and CIED may reside in the same protected component where the CIED supplies the required PED functions.

Similarly, one protected controller may implement validation, evidence commitment, capability activation, and Finality Sink verification.

Physical co-location does not eliminate the need to implement the specific logical relationships required by the enforcement points.

For example, a enforcement point requiring evidence commitment before scoped authorization must preserve that ordering even when one controller performs both operations.

7.2.45. PART VI - ATTESTATION

7.2.46. S-7.20 - Protected Measurement

A Protected Measurement means a machine-readable representation associated with one or more relevant security properties of a computing environment.

The measurement may represent:

| x | Firmware state.                       |
| - | ------------------------------------- |
| x | Executable code state.                |
| x | Enclave measurement.                  |
| x | Virtual-machine configuration.        |
| x | Protected workload identity.          |
| x | Security configuration.               |
| x | Boot measurements.                    |
| x | Protected policy state.               |
| x | Device firmware version.              |
| x | Selected runtime security attributes. |

A measurement may be represented by a cryptographic digest, structured record, signed report, or equivalent authenticated measurement artifact.

The measurement must be evaluated according to its actual source and security guarantees.

7.2.47. S-7.21 - Attestation Evidence

Attestation Evidence means information supplied to support appraisal of a protected execution environment or device state.

An attestation record may include:

AttesterIdentity

MeasurementReference

SecurityVersion

PlatformConfiguration

ProtectedWorkloadIdentity

VerifierChallenge

FreshnessReference

AttestationSignature

EndorsementReference

The record may be specific to the selected hardware platform.

The verifier checks the authenticity and applicable acceptability of the evidence according to a defined appraisal policy.

7.2.48. S-7.22 - Attestation Verifier

An Attestation Verifier means a component configured to evaluate received attestation evidence against applicable reference values, trust anchors, freshness conditions, endorsements, and appraisal policies.

The verifier may operate:

(a) locally; (b) within a PED; (c) within a CIED; (d) through a remote protected service; or

(e) through a cooperating set of trusted verification components.

The verifier may return an authenticated appraisal result to the relying enforcement service.

7.2.49. S-7.23 - Attestation and Operation Authorization

Attestation may establish that a particular protected component satisfies selected platform or workload-state conditions.

Operation authorization separately determines whether the component is permitted to perform a specific consequential act.

A representative protected authorization procedure may require both:

1. Acceptable attestation of the protected component. 2. Successful validation of the particular Candidate Act.

The presence of valid attestation does not automatically satisfy the second condition.

7.2.50. S-7.24 - Attestation-to-Session Binding

An attacker may attempt to present genuine attestation evidence from one protected environment while directing an operation to another environment.

To address such substitution, an implementation may bind the attested identity to an authenticated communication session.

For example:

1. The verifier issues a fresh challenge. 2. The protected environment generates an attestation response. 3. The response includes or authenticates a public key or channel-binding value associated with the intended protected session. 4. The verifier validates the attestation and associated key binding. 5. The protected session is established using the corresponding authenticated key. 6. The relying enforcement component associates subsequent requests with the verified protected environment.

The mechanism must be supported by the attestation platform and the chosen authentication protocol.

This procedure does not require a particular vendor-specific attestation format.

7.2.51. PART VII - PROTECTED MUTABLE STATE

7.2.52. S-7.25 - Protected Authority State

A representative CIED may maintain protected mutable state including:

1. Policy generation. 2. Revocation generation. 3. Agent or task authority scope. 4. Evidence-commitment sequence. 5. Capability-use state. 6. Nonce or replay state. 7. Usage quota. 8. Protected resource-state reference. 9. Authorized Finality Sink identity. 10. Recovery generation. 11. Device security state. 12. Required validity conditions.

The protected state may reside in secure memory, hardware-backed storage, authenticated persistent storage, secure registers, or combinations thereof.

7.2.53. S-7.26 - Protected-State Integrity

An implementation must prevent unauthorized modification of security-critical state.

Possible mechanisms include:

(a) hardware access isolation; (b) authenticated storage; (c) cryptographic message authentication; (d) digitally signed state records; (e) secure key custody; (f) protected memory; (g) restricted firmware execution; and (h) authenticated state-machine replication.

The selected mechanism must be appropriate for the relevant attacker and protected state.

Encryption alone does not necessarily protect integrity unless an appropriate authenticated construction and validation procedure are used.

7.2.54. S-7.27 - Protected State Transition

A protected authorization-state transition may be represented as:

CURRENT_STATE + VALIDATED_EVENT + EXPECTED_VERSION → NEXT_STATE

The transition may be performed using:

| x | A protected compare-and-update operation.           |
| - | --------------------------------------------------- |
| x | A transactionally protected registry.               |
| x | A secure hardware state machine.                    |
| x | A protected monotonic sequence.                     |
| x | A cryptographically authenticated state transition. |
| x | An atomic register operation.                       |
| x | An authenticated replicated state machine.          |

The implementation must define the transition's atomicity, durability, and concurrency properties required by the claimed operation.

7.2.55. PART VIII - ROLLBACK RESISTANCE

7.2.56. S-7.28 - State Rollback Threat

A protected state record may be restored from an earlier valid version.

Although its cryptographic integrity may remain valid, the record may contain obsolete authorization, revocation, or capability-consumption information.

For example, a stored record may indicate:

CapabilityStatus = UNUSED

even though a later valid state recorded:

CapabilityStatus = CONSUMED

A valid signature or authentication tag on the earlier record does not by itself establish that the earlier record is current.

7.2.57. S-7.29 - Anti-Rollback State Anchor

A rollback-resistant implementation may maintain a protected state anchor that identifies the latest accepted state or generation.

The anchor may comprise:

(a) a suitable hardware monotonic counter; (b) a hardware-protected generation register; (c) a trusted external freshness service; (d) a protected append-only state commitment; (e) an authenticated replicated monotonic state machine;

(f) a secure nonvolatile state mechanism; or

(g) another mechanism capable of enforcing the required continuity property.

The selected implementation must establish how the anchor itself is protected from unauthorized rollback.

A locally sealed record without an independent freshness or monotonicity mechanism is not necessarily rollback-resistant.

7.2.58. S-7.30 - Protected State Recovery

Upon restart, the CIED obtains its latest recoverable protected state.

A representative recovery procedure:

1. Authenticates the recovered state. 2. Determines its state generation. 3. Obtains the applicable protected continuity anchor. 4. Compares the recovered generation with the anchor. 5. Rejects prohibited stale state. 6. Reconciles incomplete capability-consumption transitions. 7. Reconciles pending or indeterminate external operations. 8. Establishes the permitted recovered authority state. 9. Resumes governed effectuation only when the required consistency conditions are satisfied.

A failure to recover the required state does not automatically authorize initialization of a fresh unrestricted authority generation.

7.2.59. PART IX - CANDIDATE ACT STAGING

7.2.60. S-7.31 - Candidate Act Capture

An AI agent generates a proposed consequential operation.

The operation may include:

| x | Network transmission.        |
| - | ---------------------------- |
| x | Protected credential use.    |
| x | File modification.           |
| x | Persistent database commit.  |
| x | Cryptographic signing.       |
| x | Payment instruction.         |
| x | Cloud resource modification. |
| x | Accelerator operation.       |
| x | Storage command.             |
| x | Physical device actuation.   |

An interceptor creates a Candidate Act associated with the authenticated originating context.

7.2.61. S-7.32 - Non-Effective Operation Holding

The system maintains the governed operation in a Non-Effective State.

Possible mechanisms include:

(a) a controlled software request buffer; (b) a protected operation registry; (c) a withheld cryptographic key-use request; (d) an uncommitted resource transaction; (e) a disabled output queue; (f) a protected command descriptor; (g) a held network request; or (h) an operation staging area controlled by the protected resource interface.

The effectuation interface must prevent the designated consequence while authorization remains unsatisfied.

7.2.62. S-7.33 - Candidate Act Descriptor

A representative descriptor includes:

CandidateActID = CA-0701

AgentContextID = AGENT-42

TaskID = TASK-204

OperationClass = CRYPTOGRAPHIC_SIGN

TargetResource = TRANSACTION-81

DescriptorDigest = DIGEST-0701

AuthorityGeneration = 105

RequiredSink = FS-HSM-01

CandidateStatus = STAGED

The values are illustrative.

A production descriptor defines the material operation parameters and the canonicalization procedure used for authorization and final effectuation.

7.2.63. PART X - PROTECTED VALIDATION

7.2.64. S-7.34 - Protected Authorization Procedure

The CIED obtains the Candidate Act Descriptor and relevant authenticated execution context.

The required authorization predicates may include:

1. Agent identity. 2. Task identity. 3. Delegation scope. 4. Requested operation. 5. Target resource. 6. Transaction or output parameters. 7. Protected policy version. 8. Revocation generation. 9. Usage quota. 10. Freshness. 11. Resource-state precondition. 12. Required attestation. 13. Approved computational-logic state. 14. Runtime behavioral condition. 15. Human authorization. 16. Target Finality Sink identity.

The predicates are selected according to the applicable enforcement point and policy.

7.2.65. S-7.35 - Protected Validation Evidence

Following successful validation, the CIED commits protected validation evidence.

A representative record comprises:

EvidenceID = VE-0701

CandidateActID = CA-0701

ValidatedDescriptorDigest = DIGEST-0701

CIEDIdentity = CIED-01

PolicyGeneration = 105

ValidationResult = APPROVED

RequiredSinkID = FS-HSM-01

EvidenceGeneration = 910

ProtectedCommitment = AUTHENTICATED-STATE-REFERENCE

The record may be authenticated through a protected key or maintained within protected mutable state.

The exact evidence format must be specified for an actual implementation.

7.2.66. S-7.36 - Evidence Commitment Ordering

Where the applicable enforcement point requires committed validation evidence before finality enablement, the following ordering is maintained:

VALIDATION SUCCESS

↓

PROTECTED EVIDENCE COMMITMENT

↓

SCOPED FINALITY CAPABILITY ACTIVATION

↓

FINALITY SINK VERIFICATION

↓

EFFECTUATION

If the evidence commitment fails, the capability is not made independently usable.

If capability activation fails after evidence commitment, the corresponding authorization remains inactive or is reconciled according to the defined protected-state procedure.

7.2.67. PART XI - SCOPED NON-BEARER FINALITY CAPABILITY

7.2.68. S-7.37 - Protected Finality Capability

A Scoped Non-Bearer Finality Capability represents a bounded authority condition associated with a validated Candidate Act.

A representative record comprises:

CapabilityID = CAP-0701

CandidateActID = CA-0701

EvidenceReference = VE-0701

AuthorizedDescriptorDigest = DIGEST-0701

AuthorizedSinkID = FS-HSM-01

AuthorizedOperation = CRYPTOGRAPHIC_SIGN

AuthorityGeneration = 105

UsagePolicy = SINGLE_USE

CapabilityStatus = ACTIVE

The capability may be represented through software-protected or hardware-protected state.

7.2.69. S-7.38 - Hardware Capability Representations

A hardware implementation may employ:

(a) a protected capability register;

(b) a secure key-use authorization entry;

(c) a protected hardware latch;

(d) an operation-specific queue grant;

(e) an authenticated protected state-machine entry;

(f) an HSM-internal authorization object;

(g) a protected command permission; or

(h) a combination thereof.

The implementation must preserve the operation scope, required validation dependencies, and usage semantics.

A hardware permission bit permitting unrestricted future operations would not automatically satisfy a enforcement point requiring a capability bound to one Candidate Act and one protected evidence commitment.

7.2.70. S-7.39 - Capability Anti-Replay

Where the applicable enforcement point requires single-use authorization, the CIED or Finality Sink maintains protected consumption state.

A representative transition is:

UNUSED → RESERVED → CONSUMED

An attempt to consume a capability already reserved or consumed is handled according to the applicable concurrency and recovery rules.

A single-use capability must not be reactivated merely by restoring an earlier host snapshot or replaying an authenticated request.

7.2.71. PART XII - FINALITY SINK IMPLEMENTATION

7.2.72. S-7.40 - Hardware or Software Finality Sink

The Finality Sink controls a specified consequential operation.

Possible implementations include:

1. A protected credential-use interface. 2. An HSM signing interface.

3. A secure network controller. 4. A SmartNIC. 5. A DPU. 6. A storage-commit controller. 7. A DMA controller. 8. An accelerator command controller. 9. A protected gateway. 10. A secure firmware actuator interface. 11. A protected application resource controller.

The Finality Sink may execute within the same protected device as the CIED or in a separate protected component.

7.2.73. S-7.41 - Independent Actual-Operation Verification

The Finality Sink obtains or reconstructs the actual pending operation.

For cryptographic signing, the sink may verify:

| x | Actual data to be signed.                          |
| - | -------------------------------------------------- |
| x | Domain-separation or signature-purpose identifier. |
| x | Applicable transaction or resource identity.       |
| x | Authorized operation scope.                        |
| x | Protected evidence reference.                      |
| x | Capability identity.                               |
| x | Current authority generation.                      |
| x | Current usage state.                               |

For network transmission, the sink may verify:

| x | Actual transmitted payload or protected digest. |
| - | ----------------------------------------------- |
| x | Destination.                                    |
| x | Applicable protocol.                            |
| x | Target interface.                               |
| x | Required authorization state.                   |

For a device command, the sink may verify:

| x | Actual command.                  |
| - | -------------------------------- |
| x | Target hardware device.          |
| x | Command parameters.              |
| x | Queue or controller identity.    |
| x | Applicable authority generation. |

The verification must correspond to the actual operation controlled by the sink.

7.2.74. S-7.42 - Remote Finality Sink

A CIED may generate protected authorization on one machine while a Finality Sink operates on another.

The authorization communication may include:

CandidateActID

EvidenceReference

CapabilityReference

AuthorizedSinkIdentity

ActualOperationDigest

AuthorityGeneration

NonceOrSequence

AuthenticationProof

The Finality Sink verifies the applicable message authenticity, scope, and protected state.

Where single-use consumption is required across remote components, the implementation must specify a suitable coordination or sink-local consumption mechanism.

A valid cryptographic signature does not alone prevent reuse where the effectuation controller lacks appropriate replay or state-consumption controls.

7.2.75. S-7.43 - Non-Bypassability

The intended architecture prevents the governed effect through unauthorized alternate paths.

For example, if an HSM protects a signing key but the same private key is also available in ordinary application memory, the HSM does not exclusively control signing with that key.

Likewise, if a TEE authorizes network requests but an agent can transmit equivalent requests directly through an unrestricted network adapter, the TEE does not provide non-bypassable network finality.

The implementation must control the actual effectuation paths covered by the enforcement point.

7.2.76. PART XIII - PROTECTED CROSS-COMMITTED EVIDENCE VARIATION

7.2.77. S-7.44 - Two Protected Validation Instances

In an additional embodiment, validation may be performed through two protected instances or independently protected validation contexts.

A first protected instance may establish collection-time or preparation-time evidence.

A second protected instance may establish execution-time validation.

The system may construct a cross-committed evidence representation linking the two results.

This is an optional stronger implementation unless expressly required by the applicable enforcement point.

7.2.78. S-7.45 - Cross-Commitment Representation

A representative cross-commitment may include:

FirstValidationEvidenceID

SecondValidationEvidenceID

CandidateActID

CanonicalDescriptorDigest

FirstProtectedDomainID

SecondProtectedDomainID

PolicyGeneration

ExecutionGeneration

CrossCommitmentDigest

The cross-commitment is constructed through a specified cryptographic encoding or authenticated state relationship.

Where the invention requires two independent protected instances, merely executing the same validation routine twice within one unseparated process does not necessarily satisfy that requirement.

7.2.79. S-7.46 - Sink Verification of Cross-Committed Evidence

In an embodiment requiring cross-committed evidence, the Finality Sink verifies:

1. Valid first-instance evidence. 2. Valid second-instance evidence. 3. Required instance-identity relationships. 4. Agreement on material operation fields. 5. Correct cross-commitment. 6. Applicable current authority state. 7. Valid scoped finality authorization. 8. Actual pending operation correspondence.

Failure of a required relationship causes the consequential operation to be withheld.

7.2.80. PART XIV - PRINCIPAL ENABLEMENT WORKFLOW

7.2.81. S-7.47 - Complete 30-Step Successful Execution Workflow

7.2.82. Step S7-01 - Hardware security initialization

The computing platform initializes the selected protected hardware or cryptographic enforcement environment.

7.2.83. Step S7-02 - Protected component authentication

The system establishes the identity of the PED, CIED, or protected controller according to the applicable implementation.

7.2.84. Step S7-03 - Protected executable-state verification

Where required, the system verifies acceptable validation logic or protected workload configuration.

7.2.85. Step S7-04 - Protected key establishment

The protected key custody mechanism initializes or obtains applicable cryptographic keys.

7.2.86. Step S7-05 - Protected authority-state recovery

The system recovers and authenticates the required authority state.

7.2.87. Step S7-06 - State-continuity verification

Applicable rollback-resistant generations or protected freshness references are verified.

7.2.88. Step S7-07 - Attestation

Where required, attestation evidence is generated and evaluated.

7.2.89. Step S7-08 - Secure communication establishment

The system creates the authenticated communication channels required between enforcement components.

7.2.90. Step S7-09 - Agent execution-context registration

The agent and assigned task are associated with authenticated execution identity and authority scope.

7.2.91. Step S7-10 - Effectuation-path verification

The controlled interfaces for designated consequential operations are identified and configured.

7.2.92. Step S7-11 - Agent computation

The agent performs permitted internal computation.

7.2.93. Step S7-12 - Consequential operation proposal

The agent generates an operation requiring protected finality.

7.2.94. Step S7-13 - Candidate Act capture

The operation is intercepted before its designated consequential effect.

7.2.95. Step S7-14 - Non-effective staging

The operation is held in a controlled representation.

7.2.96. Step S7-15 - Descriptor canonicalization

The material operation parameters are represented under a defined canonicalization profile.

7.2.97. Step S7-16 - CIED submission

The descriptor and authenticated execution context are provided to the protected enforcement domain.

7.2.98. Step S7-17 - Protected authority-state acquisition

The CIED obtains current applicable policy, revocation, scope, and usage state.

7.2.99. Step S7-18 - Protected predicate evaluation

The CIED evaluates all required authorization predicates.

7.2.100. Step S7-19 - Optional independent validation

Where required, a second protected validation instance evaluates its assigned predicates.

7.2.101. Step S7-20 - Protected evidence commitment

The required validation evidence is committed.

7.2.102. Step S7-21 - Optional cross-commitment

Where required, independent evidence records are cryptographically linked.

7.2.103. Step S7-22 - Scoped capability establishment

The CIED creates or activates bounded finality authority.

7.2.104. Step S7-23 - Capability delivery or protected reference activation

The authorization becomes available only to the permitted enforcement path.

7.2.105. Step S7-24 - Actual pending operation acquisition

The Finality Sink obtains or reconstructs the operation it is about to effectuate.

7.2.106. Step S7-25 - Evidence verification

The sink verifies the required protected validation evidence.

7.2.107. Step S7-26 - Capability and actual-operation verification

The sink verifies operation correspondence, resource scope, current authority state, and relevant capability bindings.

7.2.108. Step S7-27 - Protected consumption transition

Where required, the sink atomically reserves or consumes the capability.

7.2.109. Step S7-28 - Controlled effectuation

The authorized operation is performed.

7.2.110. Step S7-29 - Completion observation

The system obtains the available effectuation status.

7.2.111. Step S7-30 - Protected state reconciliation

The corresponding protected operation, consumption, and recovery records are updated.

7.2.112. PART XV - REFERENCE ALGORITHMS

S-7.48 - Algorithm A: Protected Hardware Initialization

function InitializeProtectedAuthoritySystem(configuration):

hardware = IdentifySupportedSecurityHardware()

if not VerifyRequiredHardwareProperties(

hardware, configuration.required_properties ):

return DENIED

protected_domain = InitializeProtectedDomain(hardware)

if not VerifyProtectedCodeState(protected_domain):

return DENIED keys = InitializeProtectedKeyMaterial(

protected_domain, configuration.key_policy )

state = RecoverAuthenticatedAuthorityState()

if not VerifyStateContinuity(state):

RestrictGovernedEffectuation() return RECOVERY_REQUIRED

RegisterProtectedDomainIdentity(

protected_domain, keys, state.generation )

if not VerifyRequiredEffectuationPaths():

RestrictGovernedEffectuation() return DENIED

return ACTIVE

The selected hardware platform must supply the protection mechanisms required by the configuration.

7.2.113. S-7.49 - Algorithm B: Attestation Appraisal

function VerifyProtectedExecutionEnvironment(

attestation_evidence, expected_context, challenge ):

if not VerifyAttestationAuthenticity(attestation_evidence):

return DENIED if not VerifyAttestationFreshness(

attestation_evidence, challenge ):

return DENIED

if not VerifyExpectedMeasurements(

attestation_evidence, expected_context ):

return DENIED

if not VerifySecurityVersionRequirements(

attestation_evidence ):

return DENIED

if not VerifySessionBinding(

attestation_evidence, expected_context.session ):

return DENIED

return ACCEPTABLE_ATTESTATION

Successful attestation establishes only the properties represented and accepted through the attestation mechanism.

It does not independently authorize a Candidate Act.

7.2.114. S-7.50 - Algorithm C: Protected CIED Validation

function ValidateCandidateInCIED(candidate_id, descriptor):

record = ProtectedOperationRegistry.get(candidate_id)

if record.status != STAGED:

return DENIED

if not VerifyAuthenticatedOriginBinding(

descriptor, record ):

return DENIED

authority = ProtectedAuthorityState.lookup(descriptor)

if not VerifyCurrentAuthorityGeneration(authority):

return DENIED if not EvaluateRequiredAuthorityPredicates(

descriptor, authority ):

CommitProtectedDenial(candidate_id) return DENIED

evidence = CommitProtectedValidationEvidence({

candidate_id: candidate_id, descriptor_digest: HashCanonical(descriptor), authority_generation: authority.generation, evaluated_scope: authority.scope, validation_result: APPROVED })

if evidence is invalid:

return DENIED capability = CreateScopedNonBearerFinalityAuthority({

candidate_id: candidate_id, evidence_reference: evidence.id, descriptor_digest: HashCanonical(descriptor), authorized_sink: descriptor.sink_id, permitted_scope: authority.scope, authority_generation: authority.generation })

if not ActivateProtectedCapabilityAtomically(

candidate_id, evidence, capability ):

DisableCapability(capability) return DENIED

return AUTHORIZED

The evidence and capability activation sequence must preserve the required protected ordering and recovery properties.

S-7.51 - Algorithm D: Hardware Finality Sink Verification

function VerifyAndEffectuate(candidate_id):

record = ProtectedOperationRegistry.get(candidate_id)

if record.status != AUTHORIZED:

return DENIED

actual_operation = ObtainActualPendingEffectOperation(

candidate_id )

if actual_operation is unavailable:

return DENIED evidence = ProtectedEvidenceRegistry.get(

record.evidence_id )

capability = ProtectedCapabilityRegistry.get(

record.capability_id )

if not VerifyEvidenceCommitment(evidence):

return DENIED if not VerifyCapabilityEvidenceBinding(

capability, evidence ):

return DENIED if not VerifyActualOperationBinding(

actual_operation, capability ):

return DENIED if not VerifyCurrentProtectedAuthorityState(capability):

return DENIED if not VerifySinkLocalProtectedState(capability):

return DENIED if not ReserveCapabilityAtomically(capability):

return DENIED result = ExecuteThroughControlledBoundary(

actual_operation )

ReconcileProtectedOperationOutcome(

candidate_id, result )

return result

A hardware implementation may realize the same procedure through protected state machines, firmware, registers, or controller microcode.

S-7.52 - Algorithm E: Single-Use Capability Consumption

function ReserveCapabilityAtomically(capability):

begin protected_atomic_transaction

state = ReadProtectedConsumptionState(

capability.id )

if state != UNUSED:

abort return DENIED

if not VerifyCurrentAuthorityAndRevocation(capability):

abort return DENIED

if not VerifyRequiredStateGeneration(capability):

abort return DENIED

SetProtectedConsumptionState(

capability.id, RESERVED )

AdvanceProtectedTransitionSequence()

commit protected_atomic_transaction

return RESERVED

If the external effect is not committed atomically with this local transition, separate dispatch and completion records are required.

7.2.115. S-7.53 - Algorithm F: Rollback-Resistant Recovery

function RecoverCIEDState():

candidate_state = LoadSealedOrAuthenticatedState()

if not VerifyStateAuthentication(candidate_state):

return RECOVERY_REQUIRED

anchor = ReadProtectedContinuityAnchor()

if anchor is unavailable:

return RECOVERY_REQUIRED

if not VerifyAcceptedGeneration(

candidate_state.generation, anchor ):

return ROLLBACK_DETECTED

unresolved = RecoverOutstandingOperations(

candidate_state )

for each operation in unresolved:

ApplyProtectedReconciliation(operation)

if not VerifyCurrentEffectuationRestrictions():

return RESTRICTED

return ACTIVE

The protected continuity anchor must itself resist the rollback attacker assumed by the deployment.

7.2.116. S-7.54 - Algorithm G: Secure Capability Revocation

function RevokeProtectedAuthority(

affected_context, restricted_scope ):

generation = AdvanceProtectedAuthorityGeneration(

affected_context )

affected_capabilities = FindAffectedCapabilities(

affected_context,

restricted_scope )

for each capability in affected_capabilities:

ApplyRevocationState(capability, generation)

affected_sinks = ResolveAffectedFinalitySinks(

restricted_scope )

for each sink in affected_sinks:

DistributeProtectedRevocationGeneration(

sink, generation )

if not VerifyRequiredSinkConvergence(affected_sinks):

ApplyCompensatingEffectuationRestrictions()

return EvaluateRevocationCompletion()

Where outstanding hardware commands are included in the restriction, the implementation must also address their queue and execution state.

7.2.117. S-7.55 - Algorithm H: Protected Key-Use Finality

function PerformProtectedSigning(candidate_id):

operation = ObtainActualPendingSigningOperation(

candidate_id )

if operation is unavailable:

return DENIED if not VerifyRequiredFinalityAuthorization(

candidate_id, operation ):

return DENIED

if not VerifySigningKeyUsePolicy(operation):

return DENIED if not ReserveSingleUseAuthorization(

candidate_id ):

return DENIED

signature = HSM.SignAuthorizedOperation(

operation.key_reference, CanonicalSigningPayload(operation) )

RecordProtectedSigningOutcome(

candidate_id, signature )

return signature

The HSM interface must prevent unauthorized callers from invoking an equivalent unrestricted signing path using the same protected key.

7.2.118. PART XVI - WORKED TECHNICAL EXAMPLES

S-7.56 - Example A: HSM-Protected Supplier Payment Authorization

The following is a hypothetical implementation example.

An AI agent prepares a payment instruction involving a supplier account.

The agent does not possess the bank's protected signing key.

The proposed payment is staged before a signature capable of authorizing settlement is generated.

A Candidate Act Descriptor identifies:

| x | The payment instruction.                     |
| - | -------------------------------------------- |
| x | The beneficiary.                             |
| x | The payment amount.                          |
| x | The payer.                                   |
| x | The required authorization context.          |
| x | The relevant transaction identifier.         |
| x | The intended cryptographic signing boundary. |

The CIED validates the required authority and transaction predicates.

Protected validation evidence is committed.

A scoped single-use capability is established for the specific payment instruction.

The HSM signing interface acts as the Finality Sink for the signing effect.

It obtains the actual canonical signing payload.

It verifies correspondence with the authorized transaction.

It checks current protected authority and capability-consumption state.

If verification succeeds, the HSM signs the permitted instruction.

A later request to sign a modified beneficiary, amount, or transaction is not authorized merely because the requesting agent previously obtained approval for a different payment.

The actual settlement of funds may occur at a distinct downstream financial boundary governed by a separate system.

7.2.119. S-7.57 - Example B: TEE-Protected Network Egress

An AI agent operates in an ordinary container.

A TEE implements protected authorization functions.

The container requests transmission of enterprise information.

The host-side egress interface stages the request.

The TEE validates the required recipient, data scope, task authority, and policy generation.

Protected validation evidence is committed.

The TEE establishes a bounded capability.

A protected network controller obtains the actual pending transmission.

The controller verifies the required capability and operation correspondence.

If all mandatory conditions succeed, the controller permits transmission.

If an untrusted host can instead transmit the same information through another uncontrolled interface, the intended non-bypassability property is not established.

S-7.58 - Example C: Attested Workload Requesting an Unauthorized Operation

An AI-agent workload executes inside a TEE having acceptable attestation evidence.

The protected workload requests deletion of a restricted enterprise database.

The attestation verifier confirms that the relevant protected workload measurement is acceptable.

However, the protected authorization service evaluates the actual deletion request separately.

The requested database deletion exceeds the assigned task authority.

The PED or CIED denies authorization.

No scoped finality capability is activated.

The resource Finality Sink does not execute the deletion.

This example illustrates that valid hardware attestation does not independently authorize every operation of the attested workload.

S-7.59 - Example D: Rollback of Consumed Authorization

A protected authorization capability is initially marked UNUSED.

The Finality Sink consumes the capability.

The protected consumption state advances to CONSUMED.

An attacker later restores a previously authenticated storage record indicating UNUSED.

The protected recovery procedure compares the restored generation against an independently protected continuity anchor.

The old state is rejected when it violates the current protected generation.

The consumed capability is not reactivated.

If the selected hardware provides authenticated sealing but no effective freshness or monotonicity mechanism, the implementation cannot enforcement point the same rollback-resistance property without an additional suitable control.

S-7.60 - Example E: Hardware Controller and Outstanding Queue Operations

An agent submits commands to a hardware accelerator through a protected controller.

The controller validates authorization before admission of governed commands.

A restrictive authority update is issued while earlier commands remain queued.

The controller advances the applicable authority generation.

Commands not yet admitted under the new generation are rejected where prohibited.

Previously admitted commands are classified according to their actual execution and cancellation status.

Where the claimed restriction requires preventing the effect of outstanding commands, the controller applies supported queue fencing, quiescence, or cancellation mechanisms.

The system does not equate updating one authorization register with proof that every previously admitted hardware command has ceased to be effect-capable.

S-7.61 - Example F: Cross-Domain Protected Validation

An enterprise agent executes in Cloud Domain A.

A protected authorization service operates in Domain B.

The Finality Sink operates in Domain C.

The agent requests a consequential resource modification.

The operation is staged and represented by a canonical descriptor.

The CIED in Domain B validates the required predicates and commits protected evidence.

A scoped capability is established for the designated Finality Sink in Domain C.

The sink authenticates the relevant authorization information.

The sink reconstructs the actual pending operation and checks its permitted resource scope.

A capability bound to a different sink or resource does not authorize the current operation.

The system performs the effect only after the required validation succeeds.

7.2.120. PART XVII - FAILURE AND ADVERSARIAL CASES

7.2.121. S-7.62 - Representative Failure Conditions

7.2.122. F1 - Unauthorized TEE Call

An agent submits a request to an otherwise valid TEE that exceeds its authorized task.

The protected validation logic denies the request.

7.2.123. F2 - HSM Signing Oracle

An attacker attempts to sign arbitrary data using a protected key.

The protected key-use policy requires the applicable operation-specific authorization.

7.2.124. F3 - Attestation Replay

An attacker replays previously valid attestation evidence.

The verifier checks the applicable challenge, freshness, and session binding.

7.2.125. F4 - Attestation Substitution

An attacker attempts to substitute evidence from a different protected environment.

The verifier checks the required execution identity and session association.

7.2.126. F5 - Compromised Host Software

An attacker controls untrusted host software.

The architecture preserves only those security properties actually enforced beyond the compromised host's authority.

7.2.127. F6 - Protected-State Tampering

An attacker modifies an ordinary storage copy of authority state.

Authenticated state verification detects unauthorized modification.

7.2.128. F7 - Sealed-State Rollback

An attacker restores an earlier valid sealed state.

A protected continuity mechanism rejects prohibited stale generations.

7.2.129. F8 - Capability Replay

A consumed capability is presented again.

Protected usage state rejects the replay.

7.2.130. F9 - Capability Substitution

A capability bound to one operation is applied to another.

The sink detects a descriptor or scope mismatch.

7.2.131. F10 - Sink Substitution

A capability authorized for one Finality Sink is presented to another.

The sink identity binding is checked.

7.2.132. F11 - Resource Substitution

The resource differs from the resource previously authorized.

The Finality Sink rejects unauthorized correspondence.

7.2.133. F12 - Signing-Payload Substitution

The actual data to be signed differs from the authorized payload.

The signing interface withholds the signature.

7.2.134. F13 - Key Extraction Attempt

An attacker attempts to export a protected private key.

The hardware key policy prevents export where the selected component supports and enforces that protection.

7.2.135. F14 - Key-Use Policy Bypass

An alternate API permits unrestricted use of the same signing key.

The configuration fails the asserted exclusive protected key-use condition until the bypass is eliminated.

7.2.136. F15 - CIED Restart

The protected enforcement component restarts.

Required authorization and consumption state are recovered and verified before protected effectuation resumes.

7.2.137. F16 - HSM Replacement

A failed HSM is replaced.

Key custody, authority generation, protected state, and pending operation status are transferred or re-established through an authorized recovery process.

7.2.138. F17 - Protected Counter Exhaustion

A protected monotonic counter reaches a platform limit or becomes unavailable.

The system applies a defined restrictive or recovery procedure rather than resetting protected authority continuity without authorization.

7.2.139. F18 - Protected Storage Unavailable

A required protected-state record cannot be retrieved.

The governed operation remains withheld until required state validity is established.

7.2.140. F19 - Expired Attestation

An attestation result is no longer acceptable under the applicable freshness policy.

The required protected access or operation is denied or revalidated.

7.2.141. F20 - Security-Version Rollback

A protected component reports a security version below an accepted minimum.

The verifier applies the configured security-version policy.

7.2.142. F21 - Concurrent Capability Use

Two workers attempt to consume one single-use capability.

An atomic protected transition prevents unauthorized double consumption.

7.2.143. F22 - Remote State Inconsistency

A CIED and Finality Sink have incompatible revocation generations.

The applicable consistency or fail-closed policy prevents unauthorized effectuation.

7.2.144. F23 - Network Partition

A protected authorization component becomes unreachable.

The system uses only an expressly permitted bounded offline authority mechanism or withholds the governed operation.

7.2.145. F24 - Hardware Queue Already Admitted

A previously authorized command remains pending after revocation.

The implementation applies the required queue-state or continuation rule.

7.2.146. F25 - Side-Channel Exposure

A hardware execution environment may remain vulnerable to selected side channels.

The specification does not assert universal side-channel resistance without platform-specific supporting protection.

7.2.147. F26 - Physical Hardware Attack

An attacker obtains physical access to a protected device.

The applicable security guarantee depends on the tamper-resistance, physical protection, key handling, and recovery properties actually supplied.

7.2.148. F27 - Firmware Compromise

A firmware component required for protected enforcement is compromised.

The design requires an appropriate measurement, update, isolation, or recovery mechanism if resistance to that compromise is claimed.

7.2.149. F28 - Alternative Effectuation Path

An agent bypasses the protected controller through an unrestricted device or service interface.

The architecture must restrict or mediate that path to satisfy the claimed non-bypassability property.

7.2.150. F29 - Incomplete Protected Transition

A crash occurs between evidence commitment and capability activation.

The recovery procedure ensures that authorization state does not become independently usable without the required committed evidence and valid activation.

7.2.151. F30 - Indeterminate External Completion

An authorized external operation may have occurred, but its acknowledgment is lost.

The system preserves the unresolved outcome and applies the defined reconciliation procedure.

7.2.152. F31 - Incorrect Canonicalization

The CIED and sink interpret the same structured request differently.

The operation is rejected or processed under a common specified canonicalization profile.

7.2.153. F32 - Unauthorized Protected Policy Update

An attacker attempts to modify the CIED's protected authorization policy.

The update interface requires the applicable authenticated policy-change authority.

7.2.154. PART XVIII - HARDWARE, SOFTWARE, AND DISTRIBUTED VARIATIONS

7.2.155. S-7.63 - TEE-Based PED with Software Finality Sink

A TEE implements protected validation and authority-state handling.

A host-side protected service acts as the Finality Sink.

This arrangement is suitable where the host-side sink remains trustworthy under the defined threat model.

It does not automatically provide non-bypassable enforcement against an attacker possessing unrestricted control over that host service.

| S-7.64 - TEE-Based PED with Hardware Finality Sink A TEE establishes protected validation evidence and bounded authorization. A SmartNIC, storage controller, cryptographic module, accelerator controller, or other protected device acts as the Finality Sink. The effectuation controller independently verifies the required authorization before performing the governed operation.                                                                               |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-7.65 - HSM-Resident PED and Signing Sink An HSM performs protected authorization evaluation, evidence handling, bounded finality authorization, and signing-effect verification within one secure module. The logical functions remain distinguishable even though the same hardware device performs them. The implementation must provide the required state and authorization functionality rather than merely exposing an unrestricted cryptographic signing API. |
| S-7.66 - Secure Element Implementation A secure element may maintain selected protected keys, counters, and operation-specific state. A host processor submits Candidate Acts through a controlled interface. The secure element may perform protected validation or bounded authorization functions supported by its actual hardware and firmware. A separate controlled interface may serve as the Finality Sink.                                                    |

7.2.156. S-7.67 - Confidential Virtual Machine Implementation

An agent executes within a confidential virtual machine.

The system may use hardware-protected workload identity or attestation.

A separate protected authorization component evaluates consequential operations.

The actual resource effectuation boundary remains governed by the applicable Finality Sink.

Confidential execution does not automatically authorize all operations generated by the confidential workload.

7.2.157. S-7.68 - SmartNIC/DPU CIED Implementation

A programmable network device contains a protected authorization or enforcement domain.

The device may maintain protected state, verify authorization artifacts, and control selected network transmissions.

A network Finality Sink may be implemented by the same protected device.

Where the enforcement point requires application-level operation verification, the device must obtain the material application fields through an appropriate trusted representation.

7.2.158. S-7.69 - Secure Accelerator Implementation

An accelerator controller may maintain protected operation context, authority generation, and command-admission state.

Agent-generated accelerator or device operations are admitted only according to the required protected authorization.

Where queue execution and completion are governed effects, the controller may additionally verify or fence outstanding commands.

The actual properties depend on the accelerator's supported hardware primitives.

7.2.159. S-7.70 - Distributed CIED Implementation

Two or more protected components may cooperate to perform validation, protected state maintenance, evidence commitment, or bounded authorization.

The distributed arrangement may use authenticated messages, protected key custody, stategeneration checks, and appropriately consistent state replication.

A distributed CIED must satisfy the cryptographic isolation and state-protection properties required by the selected enforcement point.

Cryptographically authenticated communication alone is insufficient to establish the complete distributed enforcement relationship.

7.2.160. S-7.71 - Single-Chip Integrated Finality Implementation

A processor, secure controller, system-on-chip, or equivalent integrated device may implement Candidate Act staging, protected validation, evidence commitment, capability activation, and effectuation control.

The implementation may use separate hardware state machines, protected firmware regions, secure registers, and internal authorization interfaces.

A single physical chip may therefore implement multiple logical security roles.

The enforcement point-required ordering and protected verification relationships remain applicable.

7.2.161. S-7.72 - Cross-Device Protected Authorization

A CIED may authorize operations on external effect-capable devices.

A protected interface conveys the required operation scope and authorization state to the target device.

The target Finality Sink verifies the applicable authorization before the governed effect.

Where revocation or state-consumption must remain consistent across devices, the corresponding coordination mechanism must be specified.

7.2.162. PART XIX - REPRESENTATIVE TECHNICAL DATA STRUCTURES

7.2.163. S-7.73 - ProtectedExecutionContextRecord

Fields may include:

1. ProtectedDomainID. 2. HardwareIdentityReference. 3. WorkloadMeasurement. 4. AgentContextID. 5. TaskID. 6. ExecutionGeneration. 7. AuthorityGeneration.

8. SecurityVersion. 9. ProtectionProfile. 10. LifecycleState.

7.2.164. S-7.74 - AttestationEvidenceRecord

Fields may include:

1. AttesterIdentity. 2. MeasurementReference. 3. SecurityConfiguration. 4. SecurityVersion. 5. VerifierChallenge. 6. SessionBinding. 7. AttestationSignature. 8. EndorsementReference. 9. EvidenceGeneration. 10. ValidityReference.

7.2.165. S-7.75 - ProtectedAuthorityStateRecord

Fields may include:

1. AuthorityStateID. 2. AuthorizedAgentOrTask. 3. PermittedOperationScope. 4. CurrentPolicyGeneration. 5. CurrentRevocationGeneration. 6. ProtectedQuotaState. 7. NonceOrReplayState. 8. ProtectedTransitionSequence. 9. ContinuityAnchorReference. 10. LastAuthenticatedUpdate.

7.2.166. S-7.76 - CandidateActRecord

Fields may include:

1. CandidateActID. 2. 3. 4. 5. 6.

AgentContextID. TaskID. OperationClass. TargetResource. CanonicalDescriptorDigest.

7. AuthorityGeneration. 8. IntendedSinkID. 9. CandidateStatus. 10. StagingReference.

7.2.167. S-7.77 - ProtectedValidationEvidenceRecord

Fields may include:

1. EvidenceID. 2. CandidateActID. 3. DescriptorDigest. 4. CIEDIdentity. 5. PolicyGeneration. 6. EvaluatedAuthorityScope. 7. ValidationResult. 8. EvidenceCommitment. 9. EvidenceGeneration. 10. RequiredSinkID.

7.2.168. S-7.78 - ScopedFinalityCapabilityRecord

Fields may include:

1. CapabilityID. 2. CandidateActID. 3. ValidationEvidenceReference. 4. DescriptorDigest. 5. AuthorizedOperationScope. 6. AuthorizedResource. 7. AuthorizedSinkID. 8. AuthorityGeneration. 9. UsagePolicy. 10. ExpiryCondition. 11. CapabilityStatus. 12. ProtectedConsumptionReference.

7.2.169. S-7.79 - SinkLocalProtectedStateRecord

Fields may include:

1. SinkID. 2. CapabilityID. 3. CandidateActID.

4. ExpectedOperationDigest. 5. AuthorityGeneration. 6. RevocationGeneration. 7. ConsumptionState. 8. DispatchStatus. 9. ExternalOperationReference. 10. CompletionStatus. 11. StateGeneration.

7.2.170. S-7.80 - ProtectedStateContinuityRecord

Fields may include:

1. ContinuityAnchorID. 2. LatestAcceptedGeneration. 3. ProtectedStateDigest. 4. AuthorityGeneration. 5. RevocationGeneration. 6. ConsumptionStateRoot. 7. RecoveryGeneration. 8. AnchorAuthenticationReference. 9. RecoveryStatus.

7.2.171. S-7.81 - CrossCommitmentRecord

Fields may include:

1. FirstEvidenceID. 2. SecondEvidenceID. 3. FirstProtectedDomainID. 4. SecondProtectedDomainID. 5. CandidateActID. 6. CanonicalDescriptorDigest. 7. PolicyGeneration. 8. CrossCommitmentDigest. 9. VerificationStatus.

7.2.172. S-7.82 - ProtectedHardwareOperationRecord

Fields may include:

1. 2. 3.

OperationID. OriginatingExecutionContext. HardwareDeviceID.

4. QueueID. 5. CommandClass. 6. CommandDescriptorDigest. 7. AuthorityGeneration. 8. CapabilityReference. 9. AdmissionState. 10. ExecutionState. 11. CompletionState. 12. FencingGeneration.

These records may be implemented through secure memory, authenticated persistent storage, protected registers, secure-device firmware, HSM-internal objects, or cooperating protected software and hardware components.

7.2.173. PART XX - implementer ENGINEERING VERIFICATION

7.2.174. S-7.83 - Representative Verification Tests

The following are proposed tests rather than representations of experiments already performed.

7.2.175. Test Condition

T1 Valid protected authorization T2 Missing required evidence T3 Invalid capability T4 Replayed single-use capability T5 Modified operation descriptor T6 HSM arbitrary signing attempt T7 Attestation evidence replay T8 Attestation environment substitution T9 Unsupported workload measurement Required access denied T10 Revoked policy generation T11 Sealed-state rollback T12 Concurrent consumption T13 HSM restart T14 Protected key-use bypass T15 TEE unavailable T16 Finality Sink unavailable T17 Host compromise attempt T18 Protected policy tampering T19 Hardware queue revocation T20 Incomplete evidence commitment

7.2.176. Expected technical behavior

Governed effect permitted Effect withheld Effect withheld Rejected Mismatch detected Restricted by operation policy Freshness check fails Binding mismatch detected

Invalid authorization withheld Stale generation detected where protection is claimed Usage constraint enforced Required state recovered or effect withheld Prohibited alternate key use prevented No unauthorized fallback No uncontrolled effectuation Defined hardware-backed protections tested Unauthorized change rejected Required fencing behavior established Capability not usable

T21 Remote CIED/Sink mismatch T22 Resource-state change T23 Cross-commitment mismatch T24 Attestation session-key substitution T25 Protected-counter or anchor

unavailable T26 Device replacement T27 External result indeterminate T28 Unsupported claimed hardware

property T29 Key export attempt T30 Cryptographic-purpose substitution T31 Stale capability after snapshot

restoration T32 Multiple protected components

inconsistent

Operation denied Required current-state check enforced Operation denied when mandatory Binding verification rejects substitution Restrictive recovery behavior Protected authority continuity re-established or restricted Reconciliation state preserved Implementation not represented as satisfying property Protected key policy enforced Unauthorized key use denied Replay or generation check rejects

Required consistency restriction applied

Tests should be adapted to the selected hardware platform, security-module interface, firmware, operating system, and effectuation controller.

A reproducible implementation should specify the expected state transitions, protected records, injected failures, and measurable pass/fail conditions.

7.2.177. PART XXI - Enforcement-Point Mapping and Technical Correspondence

7.2.178. S-7.84 - Enforcement-Point Mapping and Technical Correspondence

this implementation profile provides representative technical disclosure potentially relevant to enforcement points concerning:

(a) protected AI-agent execution; (b) PED and CIED implementations; (c) hardware-rooted authorization; (d) protected validation evidence; (e) scoped non-bearer finality capabilities; (f) protected credential-use finality; (g) cryptographic signing finality;

(h) attested execution;

(i) protected mutable authority state;

(j) rollback-resistant authorization;

(k) sink-local capability consumption;

(l) hardware command authorization;

(m) distributed protected enforcement;

(n) co-located authorization and effectuation control;

(o) hardware-assisted sandboxing;

(p) protected cross-committed validation evidence;

(q) device authority generations;

(r) credential and key separation; and

(s) software-hardware hybrid implementations.

The embodiment may support portions of the protected-finality, credential-finality, hardware enforcement, distributed revocation, and cross-device authority-control enforcement point families.

The exact written-description and enablement support for each finalized enforcement point must be established limitation by limitation.

7.2.179. PART XXII - implementer IMPLEMENTATION REQUIREMENTS

7.2.180. S-7.85 - Implementation Checklist

For a selected hardware or cryptographically isolated implementation, a implementer identifies:

1. The protected hardware platform. 2. The processor, controller, and firmware architecture. 3. The precise supported isolation guarantees. 4. The attacker capabilities included in the threat model. 5. The trusted computing base. 6. The protected executable measurement mechanism. 7. The hardware identity and key custody mechanisms. 8. The selected attestation format and verifier procedure. 9. The attestation freshness and session-binding procedure. 10. The authority-state storage format. 11. The protected state-update algorithm. 12. The protected state-continuity mechanism.

13. The rollback-resistance anchor, where required. 14. The Candidate Act interception point. 15. The non-effective staging mechanism. 16. The canonical descriptor schema. 17. The protected validation algorithm. 18. The required authorization predicates. 19. The evidence-commitment representation. 20. The evidence/capability ordering semantics. 21. The scoped finality capability representation. 22. The permitted cryptographic key uses. 23. The Finality Sink interface. 24. The actual pending operation reconstruction procedure. 25. The sink-local protected state. 26. The atomic authorization-consumption mechanism. 27. The authorization revocation mechanism. 28. The recovery and restart procedure. 29. The handling of incomplete state transitions. 30. The treatment of outstanding hardware commands. 31. The behavior of the system under network partition or remote authorization loss. 32. The prevention of alternate effectuation paths. 33. The protection against unrestricted cryptographic signing or credential use. 34. The hardware limitations relevant to side-channel, firmware, and physical attacks. 35. The platform-specific test procedures establishing the claimed properties.

An actual implementation must supply the specific hardware instructions, device interfaces, protected firmware functions, cryptographic encodings, storage guarantees, and statetransition mechanisms needed to implement the features.

The generic identification of a TEE, HSM, secure enclave, or protected processor is not sufficient when the enforcement point requires security properties that the selected platform does not automatically provide.

7.2.181. S-7.86 - Technical Effect

The representative embodiment separates artificial-intelligence computation from protected authority to produce consequential effects.

Hardware-rooted or cryptographically isolated components may protect validation logic, authority state, cryptographic keys, evidence commitments, and bounded finality authorization.

A Finality Sink verifies the actual pending consequential operation before permitting the governed effect.

The architecture distinguishes:

1. Protected execution. 2. Hardware attestation.

3. Operation authorization. 4. Protected evidence commitment. 5. Bounded capability activation. 6. Actual-operation verification. 7. Effectuation. 8. Protected state consumption. 9. Revocation and recovery.

These functions may be implemented within one secure device or across cooperating protected components.

The security guarantees depend on the actual hardware properties, protected execution boundaries, state-continuity mechanisms, and effectuation paths of the selected implementation.

7.2.182. S-7.87 - Technical Summary

this implementation profile discloses a hardware-rooted and cryptographically isolated artificial-intelligence-agent execution architecture comprising an agent execution context, a protected hardware or cryptographic enforcement arrangement, Candidate Act staging, protected authorization-state evaluation, validation-evidence commitment, scoped non-bearer finality enablement, and a Finality Sink controlling a specified consequential effect.

The architecture may employ TEEs, HSMs, secure enclaves, secure elements, hardwareprotected keys, authenticated storage, protected state generations, remote attestation, protected firmware, dedicated controllers, network devices, accelerator interfaces, or combinations thereof.

A protected workload or attested execution environment does not independently establish authorization of every consequential operation it proposes.

The CIED or other applicable protected enforcement component evaluates the required operation-specific predicates.

The Finality Sink verifies the actual pending operation and required protected authorization before permitting effectuation.

Protected state-continuity mechanisms may prevent stale authorization, prohibited rollback, or repeated capability consumption according to the selected implementation.

The PED, CIED, validation controller, capability controller, and Finality Sink may be physically separated or integrated within one protected device where the required logical and security relationships are maintained.

The embodiment provides representative software, firmware, hardware, and distributed implementation species without requiring every separately claimed alternative security architecture to employ the complete protected-finality sequence.

7.2.182.1. SMARTNIC-, DPU-, GPU-, ACCELERATOR-, AND HARDWARE-SOFTWARE- HYBRID ARTIFICIAL-INTELLIGENCE-AGENT SANDBOX WITH PROTECTED
7.2.182.2. DEVICE AUTHORITY, DMA AND MEMORY ISOLATION, HARDWARE COMMAND FINALITY, CROSS-DEVICE EPOCH FENCING, AND VERIFIED RESOURCE REASSIGNMENT

7.3. Implementation Profile S-8

Source location: original disclosure pages 397-460. Source technical content is presented here for implementation analysis; numbering reflects the original profile family rather than a requirement to implement every profile.

7.3.1. S-8.1 - Technical Field

this implementation profile relates to artificial-intelligence-agent security, computer architecture, processor and accelerator isolation, programmable network devices, direct memory access, input/output memory management, protected hardware command admission, hardware-enforced authorization, device-state management, resource ownership, memory sanitization, and cross-device execution control.

More particularly, the embodiment describes a computing architecture in which one or more artificial-intelligence agents execute on general-purpose processors, graphics processing units, AI accelerators, specialized processing devices, or combinations thereof, while selected consequential operations remain subject to enforceable hardware, firmware, software, or hybrid controls.

The system may employ:

(a) a Smart Network Interface Card (SmartNIC); (b) a Data Processing Unit (DPU); (c) a Graphics Processing Unit (GPU); (d) an AI inference or training accelerator; (e) a Field-Programmable Gate Array (FPGA); (f) an Application-Specific Integrated Circuit (ASIC); (g) a Network Processing Unit (NPU); (h) a Tensor Processing Unit or equivalent matrix-processing accelerator;

(i) an Input/Output Memory Management Unit (IOMMU);

(j) one or more Direct Memory Access (DMA) engines;

(k) protected processor memory;

(l) device-local memory;

(m) hardware command queues;

(n) protected device registers;

(o) secure firmware;

(p) hardware-backed authorization state;

(q) a Protected Enforcement Domain (PED);

(r) a Cryptographically Isolated Enforcement Domain (CIED);

(s) one or more Finality Sinks; or

(t) combinations thereof.

The disclosure is independent of a particular processor manufacturer, accelerator architecture, GPU programming interface, network protocol, virtualization provider, firmware vendor, or device-security product.

The selected implementation must, however, provide the actual memory, command, device, and enforcement properties required by the applicable enforcement point.

7.3.2. S-8.2 - Technical Problem

Artificial-intelligence agents may generate operations that are ultimately carried out through hardware components rather than exclusively through ordinary software interfaces.

Such operations may include:

1. GPU kernel execution. 2. AI inference execution. 3. Hardware command submission. 4. DMA reads and writes. 5. Network packet transmission. 6. Remote direct memory access. 7. Persistent storage commands. 8. Device memory modification. 9. Accelerator-to-accelerator transfer. 10. Model-output transfer. 11. Cryptographic device operations. 12. Physical actuator commands.

A software permission check may occur before a command reaches the hardware.

However, the eventual hardware effect may occur later, after the command has been admitted to a queue or after the applicable authorization state has changed.

For example:

(a) an agent may submit a GPU operation that is authorized when admitted but later executes after the relevant authority has been revoked;

(b) a kernel-mediated restriction may deny new commands while previously submitted DMA operations remain capable of modifying memory;

(c) a SmartNIC may transmit packets previously admitted to its hardware queue after a software security service has changed its policy;

(d) an IOMMU may restrict selected device memory accesses without verifying the business or task authority associated with a permitted DMA transfer;

(e) an accelerator may retain confidential information in device-local memory after a software execution context is destroyed;

(f) a GPU context may be reassigned to another tenant before all relevant commands and memory accesses from the previous tenant have completed;

(g) a device may maintain stale address translations after software updates a memory-access policy;

(h) a peer-to-peer device path may bypass a host software gateway;

(i) firmware may control a hardware queue without independently verifying the operationspecific authorization required by the corresponding enforcement point;

(j) one device may acknowledge an authority update while another device continues operating under an earlier generation;

(k) a hardware completion signal may indicate command admission or local processing rather than completion of the externally consequential effect; and

(l) an untrusted agent may attempt to exploit differences between software-visible descriptors and the commands actually executed by a hardware controller.

Accordingly, hardware isolation, software authorization, device command admission, device execution, and external effectuation represent distinguishable technical functions.

this implementation profile addresses these distinctions through protected device authority, controlled command representation, actual-operation verification, generation-aware resource admission, in-flight command handling, and hardware-software state reconciliation.

7.3.3. S-8.3 - Technical Objectives

The representative system seeks to provide:

1. Hardware-assisted isolation of agent-associated execution and resources. 2. Separation of ordinary accelerator computation from authority to produce designated consequential effects. 3. Protected association of operations with agent, task, device, and execution identities. 4. Controlled admission of commands to effect-capable hardware. 5. Non-effective staging of governed hardware operations. 6. Protected validation of operation-specific authorization conditions. 7. Protected validation-evidence commitment. 8. Scoped non-bearer finality enablement. 9. Finality Sink verification of the actual pending device operation. 10. Protected hardware authority-generation management. 11. Restrictions on stale or unauthorized device commands. 12. Control of DMA memory-access scopes. 13. Cross-device enforcement coordination. 14. Treatment of outstanding, queued, and partially executed commands. 15. Safe reassignment of device resources between execution contexts or tenants. 16. Defined device memory-sanitization and verification procedures. 17. Recovery from device resets, firmware restarts, queue failures, and incomplete operations. 18. Support for hardware-only, software-only control components, and hybrid implementations.

Not all independently claimed alternatives require the complete protected-finality sequence.

In particular, enforcement points directed to memory sanitization, static DMA confinement, native resource isolation, or hardware recovery may operate through their own mechanisms without necessarily requiring a Candidate Act receipt or scoped finality capability.

7.3.4. PART I - GENERAL HARDWARE-SOFTWARE ARCHITECTURE

7.3.5. S-8.4 - Principal Components

A representative system comprises the following functional components.

7.3.6. Component A - Host Computing Platform

A computing environment comprising one or more general-purpose processors, memories, system interconnects, and device interfaces.

7.3.7. Component B - Agent Execution Runtime

An execution environment running one or more AI agents, model-serving components, tool dispatchers, or delegated computational workers.

7.3.8. Component C - Device and Resource Manager

A component configured to allocate, configure, assign, revoke, or recover hardware resources associated with agent workloads.

7.3.9. Component D - Hardware Isolation Controller

A mechanism configured to restrict access between selected execution contexts, memory regions, devices, or tenants.

7.3.10. Component E - IOMMU or Equivalent Memory-Access Controller

A mechanism configured to enforce supported device-address translation and memory-access restrictions.

7.3.11. Component F - DMA Operation Controller

A component configured to manage selected device-initiated memory transfers.

7.3.12. Component G - Accelerator Execution Controller

A component configured to receive, schedule, or execute computation on a GPU, AI accelerator, NPU, FPGA, ASIC, or equivalent device.

7.3.13. Component H - SmartNIC/DPU Controller

A programmable network or infrastructure processing component capable of mediating selected communication, storage, DMA, or device operations.

7.3.14. Component I - Hardware Command Interceptor

A mechanism configured to identify governed device operations before their designated consequential effectuation boundary.

7.3.15. Component J - Non-Effective Command Holder

A mechanism configured to stage governed commands while preventing the specified effect.

7.3.16. Component K - Protected Enforcement Domain

A PED configured to evaluate required authorization conditions and maintain or access relevant protected authority state.

7.3.17. Component L - Cryptographically Isolated Enforcement Domain

An optional CIED configured to provide stronger cryptographic isolation and protected-state guarantees.

7.3.18. Component M - Protected Evidence Controller

A mechanism configured to commit the validation evidence required by the selected protected-finality protocol.

7.3.19. Component N - Scoped Finality Enablement Controller

A protected mechanism configured to establish bounded authorization for a validated consequential operation.

7.3.20. Component O - Hardware or Software Finality Sink

An enforcement component controlling the selected device admission, hardware execution, memory transfer, network transmission, resource commitment, or other governed effect.

7.3.21. Component P - Device Authority-Generation Controller

A component configured to maintain authorization generations associated with selected devices, queues, execution contexts, and resources.

7.3.22. Component Q - Command Queue and Completion Controller

A mechanism configured to maintain queue admission, command execution, cancellation, retirement, and completion state.

7.3.23. Component R - Hardware Fencing Controller

A mechanism configured to prevent prohibited operations associated with a superseded authority or ownership generation.

7.3.24. Component S - Device Memory Ownership Controller

A component configured to track protected memory ownership across agents, execution contexts, workloads, or tenants.

7.3.25. Component T - Memory Sanitization Controller

A mechanism configured to perform or enforce a required memory-clearing, cryptographic erasure, or equivalent sanitization procedure.

7.3.26. Component U - Device Recovery and Reconciliation Controller

A component configured to recover protected state and reconcile outstanding operations after reset, restart, or device failure.

The components may reside in one system-on-chip, multiple processors, multiple peripheral devices, host software, protected firmware, dedicated security hardware, or cooperating distributed devices.

7.3.27. S-8.5 - Reference Deployment

In one representative implementation:

1. An AI agent executes within a process, container, virtual machine, or accelerator runtime.

2. The agent generates a command requiring a consequential operation. 3. A host or device interface captures the operation before its governed effect. 4. The operation is associated with an authenticated agent and device execution context. 5. A controlled command representation is staged in a Non-Effective State. 6. A PED evaluates the applicable authorization conditions. 7. Protected validation evidence is committed. 8. A scoped non-bearer capability is established. 9. A hardware or firmware Finality Sink obtains the actual pending command. 10. The sink verifies the required evidence, capability, authority generation, device scope, and command correspondence. 11. An applicable protected hardware state transition permits the authorized operation. 12. The device performs the consequential operation. 13. Completion and unresolved operation states are reconciled.

For certain effect classes, the hardware command-admission point and the eventual effectuation point are different.

The implementation identifies the controlled effect associated with each Finality Sink.

7.3.28. PART II - HARDWARE ISOLATION DEFINITIONS

7.3.29. S-8.6 - Hardware-Isolated Execution Environment

A Hardware-Isolated Execution Environment means an execution or resource context separated from other contexts through one or more hardware-enforced mechanisms.

Isolation may comprise:

(a) processor privilege separation; (b) memory protection; (c) hardware virtualization; (d) device memory partitioning; (e) protected execution regions; (f) controlled device access; (g) IOMMU restrictions; (h) protected command scheduling; (i) secure processor partitions; or (j) combinations thereof.

The term does not imply that every implementation provides cryptographic isolation.

The particular isolation properties must be identified.

7.3.30. S-8.7 - Accelerator Execution Domain

An Accelerator Execution Domain means a machine-identifiable execution or resource context associated with an accelerator.

The context may comprise:

| x | Device execution queues.           |
| - | ---------------------------------- |
| x | Processor or compute units.        |
| x | Device-local memory allocations.   |
| x | Virtual address spaces.            |
| x | Command contexts.                  |
| x | Device register state.             |
| x | Scheduler state.                   |
| x | Tenant associations.               |
| x | Security or authority generations. |
| x | Protected device metadata.         |

The domain may correspond to a complete physical device, a virtualized accelerator, a supported partition, a process-associated device context, or another controlled resource subdivision.

The existence of separate scheduling contexts does not automatically establish confidentiality or integrity isolation between tenants.

7.3.31. S-8.8 - Device Authority Domain

A Device Authority Domain means a protected or otherwise enforceable association between an execution context and the permitted operations or resources of one or more hardware devices.

A representative authority domain may identify:

DeviceAuthorityDomainID

AgentContextID

TaskID

DeviceID

ExecutionGeneration

AuthorityGeneration

PermittedCommandClasses

PermittedMemoryRegions

PermittedEffectuationInterfaces

RevocationState

The authority domain may be enforced through protected software, firmware, hardware registers, IOMMU state, device command validation, or combinations thereof.

7.3.32. PART III - GPU AND AI ACCELERATOR EXECUTION

7.3.33. S-8.9 - GPU Execution Context

A GPU Execution Context means a logical or hardware-supported context associated with execution of commands on a graphics or compute accelerator.

A context may include:

1. Command streams. 2. Kernel execution parameters. 3. Device memory mappings. 4. Allocated memory buffers. 5. Device-side scheduling state. 6. Context identifiers. 7. Synchronization objects. 8. Completion events. 9. Relevant execution generations.

A GPU context may execute under a general-purpose host process or an accelerator virtualization environment.

The security properties of a context depend upon the underlying hardware and driver implementation.

7.3.34. S-8.10 - AI Accelerator Sandbox

An AI Accelerator Sandbox means an accelerator execution arrangement in which one or more resources, commands, memory regions, device interfaces, or consequential operations are restricted according to applicable technical controls.

Such restrictions may be implemented through:

(a) protected command submission; (b) device context isolation; (c) device memory protection; (d) runtime permission checks; (e) driver-controlled resource mapping; (f) device partitioning; (g) firmware-enforced queue restrictions;

(h) protected DMA address mappings; or

(i) external effectuation mediation.

The sandbox may be managed by host software, firmware, hardware, or a combination thereof.

A scheduling partition is not necessarily equivalent to a security-isolated hardware partition.

7.3.35. S-8.11 - Agent-Originated Accelerator Operation

An AI agent may generate an operation requesting:

| x | Model inference.                  |
| - | --------------------------------- |
| x | Model fine-tuning.                |
| x | Retrieval processing.             |
| x | Tensor computation.               |
| x | Accelerator memory transfer.      |
| x | Device buffer export.             |
| x | Peer-to-peer transfer.            |
| x | Kernel execution.                 |
| x | Output publication.               |
| x | Persistent checkpoint generation. |

The operation may be represented by a command buffer, runtime API invocation, command queue entry, driver request, or another device-specific structure.

Where the operation represents a governed consequential effect, the system captures or controls it according to the corresponding effectuation policy.

7.3.36. S-8.12 - Computation Versus Consequential Output

An accelerator may produce a computational result without that result immediately being released to an external recipient.

For example, a GPU may compute a model output into a protected or restricted buffer.

The result may remain non-effective with respect to external disclosure while it is held inside that buffer.

A separate Finality Sink may control:

(a) copying the result into an untrusted host memory region; (b) transferring the result to a remote device; (c) publishing the result through a network interface; (d) committing the result to persistent storage; (e) displaying or rendering the result; (f) providing the result to an external service; or (g) another specified consequential release.

The implementation must identify which effect is controlled.

Authorization of computation admission does not automatically establish authorization of all later output releases.

7.3.37. PART IV - GPU COMMAND SUBMISSION AND FINALITY

7.3.38. S-8.13 - Hardware Command Descriptor

A Hardware Command Descriptor means a machine-readable representation of an operation proposed for execution by a hardware device.

A representative descriptor may include:

HardwareCommandID

DeviceID

ExecutionContextID

QueueID

CommandClass

OperationParameters

InputBufferReferences

OutputBufferReferences

MemoryAccessScope

AuthorityGeneration

ResourceOwnershipGeneration

RequiredFinalitySinkID

CommandDigest

The descriptor may be represented through a protected software object, driver command, firmware structure, device queue entry, or hardware register set.

7.3.39. S-8.14 - Command Admission Boundary

A Command Admission Boundary means the point at which a hardware command is accepted into a device-controlled execution queue or another scheduled execution structure.

A device may admit commands before performing them.

Where command admission is the governed consequential effect, the Finality Sink may enforce authorization at admission.

Where the governed effect is later execution, data transfer, or physical output, additional execution-time or output-time controls may be required.

7.3.40. S-8.15 - Hardware Execution Boundary

A Hardware Execution Boundary means the point at which a queued command begins or continues an operation capable of producing the designated hardware consequence.

An execution boundary may be implemented through:

1. A command processor. 2. A protected scheduler. 3. A device execution controller. 4. A firmware admission state machine. 5. A hardware command-enable register. 6. A queue authorization predicate. 7. An equivalent enforceable device mechanism.

The exact boundary depends on the hardware.

7.3.41. S-8.16 - Device Command Finality Sink

A Device Command Finality Sink means a hardware, firmware, or effectively controlling software-hardware component configured to prevent a specified command effect unless the required authorization conditions are satisfied.

In one implementation, the Finality Sink verifies:

(a) the actual command descriptor; (b) the permitted device identity; (c) the authorized execution context; (d) the applicable authority generation; (e) the protected validation evidence; (f) the scoped capability; (g) the current resource ownership; (h) any required memory access scope; and (i) sink-local protected usage state.

The exact verification fields depend upon the enforcement point.

7.3.42. PART V - SMARTNIC AND DPU IMPLEMENTATION

7.3.43. S-8.17 - SmartNIC/DPU Enforcement Environment

A SmartNIC or DPU may provide programmable computation and networking or infrastructure-control functions independently of ordinary host application code.

Depending on the device, the protected component may control:

| x | Network packet forwarding.        |
| - | --------------------------------- |
| x | Network connection admission.     |
| x | Selected packet-processing rules. |
| x | DMA operations.                   |
| x | Storage-related data movement.    |
| x | Virtual-function assignment.      |
| x | Device queues.                    |
| x | Workload-associated network flows. |
| - | ---------------------------------- |
| x | Protected authorization state.     |

The device may contain general-purpose processing cores, specialized packet processors, firmware, hardware tables, or programmable logic.

The particular implementation must identify which functions are actually enforceable.

7.3.44. S-8.18 - SmartNIC-Based Agent Egress Finality

In one representative implementation, an AI-agent workload generates a network operation.

A protected egress controller receives the pending operation through a controlled path.

The PED validates the required authorization conditions.

Protected validation evidence and scoped finality authority are established.

A SmartNIC-based Finality Sink verifies the required authorization before the governed transmission.

The device may maintain protected association among:

(a) the agent execution context; (b) the network flow or request; (c) the authorized destination; (d) the relevant payload or protected operation descriptor; (e) the authority generation; and (f) the corresponding finality capability.

7.3.45. S-8.18.1 - Network visibility limitation

A SmartNIC may not independently observe the full application semantics of an encrypted or otherwise transformed request.

If authorization requires application-layer fields, the system must provide an appropriately trusted representation of those fields or perform the relevant verification at another controlled application boundary.

Packet filtering alone does not establish authorization of arbitrary application transactions.

7.3.46. S-8.19 - DPU-Based Resource Control

A DPU may control selected network, storage, virtualization, or device-management operations.

A protected DPU service may maintain authority-generation state and enforce selected restrictions independently of guest application code.

In a representative variation, the DPU:

1. Receives a protected workload identity association. 2. Receives or obtains current authority state. 3. Captures a proposed device or network operation. 4. Verifies required authorization. 5. Checks device or queue state. 6. Applies a protected state transition. 7. Permits the governed operation. 8. Records the resulting completion or error status.

The actual device interface must support the operation-control function being claimed.

7.3.47. PART VI - IOMMU AND DMA ISOLATION

7.3.48. S-8.20 - Direct Memory Access

Direct Memory Access means a mechanism through which a device or DMA-capable controller accesses memory without requiring a general-purpose processor to execute an ordinary load or store instruction for each transferred unit.

DMA may be used by network devices, storage controllers, accelerators, graphics devices, or other peripherals.

DMA may comprise reads, writes, or transfers between authorized address spaces and devices.

A DMA request may create a consequential effect by reading protected data, modifying memory, transmitting data, or making data accessible to another component.

7.3.49. S-8.21 - IOMMU Enforcement Domain

An IOMMU Enforcement Domain means a set of applicable device-to-memory translation and protection rules enforced by an IOMMU or equivalent device-memory access-control mechanism.

A representative domain may identify:

IOMMUDomainID

DeviceRequesterID

ApplicableAddressSpaceID

PermittedMemoryMappings

AccessPermissions

MappingGeneration

AssignedExecutionContext

DeviceOwnershipGeneration

The domain may restrict which memory regions a device can read or write.

The isolation properties depend upon the selected hardware, interconnect, translation configuration, and device behavior.

7.3.50. S-8.22 - DMA Permission Versus Operation Authorization

An IOMMU may allow a DMA write to a particular physical memory region.

Such permission does not necessarily establish that the corresponding AI-agent operation is authorized for its task.

Conversely, protected authorization of an agent operation does not automatically configure the correct DMA address mappings.

Accordingly, a hybrid implementation may require both:

1. An appropriate device memory-access permission. 2. The applicable operation-specific authorization condition.

The two mechanisms may cooperate while remaining logically distinct.

7.3.51. S-8.23 - DMA Effectuation Boundary

A DMA Effectuation Boundary means a control point at which a device-initiated memory access may be admitted, restricted, or performed.

Depending upon the device architecture, the boundary may involve:

(a) an IOMMU translation check;

(b) a device DMA descriptor admission point;

(c) a protected device command processor;

(d) a memory-controller authorization mechanism;

(e) a protected DMA submission interface; or

(f) another technically controlled path.

An IOMMU cannot be assumed to inspect arbitrary application-level operation intent.

If an applicable enforcement point requires purpose- or transaction-specific authorization, another protected component may supply or verify the relevant semantic binding.

7.3.52. S-8.24 - DMA Mapping Lifetime

An authorized DMA mapping may remain usable after the software process that created it has terminated.

Therefore, the resource manager must distinguish:

(a) process termination; (b) DMA descriptor cancellation; (c) device command completion; (d) mapping revocation; (e) translation invalidation; (f) in-flight memory-access completion; and (g) memory reassignment.

The implementation must establish the necessary ordering for the claimed protection.

7.3.53. S-8.25 - Translation Invalidation

When a DMA mapping is changed or revoked, one or more device or IOMMU translation caches may require invalidation according to the selected platform.

The relevant implementation may require:

1. Updating the mapping.

2. Issuing the appropriate invalidation operation. 3. Obtaining completion acknowledgment. 4. Restricting new requests using the old mapping. 5. Accounting for previously accepted or in-flight memory requests. 6. Establishing the required safe-to-reassign condition.

Where Address Translation Services, process-associated address spaces, or similar hardware features are used, the implementation must account for their applicable caching and invalidation semantics.

An invalidation acknowledgment must not be treated as proof that unrelated in-flight device operations have completed unless the hardware actually guarantees that relationship.

7.3.54. PART VII - CROSS-DEVICE MEMORY ACCESS

7.3.55. S-8.26 - Peer-to-Peer Device Transfer

Two or more hardware devices may communicate or transfer data through a peer-to-peer path.

Such transfers may occur without ordinary host application software inspecting every transferred byte.

The architecture may govern:

(a) accelerator-to-accelerator transfer; (b) accelerator-to-network transfer; (c) network-to-accelerator transfer; (d) accelerator-to-storage transfer; (e) storage-to-network transfer; or (f) another permitted device-to-device data path.

The actual protection depends upon the hardware topology and memory-isolation mechanisms.

7.3.56. S-8.27 - Peer-to-Peer Effectuation Control

Where a peer-to-peer path can produce a governed consequential effect, the enforcement architecture must control or restrict that path.

For example, a GPU may contain confidential output data that is transferred to a network device without first being copied into ordinary host application memory.

An implementation claiming protected output-release finality must ensure that the peer-topeer transfer cannot bypass the relevant authorization.

Possible mechanisms include:

1. Protected device memory-access permissions. 2. Controlled DMA mappings. 3. Protected transfer descriptors. 4. Secure device command admission. 5. A device-level Finality Sink. 6. A protected resource controller coordinating the participating devices. 7. Another technically effective restriction.

The exact implementation depends on the available device and interconnect controls.

7.3.57. PART VIII - PROTECTED HARDWARE AUTHORITY GENERATIONS

7.3.58. S-8.28 - Hardware Authority Generation

A Hardware Authority Generation means a machine-identifiable version or epoch associated with permitted operations of a device, command queue, execution context, or hardware resource.

A representative record comprises:

HardwareAuthorityGeneration = 620

AgentContextID = AGENT-42

DeviceID = GPU-02

ExecutionContextID = EXEC-17

PermittedCommandClasses = CLASS-A

ResourceOwnershipGeneration = 91

RevocationGeneration = 44

These values are illustrative.

The generation may be maintained in protected software, firmware, hardware registers, secure controller state, or an authenticated distributed record.

7.3.59. S-8.29 - Generation-Bound Device Command

A hardware command may be associated with the authority generation under which it was admitted.

The command descriptor may contain or reference:

CommandID

DeviceID

QueueID

ExecutionContextID

CommandDigest

AuthorityGeneration

ResourceOwnershipGeneration

PermittedEffectScope

The device controller may compare the command's generation with its protected current state at the applicable enforcement point.

Where required, commands carrying unacceptable generations are withheld or rejected.

7.3.60. S-8.30 - Authority Generation Transition

An authority transition may occur when:

1. A task is revoked. 2. A workload loses permission. 3. A device is reassigned. 4. A tenant's authority is reduced. 5. A policy is updated. 6. A security event occurs. 7. A device enters recovery. 8. A protected queue is reset. 9. A resource ownership generation changes. 10. An authorization capability is consumed.

A representative transition is:

GENERATION 620 → GENERATION 621

The transition may invalidate or constrain future operations associated with generation 620 according to the applicable policy.

Previously admitted operations require separate treatment if they remain capable of producing prohibited effects.

7.3.61. PART IX - HARDWARE QUEUE FENCING

7.3.62. S-8.31 - Hardware Queue State

A device command queue may contain operations in several states.

A representative state machine comprises:

CREATED → STAGED → AUTHORIZED → ADMITTED → SCHEDULED → EXECUTING → COMPLETED

Alternative states may include:

DENIED

CANCELED

ABORTED

FAULTED

INDETERMINATE

RECONCILIATION_REQUIRED

The definitions of admission, execution, and completion depend on the device.

A queue completion record may represent local device completion without necessarily confirming a remote service or external resource effect.

7.3.63. S-8.32 - Hardware Fencing

Hardware Fencing means a technical restriction preventing specified commands, memory accesses, resource mutations, or other operations from proceeding under an unacceptable authority or ownership generation.

Fencing may be implemented through:

(a) queue admission restrictions;

(b) protected scheduler state;

(c) command cancellation;

(d) device reset;

(e) controlled queue drain;

(f) IOMMU mapping revocation;

(g) memory access restriction;

(h) firmware-controlled execution disablement;

(i) protected hardware registers; or

(j) a combination thereof.

The selected mechanism must actually affect the operations covered by the claimed restriction.

7.3.64. S-8.33 - Admission Fence

An Admission Fence prevents new prohibited commands from entering a specified queue or execution domain.

An admission fence may be established by:

1. Disabling an entry point. 2. Updating protected queue authorization state. 3. Rejecting commands from stale generations. 4. Restricting a command-submission interface. 5. Applying an appropriate device permission transition.

An admission fence does not automatically stop commands that have already been admitted.

7.3.65. S-8.34 - Execution Fence

An Execution Fence prevents designated commands from beginning or continuing execution according to the hardware's supported control mechanisms.

Possible implementation actions include:

(a) canceling not-yet-executing commands; (b) suspending a supported execution queue;

(c) preventing scheduling under a stale generation;

(d) invoking supported preemption;

(e) resetting an affected execution context; or

(f) applying another device-specific control.

Some devices or command classes may not support safe interruption after execution begins.

The implementation must identify those limitations.

7.3.66. S-8.35 - Completion Watermark

A Completion Watermark means a machine-verifiable representation of the extent to which commands or operations within a defined sequence have reached a specified completion or retirement state.

A watermark may contain:

DeviceID

QueueID

ExecutionGeneration

LastSubmittedSequence

LastAdmittedSequence

LastCompletedSequence

LastRetiredSequence

WatermarkValidity

The semantics of each sequence must be defined.

A completion watermark for one queue does not automatically prove completion of commands executing through unrelated queues.

7.3.67. S-8.36 - Quiescence

Hardware Quiescence means a state in which a specified device, queue, resource context, or operation class has no outstanding operations capable of violating the designated safety condition.

1. 2. 3. 4. 5. 6.

Quiescence may require:

Prevention of new command admission. Completion or cancellation of admitted commands. Resolution of in-flight memory accesses. Completion of required translation invalidations. Confirmation of applicable hardware state. Restriction of alternate command paths.

Quiescence must be defined relative to the relevant operations and resources.

A device being idle according to one performance counter does not automatically establish security-relevant quiescence.

7.3.68. PART X - PROTECTED COMMAND FINALITY

7.3.69. S-8.37 - Candidate Hardware Act

A Candidate Hardware Act means a proposed device operation whose designated consequential effect remains subject to a governed authorization procedure.

The Candidate Hardware Act may comprise:

| x | DMA transfer.              |
| - | -------------------------- |
| x | Network transmission.      |
| x | Accelerator command.       |
| x | Storage command.           |
| x | Device memory export.      |
| x | Protected signing request. |
| x | Hardware actuation.        |
| x | Peripheral command.        |
| x | Cross-device transfer.     |

The operation may be staged as a command descriptor, hardware queue entry, controlled firmware request, or protected resource transaction.

7.3.70. S-8.38 - Hardware Non-Effective State

A Hardware Non-Effective State means a condition in which the command may have been generated or staged but has not yet produced the specific governed hardware effect.

Representative implementations include:

(a) an unadmitted command descriptor; (b) a disabled hardware queue entry;

(c) a protected pending-command buffer;

(d) a firmware-held command;

(e) a DMA descriptor that has not been activated;

(f) a withheld network packet or flow operation; or

(g) a command gated by protected hardware permission.

The system must prevent the governed effect while the required authorization remains absent.

7.3.71. S-8.39 - Hardware PED Validation

The PED evaluates the required operation-specific predicates.

Depending upon the command class, such predicates may include:

1. Agent identity. 2. Task identity. 3. Device identity. 4. Command class. 5. Actual command parameters. 6. Memory region. 7. Authorized DMA direction. 8. Device ownership generation. 9. Authority generation. 10. Queue identity. 11. Device security state. 12. Resource-state precondition. 13. Revocation state. 14. Required attestation. 15. Protected usage limit. 16. Required Finality Sink.

7.3.72. S-8.40 - Hardware Protected Validation Evidence

Following successful validation, the PED may commit an authenticated record comprising:

EvidenceID = VE-HW-0801

CandidateActID = CA-HW-0801

CommandDigest = DIGEST-HW-0801

DeviceID = DPU-02

AuthorityGeneration = 620

ResourceOwnershipGeneration = 91

ValidationResult = APPROVED

RequiredSink = FS-HW-02

EvidenceGeneration = 940

The evidence may be stored in protected software, secure controller memory, a hardwarebacked registry, or another suitable protected representation.

7.3.73. S-8.41 - Hardware Scoped Finality Capability

The bounded capability may be represented through:

1. A protected hardware permission entry. 2. A secure authorization register. 3. A command-specific latch. 4. An authenticated capability object. 5. A protected queue-admission entry. 6. A secure firmware state-machine reference. 7. A protected key-use condition. 8. A combination thereof.

The authorization is bounded to the operation and context required by the applicable enforcement point.

A generic device-enable bit does not necessarily satisfy a enforcement point requiring a one-time capability bound to committed validation evidence and the actual command descriptor.

7.3.74. S-8.42 - Hardware Finality Sink Verification

The hardware or firmware Finality Sink obtains the actual pending command.

It may verify:

(a) the actual command descriptor; (b) the target device and resource; (c) the authorized operation class; (d) the protected validation evidence; (e) the scoped finality capability;

(f) the authority generation;

(g) the resource ownership generation;

(h) the permitted memory scope;

(i) applicable revocation state;

(j) the required sink identity; and

(k) sink-local protected consumption state.

Upon successful verification, the sink permits the governed operation according to the applicable command-state transition.

7.3.75. PART XI - MEMORY OWNERSHIP AND TENANT ISOLATION

7.3.76. S-8.43 - Accelerator Memory Ownership

An accelerator memory allocation may be associated with a particular workload, agent, execution context, or tenant.

A representative ownership record includes:

MemoryAllocationID

DeviceID

OwnerTenantID

OwnerExecutionContextID

OwnershipGeneration

PhysicalOrDeviceMemoryRange

PermittedAccessClasses

MappingReferences

ActiveCommandReferences

SanitizationStatus

The ownership record may be maintained by a protected device manager, firmware component, hypervisor, or another enforcement component.

7.3.77. S-8.44 - Memory Ownership Transition

A memory ownership transition occurs when a resource previously associated with one execution context becomes available to another.

The transition may involve:

1. Revocation of prior authority. 2. Restriction of new accesses. 3. Completion or cancellation of outstanding operations. 4. Invalidation of relevant mappings. 5. Sanitization of residual data. 6. Verification of the required sanitization result. 7. Assignment of a new ownership generation. 8. Release to the new owner.

The ordering is important because clearing memory before all previous DMA writes have completed may permit stale data to be written again after the clearing procedure.

7.3.78. S-8.45 - Residual Accelerator Memory

Residual Accelerator Memory means data or state associated with a previous workload that remains in a device or related memory resource after the workload has ceased active execution.

Such residual state may include:

| x | Device-local memory buffers.                         |
| - | ---------------------------------------------------- |
| x | Allocator-managed memory pages.                      |
| x | Model intermediate results.                          |
| x | Temporary computation buffers.                       |
| x | Cached model data.                                   |
| x | Device-accessible host buffers.                      |
| x | Context metadata.                                    |
| x | Certain firmware-maintained or device-managed state. |

The actual residual-data surfaces depend upon the selected hardware.

An implementation must identify which surfaces are subject to its sanitization guarantee.

7.3.79. PART XII - VERIFIED MEMORY SANITIZATION

7.3.80. S-8.46 - Memory Sanitization Controller

A Memory Sanitization Controller means a component configured to ensure that selected data or state associated with a previous execution context is no longer accessible to a subsequent unauthorized context according to the applicable protection requirement.

Sanitization may comprise:

(a) overwriting selected memory; (b) zeroing; (c) secure deletion of accessible copies; (d) protected memory reinitialization; (e) cryptographic erasure through destruction of appropriate data-encryption keys;

(f) device reset where supported and sufficient; or

(g) another verified sanitization mechanism.

The selected procedure must address the relevant data residency and hardware behavior.

7.3.81. S-8.47 - Sanitization Preconditions

Before memory sanitization and reassignment, the system may require:

1. Prior owner revocation. 2. Restriction of new command submission. 3. Queue admission fencing. 4. Completion or cancellation of outstanding device commands. 5. Completion of relevant DMA operations. 6. Revocation of applicable device mappings. 7. Completion of required translation invalidations. 8. Confirmation that the prior owner cannot reestablish access. 9. Identification of the memory range to be sanitized. 10. Verification that the sanitization mechanism can reach the required memory region.

The necessary conditions vary with the device.

7.3.82. S-8.48 - Sanitization Procedure

A representative procedure is:

Step M1: Identify the resource to be reassigned.

Step M2: Obtain its current ownership generation.

Step M3: Mark the resource as REASSIGNMENT_PENDING.

Step M4: Prevent new operations by the previous owner.

Step M5: Fence the associated command queues.

Step M6: Drain, cancel, or otherwise resolve relevant outstanding commands.

Step M7: Restrict previous device and host mappings.

Step M8: Complete applicable translation invalidation.

Step M9: Verify the required quiescence condition.

Step M10: Sanitize the specified memory or protected resource state.

Step M11: Obtain evidence of sanitization completion.

Step M12: Verify that the sanitization applies to the required memory extent.

Step M13: Advance the ownership generation.

Step M14: Establish the new owner's access mappings.

Step M15: Release the resource to the new owner.

A new owner is not granted access merely because an operating-system allocator has changed the logical owner label.

7.3.83. S-8.49 - Sanitization Verification

A sanitization procedure may verify:

| x | The identity of the sanitized allocation.                               |
| - | ----------------------------------------------------------------------- |
| x | The covered memory range.                                               |
| x | The actual completed operation.                                         |
| x | The absence of outstanding prior-owner writes within the claimed scope. |
| x | The applicable translation-invalidation state.                          |
| x | The accepted ownership generation.                                      |
| x | The completion status of the selected sanitization mechanism.           |

Where readback is used, the implementation must account for the reliability and scope of that readback.

A successful zero read from one interface does not automatically prove that all hidden caches, remapped pages, device-managed copies, or inaccessible memory structures have been sanitized.

The supported sanitization guarantee must correspond to the actual hardware coverage.

7.3.84. S-8.50 - Cryptographic Erasure Variation

A memory resource may be protected through encryption under a key specific to an execution context, tenant, allocation, or generation.

Where the selected hardware provides the necessary cryptographic and key-isolation properties, destroying or making unavailable the relevant encryption key may render covered residual ciphertext inaccessible.

The implementation must verify that:

1. All data covered by the claimed erasure guarantee was encrypted under the relevant key. 2. The key is not recoverable through an unauthorized copy. 3. Reused or cached key material is appropriately cleared or invalidated. 4. The key is not shared with data that must remain accessible. 5. The replacement owner cannot recover the old key. 6. The cryptographic implementation satisfies the required security properties.

Cryptographic erasure does not automatically sanitize unencrypted copies outside the protected encryption domain.

7.3.85. PART XIII - CROSS-DEVICE REVOCATION

7.3.86. S-8.51 - Multi-Device Authority Context

An AI-agent task may use several devices.

For example:

| x | A GPU performs computation.               |
| - | ----------------------------------------- |
| x | A storage controller provides model data. |
| x | A DPU performs network transport.         |
| x | A SmartNIC transmits outputs.             |
| x | A DMA controller transfers buffers.       |

Each device may maintain different queues, mappings, and authority state.

A common task authority may therefore require coordination across multiple device-specific enforcement mechanisms.

7.3.87. S-8.52 - Cross-Device Authority Generation

A Cross-Device Authority Generation means an authority version associated with a defined set of cooperating devices or effectuation interfaces.

A representative record comprises:

AuthorityGeneration = 621

AgentContextID = AGENT-42

AffectedDevices = GPU-02, DPU-02, NIC-03

RestrictedOperationClasses = CLASS-A

RequiredFencingState = FENCE-621

ConvergenceStatus = PENDING

The generation may be maintained by a protected coordinator.

Each device may maintain a corresponding applied-generation state.

7.3.88. S-8.53 - Distributed Hardware Fencing

A cross-device fencing procedure may:

1. Identify affected devices. 2. Advance the protected authority generation. 3. Restrict new operation admission. 4. Identify outstanding commands. 5. Apply device-specific cancellation or fencing. 6. Obtain state acknowledgments. 7. Determine whether outstanding effects remain possible. 8. Apply compensating restrictions. 9. Record convergence or unresolved state.

An acknowledgment that a device has updated its policy does not necessarily prove that all previously admitted operations have stopped.

The claimed semantics determine whether admission convergence, execution convergence, or full effectuation quiescence is required.

7.3.89. S-8.54 - Cross-Device Completion Watermark

The system may associate a completion watermark with each relevant device or queue.

For example:

GPU-02: LastRetired = 1200

DPU-02: LastRetired = 850

NIC-03: LastTransmitted = 900

The values are illustrative and refer to separately defined device-local sequences.

A protected coordinator may determine whether the required operations have completed or been canceled according to the relevant watermarks and device-specific status.

No general numeric comparison between unrelated device-local sequence values is implied.

7.3.90. PART XIV - PRINCIPAL EXECUTION WORKFLOW

7.3.91. S-8.55 - Complete 32-Step Hardware Finality Workflow

7.3.92. Step S8-01 - Hardware resource initialization

The computing platform initializes the selected processors, accelerators, network devices, and related controllers.

7.3.93. Step S8-02 - Device security configuration

The system establishes the applicable hardware memory and resource isolation settings.

7.3.94. Step S8-03 - Device identity establishment

Required devices are associated with authenticated or protected device identities.

7.3.95. Step S8-04 - Authority-generation initialization

The protected authority controller establishes the current generation.

7.3.96. Step S8-05 - Execution-context registration

The agent, task, device, and permitted resource scope are associated with a machineverifiable context.

7.3.97. Step S8-06 - Memory ownership configuration

Required memory regions are assigned to the intended execution context.

7.3.98. Step S8-07 - DMA access configuration

The system establishes permitted DMA mappings and memory-access restrictions.

7.3.99. Step S8-08 - Command-interface control

The system configures applicable command submission and effectuation interfaces.

7.3.100. Step S8-09 - Effectuation-path verification

The system identifies the relevant alternative device paths capable of producing governed effects.

7.3.101. Step S8-10 - Agent computation

The agent performs ordinary computation.

7.3.102. Step S8-11 - Hardware operation proposal

The agent generates a consequential device or accelerator operation.

7.3.103. Step S8-12 - Operation interception

The command is captured before its governed effectuation boundary.

7.3.104. Step S8-13 - Candidate Hardware Act construction

The system creates a machine-readable command representation.

7.3.105. Step S8-14 - Non-effective command staging

The operation remains withheld.

7.3.106. Step S8-15 - Actual device-context association

The command is associated with its authenticated device and execution context.

7.3.107. Step S8-16 - Descriptor canonicalization

The required command parameters and resource identifiers are represented deterministically.

7.3.108. Step S8-17 - PED submission

The descriptor is submitted to protected authorization.

7.3.109. Step S8-18 - Protected authority-state retrieval

The PED obtains current authority, ownership, and revocation state.

7.3.110. Step S8-19 - Required predicate evaluation

The PED validates the operation-specific conditions.

7.3.111. Step S8-20 - Protected validation evidence commitment

The required evidence is committed.

7.3.112. Step S8-21 - Scoped finality capability establishment

Bounded finality authorization is activated.

7.3.113. Step S8-22 - Command presentation

The staged command reaches the authorized device Finality Sink.

7.3.114. Step S8-23 - Actual pending command reconstruction

The sink obtains the command representation that will actually be admitted or executed.

7.3.115. Step S8-24 - Capability verification

The sink verifies the required evidence, capability, and operation bindings.

7.3.116. Step S8-25 - Authority-generation verification

The sink checks the current applicable authority and ownership generations.

7.3.117. Step S8-26 - Memory-access verification

The sink checks required memory-scope or device-access conditions.

7.3.118. Step S8-27 - Protected consumption transition

The sink reserves or consumes the authorization according to the usage policy.

7.3.119. Step S8-28 - Hardware command admission

The command is admitted through the controlled interface.

7.3.120. Step S8-29 - Hardware execution

The device executes the authorized command.

7.3.121. Step S8-30 - Completion observation

The relevant device completion state is obtained.

7.3.122. Step S8-31 - Effectuation outcome reconciliation

The protected operation state is updated or marked unresolved.

7.3.123. Step S8-32 - Resource lifecycle update

The relevant device, queue, and ownership state are updated according to the selected resource-management policy.

7.3.124. PART XV - REFERENCE ALGORITHMS

S-8.56 - Algorithm A: Hardware Security Initialization function InitializeHardwareSandbox(configuration):

devices = EnumerateRequiredDevices(configuration)

for each device in devices:

if not VerifyRequiredDeviceCapabilities(

device, configuration.required_properties[device]

):

return DENIED

InitializeDeviceIsolation(device)

InitializeProtectedDeviceContext(device)

if not VerifyRequiredEffectuationControl(device):

return DENIED authority_generation = AllocateProtectedAuthorityGeneration()

RegisterProtectedHardwareConfiguration({

devices: devices, authority_generation: authority_generation, security_profile: configuration.profile })

if not VerifyGovernedEffectuationPathCoverage():

RestrictGovernedOperations() return DENIED return ACTIVE

The verification functions must correspond to actual platform capabilities.

A generic return value indicating success does not establish that unsupported hardware protections exist.

7.3.125. S-8.57 - Algorithm B: Hardware Command Capture

function CaptureHardwareCandidate(source, command):

context = AuthenticateDeviceExecutionContext(source)

if context is invalid:

return DENIED

if not VerifyCurrentContextGeneration(context):

return DENIED controlled_command = CaptureStableCommandRepresentation(

command )

if not IsGovernedHardwareEffect(controlled_command):

return EvaluateApplicableOrdinaryHardwarePolicy(

controlled_command )

candidate_id = AllocateCandidateActID()

descriptor = Canonicalize({

candidate_id: candidate_id, execution_context: context, device_id: controlled_command.device_id, command_class: controlled_command.class, command_parameters: controlled_command.parameters, memory_scope: controlled_command.memory_scope, authority_generation: CurrentAuthorityGeneration(context), ownership_generation: CurrentOwnershipGeneration(context), intended_sink: ResolveHardwareFinalitySink(controlled_command) })

ProtectedCommandRegistry.stage(

candidate_id, controlled_command, descriptor )

return PED.Validate(candidate_id, descriptor)

The command must remain non-effective with respect to the designated consequence during protected validation.

S-8.58 - Algorithm C: Protected Hardware Authorization

function ValidateHardwareCandidate(candidate_id, descriptor):

record = ProtectedCommandRegistry.get(candidate_id)

if record.status != STAGED:

return DENIED

if not VerifyDeviceAndContextBinding(descriptor, record):

return DENIED authority = ProtectedAuthorityRegistry.lookup(descriptor)

if not VerifyCurrentAuthorityGeneration(authority):

return DENIED

if not VerifyResourceOwnership(

descriptor, authority ):

return DENIED if not EvaluateRequiredHardwarePredicates(

descriptor, authority ):

ProtectedCommandRegistry.deny(candidate_id) return DENIED evidence = CommitProtectedValidationEvidence(

candidate_id, descriptor, authority )

capability = CreateScopedHardwareFinalityCapability({

candidate_id: candidate_id, evidence_reference: evidence.id, descriptor_digest: HashCanonical(descriptor), device_id: descriptor.device_id, intended_sink: descriptor.intended_sink, authority_generation: authority.generation, ownership_generation: descriptor.ownership_generation })

if not ActivateAuthorizationAtomically(

candidate_id, evidence, capability ):

DisableCapability(capability) return DENIED

return AUTHORIZED

The implementation must ensure the required protected ordering among evidence commitment, capability activation, and command authorization.

7.3.126. S-8.59 - Algorithm D: Hardware Finality Sink

function ExecuteAuthorizedHardwareCommand(candidate_id):

record = ProtectedCommandRegistry.get(candidate_id)

if record.status != AUTHORIZED:

return DENIED

actual_command = ReadControlledPendingCommand(candidate_id)

if actual_command is unavailable:

return DENIED 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 VerifyActualHardwareCommand(

actual_command, capability ):

return DENIED if not VerifyCurrentDeviceAuthorityGeneration(

capability ):

return DENIED if not VerifyCurrentOwnershipGeneration(

actual_command, capability ):

return DENIED

if not VerifyRequiredMemoryAccessScope(

actual_command ):

return DENIED

if not VerifySinkLocalProtectedState(capability):

return DENIED if not ReserveCapabilityAtomically(capability):

return DENIED result = AdmitCommandThroughControlledDeviceInterface(

actual_command )

RecordOrReconcileHardwareOutcome(

candidate_id, result )

return result

If the enforcement point governs actual execution rather than admission, the enforcement architecture must also prevent prohibited execution after admission.

S-8.60 - Algorithm E: Cross-Device Authority Fencing

function FenceCrossDeviceAuthority(context, restriction):

generation = AdvanceProtectedAuthorityGeneration(

context )

devices = ResolveAffectedDevices(context, restriction)

for each device in devices:

BlockNewProhibitedCommandAdmissions(

device, generation, restriction )

for each device in devices:

outstanding = EnumerateRelevantOutstandingCommands(

device, restriction

)

ApplySupportedCommandFencing(

device, outstanding, generation )

states = CollectDeviceFencingStates(

devices, generation )

if not VerifyRequiredSafetyCondition(states):

ApplyCompensatingRestrictions(devices) return FENCING_INCOMPLETE

CommitProtectedFencingCompletion(

context, generation, states )

return FENCED

The required safety condition may concern only admission of new commands or may additionally require resolution of all previously admitted effect-capable commands.

The implementation must not conflate these distinct guarantees.

7.3.127. S-8.61 - Algorithm F: DMA Access Revocation

function RevokeDMAAccess(device_context, memory_range):

BlockNewDMACommandAdmission(

device_context, memory_range )

outstanding = EnumerateRelevantDMAOperations(

device_context, memory_range )

ApplySupportedDMAFencing(

device_context, outstanding )

UpdateDeviceMemoryMappings(

device_context, memory_range, DENY_ACCESS )

IssueRequiredTranslationInvalidations(

device_context, memory_range )

if not VerifyTranslationInvalidationCompletion(

device_context ):

return RESTRICTED

if not VerifyRequiredOutstandingDMAResolution(

device_context, memory_range ):

return RESTRICTED

CommitProtectedDMARevocationState(

device_context, memory_range )

return REVOKED

The procedure must use the relevant platform-specific IOMMU, device, and interconnect mechanisms.

A translation invalidation does not independently establish complete cancellation of unrelated outstanding operations.

S-8.62 - Algorithm G: Verified Device Memory Reassignment

function ReassignDeviceMemory(

allocation_id, current_owner, new_owner ):

allocation = ProtectedMemoryRegistry.get(allocation_id)

if allocation.owner != current_owner:

return DENIED

MarkAllocationReassignmentPending(allocation)

if not BlockNewPriorOwnerOperations(allocation):

return DENIED

if not FenceRelevantDeviceQueues(allocation):

return RESTRICTED if not ResolveOutstandingMemoryAccesses(allocation):

return RESTRICTED if not RevokePriorOwnerMappings(allocation):

return RESTRICTED

if not CompleteRequiredTranslationInvalidations(allocation):

return RESTRICTED if not VerifyResourceQuiescence(allocation):

return RESTRICTED

result = PerformSelectedSanitization(allocation)

if result != SUCCESS:

return RESTRICTED

if not VerifySanitizationCoverage(allocation):

return RESTRICTED

new_generation = AdvanceOwnershipGeneration(allocation)

UpdateProtectedMemoryOwnership(

allocation, new_owner, new_generation )

EstablishNewOwnerMappings(allocation, new_owner)

return REASSIGNED

The sequence prevents the resource from becoming available to the new owner before the required prior-owner access restrictions and sanitization conditions are satisfied.

7.3.128. S-8.63 - Algorithm H: Hardware Recovery

function RecoverHardwareEnforcement():

protected_state = RecoverProtectedAuthorityState()

if not VerifyProtectedStateContinuity(protected_state):

RestrictAffectedDevices() return RECOVERY_REQUIRED

devices = EnumerateGovernedDevices()

for each device in devices:

state = RecoverOrInspectDeviceState(device)

if state is unreliable:

RestrictDeviceEffects(device) continue

ReconcileOutstandingCommandState(

device, state )

VerifyAppliedAuthorityGeneration(

device, protected_state )

VerifyRelevantMemoryOwnership(

device, protected_state )

if not VerifyRequiredDeviceEnforcementCoverage():

return RESTRICTED

return ACTIVE

Recovery must distinguish commands that are confirmed completed, confirmed not executed, canceled, and potentially effected but unresolved.

7.3.129. PART XVI - WORKED TECHNICAL EXAMPLES

S-8.64 - Example A: GPU Model Output With Protected Egress

The following is a hypothetical implementation example.

An AI agent executes a model on a GPU.

The GPU produces an output tensor containing information associated with an enterprise task.

The output remains in a controlled accelerator buffer.

The agent requests transmission of a derived report to an external service.

The controlled interface constructs a Candidate Act identifying:

| x | The originating agent.                 |
| - | -------------------------------------- |
| x | The task.                              |
| x | The intended recipient.                |
| x | The relevant output or payload digest. |
| x | The applicable data scope.             |
| x | The authority generation.              |
| x | The intended egress Finality Sink.     |

The PED evaluates whether the output may be released to the selected recipient.

Protected validation evidence is committed.

A scoped non-bearer capability is established.

A protected network Finality Sink obtains the actual pending transmission.

The sink verifies the required authorization.

Only the authorized output is transmitted.

The GPU's successful computation does not, by itself, authorize the external transmission.

S-8.65 - Example B: DPU-Controlled Agent Network Operation

An AI agent operates within a cloud-hosted virtual machine.

A DPU provides protected control over selected network-egress interfaces.

The agent generates a network operation.

The request reaches a controlled host-to-DPU operation path.

The operation is staged and associated with the authenticated workload context.

The PED evaluates the permitted destination, operation scope, and policy generation.

Protected evidence and bounded finality authorization are established.

The DPU-controlled Finality Sink verifies the actual pending network effect.

The device permits transmission only if the required authorization succeeds.

An alternative host networking path must be restricted or mediated if the deployment enforcement points non-bypassability for that network effect.

7.3.130. S-8.66 - Example C: DMA Isolation of Agent Memory

An accelerator is assigned to an agent workload.

The resource manager configures an IOMMU domain permitting the device to access selected memory regions.

The agent attempts to cause the device to write outside the permitted memory scope.

The device's effective memory request is checked against the supported IOMMU access restrictions.

The unauthorized access is rejected according to the hardware mechanism.

In an optional protected-finality variation, a PED additionally authorizes the specific device operation before command admission.

This example illustrates that hardware memory isolation and operation-specific finality may cooperate while remaining technically distinct.

S-8.67 - Example D: Revocation During GPU Queue Execution

An agent has submitted multiple GPU operations.

Some commands have completed.

Others remain queued or executing.

A protected authority controller revokes the relevant task authority.

The system advances the hardware authority generation.

New commands associated with the revoked authority are withheld.

The hardware fencing controller identifies outstanding commands.

Commands not yet executing may be canceled where supported.

Executing commands may require a supported preemption, queue-drain, or device-reset procedure, depending upon the relevant effect and device capabilities.

The system does not declare complete execution fencing until the required state of outstanding operations has been established.

S-8.68 - Example E: Accelerator Memory Sanitization Before Tenant Reassignment

Tenant A uses an AI accelerator.

The accelerator contains allocated memory associated with Tenant A's model operations.

Tenant A's workload terminates.

The resource manager prepares to assign the memory to Tenant B.

The protected ownership controller marks the allocation REASSIGNMENT_PENDING.

The system prevents new Tenant A operations.

The relevant command queues are fenced.

Outstanding memory accesses are resolved.

Prior mappings are revoked.

Required translation invalidations are completed.

The memory-sanitization mechanism clears the memory within its stated coverage.

The system verifies completion of the required sanitization procedure.

Only then is a new ownership generation established and access granted to Tenant B.

The architecture does not treat termination of Tenant A's process as proof that its device memory has already been sanitized.

S-8.69 - Example F: Peer-to-Peer GPU-to-NIC Transfer

A GPU contains a computed output.

A network device supports an applicable peer-to-peer data-transfer path.

The agent requests transfer of the GPU output to an external destination.

A protected authorization system evaluates the output-release scope.

The corresponding Finality Sink controls the peer-to-peer transfer or the final network transmission.

The implementation constrains the relevant DMA and device command interfaces so that the output cannot reach the network through an uncontrolled path.

If the GPU can otherwise expose the same data through an unrestricted alternate transfer path, the claimed non-bypassability property is not established for that data release.

7.3.131. S-8.70 - Example G: Cross-Device Revocation

An agent task uses a GPU, storage controller, and DPU.

The task's authority is reduced.

A protected coordinator advances the authority generation.

The GPU controller rejects new commands associated with the earlier generation.

The storage controller applies the required write restriction.

The DPU restricts corresponding network transfers.

Each device reports its applied generation and relevant outstanding-operation status.

The coordinator determines whether the required restriction has converged.

If one device remains capable of performing a prohibited operation, the system applies the appropriate compensating restriction or records incomplete convergence.

A central policy update alone is not treated as proof of full hardware effectuation control.

S-8.71 - Example H: Hardware Reset With Indeterminate Operations

A device executes a command that may have modified an external resource.

The device resets before the host receives a reliable completion record.

Following restart, the recovery controller obtains the available protected operation and device-state records.

The operation is classified as potentially effected but unresolved.

The system does not automatically issue the same command again.

It performs the available resource-state or external-operation reconciliation procedure.

Where no reliable completion determination is possible, the unresolved status is preserved according to the applicable policy.

7.3.132. PART XVII - FAILURE AND ADVERSARIAL SCENARIOS

7.3.133. S-8.72 - Representative Failure Conditions

7.3.134. F1 - Uncontrolled GPU Command Queue

The agent submits a command through an unmediated queue.

A protected-finality deployment must control or exclude this path for the claimed effect.

7.3.135. F2 - Device Command Substitution

The actual device command differs from the previously authorized descriptor.

The Finality Sink detects the material mismatch.

7.3.136. F3 - Stale Authority Generation

A command refers to an unacceptable authority generation.

The applicable protected controller rejects the command.

7.3.137. F4 - Stale Ownership Generation

A command attempts to use memory assigned to a subsequent owner.

The ownership-generation check prevents unauthorized access.

7.3.138. F5 - IOMMU Mapping Error

A device receives a broader memory mapping than permitted.

The configuration or verification mechanism identifies the violation.

7.3.139. F6 - DMA Translation Staleness

A device retains an old translation after mapping revocation.

The required invalidation and completion procedures address the stale state.

7.3.140. F7 - In-Flight DMA After Revocation

A DMA write remains capable of completing after software revokes the mapping.

The implementation applies the necessary device-specific fencing and outstanding-operation checks.

7.3.141. F8 - GPU Memory Reuse Without Sanitization

A memory allocation is assigned to a new tenant while residual data remains accessible.

The reassignment procedure withholds access pending the required sanitization.

7.3.142. F9 - Sanitization Before Queue Drain

Memory is cleared while a prior command remains capable of writing to it.

The resource is not released until the required outstanding-operation safety condition is satisfied.

7.3.143. F10 - Incomplete Sanitization Coverage

A memory-clearing operation does not cover the resource extent included in the security guarantee.

The verification mechanism rejects or restricts reassignment.

7.3.144. F11 - Unverified Cryptographic Erasure

A key is deleted, but residual plaintext or key copies remain outside the protected encryption domain.

The system cannot represent the complete memory resource as securely erased based solely on key deletion.

7.3.145. F12 - Peer-to-Peer Bypass

A device transfers data through an uncontrolled peer-to-peer path.

The deployment restricts or mediates that path where necessary for the enforcement point.

7.3.146. F13 - Unauthorized Device Pass-Through

A virtual machine obtains direct access to an effect-capable device.

The relevant device interface must be controlled or excluded from the governed execution configuration.

7.3.147. F14 - Firmware Authorization Bypass

A device exposes a command path that ignores the protected authorization mechanism.

The claimed finality property is not established until the bypass is addressed.

7.3.148. F15 - Capability Replay

A consumed single-use hardware authorization is presented again.

Protected sink-local state rejects the replay.

7.3.149. F16 - Concurrent Capability Use

Two command workers attempt to consume the same single-use authorization.

An atomic protected state transition restricts use according to the capability policy.

7.3.150. F17 - Device Reset Clears Revocation State

A device reset removes volatile policy restrictions.

The recovery process restricts governed operations until the required current authorization state has been restored.

7.3.151. F18 - Queue Completion Misinterpretation

A queue acknowledgment is treated as proof of physical or external completion despite lacking that meaning.

The operation-state model distinguishes the actual completion semantics.

7.3.152. F19 - Cross-Device Generation Mismatch

One device applies a new restriction while another uses stale authority.

The convergence controller detects or prevents unauthorized inconsistent execution according to the enforcement point.

7.3.153. F20 - Command Cancellation Unsupported

A device does not support cancellation of a selected running operation.

The implementation identifies the limitation and employs a supported alternative or maintains an unresolved restriction state.

7.3.154. F21 - Hardware Quiescence Misclassification

A device reports low activity but still has outstanding memory accesses.

The quiescence procedure checks the relevant device and operation state rather than relying solely on utilization.

7.3.155. F22 - Protected Register Tampering

An unauthorized component attempts to modify a protected device register.

The selected hardware protection prevents the modification according to its threat model.

7.3.156. F23 - Device Identity Substitution

Authorization intended for one device is presented to another.

The required device-identity binding is verified.

7.3.157. F24 - Queue Identity Substitution

A capability authorized for one queue is applied to a different queue.

The sink checks the applicable queue binding where required.

7.3.158. F25 - Hardware Command Parameter Expansion

A command is modified to access a broader memory or resource scope.

Actual command verification detects the unauthorized expansion.

7.3.159. F26 - GPU Context Reuse

A recycled accelerator execution-context identifier is mistaken for an earlier authorized context.

The protected context-generation mechanism distinguishes the instances.

7.3.160. F27 - Cross-Tenant Resource Alias

Different logical identifiers reference the same underlying protected hardware resource.

The ownership controller resolves or verifies the actual resource association.

7.3.161. F28 - Device Firmware Downgrade

A firmware version lacking required enforcement is installed.

The system rejects the unsupported security state when the corresponding firmware guarantee is mandatory.

7.3.162. F29 - Host-Kernel Compromise

The host kernel is compromised.

A host-software-only device authorization mechanism may fail.

Hardware-backed protection is required if the enforcement point includes resistance to that adversary.

7.3.163. F30 - Device Controller Compromise

The device's protected firmware or controller is compromised.

The security guarantee depends upon the actual hardware trust and recovery model.

7.3.164. F31 - Hardware Queue Resource Exhaustion

The command queue becomes full or the enforcement controller cannot allocate required state.

The system applies the defined restriction or failure response rather than interpreting resource exhaustion as authorization.

7.3.165. F32 - Memory Ownership Registry Rollback

An earlier resource ownership generation is restored.

Protected state continuity detects or prevents prohibited reuse.

7.3.166. F33 - Device Hot-Plug or Removal

A device is removed or replaced during operation.

The system invalidates or re-establishes the required device identity and authority association.

7.3.167. F34 - Accelerator Migration

A workload moves to a different accelerator.

The destination device receives only the authority and memory resources permitted under the applicable migration procedure.

7.3.168. F35 - External Operation Acknowledgment Lost

A device-generated operation may have produced an effect, but the completion acknowledgment is lost.

The system retains an indeterminate operation state.

7.3.169. F36 - Protected State Recovery Failure

Required authority, ownership, or consumption state cannot be recovered reliably.

The affected governed operation paths remain restricted.

7.3.170. PART XVIII - IMPLEMENTATION VARIATIONS

7.3.171. S-8.73 - GPU-Only Resource Isolation

A GPU execution environment may provide selected memory, context, and command restrictions without requiring the full protected-finality sequence.

This variation may support independent enforcement points directed to isolation, resource ownership, or sanitization.

It does not automatically satisfy enforcement points requiring protected validation evidence and scoped non-bearer finality capabilities.

7.3.172. S-8.74 - GPU With Software PED

A protected host service evaluates selected GPU operations.

| The driver or controlled accelerator interface implements the required Finality Sink. The security model relies on the integrity of the relevant host and driver enforcement components.                                                                                                                                                                                                |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-8.75 - GPU With Hardware CIED A hardware-protected or cryptographically isolated component performs protected authorization. A controlled accelerator command processor or equivalent device interface verifies the required authorization before the governed effect. The implementation must establish actual coupling between the protected authorization and device effectuation. |
| S-8.76 - SmartNIC-Only Egress Control A SmartNIC may control selected network transmissions independently of GPU operation authorization. The SmartNIC serves as the Finality Sink only for the effects it can actually prevent or permit.                                                                                                                                              |

7.3.173. S-8.77 - DPU and GPU Cooperative Enforcement

A GPU performs computation.

A DPU controls selected data transfers or network effects.

A PED evaluates required authorization conditions.

The DPU or another protected controller verifies actual output-release operations.

The arrangement may additionally use protected device memory mappings.

7.3.174. S-8.78 - FPGA-Based Enforcement

A programmable logic region may implement operation-descriptor verification, protected registers, authorization latches, bounded counters, or effectuation gating.

The FPGA's configuration and authority-critical state must be protected according to the applicable enforcement point.

7.3.175. S-8.79 - ASIC-Based Finality Controller

A dedicated hardware controller may implement:

1. Candidate command capture. 2. Protected authorization lookup. 3. Descriptor comparison. 4. Capability-state verification. 5. Atomic usage-state transition. 6. Controlled operation release.

The functions may be implemented through logic circuits, register files, protected memories, or hardware state machines.

7.3.176. S-8.80 - IOMMU-Based Memory Isolation

An IOMMU may restrict memory accesses by permitted devices.

The implementation may operate independently of the broader protected-finality mechanism where a enforcement point concerns only memory-access isolation.

Where operation-specific authority is required, corresponding authorization is added through a suitable protected controller.

7.3.177. S-8.81 - Cross-Device Protected Controller

A protected controller may coordinate authority generations across several devices.

The controller may maintain a registry of device identities, resource ownership, outstanding commands, and applied enforcement generations.

Each device implements the restrictions that its actual hardware capabilities support.

7.3.178. S-8.82 - Device Memory Sanitization Without Finality Capability

A device resource manager may implement a protected sanitization and reassignment sequence independently of a Candidate Act receipt-capability architecture.

The sequence may include queue fencing, mapping invalidation, sanitization, completion verification, and ownership-generation transition.

This variation supports an independently claimed hardware memory-protection invention where its limitations are expressly disclosed.

| S-8.83 - TEE/HSM-Assisted Hardware Authorization A TEE or HSM provides protected authorization, key custody, evidence commitment, or capability activation. A hardware device acts as the Finality Sink. The implementation must provide the required protected communication and operation binding.                                                                                                              |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| S-8.84 - Single-Chip Integrated Implementation A system-on-chip may contain general-purpose processors, accelerator units, protected memory, device controllers, and finality-enforcement logic. The relevant security roles may be implemented within one chip. Physical separation is not required unless the applicable claim expressly imposes it.                                                            |
| S-8.85 - Distributed Hardware Implementation Multiple devices located on different computing nodes may cooperate through authenticated communication and protected generation state. The system may govern cross-device operations and enforce bounded authorization at each relevant effectuation boundary. Network partitions and incomplete state convergence must be handled according to the selected claim. |

7.3.179. PART XIX - TECHNICAL DATA STRUCTURES

7.3.180. S-8.86 - HardwareExecutionContextRecord

Fields may include:

1. ExecutionContextID. 2. AgentContextID. 3. TaskID. 4. DeviceID. 5. DeviceContextID. 6. ExecutionGeneration. 7. AuthorityGeneration. 8. SecurityProfile. 9. PermittedCommandClasses. 10. LifecycleStatus.

7.3.181. S-8.87 - DeviceAuthorityRecord

Fields may include:

1. DeviceAuthorityDomainID. 2. DeviceID. 3. AgentOrTenantID. 4. TaskID. 5. AuthorityGeneration. 6. RevocationGeneration. 7. PermittedResources. 8. PermittedCommandClasses. 9. ProtectedPolicyReference. 10. CurrentEnforcementState.

7.3.182. S-8.88 - HardwareCandidateActRecord

Fields may include:

1. CandidateActID. 2. HardwareCommandID. 3. OriginatingExecutionContext. 4. DeviceID. 5. QueueID. 6. CommandClass. 7. CommandDescriptorDigest. 8. AuthorityGeneration. 9. OwnershipGeneration. 10. CandidateStatus.

7.3.183. S-8.89 - HardwareValidationEvidenceRecord

Fields may include:

1. EvidenceID. 2. CandidateActID. 3. CommandDescriptorDigest. 4. PEDIdentity. 5. AuthorityGeneration. 6. OwnershipGeneration. 7. ValidationResult. 8. ProtectedEvidenceCommitment. 9. EvidenceGeneration. 10. RequiredSinkID.

7.3.184. S-8.90 - HardwareFinalityCapabilityRecord

Fields may include:

1. CapabilityID. 2. CandidateActID. 3. EvidenceReference. 4. CommandDescriptorDigest. 5. AuthorizedDevice. 6. AuthorizedQueue. 7. PermittedCommandScope. 8. AuthorityGeneration. 9. OwnershipGeneration. 10. UsagePolicy. 11. CapabilityStatus. 12. ProtectedConsumptionReference.

7.3.185. S-8.91 - DeviceQueueStateRecord

Fields may include:

1. DeviceID. 2. QueueID. 3. QueueGeneration. 4. LastSubmittedSequence. 5. LastAdmittedSequence. 6. LastScheduledSequence. 7. LastCompletedSequence. 8. LastRetiredSequence. 9. FencingState. 10. OutstandingCommandReferences.

7.3.186. S-8.92 - DMAAccessRecord

Fields may include:

1. DMAOperationID. 2. RequestingDeviceID. 3. ExecutionContextID. 4. IOMMUDomainID. 5. MemoryRangeReference. 6. AccessDirection. 7. MappingGeneration. 8. TranslationInvalidationState. 9. OutstandingTransferState. 10. CompletionState.

7.3.187. S-8.93 - DeviceMemoryOwnershipRecord

Fields may include:

1. AllocationID. 2. DeviceID. 3. OwnerTenantID. 4. OwnerExecutionContext. 5. OwnershipGeneration. 6. MemoryRange. 7. ActiveMappingReferences. 8. ActiveCommandReferences. 9. SanitizationStatus. 10. ReassignmentStatus.

7.3.188. S-8.94 - SanitizationEvidenceRecord

Fields may include:

1. SanitizationID. 2. AllocationID. 3. PreviousOwner. 4. PreviousOwnershipGeneration. 5. SanitizationMethod. 6. CoveredMemoryRange. 7. RequiredQuiescenceReference. 8. MappingInvalidationReference. 9. SanitizationCompletionStatus. 10. VerificationResult.

11. NewOwnershipGeneration.

7.3.189. S-8.95 - CrossDeviceFencingRecord

Fields may include:

1. FencingGeneration. 2. AgentOrTaskContext. 3. AffectedDeviceIDs. 4. RestrictedOperationClasses. 5. DeviceAppliedGenerations. 6. OutstandingCommandReferences. 7. CompletionWatermarks. 8. RequiredSafetyCondition. 9. ConvergenceStatus. 10. CompensatingRestrictions.

7.3.190. S-8.96 - HardwareRecoveryRecord

Fields may include:

1. RecoveryGeneration. 2. DeviceID. 3. LastProtectedAuthorityGeneration. 4. LastAcceptedOwnershipGeneration. 5. OutstandingCommands. 6. UnresolvedDMAOperations. 7. ProtectedCapabilityConsumptionReferences. 8. SanitizationPendingResources. 9. RequiredFencingActions. 10. RecoveryStatus.

These records may be implemented using device firmware structures, protected registers, secure memories, authenticated host registries, transactionally protected software state, or combinations thereof.

7.3.191. PART XX - implementer VERIFICATION TESTS

7.3.192. S-8.97 - Representative Engineering Test Matrix

The following are proposed verification procedures, not representations of experiments already performed.

Test Technical condition Expected behavior

T1 Valid hardware command

authorization

T2 Missing capability T3 Invalid evidence T4 Replayed single-use capability T5 Modified hardware command T6 Wrong device identity T7 Wrong queue identity T8 Stale authority generation T9 Stale ownership generation T10 Unauthorized DMA mapping T11 DMA mapping revocation T12 In-flight DMA after revocation T13 Device pass-through bypass T14 Peer-to-peer transfer bypass T15 GPU output release without

authorization T16 Command replay after device reset T17 Concurrent capability use T18 Hardware queue fencing T19 Outstanding queued operation T20 Incomplete quiescence T21 Memory not fully sanitized T22 Sanitization after prior-owner writes T23 Cryptographic erasure with residual

plaintext T24 Tenant reassignment T25 GPU context identifier reuse T26 Multi-device generation mismatch T27 Device reset loses volatile restrictions Recovery reestablishes required controls T28 Firmware downgrade T29 Alternate command interface T30 Protected register tampering T31 Hardware recovery after incomplete

dispatch T32 Unreliable completion watermark T33 Cross-device fencing incomplete T34 Memory ownership registry rollback Stale state detected T35 Device replacement T36 Device resource exhaustion

Governed operation permitted Effect withheld Effect withheld Rejected Mismatch detected Authorization rejected Required binding enforced Command restricted Access rejected Access denied Required invalidation completed Required safety condition enforced Governed effect restricted Controlled or denied Release withheld Protected state prevents unauthorized reuse Atomic consumption enforced Required new-command restrictions applied Required cancellation or continuation semantics applied Reassignment withheld Reassignment withheld Required ordering enforced Incomplete protection recognized New ownership generation verified Stale authorization rejected Convergence failure recognized

Required version policy enforced Controlled or excluded Unauthorized modification prevented under defined model Unresolved operations reconciled No unsupported completion enforcement point Restriction remains unresolved

Authority and ownership revalidated Defined restrictive behavior

T37 GPU-to-NIC unauthorized transfer T38 Shared accelerator tenant separation T39 Stale device-side translation T40 Failed sanitization controller

Protected release restriction enforced Actual supported isolation guarantees tested Required mapping safety enforced Resource not released as sanitized

Each test should be adapted to the actual device architecture.

Platform-specific validation must account for the differences among command admission, execution completion, memory translation, device synchronization, and external effectuation.

7.3.193. PART XXI - Enforcement-Point Mapping and Technical Correspondence

7.3.194. S-8.98 - Enforcement-Point Mapping and Technical Correspondence

this implementation profile provides representative technical disclosure relevant to proposed enforcement points concerning:

(a) hardware and firmware AI-agent sandboxing;

(b) SmartNIC/DPU enforcement;

(c) GPU and accelerator execution isolation;

(d) IOMMU memory-access controls;

(e) DMA operation restriction;

(f) hardware Candidate Act staging;

(g) protected validation evidence;

(h) scoped non-bearer hardware finality capabilities;

(i) hardware Finality Sink verification;

(j) actual pending device-command reconstruction;

(k) hardware authority generations;

(l) queue admission and execution control;

(m) cross-device fencing;

(n) protected device command consumption;

(o) completion watermarks;

(p) device memory ownership;

(q) accelerator memory sanitization;

(r) verified tenant reassignment;

(s) peer-to-peer transfer restrictions;

(t) asynchronous device operation recovery; and

(u) hardware-software hybrid enforcement.

The embodiment is particularly relevant to the proposed hardware-related independent enforcement point(s) 76, 84, 93, and 97 and their applicable dependent-enforcement point families.

It may also contribute implementation support to enforcement point(s) 1, 9, 21, 33, and other enforcement points requiring hardware variants of protected effectuation control.

The correspondence is provisional. Each finalized enforcement point must be checked against the actual disclosed components, algorithms, state transitions, and implementation alternatives.

7.3.195. PART XXII - implementer IMPLEMENTATION REQUIREMENTS

7.3.196. S-8.99 - Hardware Implementation Checklist

For a selected accelerator, SmartNIC, DPU, storage controller, or other hardware platform, a person having ordinary skill in the art identifies:

1. The actual hardware and firmware architecture. 2. The supported processor and device execution interfaces. 3. The device isolation mechanisms. 4. The available memory protection mechanisms. 5. The device command queue structure. 6. The command admission and execution semantics. 7. The supported cancellation and preemption mechanisms. 8. The available completion and retirement indicators. 9. The trusted computing base. 10. The applicable adversary model. 11. The agent-to-device execution-context binding. 12. The protected device identity mechanism. 13. The operation classes requiring authorization. 14. The controlled effectuation boundaries. 15. The relevant alternate command and memory paths. 16. The Candidate Act descriptor format. 17. The non-effective staging mechanism. 18. The PED or CIED implementation. 19. The required authorization predicates. 20. The protected authority-state representation.

21. The validation-evidence format and commitment ordering. 22. The scoped capability implementation. 23. The hardware or firmware Finality Sink. 24. The actual pending command verification mechanism. 25. The protected capability-consumption semantics. 26. The authority-generation allocation and update procedure. 27. The device ownership-generation mechanism. 28. The queue fencing procedure. 29. The outstanding-command resolution procedure. 30. The hardware completion-watermark semantics. 31. The IOMMU domain configuration. 32. The DMA mapping and revocation procedure. 33. The applicable translation-invalidation semantics. 34. The peer-to-peer device transfer restrictions. 35. The memory sanitization procedure. 36. The sanitization coverage-verification procedure. 37. The memory ownership transition. 38. The device reset and recovery procedure. 39. The treatment of indeterminate external effects. 40. The cross-device authority-convergence mechanism. 41. The platform-specific failure-injection procedures. 42. The actual verification tests demonstrating the claimed technical properties.

Where the selected hardware lacks a required primitive, the implementation must disclose a supported equivalent control or narrow the corresponding guarantee.

A generic statement that a GPU, DPU, FPGA, ASIC, or IOMMU enforces authorization is not sufficient if the specific enforcement point requires a property that the chosen hardware cannot establish.

7.3.197. PART XXIII - TECHNICAL EFFECT

7.3.198. S-8.100 - Technical Effect

this implementation profile provides a hardware-software architecture in which artificialintelligence computation, device resource isolation, operation authorization, command admission, hardware execution, and consequential effectuation can be governed as distinct technical stages.

A GPU or accelerator may perform permitted computation without thereby receiving unrestricted authority to transmit outputs, modify protected resources, access unauthorized memory, or execute additional device commands.

A PED or CIED may evaluate applicable operation-specific authorization conditions.

Protected validation evidence and scoped finality authorization may be established for governed Candidate Acts.

A hardware or firmware Finality Sink may verify the actual pending command before permitting the designated effect.

Hardware authority generations, protected queue state, IOMMU controls, DMA restrictions, completion watermarks, and fencing mechanisms may be used to coordinate restrictions across device boundaries.

Separate sanitization and ownership-transition mechanisms may prevent memory associated with an earlier execution context from becoming accessible to a subsequent unauthorized context.

The claimed technical guarantees depend upon the actual hardware capabilities and enforcement positions.

7.3.198.1. S-8.101 - Technical Summary

this implementation profile discloses a SmartNIC-, DPU-, GPU-, accelerator-, and hardwaresoftware-hybrid artificial-intelligence-agent execution architecture comprising one or more agent execution contexts, protected device authority, controlled command interfaces, hardware memory-access restrictions, and effectuation-control mechanisms.

In a representative protected-finality implementation, an agent-generated hardware operation is represented as a Candidate Act, maintained in a Non-Effective State, validated by a PED or CIED, associated with protected validation evidence and scoped non-bearer finality authorization, and verified by a Finality Sink before its governed consequential effect.

The embodiment additionally discloses authority-generation-bound hardware commands, cross-device revocation, device queue fencing, completion watermarks, DMA mapping restrictions, peer-to-peer transfer control, and protected recovery.

A further implementation provides device memory ownership transitions in which prior access is restricted, outstanding commands and memory accesses are resolved, applicable mappings are invalidated, selected memory is sanitized, and the sanitization result is verified before reassignment.

The hardware components may reside within a single processor or system-on-chip, on peripheral devices, within protected firmware, across multiple host systems, or within distributed computing infrastructure.

The disclosure does not require every independently claimed hardware isolation or memorygovernance invention to employ the complete protected-finality sequence unless the relevant enforcement point expressly requires it.

7.3.198.2. PROTECTED INLINE TRANSACTION-FINALITY ENFORCEMENT USING ATOMIC AUTHORIZATION-STATE TRANSITIONS, NATIVE RESOURCE
7.3.198.3. CONTROL, INTERNALLY COMMITTED VALIDATION EVIDENCE, AND NON- PORTABLE EXECUTION ENABLEMENT

7.4. Implementation Profile C-09

Source location: original disclosure pages 461-501. 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. C-09.1 - Technical Field

this implementation profile relates to artificial-intelligence-agent security, database transaction processing, protected authorization, native resource enforcement, transactional state machines, concurrency control, and effectuation-boundary security.

More particularly, the embodiment discloses a computer-implemented method and corresponding system in which a transaction or operation generated directly or indirectly by an artificial-intelligence agent is retained in a non-effective condition while an inline effectuation controller performs protected authority validation, updates protected authorization state, commits an internal validation-state representation, establishes bounded execution enablement, and verifies the actual operation before permitting its consequential effect.

The architecture may operate without generating or transmitting a separately portable authorization token.

The effectuation controller may perform the applicable authorization and finality functions within one protected transaction, execution context, secure resource controller, database engine, protected kernel path, transaction processor, or equivalent protected enforcement arrangement.

The embodiment may be implemented in software, firmware, hardware, or combinations thereof.

7.4.2. C-09.2 - Technical Problem

Artificial-intelligence agents may generate operations through tools, APIs, database clients, software automation, enterprise applications, and delegated processes.

Some operations produce consequential effects by modifying native resource state.

Examples include:

1. Committing a database transaction. 2. Updating an enterprise account. 3. Changing a protected configuration. 4. Writing a persistent storage record. 5. Executing a payment-ledger mutation. 6. Activating a cloud resource. 7. Modifying a protected document. 8. Changing resource permissions. 9. Performing a privileged API operation.

10. Submitting an irreversible command to a controlled subsystem.

Conventional authorization may determine that an identity is permitted to access the underlying resource.

However, resource-level permission does not necessarily establish that the particular operation is authorized for an agent's assigned task, purpose, current policy, or protected resource state.

A further problem arises where authorization and effectuation are implemented as separate software transactions.

For example:

(a) an authorization service approves an operation; (b) the approval is stored in ordinary application state; (c) the operation is subsequently submitted to a resource controller; and

(d) the resource controller performs the operation without verifying that the actual pending operation still corresponds to the approved transaction.

Such separation may permit stale authorization, operation substitution, duplicate execution, or time-of-check/time-of-use inconsistency.

An alternative architecture may issue a portable authorization artifact to an external executor.

However, a separately portable authorization token is not technically necessary when protected validation and actual resource effectuation are controlled by the same transaction processor or by an appropriately integrated enforcement path.

this implementation profile addresses these problems through inline protected finality.

7.4.3. C-09.3 - Central Technical Principle

In the representative embodiment:

The same controlled transaction context that verifies the actual pending operation also determines whether the operation may cross the protected effectuation boundary.

The authorization may be represented internally by:

| x | A protected transaction-state entry. |
| - | ------------------------------------ |
| x | A protected register.                |
| x | A secure transaction latch.          |
| x | A protected permission bit.          |
| x | A sink-local authorization record.   |
| x | A protected write-ahead state transition.                |
| - | -------------------------------------------------------- |
| x | An authenticated internal validation entry.              |
| x | An equivalent non-portable execution-enabling condition. |

No externally transferable finality token is required.

The authorization must nevertheless remain bounded to the actual operation, current protected state, permitted effectuation scope, and applicable freshness conditions.

7.4.4. PART I - PRINCIPAL ARCHITECTURE

7.4.5. C-09.4 - Principal Components

A representative system comprises the following components.

7.4.6. Component A - Artificial-Intelligence-Agent Execution Environment

A process, container, virtual machine, hosted agent runtime, managed tool environment, or other computational context executing one or more artificial-intelligence agents.

7.4.7. Component B - Operation Submission Interface

An interface through which the agent requests a transaction or resource operation.

7.4.8. Component C - Inline Effectuation Controller

A protected controller configured to receive or intercept the operation and control its actual effectuation.

7.4.9. Component D - Candidate Transaction Holder

A staging mechanism configured to maintain the operation in a non-effective condition.

7.4.10. Component E - Actual-Operation Descriptor Generator

A mechanism configured to obtain, measure, or reconstruct material parameters of the operation presented at the effectuation interface.

7.4.11. Component F - Protected Authority-State Store

A protected repository containing applicable task, resource, policy, revocation, quota, and operation-state information.

7.4.12. Component G - Protected Predicate Evaluator

A component configured to evaluate required machine-verifiable authorization conditions.

7.4.13. Component H - Protected Validation-State Store

A protected component configured to commit validation outcomes and operation-binding information.

7.4.14. Component I - Inline Enablement Controller

A mechanism configured to establish the bounded execution-enabling condition required for effectuation.

7.4.15. Component J - Native Resource Controller

A component controlling the database, storage, payment, file, API, or other selected native resource.

7.4.16. Component K - Protected Consumption Controller

A component configured to transition or consume the required operation authorization state.

7.4.17. Component L - Transaction Recovery Controller

A mechanism configured to recover or reconcile incomplete authorization and effectuation operations following interruption or failure.

The components may be implemented within one database engine, resource controller, trusted service, protected transaction processor, secure device, or cooperating protected components.

7.4.18. C-09.5 - Integrated Effectuation Controller

In one implementation, the Inline Effectuation Controller comprises a native database transaction processor.

The controller performs:

1. Candidate operation staging. 2. Actual operation descriptor reconstruction. 3. Protected authority-state lookup. 4. Machine-verifiable predicate evaluation. 5. Protected validation-state commitment. 6. Bounded execution-enabling state establishment. 7. Actual-operation correspondence verification. 8. Protected authorization-state transition. 9. Native resource modification. 10. Transaction completion or rollback.

These functions may execute through one logically protected transaction without requiring separate physical machines, cryptographic receipts delivered to the agent, or external authorization-token exchange.

7.4.19. PART II - OPERATION AND RESOURCE REPRESENTATION

7.4.20. C-09.6 - Candidate Inline Transaction

A Candidate Inline Transaction means a proposed operation presented to a controlled resource interface but not yet permitted to produce its specified consequential effect.

The candidate may comprise:

(a) a database update; (b) a protected file modification; (c) a payment-ledger entry; (d) a cloud resource-state transition; (e) a protected API operation; (f) a storage commit; (g) a native application transaction; or (h) another governed operation.

The candidate remains staged until the required protected conditions are satisfied.

7.4.21. C-09.7 - Candidate Transaction Descriptor

A representative descriptor comprises:

TransactionID = TX-0901

CandidateActID = CA-0901

AgentContextID = AGENT-42

TaskID = TASK-204

OperationClass = UPDATE_RESOURCE

ResourceID = RESOURCE-81

OperationParametersDigest = DIGEST-0901

ExpectedResourceVersion = 17

AuthorityGeneration = 105

RequiredControllerID = CTRL-09

CandidateStatus = STAGED

The identifiers are illustrative.

The implementation defines a deterministic encoding of material operation parameters.

A descriptor may include operation-specific fields such as account identity, transaction amount, row identity, destination, command arguments, policy generation, or resource-state precondition.

7.4.22. C-09.8 - Actual-Operation Reconstruction

The Inline Effectuation Controller obtains the operation that would actually be performed by the native resource mechanism.

For a database update, the controller may reconstruct:

1. The effective database. 2. The target table or resource class. 3. The selected row or object. 4. The proposed modification. 5. The requesting task context. 6. The current resource version. 7. The current authority generation. 8. The actual transaction identity.

The controller compares the actual operation with the permitted scope.

The operation description is not accepted solely because the requesting agent supplies a matching authorization label.

7.4.23. C-09.9 - Non-Effective Staging

The Candidate Inline Transaction is retained without producing the governed effect.

Possible implementations include:

| x | An uncommitted database transaction. |
| - | ------------------------------------ |
| x | A protected transaction object.      |
| x | A pending native-resource mutation.  |
| x | A disabled resource operation.       |
| x | A protected write buffer.            |
| x | A withheld API dispatch.         |
| - | -------------------------------- |
| x | A secure pending-command record. |

The implementation must distinguish a staged resource change from a change already visible or irreversible outside the controlled transaction.

A database's uncommitted state is a suitable non-effective representation for durable commit finality only where the transaction isolation and visibility rules prevent the claimed externally effective consequence before commit.

7.4.24. PART III - PROTECTED AUTHORITY STATE

7.4.25. C-09.10 - Protected Authority-State Record

A representative authority record comprises:

AuthorityRecordID = AUTH-0901

AgentContextID = AGENT-42

TaskID = TASK-204

PermittedResource = RESOURCE-81

PermittedOperation = UPDATE_RESOURCE

PolicyGeneration = 105

RevocationGeneration = 27

PermissionScope = SCOPE-A

QuotaRemaining = 3

AuthorityStatus = ACTIVE

The protected authority store is not directly writable by the requesting agent.

The protection may rely upon operating-system isolation, database ownership, privileged transaction procedures, cryptographic integrity, hardware-backed state, or combinations thereof.

7.4.26. C-09.11 - Native Resource Permission

The controller may obtain ordinary resource permissions supplied by the native resource system.

For example:

NativePermission = WRITE

AgentTaskPermission = UPDATE_CONFIG

The controller requires both ordinary permission and operation-specific protected authorization when the selected policy so specifies.

Ordinary resource permission remains an input to the authorization decision rather than a substitute for it.

7.4.27. C-09.12 - Protected Predicate Evaluation

A representative predicate set includes:

P1 - Authenticated execution context.

P2 - Permitted task.

P3 - Authorized operation class.

P4 - Authorized target resource.

P5 - Valid current policy generation.

P6 - Valid revocation state.

P7 - Required resource-state precondition.

P8 - Permitted operation arguments.

P9 - Available protected quota.

P10 - Valid freshness constraint.

P11 - Valid effectuation controller identity.

P12 - Required native resource permission.

The protected authorization result is determined from the predicates required for the selected operation.

7.4.28. PART IV - INLINE VALIDATION-STATE COMMITMENT

7.4.29. C-09.13 - Protected Validation-State Representation

A Protected Validation-State Representation means a machine-verifiable record or state transition establishing the validation result and its association with the pending operation.

A representative record comprises:

ValidationStateID = VS-0901

TransactionID = TX-0901

CandidateActID = CA-0901

OperationDescriptorDigest = DIGEST-0901

ValidationOutcome = APPROVED

AuthorityGeneration = 105

ProtectedStateVersion = 302

ControllerID = CTRL-09

EnablementStatus = ELIGIBLE

The record may remain entirely within the protected transaction engine.

7.4.30. C-09.14 - Internal Commitment Without External Receipt

In one implementation, the validation-state representation is committed internally through a protected transaction-state mechanism.

The system may use:

1. A sealed internal record. 2. A protected register transition. 3. A hash-linked state entry. 4. A cryptographic accumulator update. 5. A protected write-ahead log record. 6. A monotonic state transition. 7. A transactional authorization row. 8. An equivalent protected state commitment.

The agent need not receive the validation record.

The Finality Sink need not receive a separately transmitted external receipt if the required state is already available within the protected transaction.

Absence of an external receipt does not remove the requirement to commit the protected validation state.

7.4.31. C-09.15 - Commitment Ordering

A representative logical sequence comprises:

VALIDATE ACTUAL OPERATION

↓

ESTABLISH PROTECTED VALIDATION STATE

↓

COMMIT VALIDATION STATE BEFORE OR ATOMICALLY WITH ENABLEMENT

↓

ESTABLISH BOUNDED INLINE ENABLEMENT

↓

VERIFY CURRENT PENDING OPERATION

↓

PERMIT EFFECTUATION

In a transactionally integrated implementation, the validation record and resource mutation may become durable through one atomic commit.

Before that commit, neither is externally committed.

The controller's internal protected state machine ensures that resource modification cannot commit unless the corresponding validation-state conditions are included in the successful transaction.

7.4.32. PART V - NON-PORTABLE INLINE ENABLEMENT

7.4.33. C-09.16 - Bounded Execution-Enabling Condition

A Bounded Execution-Enabling Condition means a protected state or control condition that permits a specified operation only within the applicable protected effectuation scope.

A representative condition comprises:

EnablementID = EN-0901

TransactionID = TX-0901

DescriptorDigest = DIGEST-0901

ControllerID = CTRL-09

PermittedResource = RESOURCE-81

AuthorityGeneration = 105

ProtectedStateVersion = 302

UsageStatus = UNUSED

The condition is maintained internally by the effectuation controller or another appropriately protected component.

7.4.34. C-09.17 - Non-Portable Authority

The bounded enablement does not need to be represented by a separately transferable bearer or non-bearer authorization token.

For example, the controller may associate authorization with:

(a) a protected transaction identifier; (b) a private state-machine entry; (c) a transaction-local latch; (d) a protected register; (e) an internal permission state; (f) a protected operation slot; or (g) a sink-local authorization record.

The requesting agent cannot independently apply that condition to a different operation or resource.

An ordinary transaction identifier communicated to the agent does not itself grant execution authority.

7.4.35. C-09.18 - Transaction-Local Enablement

In one implementation, the bounded enablement exists only within the protected transaction executing the actual operation.

The enablement is invalidated when:

1. The transaction commits. 2. The transaction aborts. 3. The operation changes materially. 4. Required authority is revoked. 5. A protected state precondition becomes invalid. 6. A required freshness condition expires. 7. The controller encounters an unrecoverable validation failure.

A subsequent operation requires a corresponding permitted authorization transition.

7.4.36. PART VI - ATOMIC CONSUMPTION AND EFFECTUATION

7.4.37. C-09.19 - Atomic Authorization Consumption

A protected authorization state may have the following logical states:

AVAILABLE

RESERVED

CONSUMED

DENIED

REVOKED

EXPIRED

The effectuation controller prevents unauthorized reuse of authorization already consumed by another operation.

In a native transactional implementation, the authorization-state transition and resource mutation can be included in the same atomic transaction.

7.4.38. C-09.20 - Database Atomicity

Consider a protected database containing:

AuthorityState

ValidationState

ResourceState

The controller may use one transaction to:

1. Lock or otherwise protect the required authority-state version. 2. Reconstruct the actual proposed resource mutation. 3. Evaluate current authorization. 4. Insert the protected validation-state entry. 5. Update or consume the authorization state. 6. Perform the resource mutation. 7. Commit all required changes atomically.

If a required operation fails, the transaction rolls back.

No durable resource mutation becomes committed without the required protected validation state.

7.4.39. C-09.21 - Native Resource Transaction Boundary

In one implementation:

Protected authorization-state commitment and native resource modification belong to the same atomic transactional boundary.

The controller may use serializable execution, transactional row locks, compare-and-update semantics, or another native concurrency-control mechanism.

The implementation must ensure that an authorization consumed for one operation cannot be concurrently consumed for an unauthorized duplicate operation.

7.4.40. C-09.22 - Atomicity Limitation

Atomicity across independent external services is not assumed.

For example, a database transaction cannot ordinarily guarantee atomic commitment of both:

(a) a local authorization-state update; and (b) an independent remote payment or HTTP request

unless the external system participates in an appropriate common transaction protocol or the architecture controls a suitable equivalent effectuation boundary.

Where such atomicity is unavailable, the embodiment may use an operation registry, reservation state, durable outbox, external idempotency control, or reconciliation procedure.

Those mechanisms provide defined delivery and recovery semantics but must not be described as universal exactly-once external effectuation.

7.4.41. PART VII - PROTECTED CACHED AUTHORIZATION

7.4.42. C-09.23 - Cached Authorization State

A previously evaluated authorization result may be stored in protected cache state.

A representative cache record comprises:

CacheEntryID = CACHE-0901

AgentContextID = AGENT-42

AuthorizedOperationClass = UPDATE_RESOURCE

PermittedResourceScope = SCOPE-A

PolicyGeneration = 105

RevocationGeneration = 27

ExpiryCondition = TIME-BOUND

CacheStatus = ACTIVE

The cached record may accelerate repeated predicate evaluation.

7.4.43. C-09.24 - Cache as Intermediate Authority Input

A cached authorization result is not unconditional authority to perform arbitrary operations.

Before effectuation, the Inline Effectuation Controller verifies:

(a) actual operation binding; (b) permitted resource scope; (c) current policy state; (d) current revocation state; (e) applicable freshness; (f) protected-state validity; and

(g) required usage limits.

If a cached result is insufficient, stale, or inconsistent with the pending operation, the controller performs fresh validation or denies the operation.

7.4.44. C-09.25 - Cache Generation Invalidation

A change in protected policy or revocation generation may invalidate affected cache entries.

The implementation may use:

1. Generation comparison. 2. Explicit cache revocation. 3. Protected expiry. 4. Protected invalidation tables. 5. Current authority-state lookup. 6. A combination of these mechanisms.

The cache is not permitted to override a current mandatory protected restriction merely because the earlier cached result remains cryptographically valid.

7.4.45. PART VIII - TRANSACTION-LOCAL DENIAL EVIDENCE

7.4.46. C-09.26 - Protected Denial State

When a required validation condition fails, the controller may create a protected denial-state representation.

A representative record comprises:

DenialRecordID = DENY-0901

CandidateActID = CA-0901

OperationDescriptorDigest = DIGEST-0901

AuthorityGeneration = 105

DenialReasonClass = RESOURCE_SCOPE_MISMATCH

DenialGeneration = 481

RetryPolicy = NEW_VALIDATION_REQUIRED

DenialStatus = ACTIVE

The record may be maintained in protected transactional storage.

7.4.47. C-09.27 - Denial Commitment

A protected denial record may be committed when:

1. An authorization predicate fails. 2. The actual operation differs from the authorized descriptor. 3. The required authority has been revoked. 4. The operation is stale. 5. Required protected evidence is invalid. 6. A replay attempt is detected. 7. A required resource-state precondition fails. 8. A prohibited rollback is detected.

The denial record may reference the applicable operation identity, generation, and restriction.

7.4.48. C-09.28 - Denial and Retry Control

A denied Candidate Act may not automatically regain authorization by repeating the same operation identifier.

In one implementation, a protected operation registry records a terminal denial state.

A subsequent attempt must use a new authorized validation transition satisfying current policy.

The system must distinguish:

(a) retrying the same denied operation without new authorization; and (b) submitting a legitimate new Candidate Act after required conditions have changed.

The denial mechanism prevents unauthorized reuse without necessarily prohibiting every future independently authorized operation.

7.4.49. C-09.29 - Durable Denial Following Transaction Rollback

A failed business transaction may require its resource changes to roll back while retaining durable evidence of the denial.

In one implementation, the controller:

1. Detects validation failure.

2. Aborts the resource transaction. 3. Creates a protected denial record in a separate authorized protected-state transaction. 4. Binds the denial record to the original Candidate Act identity and relevant generation. 5. Prevents subsequent execution of the denied Candidate Act without fresh authorization.

The protected operation registry uses a unique Candidate Act identity or equivalent mechanism to prevent conflicting concurrent retries during this process.

This ordering distinguishes rollback of uncommitted business effects from durable recording of the authorization failure.

7.4.50. PART IX - COMPLETE INLINE EXECUTION WORKFLOW

7.4.51. C-09.30 - Principal 25-Step Workflow

7.4.52. Step C9-01 - Agent operation proposal

The artificial-intelligence agent generates a proposed native resource operation.

7.4.53. Step C9-02 - Controlled interface reception

The operation reaches the Inline Effectuation Controller.

7.4.54. Step C9-03 - Candidate Act identification

A unique Candidate Act identity is established.

7.4.55. Step C9-04 - Non-effective staging

The operation is retained without producing the governed consequence.

7.4.56. Step C9-05 - Protected transaction initiation

The controller establishes the applicable protected transactional context.

7.4.57. Step C9-06 - Actual-operation reconstruction

The controller obtains the actual resource, operation class, and material parameters.

7.4.58. Step C9-07 - Descriptor canonicalization

The operation is represented using a deterministic descriptor.

7.4.59. Step C9-08 - Authenticated context association

The agent, task, and relevant execution identity are associated with the operation.

7.4.60. Step C9-09 - Native permission retrieval

The controller obtains relevant ordinary resource permissions.

7.4.61. Step C9-10 - Protected authority-state acquisition

The controller obtains current task, policy, revocation, and usage state.

7.4.62. Step C9-11 - Resource-state protection

The required resource-state version is locked or protected through the selected concurrency mechanism.

7.4.63. Step C9-12 - Predicate evaluation

The controller evaluates mandatory authority predicates.

7.4.64. Step C9-13 - Protected-state operation

The controller performs the required reservation, version, quota, or other protected-state operation.

7.4.65. Step C9-14 - Validation-state construction

The controller creates the internal machine-verifiable validation-state representation.

7.4.66. Step C9-15 - Validation-state commitment

The protected validation state is committed before or atomically with the permitted effectuation transition.

7.4.67. Step C9-16 - Inline bounded enablement

The controller establishes the non-portable execution-enabling condition.

7.4.68. Step C9-17 - Current-operation re-acquisition

Where required, the controller obtains the actual pending operation again.

7.4.69. Step C9-18 - Operation-binding verification

The controller verifies correspondence between the actual pending operation and validated descriptor.

7.4.70. Step C9-19 - Protected-state verification

Current protected authority and usage conditions are checked.

7.4.71. Step C9-20 - Enablement verification

The bounded enablement is verified against the intended controller, scope, and applicable freshness.

7.4.72. Step C9-21 - Atomic authorization consumption

The protected authorization state is transitioned according to the selected usage policy.

7.4.73. Step C9-22 - Native resource mutation

The corresponding native resource operation is performed.

7.4.74. Step C9-23 - Atomic commit

The required authorization-state and resource-state changes are committed under the selected transactional semantics.

7.4.75. Step C9-24 - Outcome recording

The controller records completion or failure state.

7.4.76. Step C9-25 - Enablement invalidation

The bounded transaction-local enablement is consumed or disabled against unauthorized subsequent use.

7.4.77. PART X - REFERENCE IMPLEMENTATION ALGORITHMS

C-09.31 - Algorithm A: Protected Inline Native-Resource Transaction

function ExecuteInlineFinality(candidate):

context = AuthenticateRequestOrigin(candidate)

if context is invalid:

return DENIED

begin serializable_transaction

if not ReserveUniqueCandidateIdentity(candidate.id):

rollback return DENIED_OR_EXISTING_STATUS

actual = ReconstructNativeOperation(candidate)

if actual is invalid:

rollback CommitProtectedDenialSeparately(candidate) return DENIED

descriptor = Canonicalize(actual, context)

authority = ReadAndLockProtectedAuthority(

context, descriptor )

resource = ReadAndLockTargetResource(

descriptor.resource_id )

if not VerifyNativeResourcePermission(

context, resource, actual ):

rollback CommitProtectedDenialSeparately(candidate) return DENIED if not EvaluateRequiredAuthorityPredicates(

descriptor, authority, resource ):

rollback CommitProtectedDenialSeparately(candidate) return DENIED validation = InsertProtectedValidationState({

candidate_id: candidate.id, descriptor_digest: HashCanonical(descriptor), authority_generation: authority.generation, resource_version: resource.version, validation_result: APPROVED })

if validation is invalid:

rollback return DENIED enablement = EstablishTransactionLocalEnablement(

candidate.id, validation, descriptor )

if not VerifyActualPendingOperation(

actual,

descriptor, enablement ):

rollback CommitProtectedDenialSeparately(candidate) return DENIED

if not ConsumeAuthorizationState(

authority, enablement ):

rollback return DENIED

ApplyNativeResourceMutation(resource, actual)

MarkCandidateCompleted(candidate.id)

commit serializable_transaction

return COMMITTED

In a concrete implementation, candidate reservation must be durable or otherwise coordinated with denial recording so that a failed transaction cannot race with an unauthorized duplicate submission.

The selected resource engine must actually provide the required isolation and atomic-commit guarantees.

C-09.32 - Algorithm B: Non-Portable Inline Enablement

function EstablishTransactionLocalEnablement(

candidate_id, validation, descriptor ):

if validation.result != APPROVED:

return DENIED if not IsCurrentProtectedTransaction():

return DENIED

enablement = ProtectedTransactionState.create({

candidate_id: candidate_id, descriptor_digest: HashCanonical(descriptor), validation_state_id: validation.id, controller_id: CurrentControllerID(),

resource_scope: descriptor.resource_scope, authority_generation: validation.authority_generation, usage_state: UNUSED })

return enablement

The enablement need not be exported as a token.

It remains meaningful only within the applicable protected transaction or controller-local authorization state.

C-09.33 - Algorithm C: Atomic Authorization Consumption

function ConsumeAuthorizationState(authority, enablement):

if enablement.usage_state != UNUSED:

return DENIED

if enablement.controller_id != CurrentControllerID():

return DENIED

if authority.generation != enablement.authority_generation:

return DENIED

if not VerifyCurrentRevocationState(authority):

return DENIED

if not VerifyProtectedValidationBinding(enablement):

return DENIED

if not TransactionalCompareAndUpdate(

enablement.usage_state, UNUSED, CONSUMED ):

return DENIED

return CONSUMED

The usage transition participates in the same protected transactional context as the governed resource effect where native atomicity is claimed.

C-09.34 - Algorithm D: Protected Cache Revalidation

function ValidateCachedAuthorization(

cache_entry, actual_operation ):

if cache_entry is unavailable:

return CACHE_MISS

if not VerifyProtectedCacheIntegrity(cache_entry):

return CACHE_INVALID if not MatchOperationScope(

actual_operation, cache_entry ):

return CACHE_INVALID

current = ReadCurrentProtectedAuthorityState(

actual_operation )

if current.policy_generation != cache_entry.policy_generation:

return CACHE_INVALID if current.revocation_generation != cache_entry.revocation_generation:

return CACHE_INVALID if not VerifyFreshness(cache_entry):

return CACHE_INVALID

if not VerifyCurrentUsageConditions(

current, actual_operation ):

return CACHE_INVALID

return VALID_INTERMEDIATE_AUTHORIZATION

The cached result supplies an intermediate input.

Actual effectuation still requires the protected inline transaction and its current-operation verification.

7.4.78. C-09.35 - Algorithm E: Transaction-Local Denial

function CommitProtectedDenialSeparately(candidate):

begin protected_denial_transaction

existing = ProtectedOperationRegistry.lookup(

candidate.id )

if existing.status == COMPLETED:

rollback return ALREADY_EFFECTUATED if existing.status == DENIED:

rollback return ALREADY_DENIED

if not VerifyCandidateStillDeniable(existing):

rollback return RECONCILIATION_REQUIRED

InsertOrUpdateProtectedDenial({

candidate_id: candidate.id, descriptor_digest: candidate.descriptor_digest, authority_generation: CurrentAuthorityGeneration(), denial_status: DENIED, retry_policy: NEW_VALIDATION_REQUIRED })

commit protected_denial_transaction

return DENIAL_COMMITTED

The implementation must use appropriate candidate-state serialization to prevent the denial transaction from conflicting with another transaction that has already committed an authorized effect.

7.4.79. C-09.36 - Algorithm F: Transaction Recovery

function RecoverInlineFinalityState():

RecoverNativeTransactionalStorage()

operations = LoadIncompleteCandidateOperations()

for each operation in operations:

if operation.status == COMPLETED:

continue

if operation.status == DENIED:

PreserveDenialRestrictions(operation) continue

if operation.status == STAGED:

RequireFreshProtectedValidation(operation) continue

if operation.status == INDETERMINATE:

ReconcileAgainstAuthoritativeResourceState(

operation )

VerifyProtectedAuthorityGenerations()

VerifyAuthorizationConsumptionState()

return EvaluateRecoveryStatus()

A native database recovery mechanism may provide authoritative evidence of transaction commit or rollback.

For external operations outside its atomic transactional boundary, additional reconciliation mechanisms may be necessary.

7.4.80. PART XI - WORKED TECHNICAL EXAMPLES

C-09.37 - Example A: Atomic Enterprise Database Update

The following is a hypothetical implementation example.

An AI agent is authorized to modify a designated configuration record.

The agent proposes an update.

The resource controller receives the request.

The controller opens a protected native database transaction.

It identifies the actual target row.

It verifies ordinary database permission and task-specific authorization.

It checks the current policy generation and expected row version.

It creates an internal protected validation-state entry.

A transaction-local enablement is established.

The controller verifies the actual update parameters.

The authorization state is consumed.

The configuration record is updated.

The transaction commits the authorization-state and resource-state changes atomically.

The same authorization cannot be used for another modification without a fresh permitted transition.

C-09.38 - Example B: Concurrent Duplicate Operation

Two agent workers attempt the same protected database modification using the same Candidate Act identity.

Worker A acquires the required protected operation-state lock.

Worker B attempts a conflicting operation.

Worker A validates and commits the authorized modification.

The protected operation state transitions to COMPLETED.

Worker B observes the committed state or encounters a transaction conflict requiring retry.

Worker B cannot commit another resource mutation under the already consumed Candidate Act authority.

This implementation may use a unique Candidate Act constraint, transactional compare-andupdate, serializable isolation, or equivalent supported mechanism.

C-09.39 - Example C: Cached Authorization After Revocation

An agent previously received authorization to update a permitted enterprise resource.

The corresponding result is stored in protected cache state.

A security controller subsequently revokes the relevant authority.

The protected revocation generation advances.

The agent proposes another operation.

The Inline Effectuation Controller retrieves the cached authorization.

The controller compares the cached generation with current protected authority state.

The cache entry is invalid.

The proposed operation is withheld.

The earlier cached approval does not independently authorize the new effect.

C-09.40 - Example D: Atomic Payment-Ledger Mutation

An AI agent proposes a payment-related ledger update.

The transaction processor stages the operation.

The processor validates the intended payer, beneficiary, amount, transaction scope, and applicable protected authority.

It creates an internal protected validation-state entry.

The processor establishes bounded transaction-local enablement.

It verifies that the actual ledger mutation corresponds to the validated operation.

It consumes the required authorization and commits the ledger-state transition in one native transaction.

Where actual interbank settlement occurs later through a separate external system, the embodiment does not enforcement point that local ledger atomicity automatically provides atomicity of remote settlement.

A separate finality or reconciliation mechanism may govern that downstream effect.

7.4.81. C-09.41 - Example E: Protected File Commit

An agent prepares a modified configuration file.

The modification is staged in a protected temporary representation.

The file controller obtains the actual target resource and content digest.

The protected authorization predicates are evaluated.

A validation-state record is committed.

The controller establishes bounded enablement.

The actual pending file modification is verified.

The resource modification is committed through an applicable protected filesystem or transactional storage mechanism.

If the file system lacks an atomic multi-object transaction covering the relevant authorization state and file content, the implementation must use a suitable journaled recovery procedure or limit the claimed atomic guarantee accordingly.

C-09.42 - Example F: Transaction-Local Denial After Operation Substitution

An agent requests modification of Resource A.

The protected validation procedure approves the permitted operation for Resource A.

Before effectuation, the actual pending operation is found to target Resource B.

The controller detects a descriptor mismatch.

The resource transaction is aborted.

A protected denial-state record is committed for the invalid Candidate Act.

A later retry using the same stale Candidate Act identity is refused.

A new independently authorized Candidate Act is required before any permitted modification of Resource B.

7.4.82. PART XII - FAILURE AND ADVERSARIAL SCENARIOS

7.4.83. C-09.43 - Representative Failure Conditions

7.4.84. F1 - Missing Protected Validation State

The effectuation controller cannot establish the required protected validation representation.

Effectuation is withheld.

7.4.85. F2 - Invalid Operation Binding

The actual resource operation differs from the validated descriptor.

Effectuation is denied.

7.4.86. F3 - Stale Policy Generation

The authorization references an unacceptable policy generation.

The current operation is revalidated or denied.

7.4.87. F4 - Revoked Authority

The required protected authority is revoked before effectuation.

The controller withholds the operation.

7.4.88. F5 - Expired Enablement

The transaction-local enablement no longer satisfies the applicable freshness condition.

Effectuation is denied.

7.4.89. F6 - Wrong Controller

An enablement associated with one controller is presented to another controller.

The protected controller binding prevents unauthorized use.

7.4.90. F7 - Wrong Resource

The proposed resource identity differs from the authorized resource.

The resource operation is denied.

7.4.91. F8 - Concurrent Consumption

Two transactions attempt to consume the same bounded authorization.

The required transactional isolation or atomic state transition prevents unauthorized duplicate consumption.

7.4.92. F9 - Native Resource Permission Failure

The ordinary resource permission check fails.

Protected operation-specific authorization does not override that required native restriction.

7.4.93. F10 - Cached Authorization Stale

A cached result no longer matches current policy or revocation state.

The cached result is rejected.

7.4.94. F11 - Cache Scope Expansion

A cached permission for a limited resource is applied to a broader operation.

Current-operation scope verification rejects the expansion.

7.4.95. F12 - Transaction Crash Before Commit

A transaction fails before the required commit.

The transactional storage mechanism rolls back uncommitted resource changes and corresponding authorization-state changes.

7.4.96. F13 - Crash After Commit

A transaction commits but the agent does not receive confirmation.

The recovery mechanism consults authoritative committed operation state rather than blindly repeating the effect.

7.4.97. F14 - Validation-State Tampering

The agent attempts to modify protected validation state.

The protected-state boundary prevents unauthorized modification according to the selected threat model.

7.4.98. F15 - Denial-State Rollback

An attacker attempts to restore an earlier state lacking a committed denial or revocation.

The applicable protected continuity or transactional recovery mechanism prevents prohibited stale authority from becoming effective.

7.4.99. F16 - Candidate Identity Reuse

An agent reuses an earlier Candidate Act identifier.

The protected operation registry detects conflicting or terminal state.

7.4.100. F17 - Resource Version Conflict

The resource changes after a prior read.

The required version or isolation predicate prevents commitment based on stale resource assumptions.

7.4.101. F18 - Transaction Deadlock

The native resource engine detects a deadlock.

The transaction aborts according to its concurrency protocol.

A retry must satisfy the applicable current authorization conditions.

7.4.102. F19 - Protected-State Store Unavailable

The required protected authority or validation-state store is unavailable.

The governed operation remains non-effective.

7.4.103. F20 - Authorization Failure Followed by Retry

The controller commits protected denial state.

A subsequent retry cannot bypass the denial by reusing the invalid Candidate Act.

7.4.104. F21 - Uncontrolled Native Resource Path

An agent possesses an alternative route for modifying the same governed resource without the Inline Effectuation Controller.

The implementation must restrict or mediate that path to establish non-bypassable finality.

7.4.105. F22 - Remote Effect Outside Atomic Boundary

A local transaction triggers a remote operation that cannot participate in the native commit.

The system distinguishes locally atomic state changes from independently executed remote consequences.

7.4.106. F23 - Protected Counter or Quota Exhaustion

A required quota is exhausted.

The authorization predicate fails.

7.4.107. F24 - Resource Snapshot Restoration

An earlier resource snapshot is restored.

The system applies the necessary protected generation and state-continuity checks to prevent prohibited authority reuse.

7.4.108. PART XIII - IMPLEMENTATION VARIATIONS

7.4.109. C-09.44 - Native Database Implementation

The protected controller resides in a database engine, trusted stored procedure, transaction service, or equivalent resource mechanism.

Authorization-state changes and resource mutations may share one native transaction.

7.4.110. C-09.45 - Payment-Switch Implementation

A payment switch or transaction processor controls a defined payment authorization or ledger-effectuation boundary.

Protected authorization and bounded enablement are implemented within the applicable transaction-processing context.

External settlement boundaries remain subject to their own actual control mechanisms.

| C-09.46 - Filesystem Implementation A protected file-operation controller stages modifications and verifies them before protected commitment. The atomicity guarantee is limited to operations and state covered by the selected filesystem or transaction mechanism.                                                                                                                        |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-09.47 - Cloud Resource-Controller Implementation An agent requests a cloud resource change. A protected native resource controller validates the operation, maintains internal authorization state, and controls the corresponding resource transition. Where the actual change occurs through another independently operated system, the claimed boundary must be identified accordingly. |
| C-09.48 - Kernel-Mediated Implementation An applicable kernel enforcement component controls a selected resource operation. The kernel or associated protected resource controller establishes the required inline authority conditions. The security model depends on the protection provided by the selected operating system and enforcement mechanism.                                   |

7.4.111. C-09.49 - TEE-Assisted Implementation

A TEE maintains required protected authority or validation state.

A controlled effectuation interface uses bounded authorization established by the TEE.

The implementation must preserve the required relationship between protected validation and actual resource effectuation.

| C-09.50 - Hardware Transaction-Controller Implementation A protected controller implements validation-state transition, bounded enablement, and command release through hardware or firmware state machines. A protected register or latch may represent the non-portable enablement condition. The selected device must provide the claimed ordering and state properties.                                                                                          |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-09.51 - Single-Process Protected Transaction One appropriately protected process may implement the complete finality sequence. No separately portable capability, physical PED server, or external receipt exchange is required. The required logical operations remain identifiable.                                                                                                                                                                              |
| C-09.52 - Distributed Transactional Implementation Multiple protected components may coordinate a common transactional authorization and effectuation procedure. An actual common atomic commit requires a suitable distributed transaction protocol or equivalent mechanism implemented by the participating resource controllers. A conventional RPC authorization call followed by an unrelated external operation does not by itself provide the same atomicity. |

7.4.112. PART XIV - REPRESENTATIVE DATA STRUCTURES

7.4.113. C-09.53 - CandidateInlineTransactionRecord

Fields may include:

1. CandidateActID. 2. TransactionID.

3. AgentContextID. 4. TaskID. 5. OperationClass. 6. ResourceID. 7. OperationDescriptorDigest. 8. AuthorityGeneration. 9. CandidateStatus. 10. TransactionReference.

7.4.114. C-09.54 - ProtectedAuthorityRecord

Fields may include:

1. AuthorityRecordID. 2. AuthorizedAgentOrTask. 3. PermittedOperationClasses. 4. PermittedResources. 5. PolicyGeneration. 6. RevocationGeneration. 7. ProtectedQuotaState. 8. AuthorityStatus. 9. StateVersion.

7.4.115. C-09.55 - InlineValidationStateRecord

Fields may include:

1. ValidationStateID. 2. CandidateActID. 3. TransactionID. 4. DescriptorDigest. 5. ValidationOutcome. 6. AuthorityGeneration. 7. ProtectedStateVersion. 8. ControllerID. 9. CommitmentStatus.

7.4.116. C-09.56 - InlineEnablementRecord

Fields may include:

1. EnablementID. 2. CandidateActID. 3. TransactionID.

4. 5. 6. 7. 8. 9.

DescriptorDigest. ControllerID. PermittedEffectuationScope. AuthorityGeneration. FreshnessReference. UsageState.

7.4.117. C-09.57 - NativeResourceStateRecord

Fields may include:

1. ResourceID. 2. ResourceClass. 3. CurrentResourceVersion. 4. CurrentProtectedOperationState. 5. NativePermissionReference. 6. LastCommittedTransactionID. 7. LastAppliedAuthorityGeneration.

7.4.118. C-09.58 - ProtectedCacheRecord

Fields may include:

1. CacheEntryID. 2. AgentContextID. 3. AuthorizedOperationClass. 4. PermittedResourceScope. 5. PolicyGeneration. 6. RevocationGeneration. 7. ExpiryCondition. 8. CacheStatus.

7.4.119. C-09.59 - ProtectedDenialRecord

Fields may include:

1. 2. 3. 4. 5. 6. 7. 8.

DenialRecordID. CandidateActID. DescriptorDigest. DenialReasonClass. AuthorityGeneration. DenialGeneration. RetryPolicy. DenialStatus.

7.4.120. C-09.60 - TransactionRecoveryRecord

Fields may include:

1. TransactionID. 2. CandidateActID. 3. LastProtectedStateTransition. 4. ValidationCommitmentReference. 5. AuthorizationConsumptionState. 6. NativeResourceCommitStatus. 7. ExternalOperationReference. 8. RecoveryStatus.

These records may be realized through database rows, protected memory, write-ahead records, secure registers, protected transaction logs, or authenticated storage.

7.4.121. PART XV - PROPOSED VERIFICATION TESTS

7.4.122. C-09.61 - Engineering Test Matrix

The following tests are proposed rather than completed experiments.

7.4.123. Test Condition

T1 Authorized native resource transaction T2 Unauthorized operation T3 Missing validation-state commitment T4 Missing bounded enablement T5 Altered actual operation T6 Concurrent duplicate operation T7 Replayed consumed authorization T8 Native resource permission missing T9 Stale policy generation T10 Cached authorization after revocation T11 Cache used outside permitted scope T12 Transaction crash before commit T13 Crash after successful commit T14 Resource-version conflict T15 Denial-state commitment T16 Candidate identifier reuse T17 Protected-state rollback attempt T18 Controller identity mismatch T19 Protected authority-store failure

7.4.124. Expected result

Commit permitted Denied Effect withheld Effect withheld Mismatch rejected No unauthorized duplicate commit Rejected Commit denied Revalidated or denied Cache invalidated Rejected Atomic rollback Completion recovered Conflicting commit prevented Invalid operation remains blocked Conflicting reuse rejected Required continuity enforced Enablement rejected No permissive fallback

T20 Protected quota exhaustion T21 External operation outside native

transaction T22 Resource transaction deadlock T23 Invalid internally committed evidence T24 No external receipt transmitted

Operation denied Boundary limitation recognized Required rollback or retry procedure Effect denied Internal required commitment still enforced

The test harness must establish the actual native transaction boundaries and protected-state guarantees supported by the selected resource engine.

7.4.125. PART XVI - Enforcement-Point Mapping and Technical Correspondence

7.4.126. C-09.62 - Independent enforcement point(s) 9

this implementation profile supports the proposed method through:

(a) the Operation Submission Interface; (b) Candidate Inline Transaction staging; (c) actual-operation reconstruction; (d) protected predicate evaluation; (e) protected authority-state operations; (f) internal validation-state commitment; (g) non-portable transaction-local enablement; (h) current-operation, scope, state, freshness, and controller verification; (i) controlled native effectuation; and (j) denial or withholding upon failure.

The embodiment does not require an independently portable capability or externally disclosed validation receipt.

7.4.127. C-09.63 - Dependent enforcement point(s) 10

Atomic commit and consumption are addressed through:

x Protected authorization-state transitions.

| x | Native transactional resource mutation. |
| - | --------------------------------------- |
| x | Transaction isolation.                  |
| x | Concurrent consumption control.         |
| x | Rollback and recovery.                  |
| x | Prevention of duplicate effectuation.   |

A enforcement point requiring atomicity must be limited to an actually atomic enforcement boundary.

7.4.128. C-09.64 - Dependent enforcement point(s) 11

Native resource enforcement is addressed through:

| x | Database transaction processors.       |
| - | -------------------------------------- |
| x | Storage commit controllers.            |
| x | Payment-ledger controllers.            |
| x | File-operation controllers.            |
| x | Cloud resource controllers.            |
| x | Native permission checks.              |
| x | Protected operation-specific finality. |

The examples distinguish native resource permission from independent task-specific authorization.

7.4.129. C-09.65 - Dependent enforcement point(s) 12

Evidence commitment without external receipt release is addressed through:

| x | Internal protected validation records. |
| - | -------------------------------------- |
| x | Protected register transitions.        |
| x | Hash-linked state.                     |
| x | Write-ahead commitments.               |
| x | Protected transactional entries.       |
| x | Transaction-local validation state.    |

The absence of externally delivered evidence does not bypass the required internal commitment.

7.4.130. C-09.66 - Dependent enforcement point(s) 13

Protected cached authorization is addressed through:

| x | Protected cache entries.        |
| - | ------------------------------- |
| x | Operation-specific cache scope. |
| x | Policy-generation checks.       |
| x | Revocation-generation checks.            |
| - | ---------------------------------------- |
| x | Freshness validation.                    |
| x | Current resource and usage verification. |

Cached authorization remains an intermediate input.

7.4.131. C-09.67 - Dependent enforcement point(s) 14

Transaction-local denial evidence is addressed through:

| x | Protected denial records.                               |
| - | ------------------------------------------------------- |
| x | Candidate-specific terminal states.                     |
| x | Protected retry policy.                                 |
| x | Revocation and mismatch records.                        |
| x | Durable denial following business transaction rollback. |
| x | Prevention of stale Candidate Act reuse.                |

The implementation supports legitimate new authorization while preventing unauthorized replay of invalid prior state.

7.4.132. PART XVII - IMPLEMENTATION REQUIREMENTS

7.4.133. C-09.68 - implementer Implementation Checklist

A person having ordinary skill in the art implementing the embodiment identifies:

1. The native resource controller. 2. The actual effectuation boundary. 3. The trusted computing base. 4. The agent-origin authentication mechanism. 5. The Candidate Act identifier. 6. The actual-operation descriptor format. 7. The staging mechanism. 8. The protected authority-state store. 9. The required predicates. 10. The native resource-permission interface. 11. The current resource-state preconditions. 12. The protected validation-state representation. 13. The commitment ordering. 14. The non-portable enablement mechanism. 15. The current-operation verification procedure. 16. The protected consumption transition. 17. The native resource mutation operation. 18. The transactional atomicity guarantee. 19. The concurrency-control mechanism. 20. The protected cache policy.

21. The cache invalidation procedure. 22. The denial-state commitment procedure. 23. The retry and duplicate-operation restrictions. 24. The crash-recovery mechanism. 25. The treatment of external effects outside the atomic boundary. 26. The verification procedures demonstrating the required security properties.

The selected implementation must provide concrete technical mechanisms for each feature.

7.4.134. C-09.69 - Technical Effect

this implementation profile permits protected operation-specific finality to be enforced within a native transactional resource controller without requiring external transmission of a separately portable authorization token.

The controller maintains the proposed operation in a non-effective condition, determines the actual pending operation, evaluates protected authority predicates, commits internal validation state, establishes bounded inline enablement, and verifies the actual operation before effectuation.

Where the protected authorization state and native resource mutation participate in the same atomic transaction, the system can prevent a protected authorization from being consumed independently of the corresponding committed resource effect.

The architecture also provides protected cache revalidation, transaction-local denial evidence, and recovery procedures designed to prevent stale authorization and unauthorized duplicate operation.

The claimed atomicity applies to the technical boundary actually controlled by the selected resource system.

7.4.135. C-09.70 - Technical Summary

this implementation profile discloses a protected inline transaction-finality architecture in which an artificial-intelligence-agent-generated operation is submitted to an effectuation controller, maintained in a Non-Effective State, reconstructed into a machine-verifiable operation descriptor, evaluated against protected authority conditions, and associated with an internally committed validation-state representation.

A bounded execution-enabling condition is established within the protected controller or transaction context without requiring issuance of a separately portable authorization token.

The controller verifies the actual pending operation against the protected validation state, current authority conditions, freshness, effectuation scope, and controller identity.

Upon successful verification, the controller permits the governed native resource effect and performs the required protected authorization-state transition.

A native transactional implementation may atomically commit the protected state transition and resource mutation.

Further embodiments provide protected cached authorization revalidation and transactionlocal denial evidence.

The architecture may be implemented within database engines, storage controllers, payment processors, cloud resource services, file-system controllers, protected kernels, hardware transaction controllers, or equivalent effectuation interfaces.

7.4.135.1. PROTECTED MULTI-AGENT INFLUENCE-LINEAGE GOVERNANCE WITH AUTHORITY-SEPARATED INFORMATION FLOW, RETRIEVAL-TO-
7.4.135.2. EXECUTION CONTROL, DELEGATED OPERATION BINDING, AND DOWNSTREAM FINALITY SINK VERIFICATION

7.5. Implementation Profile C-60

Source location: original disclosure pages 1044-1104. 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-60.1 - Technical Field

this implementation profile relates to computer-implemented resource security, database transaction processing, artificial-intelligence-agent authorization, native resource-state protection, multiversion concurrency control, transactional event processing, cross-object integrity enforcement, and concurrency-safe resource modification.

More particularly, the embodiment discloses a system in which a resource engine receives a state-modifying operation initiated directly or indirectly by an artificial-intelligence agent, constructs an isolated prospective representation of the resource state that would result from that operation and its applicable transaction-associated dependencies, evaluates machineenforced resource invariants over the combined prospective state, and commits or rejects the resulting resource changes as part of a native transaction.

The system further provides atomic association of accepted resource modifications with transactional outbox records representing authorized downstream asynchronous work.

The architecture may be implemented through:

(a) relational database engines; (b) transactional key-value stores; (c) document databases with suitable transaction support;

(d) resource-management services;

(e) enterprise workflow databases;

(f) account and entitlement stores;

(g) cloud configuration databases;

(h) transactional storage engines;

(i) durable workflow state machines;

(j) distributed databases with appropriate consistency guarantees;

(k) transactional native resource controllers; or

(l) combinations thereof.

The invention does not depend upon a particular database vendor, SQL dialect, programming language, cloud provider, transaction implementation, or artificial-intelligence-agent framework.

The required isolation, atomicity, trigger semantics, and concurrency guarantees must be supported by the actual selected resource engine.

7.5.2. PART I - TECHNICAL PROBLEM

7.5.3. C-60.2 - Authorization Based Only on the Requested Operation

An artificial-intelligence agent may request a resource-state change that appears permissible when evaluated independently.

For example, the agent may request:

UPDATE ACCOUNT A

or:

CHANGE SUPPLIER RESOURCE R

or:

CREATE ACCESS RECORD X.

A preliminary authorization mechanism may verify that the agent possesses a role allowing the requested operation.

However, the actual resulting resource state may violate an invariant after considering:

1. Existing resource relationships. 2. Other objects modified by the same transaction. 3. Database triggers. 4. Stored procedures. 5. Automatically generated dependent records. 6. Resource ownership restrictions. 7. Aggregate modification bounds. 8. Transaction-associated event records. 9. Concurrent state changes. 10. Application-specific prohibited transitions.

The identity or declared permission of the requesting agent does not, by itself, establish that the resulting combined resource state is authorized.

7.5.4. C-60.3 - Cross-Object Invariant Problem

A resource operation may modify several related objects.

For example, transferring ownership of an enterprise resource may involve:

(a) modification of the resource's owner field; (b) modification of the previous owner's resource index; (c) modification of the new owner's resource index; (d) changes to access-control relationships; and (e) creation of an audit or notification event.

Authorizing only the primary object's proposed modification may permit an inconsistent combined state.

The invention evaluates the relevant post-operation relationships before committing the transaction.

7.5.5. C-60.4 - Trigger-Generated Effect Problem

A database mutation may activate a trigger or stored procedure.

The trigger may:

1. Modify another table. 2. Update an aggregate counter. 3. Generate a dependent record. 4. Record an audit entry.

5. Add a transactional outbox event. 6. Invoke another transaction-associated rule.

A validation performed solely on the initial request may omit such changes.

The system therefore identifies transaction-associated dependencies and evaluates the combined projected state.

7.5.6. C-60.5 - Concurrent Authorization Problem

Two AI-agent operations may each appear valid against the same initial state.

Their combined committed effects may nevertheless violate a shared invariant.

For example:

Current number of privileged administrators = 1.

Operation A removes Administrator X.

Operation B removes Administrator Y.

Each transaction may independently observe the other administrator and conclude that at least one administrator remains.

If both transactions commit without adequate concurrency control, no privileged administrator remains.

This is a representative write-skew problem.

The system must prevent acceptance of a combined state violating the applicable invariant.

7.5.7. C-60.6 - Transactional Outbox Problem

An authorized resource mutation may require a downstream asynchronous operation.

For example:

RESOURCE UPDATE

→ OUTBOX EVENT

→ WORKER

→ EXTERNAL NOTIFICATION.

If the primary resource change commits but the outbox record is not written, the required downstream processing may be omitted.

If the outbox record commits but the primary resource change is rejected, a worker may act upon a resource state that never became valid.

The embodiment atomically associates accepted primary resource modifications with required transactional outbox records.

7.5.8. C-60.7 - Distinction From Upstream API Admission

An upstream API gateway may determine whether a request is permitted based on its predicted effects.

However, the actual native resource state may change between admission and commit.

The native resource engine has access to transaction-specific state and concurrency mechanisms.

This embodiment therefore performs the required authorization during the native resource transaction.

An upstream effect-closure admission system may optionally be used in addition, but it does not replace the claimed transaction-native invariant evaluation.

7.5.9. PART II - CENTRAL TECHNICAL PRINCIPLE

7.5.10. C-60.8 - Authorization of the Resulting State

The central principle is:

A state-modifying operation is authorized only when the combined projected resource state resulting from the operation and its applicable transaction-associated dependencies satisfies the required machine-enforced invariants at the commit boundary.

The system does not rely exclusively upon the requested API method, identity role, or original input parameters.

It evaluates the state that would result if the transaction were committed.

7.5.11. C-60.9 - Representative Authorization Predicate

For a transaction T:

COMMIT_ALLOWED(T) =

VALID_REQUEST_CONTEXT

AND VALID_NATIVE_RESOURCE_AUTHORITY

AND VALID_PROJECTED_STATE(T)

AND REQUIRED_DEPENDENCIES_INCLUDED(T)

AND ALL_REQUIRED_INVARIANTS_SATISFIED(T)

AND VALID_TRANSACTIONAL_OUTBOX_STATE(T)

AND CONCURRENCY_STATE_ACCEPTABLE(T).

The exact invariant set and authorization predicates are selected according to the resource engine and enforcement point implementation.

7.5.12. C-60.10 - Atomicity Boundary

The native transaction controls:

1. Primary resource modifications. 2. Dependent modifications included in the same native transaction. 3. Relevant invariant checks. 4. Required transactional outbox entries. 5. Commit or rollback. 6. Appropriate concurrency validation.

A successful transaction commits its supported resource changes and outbox records together.

An unsuccessful transaction commits neither the prohibited resource changes nor their associated outbox records.

External downstream effects are not automatically included in the resource engine's native atomicity boundary.

7.5.13. C-60.11 - No Separate DAS Receipt Requirement

The resource engine may make its authorization decision using its native transaction state and invariant evaluator.

It need not issue:

(a) an independent protected validation receipt;

(b) a separately transferable finality capability; or

(c) a downstream sink-bound enablement artifact.

Those mechanisms may be combined with the native transaction engine in another implementation.

However, this implementation profile is independently implementable through transaction-native authorization, state projection, isolation, and commit control.

7.5.14. PART III - PRINCIPAL SYSTEM COMPONENTS

7.5.15. C-60.12 - Agent-Associated Resource Request Interface

A Resource Request Interface receives state-modifying operations initiated directly or indirectly by an AI agent.

The request may originate through:

(a) a controlled API; (b) an application service; (c) a database driver; (d) a resource-management service; (e) a workflow controller; (f) a delegated worker; (g) an enterprise connector; or (h) a native resource operation interface.

The interface associates the operation with the applicable agent, task, resource, and authority context.

7.5.16. C-60.13 - Native Resource Engine

A Native Resource Engine controls the authoritative resource state and its transactional modification.

It provides the supported facilities necessary to:

1. Begin a transaction.

2. Read a suitable resource snapshot. 3. Stage prospective changes. 4. Execute transaction-associated dependencies. 5. Evaluate invariants. 6. Detect relevant concurrent conflicts. 7. Commit or roll back. 8. Persist corresponding outbox records.

7.5.17. C-60.14 - Transaction-State Mechanism

The Transaction-State Mechanism establishes an isolated prospective representation of the relevant resource objects.

The representation may use:

(a) multiversion concurrency control; (b) transaction-local write sets; (c) copy-on-write state; (d) versioned resource objects; (e) private transactional buffers; (f) isolated state-machine proposals; or (g) equivalent transaction-state facilities.

The prospective state is not externally committed while validation remains incomplete.

7.5.18. C-60.15 - Dependency Evaluator

A Dependency Evaluator identifies additional resource-state transitions or event records generated by:

1. 2. 3. 4. 5. 6.

Database triggers. Stored procedures. Resource rules. Transaction-associated event handlers. Resource update cascades. Transactional workflow rules.

It identifies the dependencies relevant to the proposed operation and the selected invariant set.

7.5.19. C-60.16 - Projected-State Generator

A Projected-State Generator determines the combined prospective resource state.

It applies:

(a) the initiating modification; (b) applicable dependent modifications; (c) transaction-associated trigger effects; and (d) relevant outbox record generation.

The resulting representation is evaluated before native commit.

7.5.20. C-60.17 - Invariant Evaluator

An Invariant Evaluator checks machine-enforced constraints over the combined projected state.

Representative invariant classes include:

OBJECT_INTEGRITY

FIELD_CONSISTENCY

OWNERSHIP_RESTRICTION

AUTHORIZATION_CONSTRAINT

AGGREGATE_MUTATION_BOUND

CROSS_OBJECT_RELATIONSHIP

PROHIBITED_STATE_TRANSITION

RESOURCE_VERSION_CONSISTENCY

OUTBOX_ASSOCIATION.

7.5.21. C-60.18 - Native Transaction Controller

The Native Transaction Controller determines whether to commit, reject, or re-evaluate the transaction.

It performs the commit under the applicable native isolation and concurrency guarantees.

7.5.22. C-60.19 - Transactional Outbox Controller

The Transactional Outbox Controller constructs and persists event records required for downstream processing.

The outbox records are associated with the accepted primary state modification within the same native transaction.

7.5.23. C-60.20 - Outbox Dispatch Worker

An Outbox Dispatch Worker reads committed event records and performs corresponding downstream operations.

It verifies applicable event identity, resource version, and permitted downstream effect classification.

The worker maintains a durable processing state to manage duplicate delivery, retries, and inconsistent events.

7.5.24. C-60.21 - Concurrent Conflict Controller

A Concurrent Conflict Controller detects conditions in which a transaction's projected state is no longer valid because of another concurrent modification.

It may use:

(a) serializable isolation; (b) explicit predicate or resource locks;

(c) optimistic concurrency validation;

(d) compare-and-swap version checks;

(e) transaction retries;

(f) serialization fences; or

(g) another mechanism sufficient for the selected invariants.

7.5.25. PART IV - RESOURCE-STATE REPRESENTATION

7.5.26. C-60.22 - Resource Object

A Resource Object means a stateful object governed by the native resource engine.

Examples include:

1. Database records. 2. Account objects. 3. Access-control records. 4. Ownership records. 5. Cloud resource configurations. 6. Inventory entries. 7. Workflow state. 8. Storage metadata. 9. Transaction records. 10. Related resource indexes.

7.5.27. C-60.23 - Resource State Record

A representative record comprises:

ResourceID = RESOURCE-6001

ResourceClass = ENTERPRISE_RECORD

ResourceVersion = 41

OwnerID = PRINCIPAL-A

ResourceStatus = ACTIVE

AuthorizationScope = TASK-204

StateDigest = DIGEST-6001.

The values are illustrative.

The version identifies a relevant committed state of the resource.

7.5.28. C-60.24 - Resource Version

A Resource Version identifies the committed state against which a transaction may evaluate or modify an object.

A version may comprise:

(a) an integer generation; (b) a transaction identifier; (c) an MVCC tuple version; (d) a database commit sequence; (e) an authenticated state reference; or (f) another native consistency identifier.

The required version semantics are defined by the selected engine.

7.5.29. C-60.25 - Prospective State

A Prospective State is the state that would exist if the proposed transaction and all applicable transaction-local dependencies were committed.

For example:

Committed State:

ResourceOwner = PRINCIPAL-A.

Proposed Operation:

TransferOwnership(PRINCIPAL-B).

Prospective State:

ResourceOwner = PRINCIPAL-B.

The prospective state is initially isolated from ordinary committed-state readers according to the transaction engine's isolation semantics.

7.5.30. C-60.26 - Transaction Read Set

A Transaction Read Set identifies resource objects and predicates relied upon during authorization.

A representative set may contain:

ReadObjectIDs.

ReadResourceVersions.

ReadPredicateReferences.

ObservedAggregateValues.

AuthorityStateReferences.

The read set supports appropriate concurrency validation.

7.5.31. C-60.27 - Transaction Write Set

A Transaction Write Set identifies proposed modifications to resource objects.

A representative write entry comprises:

ResourceID.

ExpectedVersion.

ProposedNewState.

ModificationClass.

OriginatingOperationID.

The write set remains uncommitted until required invariant evaluation and commit authorization succeed.

7.5.32. C-60.28 - Dependent Change Set

A Dependent Change Set contains additional resource-state modifications generated by transaction-associated rules.

For example:

PrimaryChange:

UPDATE ACCOUNT OWNER.

DependentChanges:

UPDATE OWNER INDEX.

UPDATE ACCESS RELATIONSHIP.

CREATE AUDIT RECORD.

CREATE OUTBOX EVENT.

The combined state is evaluated for consistency.

7.5.33. PART V - DEPENDENCY EVALUATION

7.5.34. C-60.29 - Applicable Resource Dependencies

The Dependency Evaluator identifies dependencies that may be triggered by the proposed state modification.

Examples include:

(a) a BEFORE UPDATE trigger; (b) an AFTER UPDATE trigger executing within the same transaction;

(c) a stored procedure invoked by the operation;

(d) a cascading foreign-key action;

(e) a resource ownership update rule;

(f) a transactional event-record generator;

(g) an application rule executed inside the same transaction.

The engine determines the selected resource state's actual dependency semantics.

7.5.35. C-60.30 - Trigger Ordering

Some triggers execute before the primary modification.

Others execute after a row or statement modification but before transaction commit.

The implementation must preserve the native engine's defined trigger ordering.

The final invariant check evaluates the combined state that is actually eligible for commit.

It must not assume that all trigger effects can be predicted accurately by a detached simulation that does not execute the applicable native rules.

7.5.36. C-60.31 - Trigger Closure

An applicable trigger may create additional changes that activate further transactionassociated triggers.

The Dependency Evaluator may compute:

PrimaryOperation

→ Trigger A

→ Dependent Change B

→ Trigger C

→ Dependent Change D.

The evaluator continues until the required transaction-associated dependency state is resolved, or the engine rejects an unsupported or unbounded dependency condition.

7.5.37. C-60.32 - Trigger Cycle Handling

A trigger cycle may produce repeated modifications.

A selected implementation may use:

1. Native trigger recursion limits. 2. Cycle detection. 3. Statement execution bounds. 4. Recursive dependency-state tracking. 5. Resource mutation limits. 6. Transaction timeouts.

An unresolved cycle does not justify committing a partially evaluated resource state.

Where the required invariant cannot be evaluated, the transaction is rejected or otherwise kept noncommitted.

7.5.38. C-60.33 - External Operations Inside Triggers

A database trigger may attempt external network communication or invoke a nontransactional service.

Such external effects may not be rolled back when the native transaction fails.

Therefore, the principal atomic outbox implementation prohibits or isolates external irreversible effects during speculative resource-state evaluation.

Instead, the transaction writes a durable outbox record describing the permitted downstream operation.

The external operation is dispatched only after commit.

Where the selected resource engine permits external side effects inside triggers, the implementation must separately address their nontransactional semantics and cannot assume native rollback reverses them.

7.5.39. PART VI - PROJECTED STATE GENERATION

7.5.40. C-60.34 - Combined State Construction

The Projected-State Generator constructs a combined state representation:

ProjectedState(T) = Apply( BaseState, PrimaryMutation, ApplicableDependentMutations ).

The projected state also includes transaction-associated outbox records where relevant to the invariant evaluation.

7.5.41. C-60.35 - Prospective State Isolation

Other transactions do not observe uncommitted prospective modifications as though they were authoritative committed state.

The mechanism may use native snapshot isolation, serializable transactions, or equivalent isolation.

However, snapshot isolation alone does not universally prevent write-skew anomalies.

The selected implementation must use additional predicate locking, serializable validation, or equivalent mechanisms where shared invariants require them.

7.5.42. C-60.36 - Projected-State Completeness

Before invariant evaluation, the controller establishes whether the relevant transactionassociated effects have been included.

If a mandatory trigger or resource rule cannot be resolved, the system does not certify the projected state as complete.

The controller may reject the transaction or invoke a supported conservative procedure.

7.5.43. C-60.37 - Resource-Scoped Projection

A full copy of the entire database is not required.

The transaction may project only:

1. Objects directly modified. 2. Dependent objects. 3. Aggregate records. 4. Resource-version predicates. 5. Objects necessary to evaluate the applicable invariants. 6. Required transactional event entries.

The projection is sufficient when those objects and predicates cover the invariant's relevant read and write dependencies.

7.5.44. PART VII - RESOURCE INVARIANTS

7.5.45. C-60.38 - Object Integrity Invariant

An Object Integrity Invariant requires a resource object to satisfy defined integrity conditions.

For example:

ResourceID must remain unique.

Required fields must be present.

Object version must be valid.

The native transaction controller rejects a projected state violating the invariant.

7.5.46. C-60.39 - Field Consistency Invariant

A Field Consistency Invariant governs relationships among fields.

For example:

If ResourceStatus = CLOSED,

then ActiveCredentialCount = 0.

A transaction attempting to close a resource while leaving an active credential reference may be rejected.

7.5.47. C-60.40 - Ownership Invariant

An Ownership Invariant governs permitted owner relationships.

For example:

A protected resource must have exactly one current owner.

A transfer operation must update the resource and corresponding ownership records consistently.

The projected state is checked before commit.

7.5.48. C-60.41 - Authorization Constraint

An Authorization Constraint governs whether a particular agent-associated operation may produce the proposed resource-state transition.

A representative constraint may require:

(a) valid originating identity; (b) permission to modify the target resource; (c) current task scope; (d) permitted state transition; (e) valid resource ownership; or (f) another machine-enforced condition.

The authorization is evaluated in relation to the proposed resulting state.

7.5.49. C-60.42 - Aggregate Mutation Bound

A transaction may be subject to a maximum number or aggregate amount of permitted modifications.

For example:

AggregateActiveAdministrators ≤ 5.

A transaction adding an administrator may require evaluation of the resulting aggregate.

Concurrent transactions must not each rely upon the same stale aggregate value to exceed the bound.

7.5.50. C-60.43 - Prohibited State-Transition Relationship

An invariant may prohibit selected transitions.

For example:

ResourceStatus = LOCKED

must not transition directly to:

ResourceStatus = EXTERNALLY_PUBLISHED

without an authorized intermediate state.

The native transaction controller evaluates the actual proposed transition.

7.5.51. C-60.44 - Inter-Object Relationship Invariant

A dependent enforcement point implementation may require:

If Resource A references Resource B,

then Resource B must exist and satisfy a defined compatible state.

The projected combined state is checked for consistency across the related objects.

7.5.52. PART VIII - CROSS-OBJECT MODIFICATION

7.5.53. C-60.45 - Multiple Resource Objects

A state-modifying operation may affect:

PrimaryObject.

DependentObjectA.

DependentObjectB.

AggregateObject.

AuditObject.

OutboxRecord.

The transaction controller evaluates the relevant combined state.

7.5.54. C-60.46 - Cross-Object Atomicity

In one implementation, all affected objects reside within a native transaction domain supporting atomic commit.

If any required invariant fails, none of the transaction's covered object modifications become committed.

Where objects reside in separate resource engines lacking a shared atomic transaction, the implementation must use a suitable distributed transaction or narrow its enforcement point of atomicity to the actual native transaction domain.

7.5.55. C-60.47 - Example Cross-Object Ownership Change

Before the operation:

Resource R owner = A.

OwnerIndex A includes R.

OwnerIndex B excludes R.

Proposed operation:

Transfer R from A to B.

Required projected state:

Resource R owner = B.

OwnerIndex A excludes R.

OwnerIndex B includes R.

The invariant evaluator checks these relationships before commit.

If one dependent update fails, the transaction is rejected rather than committing a partially inconsistent ownership transfer.

7.5.56. C-60.48 - Shared Aggregate Object

Several transactions may depend upon a shared aggregate object.

For example:

ActiveAccountCount.

ResourceQuotaUsed.

PrivilegedRoleCount.

The aggregate object may be updated or locked as part of the transaction to prevent concurrent invariant violations.

An implementation may alternatively use serializable predicate validation rather than a physical aggregate counter.

7.5.57. PART IX - TRANSACTIONAL OUTBOX

7.5.58. C-60.49 - Transactional Outbox Record

A Transactional Outbox Record represents an authorized downstream asynchronous operation.

A representative record comprises:

OutboxEventID = EVENT-6001

LogicalOperationID = OP-6001

ResourceID = RESOURCE-6001

CommittedResourceVersion = 42

PermittedEffectClass = CUSTOMER_NOTIFICATION

PayloadReference = PAYLOAD-6001

EventStatus = PENDING

EventGeneration = 17.

The values are illustrative.

7.5.59. C-60.50 - Outbox Creation

The native transaction controller creates the required outbox entries as part of the same transaction that modifies the primary resource.

The outbox event may identify:

1. The logical operation. 2. The affected resource. 3. The resulting resource version. 4. The permitted downstream effect class. 5. The authorized destination or resource scope. 6. The event identity. 7. The event payload or digest.

7.5.60. C-60.51 - Atomic Commit Relationship

A representative transaction includes:

UPDATE RESOURCE

x

UPDATE DEPENDENT OBJECT

x

INSERT OUTBOX EVENT.

The native engine commits all required transaction-covered records or none.

The outbox worker cannot obtain a committed event for a resource mutation that the same transaction rejected, assuming it reads only committed outbox entries and the underlying database supplies the required atomicity.

7.5.61. C-60.52 - Rejection Behavior

If the invariant evaluator rejects the transaction:

1. The primary resource modification is not committed. 2. The dependent resource modifications are not committed. 3. The associated transactional outbox entries are not committed. 4. The transaction's reserved native state is released or rolled back according to engine semantics. 5. The initiating operation receives a rejection or retry decision.

7.5.62. C-60.53 - Post-Commit Dispatch

The outbox dispatcher reads committed event records.

It verifies applicable event constraints.

It may then invoke the downstream operation.

The dispatch is not part of the original database transaction unless a supported distributed atomic mechanism explicitly includes it.

7.5.63. C-60.54 - At-Least-Once Delivery

An outbox dispatcher may deliver an event more than once because of retries or acknowledgment loss.

The architecture therefore supports idempotency or duplicate-event rejection by the downstream worker.

Exactly-once external effectuation is not assumed merely because the outbox entry itself was committed once.

7.5.64. C-60.55 - Event Identity Constraint

A downstream event worker may maintain a durable record of processed event identities.

A representative uniqueness key is:

(ConsumerID, OutboxEventID).

If the same event is delivered again to the same consumer, the worker can reject duplicate processing or return the previous result.

The mechanism must be durable and coordinated with the downstream effect to guarantee prevention of duplicate resource changes.

7.5.65. C-60.56 - Resource-Version Binding

The outbox event references the resource version associated with the committed transaction.

| The worker verifies that the event was generated from a valid committed resource state. The worker must distinguish a stale but legitimate historical event from an inconsistent or forged event. A newer current resource version alone does not automatically make an older event invalid. The appropriate decision depends upon the effect class and ordering policy.                                                         |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-60.57 - Version-Sensitive Downstream Effects For an operation requiring only the latest resource version, the worker may reject an event superseded by a newer version. For an operation representing a historical audit event, the worker may process an older version even after further resource changes. The version-consistency policy is defined by the downstream effect contract.                                      |
| C-60.58 - Permitted Effect Class An outbox event identifies the downstream effect class authorized by the native transaction. For example: SEND_NOTIFICATION. UPDATE_SEARCH_INDEX. SYNCHRONIZE_APPROVED_RESOURCE. The worker verifies that the event's operation falls within that class. A malicious or corrupted event cannot automatically substitute a privileged resource modification for an authorized notification. |

7.5.66. PART X - CONCURRENCY AND CONFLICT CONTROL

7.5.67. C-60.59 - Concurrent Operations

Two or more AI-agent operations may execute concurrently against related resource objects.

The resource engine must ensure that their committed results satisfy the applicable invariants.

| C-60.60 - Optimistic Concurrency An optimistic implementation records the resource versions read during state projection. Before commit, the controller verifies that relevant versions or predicates remain valid. A conflict causes the operation to be retried, re-evaluated, or rejected.                                                                                  |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-60.61 - Pessimistic Concurrency A pessimistic implementation obtains locks covering the required resource objects or invariant predicates. The locks prevent conflicting modifications from invalidating the projected state before commit. The lock scope must correspond to the invariant being protected.                                                                 |
| C-60.62 - Serializable Isolation A serializable transaction implementation may enforce an execution equivalent to some serial ordering of the committed transactions. This can prevent relevant write-skew anomalies. The implementation must use the actual serializable semantics supplied by the resource engine, including appropriate handling of serialization failures. |

7.5.68. C-60.63 - Snapshot Isolation Limitation

Snapshot isolation may permit two transactions to read the same state and update disjoint objects.

Each transaction's local projected state may satisfy the invariant.

The combined committed state may violate it.

Accordingly, snapshot isolation alone is not universally sufficient for enforcement point(s) 63.

The implementation may add explicit invariant locks, predicate conflict detection, aggregateobject updates, or another suitable mechanism.

7.5.69. C-60.64 - Optimistic Revalidation

When a relevant concurrent change occurs, the transaction controller may:

1. Abort the current transaction. 2. Obtain a new resource snapshot. 3. Reconstruct the projected state. 4. Re-execute applicable transaction-associated dependencies. 5. Reevaluate the invariants. 6. Attempt commit under the required concurrency checks.

The previously approved projection is not reused without accounting for the changed state.

7.5.70. C-60.65 - Retry Bound

A resource transaction may repeatedly encounter conflicts.

The implementation may impose:

MaximumRetryCount.

MaximumRetryDuration.

MaximumTransactionAge.

A transaction exhausting the bound is rejected or returned for later authorized retry.

The system does not waive invariant checks to force progress.

7.5.71. PART XI - RESOURCE-NATIVE AUTHORIZATION

7.5.72. C-60.66 - Agent Context Binding

The resource engine may associate the transaction with:

AgentContextID.

TaskID.

OriginatingServiceID.

RequestedOperationID.

ApplicableResourceAuthority.

TransactionID.

The engine verifies the relevant identity and resource scope according to its native authorization mechanism.

7.5.73. C-60.67 - Operation Authorization

An agent may possess general authority to request a class of resource modifications.

However, the final transaction may still fail when its projected combined state violates a resource invariant.

Thus:

PERMISSION TO REQUEST

is distinct from:

AUTHORIZATION TO COMMIT THE RESULTING STATE.

7.5.74. C-60.68 - Trigger Authority

A trigger may execute using privileges different from those of the initiating caller.

The resource engine must define the effect and authorization semantics of that trigger.

A trigger running with elevated native privileges does not automatically make a prohibited projected state acceptable.

The invariant evaluator checks the resulting resource state regardless of which transactionassociated component produced the change.

7.5.75. C-60.69 - Resource Ownership Check

Where authorization depends upon resource ownership, the transaction may read the current owner and proposed owner.

The invariant evaluator checks the transition under the same concurrency protection used for the commit.

An ownership check performed against an earlier stale state is insufficient when a concurrent change invalidates it.

7.5.76. PART XII - COMPLETE PRINCIPAL WORKFLOW

7.5.77. C-60.70 - Thirty-Four-Step Transaction Workflow

7.5.78. Step C60-01 - Resource operation receipt

The native resource engine receives an AI-agent-associated state-modifying request.

7.5.79. Step C60-02 - Requesting context identification

The originating agent, task, and applicable authority are identified.

7.5.80. Step C60-03 - Transaction initiation

The engine begins an isolated native transaction.

7.5.81. Step C60-04 - Resource snapshot acquisition

The required current resource state is obtained.

7.5.82. Step C60-05 - Read-set recording

The resource objects and invariant predicates relied upon are identified.

7.5.83. Step C60-06 - Primary change construction

The requested modification is staged.

7.5.84. Step C60-07 - Dependency discovery

Applicable triggers, stored procedures, resource rules, and event handlers are identified.

7.5.85. Step C60-08 - Dependent transition evaluation

Transaction-associated dependent changes are calculated or executed within the transaction.

7.5.86. Step C60-09 - Cross-object expansion

Additional related resource objects are incorporated as required.

7.5.87. Step C60-10 - Trigger-chain evaluation

Applicable nested transaction-associated effects are processed.

7.5.88. Step C60-11 - Dependency-completeness determination

The controller verifies that relevant dependency processing is complete.

7.5.89. Step C60-12 - Prospective state generation

The combined projected resource state is constructed.

7.5.90. Step C60-13 - Applicable invariant selection

Object, field, ownership, authorization, aggregate, and transition invariants are identified.

7.5.91. Step C60-14 - Object integrity evaluation

Object-level constraints are checked.

7.5.92. Step C60-15 - Field consistency evaluation

Required field relationships are checked.

7.5.93. Step C60-16 - Cross-object invariant evaluation

Relevant inter-object relationships are checked.

7.5.94. Step C60-17 - Aggregate invariant evaluation

Shared quotas and aggregate restrictions are evaluated.

7.5.95. Step C60-18 - Authorization-state evaluation

The requested transition is checked against current native authority.

7.5.96. Step C60-19 - Invariant decision

The transaction is classified as eligible or ineligible for commit.

7.5.97. Step C60-20 - Outbox effect classification

Required asynchronous downstream effects are identified.

7.5.98. Step C60-21 - Event identity allocation

Unique event identities are established.

7.5.99. Step C60-22 - Resource-version association

The proposed committed resource version is associated with each required outbox event.

7.5.100. Step C60-23 - Transactional outbox insertion

The required event records are staged within the native transaction.

7.5.101. Step C60-24 - Final projected-state verification

The complete proposed transaction state is checked.

7.5.102. Step C60-25 - Concurrency validation

Relevant resource versions, locks, or predicates are verified.

7.5.103. Step C60-26 - Conflict handling

An invalidated projection is retried or rejected.

7.5.104. Step C60-27 - Native commit decision

The engine determines whether the transaction satisfies all required conditions.

7.5.105. Step C60-28 - Atomic commit or rollback

The native engine commits the primary changes and outbox records together, or rejects both.

7.5.106. Step C60-29 - Commit outcome registration

The committed resource version and transaction outcome are recorded.

7.5.107. Step C60-30 - Outbox visibility

Committed outbox events become eligible for asynchronous processing.

7.5.108. Step C60-31 - Downstream event verification

The worker verifies event identity, resource version, and permitted effect class.

7.5.109. Step C60-32 - Duplicate-event handling

Repeated event delivery is detected and controlled.

7.5.110. Step C60-33 - Downstream processing

An eligible event is processed according to native worker semantics.

7.5.111. Step C60-34 - Completion and reconciliation

The downstream processing state is recorded and recoverable failures are handled.

7.5.112. PART XIII - REFERENCE IMPLEMENTATION ALGORITHMS

C-60.71 - Algorithm A: Native Transaction Initialization

function BeginAgentResourceTransaction(request):

context = AuthenticateOriginatingResourceContext(

request.agent_context )

if context is invalid:

return DENIED

operation = CanonicalizeResourceMutation(request)

if operation is invalid:

return DENIED transaction = NativeResourceEngine.beginTransaction({

isolation: REQUIRED_ISOLATION_LEVEL, agent_context: context, logical_operation_id: operation.id })

if transaction failed:

return DENIED

return transaction

The required isolation level depends upon the selected invariant set.

C-60.72 - Algorithm B: Prospective State Construction

function ConstructProjectedResourceState(

transaction, proposed_operation ):

base_state = transaction.readRequiredResourceState(

proposed_operation )

primary_change = ApplyMutationToTransactionLocalState(

transaction, proposed_operation )

dependencies = ResolveApplicableResourceDependencies(

proposed_operation, transaction )

for each dependency in NativeDependencyExecutionOrder(

dependencies ):

if not ExecuteDependencyWithinTransaction(

transaction, dependency ):

transaction.rollback() return DENIED if not VerifyDependencyClosureComplete(transaction):

transaction.rollback() return DENIED projected_state = MaterializeRelevantProspectiveState(

transaction )

return projected_state

The primary and dependent changes remain uncommitted.

C-60.73 - Algorithm C: Cross-Object Invariant Evaluation

function EvaluateCrossObjectInvariants(

transaction, projected_state, invariant_set ):

for each invariant in invariant_set:

relevant_objects = ResolveInvariantReadDomain(

transaction, invariant, projected_state )

if not VerifyRequiredConcurrencyProtection(

transaction, relevant_objects, invariant ):

return REVALIDATION_REQUIRED

result = EvaluateInvariantOverProjectedState(

invariant, projected_state, relevant_objects )

if result != SATISFIED:

return INVARIANT_FAILURE

return ALL_INVARIANTS_SATISFIED

The required read domain may include predicate-defined objects, not only explicitly modified rows.

C-60.74 - Algorithm D: Combined Native Authorization

function AuthorizeNativeProjectedState(

transaction, proposed_operation ):

projected = ConstructProjectedResourceState(

transaction, proposed_operation )

if projected is invalid:

return DENIED authority = ResolveCurrentNativeResourceAuthority(

transaction.agent_context )

if not VerifyRequestedTransitionAuthority(

authority, proposed_operation, projected ):

transaction.rollback() return DENIED invariants = ResolveApplicableResourceInvariants(

proposed_operation, projected )

result = EvaluateCrossObjectInvariants(

transaction, projected, invariants )

if result != ALL_INVARIANTS_SATISFIED:

transaction.rollback() return DENIED_OR_RETRY return ELIGIBLE_FOR_OUTBOX_AND_COMMIT

The authorization decision is based on the projected combined state.

C-60.75 - Algorithm E: Atomic Outbox Creation and Commit

function CommitResourceMutationWithOutbox(

transaction, authorized_projection ):

if not VerifyCurrentTransactionAuthorization(

transaction, authorized_projection ):

transaction.rollback() return DENIED events = DeriveRequiredTransactionalOutboxEvents(

authorized_projection )

for each event in events:

if not VerifyPermittedDownstreamEffectClass(event):

transaction.rollback() return DENIED event_id = AllocateStableOutboxEventID(

transaction.logical_operation_id, event )

version_reference = ResolveProposedCommittedVersion(

transaction, event.resource_id )

transaction.insertOutbox({

event_id: event_id, logical_operation_id: transaction.logical_operation_id, resource_id: event.resource_id, committed_version_reference: version_reference, permitted_effect_class: event.effect_class, payload: event.payload, status: PENDING })

if not RevalidateCommitCriticalPredicates(

transaction ):

transaction.rollback() return RETRY_REQUIRED

result = transaction.commit()

if result == COMMITTED:

return COMMITTED_WITH_OUTBOX return REJECTED_OR_INDETERMINATE

The transaction engine must support atomic resource and outbox persistence.

C-60.76 - Algorithm F: Optimistic Conflict Detection

function ValidateProspectiveStateVersions(

transaction, projection ):

for each read_dependency in projection.read_set:

current = NativeResourceEngine.getCommitRelevantVersion(

read_dependency )

if not VersionPredicateStillValid(

read_dependency, current ):

return CONFLICT

for each aggregate_predicate in projection.invariant_predicates:

if not VerifySerializablePredicateProtection(

transaction,

aggregate_predicate ):

return CONFLICT

return VALID

Simple version comparison of individual rows may not detect phantom or predicate conflicts.

The selected engine must supply the required additional predicate protection.

C-60.77 - Algorithm G: Conflict-Safe Transaction Retry

function ExecuteWithConflictReevaluation(

agent_operation ):

for attempt in 1..MAX_TRANSACTION_RETRIES:

transaction = BeginAgentResourceTransaction(

agent_operation )

if transaction is invalid:

return DENIED

projection = ConstructProjectedResourceState(

transaction, agent_operation )

if projection is invalid:

transaction.rollback() return DENIED

if not EvaluateRequiredInvariants(

transaction, projection ):

transaction.rollback() return DENIED

if not ValidateProspectiveStateVersions(

transaction, projection ):

transaction.rollback() continue

PrepareRequiredTransactionalOutbox(

transaction, projection )

result = transaction.commit()

if result == COMMITTED:

return COMMITTED if result == SERIALIZATION_CONFLICT:

continue

return REJECTED_OR_RECONCILIATION_REQUIRED return CONFLICT_RETRY_LIMIT_REACHED

The retry reconstructs the projected state rather than reusing an invalid earlier approval.

C-60.78 - Algorithm H: Native Shared-Invariant Lock

function AcquireSharedInvariantProtection(

transaction, invariant_id, resource_scope ):

lock_key = CanonicalInvariantLockKey({

invariant_id: invariant_id, scope: resource_scope })

if not transaction.acquireLock(lock_key):

return CONFLICT

return LOCK_HELD_UNTIL_TRANSACTION_COMPLETION

A deployment may employ a native lockable aggregate row or advisory lock with appropriate semantics.

The lock must actually serialize transactions capable of violating the same shared invariant.

C-60.79 - Algorithm I: Downstream Outbox Event Verification

function VerifyCommittedOutboxEvent(event, consumer):

if not VerifyCommittedEventIdentity(event):

return DENIED

if not VerifyPermittedEffectClass(

event.effect_class, consumer ):

return DENIED if not VerifyCommittedResourceVersionReference(

event.resource_id, event.committed_version_reference ):

return DENIED

if not VerifyEventOrderingPolicy(event, consumer):

return DENIED_OR_DEFERRED if AlreadyProcessedByConsumer(

consumer.id, event.event_id ):

return DUPLICATE

return ELIGIBLE_FOR_IDEMPOTENT_PROCESSING

A later current resource version is not automatically grounds for rejecting a historically valid event.

C-60.80 - Algorithm J: Durable Duplicate-Event Processing

function ProcessOutboxEventExactlyOnceLocally(

consumer, event ):

begin consumer_native_transaction

if ConsumerEventLedger.exists(

consumer.id, event.event_id ):

rollback return ALREADY_PROCESSED

if not VerifyCommittedOutboxEvent(event, consumer):

rollback return DENIED

ApplyPermittedLocalResourceEffect(

consumer, event )

ConsumerEventLedger.insertUnique({

consumer_id: consumer.id, event_id: event.event_id, status: COMPLETED })

commit consumer_native_transaction

return PROCESSED

The algorithm supplies atomic duplicate protection only for effects and processing-ledger entries included within the consumer's native transaction.

It does not by itself guarantee exactly-once execution of an external nontransactional effect.

7.5.113. C-60.81 - Algorithm K: Outbox Worker Recovery

function RecoverOutboxProcessing(event_id):

event = NativeOutboxRegistry.get(event_id)

if event is unavailable:

return DENIED

if event.status == COMPLETED:

return COMPLETED

if event.status == PENDING:

return ELIGIBLE_FOR_VERIFIED_PROCESSING

if event.status == IN_PROGRESS:

result = QueryAuthoritativeDownstreamState(event)

if result == CONFIRMED_EFFECTED:

MarkOutboxCompleted(event) return COMPLETED

if result == CONFIRMED_NOT_EFFECTED:

return ELIGIBLE_FOR_RETRY

MarkEventIndeterminate(event)

return RECONCILIATION_REQUIRED

return APPLY_DEFINED_RECOVERY_POLICY

The system does not automatically retry an externally consequential operation merely because the previous acknowledgment is missing.

C-60.82 - Algorithm L: Cross-Object Ownership Transfer

function TransferProtectedResourceOwnership(

resource_id, old_owner, new_owner, agent_context ):

transaction = NativeResourceEngine.beginSerializable()

resource = transaction.readForUpdate(resource_id)

if resource.owner != old_owner:

transaction.rollback() return DENIED

previous_index = transaction.readForUpdate(

OwnerIndex(old_owner) )

next_index = transaction.readForUpdate(

OwnerIndex(new_owner) )

transaction.update(resource_id, {

owner: new_owner })

transaction.remove(previous_index, resource_id)

transaction.add(next_index, resource_id)

projected = transaction.readProjectedState({

resource_id, previous_index, next_index })

if not VerifyOwnershipRelationshipInvariant(projected):

transaction.rollback()

return DENIED

transaction.insertOutbox(

BuildOwnershipChangedEvent(projected) )

return transaction.commit()

This is one concrete implementation species of enforcement point(s) 61.

7.5.114. PART XIV - WORKED TECHNICAL EXAMPLES

C-60.83 - Example A: Protected Supplier Ownership Change

The following is a hypothetical implementation example.

An AI agent proposes transferring responsibility for a supplier resource from Department A to Department B.

The native transaction stages:

1. Supplier owner update. 2. Department A index removal. 3. Department B index addition. 4. Updated access relationship. 5. Ownership-change outbox event.

The invariant evaluator checks that the supplier has exactly one valid owner and that the associated indexes are consistent.

If all conditions succeed, the native transaction commits all supported changes and the outbox record.

If the projected relationship is inconsistent, the entire transaction is rejected.

C-60.84 - Example B: Preventing Privileged Administrator Deletion

An enterprise resource must always have at least one active privileged administrator.

Two AI agents concurrently attempt to remove different administrator accounts.

Each transaction initially observes two active administrators.

Under insufficient snapshot-isolation handling, both removals might appear valid separately.

The protected implementation uses serializable isolation or a shared invariant lock.

Only one removal can commit under the invariant.

The other transaction is re-evaluated and rejected because it would leave zero active administrators.

C-60.85 - Example C: Database Trigger Producing a Dependent Record

An agent requests modification of an account status.

The database's transaction-associated trigger creates a related compliance record.

The projected state includes both the account update and the compliance record.

The invariant evaluator checks that the new account status requires a matching compliance record.

The transaction commits only if the combined state is valid.

C-60.86 - Example D: Transactional Notification Outbox

An agent updates a customer resource.

An authorized notification must be sent after successful commit.

The native transaction stages:

CUSTOMER UPDATE

x

OUTBOX NOTIFICATION EVENT.

Both are committed together.

The notification worker reads only committed events.

If the customer update is rejected, no corresponding notification event is committed.

The later external notification is processed separately and may require its own idempotency and retry controls.

C-60.87 - Example E: Rejected Resource Update Does Not Emit Event

An AI agent requests a modification that violates a prohibited resource transition.

The transaction-associated workflow would ordinarily generate an event record.

The invariant evaluator rejects the projected state.

The native transaction rolls back.

Neither the resource modification nor the associated transactional outbox event becomes committed.

The asynchronous worker therefore does not receive a committed event representing the rejected change.

7.5.115. C-60.88 - Example F: Concurrent Quota Consumption

A resource group permits at most five active allocations.

Four allocations currently exist.

Two AI agents concurrently request one additional allocation.

The native transaction controller uses an invariant lock or equivalent serializable mechanism.

One transaction commits the fifth allocation.

The second transaction is re-evaluated against the new committed state and rejected.

The total remains within the protected limit.

7.5.116. C-60.89 - Example G: Duplicate Outbox Event

A committed resource update generates an outbox event.

The worker processes the event.

Before acknowledging completion, the worker restarts.

The outbox dispatcher delivers the same event again.

The consumer's durable event ledger identifies the same event ID.

Where the consumer's effect and ledger are atomically coupled, the duplicate does not repeat the corresponding native resource modification.

7.5.117. C-60.90 - Example H: Resource-Version Consistency

An outbox event references Resource Version 41.

The resource subsequently advances to Version 42.

A worker receives the historical Version 41 event.

If the event represents an audit record, it may remain valid.

If it represents a latest-state synchronization operation, the policy may require the worker to suppress or replace it.

The event-version rule distinguishes legitimate historical processing from inconsistent stale processing.

7.5.118. C-60.91 - Example I: Protected Inventory Transfer

An AI agent requests transfer of inventory between two locations.

The transaction stages:

Source quantity decrease.

Destination quantity increase.

Transfer-record creation.

Outbox event creation.

The invariant evaluator checks that the source quantity does not become negative and that the combined quantities remain consistent.

The transaction commits all changes or none.

7.5.119. C-60.92 - Example J: Trigger Dependency Cycle

A resource update activates a trigger.

The trigger updates another resource.

The second resource activates a trigger that would repeatedly modify the first.

The engine detects an unsupported or unbounded dependency cycle under the selected transaction rules.

The controller rejects the transaction rather than committing an incompletely projected state.

C-60.93 - Example K: Agent Context Change During Transaction

An AI agent begins a resource modification under an authorized task.

Before commit, a relevant resource authority or ownership condition changes.

The transaction controller detects the changed authorization predicate through its selected concurrency mechanism.

The earlier projection is invalidated.

The operation is retried under current state or rejected.

7.5.120. C-60.94 - Example L: Outbox Dispatch Failure

An authorized resource update commits successfully with its required outbox event.

The external notification service is unavailable.

The primary resource transaction remains committed.

The outbox event remains pending or retryable.

The worker later resumes processing under the defined event validity and duplicate-control rules.

The system does not enforcement point that a failed external notification rolls back the already committed primary resource update.

7.5.121. PART XV - FAILURE AND ADVERSARIAL CONDITIONS

7.5.122. C-60.95 - Representative Failure Cases

7.5.123. F1 - Primary-Only Authorization

A controller validates only the requested object modification.

Required dependent changes must also be included in the projected state.

7.5.124. F2 - Missing Database Trigger

A transaction-associated trigger is omitted from the dependency model.

The projected-state completeness condition fails.

7.5.125. F3 - Hidden Stored Procedure Mutation

A stored procedure modifies an additional resource object.

The relevant change must be represented or executed within the native transaction before invariant evaluation.

7.5.126. F4 - Cross-Object Ownership Violation

A primary owner field changes without corresponding dependent relationship updates.

The combined invariant rejects the transaction.

7.5.127. F5 - Invalid Aggregate State

The projected aggregate exceeds a permitted resource bound.

The transaction is rejected.

7.5.128. F6 - Prohibited State Transition

The operation attempts an invalid state-machine transition.

The native invariant evaluator rejects it.

7.5.129. F7 - Missing Authorization Scope

The requesting agent lacks authority for the projected resource transition.

The transaction is rejected.

7.5.130. F8 - Trigger Recursion

A trigger creates an unresolved recursive dependency.

The native engine rejects or restricts the transaction according to the defined bound.

7.5.131. F9 - External Side Effect Inside Transaction

A trigger attempts an irreversible external operation before commit.

The implementation routes the effect through the appropriate post-commit mechanism or explicitly treats it as outside the native atomicity guarantee.

7.5.132. F10 - Primary Commit Without Outbox

The primary resource update commits while a required event record is omitted.

The atomic outbox design prevents this condition for transaction-covered event creation.

7.5.133. F11 - Outbox Without Primary Commit

An event record becomes committed for a rejected primary mutation.

The shared native transaction prevents this inconsistency.

7.5.134. F12 - Outbox Event Identity Collision

Different events receive the same event identity.

The event identity scheme and uniqueness constraints prevent accidental or unauthorized collision.

7.5.135. F13 - Duplicate Outbox Delivery

A dispatcher sends the same event more than once.

The worker applies the defined durable duplicate-control rule.

7.5.136. F14 - Resource-Version Mismatch

An event references a resource version inconsistent with the originating committed transaction.

The worker rejects or reconciles it.

7.5.137. F15 - Legitimate Historical Event

The resource has advanced beyond an older event's version.

The worker applies the effect-class ordering rule rather than automatically rejecting every older version.

7.5.138. F16 - Unauthorized Downstream Effect Class

An outbox record requests an operation outside its permitted effect class.

The worker rejects it.

7.5.139. F17 - Concurrent Write Skew

Two transactions independently satisfy an invariant but jointly violate it.

Serializable or equivalent shared-invariant protection prevents both commits.

7.5.140. F18 - Lost Update

Two transactions attempt to overwrite the same resource state.

The native concurrency mechanism detects or serializes the conflict.

7.5.141. F19 - Phantom Predicate Conflict

An aggregate invariant depends upon a query result changed by a concurrent insertion.

The implementation uses appropriate predicate protection rather than only checking previously read row versions.

7.5.142. F20 - Stale Resource Version

A transaction relies upon a version superseded before commit.

The engine retries or rejects the affected projection.

7.5.143. F21 - Transaction Retry Reuses Old Approval

A conflicting transaction retries using an outdated invariant result.

The system reconstructs and re-evaluates the projection.

7.5.144. F22 - Retry Exhaustion

Repeated serialization conflicts exceed the configured retry bound.

The operation is rejected or returned for later authorized retry.

7.5.145. F23 - Transaction Timeout

A projected-state transaction exceeds supported execution limits.

The engine rolls back or applies its defined failure procedure.

7.5.146. F24 - Outbox Worker Crash

A worker fails after receiving an event.

The durable outbox and consumer state support appropriate recovery.

7.5.147. F25 - Lost External Acknowledgment

An external operation may have occurred but no acknowledgment is available.

The system records an indeterminate outcome and does not blindly assume non-effectuation.

7.5.148. F26 - Duplicate External Payment or Message

A nontransactional destination may execute a repeated operation twice.

The architecture requires suitable destination idempotency or reconciliation for any claimed duplicate-prevention guarantee.

7.5.149. F27 - Resource-State Rollback

An earlier database state is restored.

The recovery procedure reconciles committed transaction and outbox generations according to the selected durability model.

7.5.150. F28 - Unauthorized Trigger Modification

An attacker alters a resource rule.

The applicable trusted configuration and transaction policy identify or prevent unauthorized rule changes.

7.5.151. F29 - New Trigger Introduced

A new transaction-associated trigger modifies additional state.

The native projection must include its effects under the current resource configuration.

7.5.152. F30 - Outbox Processing Out of Order

Events are delivered in a different order from resource commits.

The consumer applies its resource-version and ordering policy.

7.5.153. F31 - Incomplete Distributed Transaction

Related resource objects reside in different databases without shared atomicity.

The implementation does not falsely enforcement point one native atomic transaction across unsupported domains.

7.5.154. F32 - Snapshot Isolation Insufficient

An implementation uses snapshot isolation without protection for shared invariants.

The missing predicate or aggregate conflict control must be supplied.

7.5.155. F33 - Wrong Agent Context

A mutation is attributed to another agent's authority.

The resource engine rejects the invalid context.

7.5.156. F34 - Outbox Payload Substitution

An event payload is modified after commitment.

The required transaction-state or event-integrity checks detect the change.

7.5.157. F35 - Native Engine Unavailable

The resource engine cannot establish a valid transaction.

No speculative resource change is committed.

7.5.158. F36 - Invariant Evaluator Failure

A mandatory invariant cannot be evaluated.

The transaction remains uncommitted or is rejected.

7.5.159. F37 - Atomic Commit Outcome Unknown

The client loses the commit response.

The system queries authoritative transaction state before repeating the logical operation.

7.5.160. F38 - Compensating Action Confused With Rollback

An already committed external effect requires later compensation.

The system distinguishes compensation from native rollback.

7.5.161. PART XVI - IMPLEMENTATION VARIATIONS

7.5.162. C-60.96 - Relational Database Implementation

The resource engine uses ACID transactions, constraints, stored procedures, triggers, and transactional outbox tables.

Serializable isolation or appropriate invariant-specific locking protects concurrent operations.

7.5.163. C-60.97 - Transactional Document Database

A document database with native multi-document transactions stages changes to several related documents.

The invariant evaluator checks their combined prospective state.

The transaction commits or rejects all covered mutations.

7.5.164. C-60.98 - Transactional Key-Value Engine

A versioned key-value system uses conditional writes or an atomic transaction API.

Resource state and outbox records are committed under the supported transactional consistency model.

7.5.165. C-60.99 - Enterprise Resource Management

An enterprise application uses native resource transactions to protect related ownership, account, compliance, or allocation records.

| Agent-originating operations are associated with authenticated task identities.                                                                                                                                                                                                                                      |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-60.100 - Financial Workflow Resource Engine A financial workflow database evaluates projected ledger, approval, ownership, or transaction state under applicable invariants. Any later external settlement remains governed by the separately defined settlement architecture.                                     |
| C-60.101 - Cloud Configuration Database An AI agent requests infrastructure configuration changes. A native resource database projects related configuration objects and dependent event records. The transaction commits only when the resulting state satisfies defined consistency and authorization constraints. |
| C-60.102 - Native Resource Outbox Worker The resource engine commits event records atomically with resource changes. A downstream worker verifies event identity, resource version, and permitted effect class before executing corresponding work.                                                                  |

7.5.166. C-60.103 - Multi-Agent Concurrency

Multiple AI-agent identities submit transactions to the same resource engine.

The native transaction controller serializes or rejects conflicting proposals to maintain shared invariants.

7.5.167. C-60.104 - Optimistic Concurrency Variation

The system uses resource-version comparison and transaction restart after conflicts.

| Additional predicate or aggregate protection is supplied where required.                                                                                                                                                                                                                                                                                                                                 |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-60.105 - Pessimistic Concurrency Variation The system obtains shared-invariant locks covering relevant objects or predicates. Transactions retain those locks through commit or rollback.                                                                                                                                                                                                              |
| C-60.106 - Distributed Serializable Resource Engine A distributed database with appropriate serializable transaction support implements the projection, invariant checks, and atomic outbox records. The guarantees are limited to the engine's actual transaction domain.                                                                                                                       |
| C-60.107 - Optional DAS Protected Finality Integration The native resource engine may be combined with separate protected validation evidence, scoped finality capabilities, and an external or integrated Finality Sink. Such integration can provide additional execution-boundary authorization. However, the independent native projected-state claim does not depend upon these separate artifacts. |

7.5.168. PART XVII - REPRESENTATIVE DATA STRUCTURES

7.5.169. C-60.108 - AgentResourceOperationRecord

Fields may include:

1. LogicalOperationID. 2. AgentContextID.

3. 4. 5. 6. 7. 8. 9.

TaskID. ResourceClass. RequestedMutation. TargetResourceIDs. NativeAuthorityReference. OperationGeneration. OperationStatus.

7.5.170. C-60.109 - NativeTransactionRecord

Fields may include:

1. TransactionID. 2. LogicalOperationID. 3. IsolationLevel. 4. SnapshotReference. 5. ReadSetReference. 6. WriteSetReference. 7. PredicateSetReference. 8. TransactionStatus. 9. CommitSequenceReference.

7.5.171. C-60.110 - ProspectiveResourceStateRecord

Fields may include:

1. ProjectionID. 2. TransactionID. 3. BaseResourceVersions. 4. PrimaryChangeSet. 5. DependentChangeSet. 6. ProjectedObjectStates. 7. RequiredOutboxReferences. 8. ProjectionGeneration. 9. ProjectionCompletenessStatus.

7.5.172. C-60.111 - ResourceDependencyRecord

Fields may include:

1. DependencyID. 2. OriginatingOperationClass. 3. TriggerOrRuleIdentity. 4. DependentResourceClass.

5. GeneratedTransitionClass. 6. ConditionalPredicate. 7. TransactionAssociation. 8. DependencyVersion. 9. DependencyStatus.

7.5.173. C-60.112 - ResourceInvariantRecord

Fields may include:

1. InvariantID. 2. InvariantClass. 3. RelevantResourceClasses. 4. ReadDomainPredicate. 5. ConstraintExpression. 6. RequiredIsolationSemantics. 7. ViolationDisposition. 8. PolicyGeneration. 9. InvariantStatus.

7.5.174. C-60.113 - CrossObjectInvariantRecord

Fields may include:

1. RelationshipID. 2. PrimaryResourceID. 3. DependentResourceIDs. 4. RequiredRelationshipPredicate. 5. BaseVersionReferences. 6. ProjectedVersionReferences. 7. EvaluationOutcome. 8. TransactionReference.

7.5.175. C-60.114 - TransactionalOutboxRecord

Fields may include:

1. OutboxEventID. 2. 3. 4. 5. 6. 7.

LogicalOperationID. TransactionID. ResourceID. CommittedResourceVersion. PermittedDownstreamEffectClass. DestinationOrResourceScope.

8. EventPayloadReference. 9. EventStatus. 10. DeliveryAttemptCount.

7.5.176. C-60.115 - ConsumerEventLedgerRecord

Fields may include:

1. ConsumerID. 2. OutboxEventID. 3. LogicalOperationID. 4. ResourceVersionReference. 5. EffectClass. 6. LocalProcessingTransactionID. 7. CompletionStatus. 8. CompletionReference.

7.5.177. C-60.116 - ConcurrentConflictRecord

Fields may include:

1. ConflictID. 2. TransactionA. 3. TransactionB. 4. SharedInvariantID. 5. ConflictingResourceReferences. 6. ConflictingPredicateReference. 7. ObservedVersionMismatch. 8. ResolutionAction. 9. RetryGeneration.

7.5.178. C-60.117 - NativeCommitOutcomeRecord

Fields may include:

1. 2. 3. 4. 5. 6. 7. 8.

TransactionID. LogicalOperationID. CommitOutcome. CommittedResourceVersions. OutboxEventReferences. CommitSequenceReference. ConflictStatus. RecoveryStatus.

These structures may be implemented through database tables, native resource metadata, transaction logs, transactional document collections, or equivalent resource-engine facilities.

7.5.179. PART XVIII - ENGINEERING VERIFICATION

7.5.180. C-60.118 - Proposed Test Matrix

The following tests are proposed and are not representations of completed experiments.

7.5.181. Test Condition

T1 Valid projected state T2 Invalid object integrity T3 Invalid field relationship T4 Invalid ownership change T5 Prohibited state transition T6 Aggregate bound exceeded T7 Primary modification triggers dependent

update T8 Trigger creates outbox event T9 Primary transaction rejected T10 Dependent modification fails T11 Cross-object relationship valid T12 Cross-object relationship invalid T13 Two concurrent operations violate shared

invariant T14 Serializable conflict T15 Optimistic version conflict T16 Predicate phantom conflict T17 Write-skew scenario T18 Concurrent quota increment T19 Native lock conflict T20 Retry under new snapshot T21 Retry limit exceeded T22 Transaction timeout T23 Outbox record references committed

resource version T24 Duplicate event delivery T25 Outbox event with wrong resource version T26 Legitimate historical event T27 Outbox event with unauthorized effect class Rejected T28 Worker crashes before effect

7.5.182. Expected result

Transaction commits Transaction rejected Transaction rejected Transaction rejected Transaction rejected Transaction rejected Combined state evaluated Event atomically committed Outbox event not committed Primary change rolled back Combined transaction commits Transaction rejected At least one rejected or re-evaluated Transaction retried or rejected Stale projection rejected Aggregate invariant protected Combined invariant preserved Limit maintained Required serialization enforced Invariants recomputed No unsafe commit Uncommitted changes rolled back Version verified Duplicate effect controlled Rejected or reconciled Effect-specific version rule applied

Recoverable pending state

T29 Worker crashes after local transactional

effect T30 Lost external acknowledgment T31 Outbox event reordered T32 Unauthorized trigger introduced T33 Trigger cycle T34 Incomplete projection T35 External call attempted within speculative

transaction T36 Agent authority invalid T37 Resource ownership changed concurrently T38 Resource state restored from stale snapshot T39 Distributed transaction unsupported T40 Commit response lost T41 Multi-agent concurrent ownership transfer T42 Outbox creation fails T43 Database trigger updates aggregate object T44 Trigger-created event after nested mutation T45 Event payload tampered T46 Resource version advances after event

creation T47 Consumer duplicate ledger fails to commit T48 Native transaction service unavailable

Durable duplicate ledger prevents repeat Indeterminate state retained Ordering policy enforced Current dependency configuration verified Native bound or rejection Commit withheld Nontransactional boundary correctly handled Native transaction rejected Authorization re-evaluated Required continuity and conflict checks applied No false atomicity enforcement point Authoritative commit state queried Combined state remains valid Primary transaction not committed Aggregate invariant checked Required dependency closure evaluated Required integrity or transaction-state check fails Defined historical/latest semantics applied Effect and ledger transaction outcome reconciled No speculative state committed

Concrete tests should specify the database engine, isolation level, schema, transactionassociated rules, concurrent schedules, invariant predicates, resource versions, expected outbox entries, and observed commit or rollback outcomes.

7.5.183. PART XIX - Enforcement-Point Mapping and Technical Correspondence

7.5.184. C-60.119 - Independent enforcement point(s) 60

The embodiment provides the following mapping.

enforcement point(s) 60(a): Native resource engine receiving AI-agent-initiated resource mutations.

enforcement point(s) 60(b): Isolated prospective resource-state representation maintained through native

transaction facilities.

enforcement point(s) 60(c): Dependency evaluator identifying trigger, procedure, resource-rule, and

transaction-associated event effects.

enforcement point(s) 60(d): Projected-state generator combining primary and applicable dependent

changes.

enforcement point(s) 60(e): Invariant evaluator checking object integrity, field consistency, ownership,

authorization, aggregate bounds, and prohibited state transitions.

enforcement point(s) 60(f): Native transaction controller committing or rejecting according to invariant

evaluation.

enforcement point(s) 60(g): Atomic association of accepted resource changes with required transactional

outbox entries.

enforcement point(s) 60(h): Rollback of both primary changes and corresponding outbox entries following

rejection.

enforcement point(s) 60(i): Detection of concurrent changes invalidating projected state, followed by re-

evaluation or rejection.

First concluding requirement: Authorization occurs as part of the native resource

transaction.

Second concluding requirement: The resource engine may operate without separately

committed validation receipts or separately transferable effectuation capabilities.

7.5.185. C-60.120 - Dependent enforcement point(s) 61: Cross-Object Modification

The embodiment provides:

1. Primary resource objects. 2. Dependent resource objects. 3. Transaction-local multi-object changes. 4. Inter-object relationship predicates. 5. Ownership-index consistency. 6. Shared aggregate objects. 7. Cross-object invariant evaluation. 8. Atomic commit or rejection within the supported transaction domain. 9. Concurrent relationship protection. 10. Worked ownership-transfer implementation.

C-60.121 - Dependent enforcement point(s) 62: Transactional Outbox Consistency

The embodiment provides:

1. Atomic outbox record creation. 2. Committed resource-version references. 3. Permitted downstream effect classes. 4. Stable event identity. 5. Durable event-processing ledger. 6. Duplicate-event detection. 7. Resource-version consistency checks. 8. Historical versus latest-state event semantics. 9. Retry and recovery handling. 10. Distinction between native atomicity and external downstream effectuation.

C-60.122 - Dependent enforcement point(s) 63: Concurrent Transaction Conflict

The embodiment provides:

1. Multiple concurrent agent transactions. 2. Projected resource states. 3. Shared resource invariants. 4. Serializable transaction controls. 5. Optimistic resource-version validation. 6. Predicate conflict handling. 7. Shared-invariant locking. 8. Write-skew prevention. 9. Conflict-triggered re-evaluation. 10. Transaction rejection where the combined committed state would violate the invariant.

7.5.186. PART XX - implementer IMPLEMENTATION REQUIREMENTS

7.5.187. C-60.123 - Implementation Checklist

A person having ordinary skill in the art implementing the embodiment identifies:

1. The native resource engine. 2. Its supported transaction isolation levels. 3. Its transaction durability semantics. 4. The agent-originating request interface. 5. The authenticated agent and task context. 6. The canonical state-modifying operation descriptor. 7. The affected resource objects. 8. The applicable resource-version scheme. 9. The transaction read set. 10. The transaction write set. 11. The transaction-associated trigger definitions. 12. The applicable stored procedures. 13. The resource rules.

14. The dependency evaluation ordering. 15. The nested trigger handling. 16. The projected-state representation. 17. The required object integrity constraints. 18. The required field consistency rules. 19. The ownership and authorization invariants. 20. The aggregate resource bounds. 21. The prohibited state-transition rules. 22. The cross-object relationship predicates. 23. The invariant read-domain requirements. 24. The native transaction commit controller. 25. The rollback procedure. 26. The transactional outbox schema. 27. The event identity-generation procedure. 28. The committed resource-version binding. 29. The permitted downstream effect classes. 30. The outbox worker. 31. The event deduplication procedure. 32. The event ordering and version-consistency rules. 33. The outbox recovery policy. 34. The handling of unknown external completion. 35. The shared-invariant concurrency protection. 36. The serializable or equivalent predicate validation. 37. The conflict detection procedure. 38. The transaction retry algorithm. 39. The transaction retry resource bounds. 40. The handling of incomplete dependency projection. 41. The treatment of external side effects inside triggers. 42. The distributed transaction-domain limitations. 43. The durability and recovery guarantees. 44. The tests demonstrating native atomicity and invariant preservation.

A resource engine implementing this embodiment must enforce the stated properties using actual supported transaction facilities.

A preliminary API approval, audit log, or post-commit compliance scan does not by itself supply the transaction-native combined projected-state authorization required by the enforcement points.

7.5.188. C-60.124 - Technical Effect

The disclosed system enables an artificial-intelligence-agent-associated resource operation to be authorized according to the combined resource state that would result from its execution.

The native resource engine constructs an isolated prospective state comprising the primary modification and applicable transaction-associated dependent changes.

Machine-enforced resource invariants are evaluated before the transaction commits.

The native transaction controller prevents commitment of an invalid combined state.

Required transactional outbox entries are atomically associated with accepted resource modifications, preventing the outbox from representing rejected primary changes within the supported transaction boundary.

Concurrent conflict detection prevents competing agent operations from committing a combined state that violates a shared invariant.

The architecture supports resource-native authorization without mandating a separately committed receipt or transferable finality capability.

Its guarantees depend upon the actual isolation, trigger, transactional outbox, concurrency, and durability semantics supplied by the selected resource engine.

7.5.189. C-60.125 - Technical Summary

this implementation profile discloses a computer-implemented native resource-state protection system for artificial-intelligence-agent-initiated operations.

A Native Resource Engine receives a proposed state-modifying operation and establishes an isolated prospective resource representation through a supported transaction-state mechanism.

A Dependency Evaluator identifies applicable database triggers, stored procedures, resource rules, and transaction-associated event effects.

A Projected-State Generator determines the combined prospective state produced by the primary operation and its dependent modifications.

An Invariant Evaluator compares the combined state with machine-enforced integrity, field consistency, ownership, authorization, aggregate mutation, and prohibited-transition constraints.

A Native Transaction Controller commits or rejects the modification according to the invariant evaluation.

Required transactional outbox records are committed atomically with the accepted primary resource changes.

Rejection prevents both the invalid primary changes and corresponding transactional outbox entries from becoming committed.

A concurrency-control mechanism detects modifications that invalidate the previously projected state and causes re-evaluation, serialization, or rejection.

A downstream event worker verifies committed resource-version references, permitted effect classes, and event identities before processing eligible outbox records.

The system thereby provides transaction-native authorization and consistency protection for direct and transaction-associated indirect effects of AI-agent operations.

The architecture is independently implementable through the native resource engine without requiring a separate DAS validation receipt or scoped finality capability.

7.5.189.1. POST-EFFECT CAUSAL CONTAINMENT AND SELECTIVE REMEDIATION OF ARTIFICIAL-INTELLIGENCE-AGENT OPERATIONS USING CROSS-SERVICE
7.5.189.2. EFFECT LINEAGE, CONFLICT-PRESERVING STATE RECONSTRUCTION, DEPENDENCY-ORDERED CORRECTION, IRREVERSIBILITY
7.5.189.3. CLASSIFICATION, AND VERIFIED RECOVERY

7.6. Implementation Profile C-76

Source location: original disclosure pages 1322-1396. Source technical content is presented here for implementation analysis; numbering reflects the original profile family rather than a requirement to implement every profile.

END OF EMBODIMENT C-72 EMBODIMENT C-76 HARDWARE-RESIDENT DEFERRED- EFFECT BUDGET ACCOUNTING FOR ARTIFICIAL-INTELLIGENCE-AGENT WORKLOADS USING PROTECTED

QUEUE-ADMISSION RESERVATIONS, TASK-BOUND RESOURCE-EFFECT METERS, ATOMIC COMPLETION RECONCILIATION, DELEGATED COMMAND AGGREGATION, AND RESET-SAFE HARDWARE QUEUE

7.6.1. CONTINUITY

7.6.2. C-76.1 - Technical Field

this implementation profile relates to computer security, hardware-assisted resource governance, artificial-intelligence-agent execution, programmable network interfaces, directmemory-access control, input/output memory management, accelerator command queues, hardware resource budgeting, protected accounting registers, and persistent authorization state.

More particularly, the embodiment discloses a hardware-assisted resource-control system configured to receive resource-operation commands attributable to an artificial-intelligenceagent workload; determine a bounded quantity of consequential resource effects associated with each command; reserve that quantity in a hardware-protected accounting structure before admitting the command to an effect-capable queue; and reconcile reserved and completed quantities when commands execute, partially execute, fail, or become verifiably incapable of further effectuation.

The system may operate at a network adapter, SmartNIC, data-processing unit, storage controller, DMA controller, accelerator queue manager, peripheral interface, IOMMUassociated admission service, or another hardware-adjacent resource-operation boundary.

The architecture may implement budget enforcement independently of a portable, percommand authorization receipt or separately issued finality capability.

7.6.3. PART I - TECHNICAL PROBLEM

7.6.4. C-76.2 - Software Authorization Can Precede Physical Effectuation

An artificial-intelligence agent may submit commands to an operating system or resource controller.

The commands may be accepted into:

1. Network transmission queues. 2. Storage command rings. 3. DMA descriptor queues. 4. Accelerator execution queues. 5. Device command buffers. 6. Peripheral operation queues. 7. Host-to-device shared memory. 8. Asynchronous I/O submission rings. 9. Virtual-function queues. 10. Device-managed work schedulers.

Once accepted, a command may execute independently of the original agent process.

The originating process may terminate, be restarted, or lose its software entitlement while the command remains capable of producing a physical or externally consequential effect.

7.6.5. C-76.3 - Pending Commands as Future Effect Liability

Consider an agent authorized to transmit at most one specified quantity of data through a controlled network interface.

The agent may submit multiple transmission descriptors before any have completed.

If accounting increments only after hardware completion, the agent may submit more commands than the available effect budget permits.

The total completed effect may later exceed the intended limit.

The disclosed system therefore reserves effect capacity before a command enters the relevant executable queue.

7.6.6. C-76.4 - Multi-Process Budget Circumvention

An agent may create:

(a) child processes; (b) delegated workers; (c) separate container processes; (d) concurrent host threads; (e) multiple accelerator streams; (f) multiple network transmit rings; (g) several virtual-function contexts; or (h) additional submission contexts.

If each context receives an independently reset budget, the originating task can potentially exceed the intended aggregate effect limit.

The embodiment associates the commands with a common protected task-accounting domain.

7.6.7. C-76.5 - Cancellation Does Not Necessarily Stop Effectuation

A host may issue:

CANCEL COMMAND.

However, the device may already have:

1. Fetched a descriptor. 2. Transmitted part of a packet sequence. 3. Written a portion of a storage extent. 4. Completed a DMA burst. 5. Submitted work to a downstream engine. 6. Transferred command ownership to another queue. 7. Continued executing after a cancellation acknowledgment was initiated.

The accounting controller cannot release all reserved capacity merely because the host requested cancellation.

It must establish which portion of the command has already effected a resource change and whether the remaining portion can still complete.

7.6.8. C-76.6 - Reset and Snapshot Replay

A host may restart and restore an earlier software state.

A virtual machine may be resumed from a snapshot.

An accelerator controller may reset.

A queue may fail over to another device.

If the effect-budget table is restored to an earlier value while previously submitted commands remain executable, the same budget may be consumed more than once.

this implementation profile includes protected continuity, fencing, and reconciliation rules.

7.6.9. C-76.7 - Device-Level Concurrency

Commands from several host processes may arrive through independent queue pairs.

An ordinary software counter may not atomically coordinate all submissions.

For example:

Remaining budget = 1 operation.

Queue A submits one operation.

Queue B simultaneously submits one operation.

Both queue processors observe the same unused budget.

If both are admitted, the budget is exceeded.

The hardware-adjacent admission controller therefore uses an atomic reservation mechanism shared across the applicable queues.

7.6.10. C-76.8 - Different Resource Effect Classes

A system may govern:

NETWORK_TRANSMISSION_BYTES.

PERSISTENT_STORAGE_WRITES.

DMA_WRITE_BYTES.

ACCELERATOR_EGRESS_BYTES.

PERIPHERAL_COMMAND_COUNT.

PRIVILEGED_DEVICE_OPERATIONS.

RESOURCE_MUTATION_COUNT.

The meaning of a completed effect differs among these classes.

Network transmission by a NIC is not automatically proof of remote delivery.

A DMA write may be effective when it reaches the protected target memory domain.

A storage write may have separate issued, accepted, and durable-completion stages.

The implementation defines the measured effect boundary for each class.

7.6.11. PART II - CENTRAL TECHNICAL PRINCIPLE

7.6.12. C-76.9 - Pre-Queue Reservation

The principal mechanism is:

A resource-operation command cannot enter an effect-capable hardware queue unless the applicable effect-budget capacity has already been reserved against its originating task.

The reservation remains outstanding while the command can produce an effect.

A verified completed portion is transferred to completed-effect accounting.

A remaining portion is released only after the controller establishes that it cannot subsequently produce the corresponding effect.

7.6.13. C-76.10 - Principal Accounting Invariant

For task context t and effect class e:

B(t,e) = authorized effect-budget limit.

C(t,e) = completed effect quantity.

R(t,e) = reserved outstanding-effect quantity.

The invariant is:

C(t,e) + R(t,e) ≤ B(t,e).

Admission of a new command having bounded exposure q requires:

C(t,e) + R(t,e) + q ≤ B(t,e).

The controller atomically establishes this condition and increases R by q before making the command effect-capable.

7.6.14. C-76.11 - Typed Effect Dimensions

The budget may be represented as a vector:

B(t) = (B₁, B₂, …, Bₙ).

Corresponding protected accounting state comprises:

C(t) = (C₁, C₂, …, Cₙ).

R(t) = (R₁, R₂, …, Rₙ).

The admission controller checks the applicable dimensions.

A command may consume multiple dimensions.

For example, a network transmission may contribute to:

NetworkBytes.

TransmissionCommandCount.

DestinationSpecificBytes.

The quantities are not combined without defined compatible units.

7.6.15. C-76.12 - Reservation Conservation

For a command initially assigned reservation q:

q = completed_quantity + remaining_reserved_quantity + verifiably_released_quantity,

subject to any separately recorded adjustment authorized by the selected accounting semantics.

At any time, the controller must not count the same completed quantity as both available headroom and canceled unused capacity.

Where the outcome is uncertain, the corresponding quantity remains charged as completed or reserved according to a conservative policy.

7.6.16. C-76.13 - Command Inertness Before Admission

Before successful reservation, a command may exist in host memory or a protected staging buffer.

It must not be executable through the governed hardware queue.

The command becomes eligible for effectuation only after the admission controller commits the applicable accounting reservation.

7.6.17. C-76.14 - Enforcement Without Portable Per-Command Receipt

The controller may enforce the command using:

1. A protected budget table. 2. Queue-local admission state. 3. Task association. 4. Protected command descriptors. 5. Atomic accounting. 6. Device-local command state. 7. Relevant resource limits.

The host need not receive a portable per-command validation receipt.

Nor must it possess a separately issued non-bearer finality capability for each command.

This differentiates the present mechanism from other DAS execution-finality embodiments, while allowing optional integration with them.

7.6.18. PART III - PRINCIPAL SYSTEM COMPONENTS

7.6.19. C-76.15 - AI-Agent Host Execution Environment

The host environment may include an agent runtime, sandbox, container, virtual machine, process, or delegated worker.

The environment generates commands destined for a hardware resource interface.

The host-side component may be untrusted or less trusted than the protected accounting controller.

7.6.20. C-76.16 - Task-Context Association Mechanism

A Task-Context Association Mechanism binds submitted commands to a machine-readable task identity.

A representative association comprises:

TaskID.

RootAgentID.

ExecutionContextID.

DelegatedContextID.

AuthorityGeneration.

EffectClass.

BudgetDomainID.

The command's task identity must be established through a controlled mechanism, not solely a freely editable descriptor field supplied by the agent.

7.6.21. C-76.17 - Hardware-Adjacent Admission Controller

The admission controller mediates the transition from non-executable staging into an effectcapable hardware queue.

It may reside:

(a) in NIC firmware; (b) in a SmartNIC processor; (c) in a DPU control plane; (d) in a device queue manager; (e) in a trusted host-to-device submission controller; (f) in an accelerator runtime protected by appropriate device isolation; (g) in a storage controller; or (h) in a suitably protected I/O admission domain.

The selected location must provide effective control over the governed queue-admission path.

7.6.22. C-76.18 - Hardware-Protected Accounting Table

The accounting table includes entries indexed by task and effect class.

A representative entry comprises:

TaskID = TASK-204.

EffectClass = NETWORK_TX_BYTES.

BudgetLimit = 1,048,576.

ReservedOutstanding = 262,144.

CompletedEffects = 524,288.

AuthorityGeneration = 17.

AccountingGeneration = 301.

The values are illustrative quantities in bytes.

7.6.23. C-76.19 - Effect Quantity Estimator

An Effect Quantity Estimator determines an estimated or bounded resource-effect quantity associated with a command.

It may examine:

1. Command type. 2. Descriptor length. 3. Number of scatter-gather entries. 4. Transfer size. 5. Maximum permitted repetitions. 6. Destination count. 7. Accelerator output size. 8. Storage block count. 9. Resource operation cardinality. 10. Queue execution parameters.

The admission decision uses a bound sufficient for the selected enforcement guarantee.

7.6.24. C-76.20 - Atomic Reservation Engine

An Atomic Reservation Engine coordinates admission against the protected budget table.

It implements an indivisible operation that:

1. Reads the applicable budget state. 2. Verifies available capacity. 3. Adds the required reservation. 4. Records the command reservation association. 5. Commits the updated accounting generation.

Only successful reservation permits queue admission.

7.6.25. C-76.21 - Effect-Capable Queue

An Effect-Capable Queue contains commands that the hardware may execute.

Examples include:

NIC transmit rings.

DMA submission queues.

Storage operation queues.

Accelerator work queues.

Peripheral command rings.

The queue may have multiple producers and execution engines.

7.6.26. C-76.22 - Command-Execution Controller

The Command-Execution Controller determines whether a submitted command is admitted, executed, deferred, canceled, or rejected.

It ensures that a command does not bypass the reservation requirement.

7.6.27. C-76.23 - Hardware Completion Observer

A Hardware Completion Observer identifies authoritative evidence of resource effectuation or command completion.

Possible sources include:

(a) device completion records;

(b) hardware byte counters;

(c) DMA transaction completion state;

(d) storage-controller acknowledgments;

(e) protected queue ownership transitions;

(f) accelerator execution completion records;

(g) resource-specific effect counters.

The observation must correspond to the defined effect boundary.

7.6.28. C-76.24 - Completion-Reconciliation Engine

The Completion-Reconciliation Engine updates protected accounting following:

COMPLETION.

PARTIAL_COMPLETION.

VERIFIED_CANCELLATION.

FAILURE.

INDETERMINATE_EXECUTION.

QUEUE_RECOVERY.

It distinguishes quantities already effected from quantities that remain capable of future effectuation.

7.6.29. C-76.25 - Delegation-Accounting Controller

The Delegation-Accounting Controller associates subordinate execution contexts with an originating task budget.

The mechanism may maintain:

ParentTaskID.

ChildExecutionContextID.

DelegationGeneration.

SharedBudgetReference.

PermittedEffectClasses.

DelegationStatus.

7.6.30. C-76.26 - Recovery and Queue-Continuity Controller

A Recovery Controller coordinates:

1. Host restart. 2. Device reset. 3. Queue reconstruction. 4. Controller failover. 5. VM migration. 6. Persisted budget recovery. 7. Outstanding command identification. 8. Prior reservation reconciliation. 9. Stale submission prevention.

7.6.31. C-76.27 - Protected Configuration Authority

A Protected Configuration Authority establishes authorized task budgets and effect classes.

It may be a privileged host service, trusted firmware control path, device management service, or another authenticated budget-provisioning authority.

The agent cannot arbitrarily increase its own budget by writing to the accounting table.

7.6.32. PART IV - TRUST AND ENFORCEMENT BOUNDARIES

7.6.33. C-76.28 - Host-Controller Separation

The host may generate arbitrary commands.

The admission controller determines whether the commands may enter the governed effectcapable queue.

The host does not obtain unrestricted write access to:

(a) budget limits; (b) reserved counters; (c) completed counters; (d) command-reservation identities; (e) delegation accounting; (f) accounting generations; or (g) recovery state.

7.6.34. C-76.29 - Meaning of Hardware Protection

The phrase hardware-protected accounting may refer to an implementation in which:

1. Device firmware controls table modification. 2. Memory regions are inaccessible to unauthorized host contexts. 3. A trusted controller mediates counter updates. 4. Hardware access-control registers restrict writes. 5. Protected SRAM or device-local memory stores accounting state. 6. An appropriately isolated management processor maintains authoritative counters.

The required protection is against unauthorized alteration by the agent and relevant lesstrusted host execution contexts.

The enforcement point does not require all implementations to use the same secure-memory technology.

7.6.35. C-76.30 - Host-Controlled Descriptor Risk

A command descriptor may contain a claimed TaskID.

If the host can freely substitute another task's identity, it may evade the intended budget.

The controller therefore uses an authenticated or protected context-to-task association.

Possible bindings include:

(a) device submission queue identity; (b) PASID-associated process context; (c) virtual-function identity;

(d) protected queue ownership;

(e) host-authenticated control-plane assignment;

(f) device-local execution context;

(g) another enforced task mapping.

7.6.36. C-76.31 - Device Queue Isolation

The controller must prevent commands from entering an effect-capable queue outside its admission path where that queue falls within the claimed governed effect domain.

For example, a network device with several transmit rings may require common budget enforcement across the relevant rings.

A reservation mechanism protecting only one ring does not automatically govern another unrestricted ring.

7.6.37. C-76.32 - Multiple Physical Paths

A task may have access to:

NIC A.

NIC B.

DMA engine C.

An application-specific command interface D.

The budget controller must define which paths contribute to the protected aggregate.

Where a shared budget governs several physical paths, appropriate cross-controller accounting or disjoint allocated sub-budgets are required.

A controller cannot guarantee a global effect cap if material uncontrolled alternative paths remain available.

7.6.38. PART V - TASK AND DELEGATION IDENTITY

7.6.39. C-76.33 - Root Task Identity

A Root Task ID identifies the original AI-agent task whose resource effects are governed.

For example:

RootTaskID = TASK-204.

The identifier is allocated or authenticated by the trusted task-control authority.

7.6.40. C-76.34 - Execution Context Identity

An Execution Context may represent:

1. A process. 2. A thread group. 3. A container. 4. A virtual machine. 5. A GPU context. 6. A NIC queue owner. 7. A delegated worker. 8. A device virtual function.

Each context receives an association with its authorized task.

7.6.41. C-76.35 - Parent-Child Delegation

A representative delegation structure is:

ROOT TASK-204

→ PROCESS-A

→ WORKER-B

and:

ROOT TASK-204

→ PROCESS-C

→ ACCELERATOR-QUEUE-D.

Commands submitted by these descendants contribute to the applicable root budget.

7.6.42. C-76.36 - Delegation Does Not Reset Exposure

Creating a new descendant execution context does not automatically create additional effectbudget capacity.

The delegated context either:

(a) consumes the shared root budget directly; or (b) receives a bounded sub-budget deducted from an ancestor's available capacity.

7.6.43. C-76.37 - Shared Root-Budget Model

In a shared-budget implementation:

All governed descendant commands use the same protected accounting entry.

For example:

TaskID = TASK-204.

BudgetClass = NETWORK_TX_BYTES.

The budget table stores one shared reservation and completed-effect state.

7.6.44. C-76.38 - Sub-Budget Allocation Model

A trusted controller may allocate:

Root Budget = 1,000 units.

Worker A Sub-Budget = 300.

Worker B Sub-Budget = 200.

Unallocated Root Headroom = 500.

The allocation must prevent a sub-budget from being spent independently while remaining available for unrestricted root-level admission.

Unused sub-budget capacity may be returned only under the required reconciliation and revocation conditions.

7.6.45. C-76.39 - Delegation Identity Substitution

A subordinate worker may attempt to submit a command using a different TaskID.

The admission controller verifies that the submission context is authorized for the claimed task.

A command carrying an unsupported task identity is rejected.

7.6.46. PART VI - EFFECT-QUANTITY ESTIMATION

7.6.47. C-76.40 - Command Effect Quantity

Each command receives a bounded exposure quantity q.

For example:

Network transmit command: up to 8,192 bytes.

Storage write command: up to 16 blocks.

DMA command: up to 4,096 destination bytes.

The quantity is expressed in the selected effect unit.

7.6.48. C-76.41 - Precise Versus Conservative Bounds

A command may have a precisely known maximum effect.

Alternatively, its exact effect may depend on runtime conditions.

The estimator may reserve a conservative upper bound.

For example:

A descriptor permits a maximum of 64 KiB transfer.

The actual transfer may be smaller.

The controller reserves 64 KiB unless the hardware admission path can enforce a lower bound.

7.6.49. C-76.42 - Unbounded Command

Some commands may repeat without an established maximum effect quantity.

If no bounded exposure can be established, the controller may:

1. Reject the command. 2. Split it into bounded subcommands. 3. Apply a hardware effect meter that gates further execution. 4. Require additional reservation. 5. Use another verifiably bounded execution arrangement.

It must not reserve an arbitrarily small estimate while permitting unbounded effectuation.

7.6.50. C-76.43 - Scatter-Gather Descriptors

A DMA or network command may contain multiple scatter-gather segments.

The estimator calculates a bound over the segments.

For example:

Segment 1 = 4,096 bytes.

Segment 2 = 2,048 bytes.

Segment 3 = 1,024 bytes.

Total bounded payload = 7,168 bytes.

The implementation may account separately for protocol overhead or physical transmitted bytes depending upon the selected effect definition.

7.6.51. C-76.44 - Device-Generated Expansion

A hardware engine may expand a compact command into several lower-level operations.

The estimator must consider the maximum resulting effect quantity.

For example:

One accelerator command may generate multiple DMA writes.

The budget applies to the aggregate covered effect, not merely to the number of original host descriptors.

7.6.52. C-76.45 - Variable Effect Cardinality

A command may contain a loop or repetition parameter.

The estimator may calculate:

MaximumEffect = MaxIterations × MaximumEffectPerIteration,

subject to checked arithmetic and valid execution bounds.

Overflow, undefined iteration limits, or unsupported arithmetic causes restriction rather than under-reservation.

7.6.53. C-76.46 - Effect Boundary Definition

The effect class determines when quantity is charged as completed.

Examples:

NETWORK_TX_BYTES: bytes accepted through the defined protected transmit boundary.

DMA_WRITE_BYTES: bytes confirmed written to the target memory domain.

STORAGE_WRITE_BLOCKS: blocks satisfying the selected storage-controller completion semantics.

ACCELERATOR_OUTPUT_BYTES: bytes confirmed committed to the designated output domain.

The implementation must not enforcement point remote delivery or persistence stronger than the underlying completion evidence establishes.

7.6.54. PART VII - HARDWARE-PROTECTED EFFECT-ACCOUNTING TABLE

7.6.55. C-76.47 - Table Schema

A representative protected entry comprises:

BudgetEntryID.

RootTaskID.

EffectClass.

BudgetLimit.

ReservedOutstanding.

CompletedEffects.

AuthorityGeneration.

AccountingGeneration.

ActiveQueueReferences.

RecoveryState.

7.6.56. C-76.48 - Example Table

7.6.57. Task Effect class Limit Reserved Completed Remaining 

| TASK-A Network KiB | 1,024 | 256 | 512   | 256 |
| ------------------ | ----- | --- | ----- | --- |
| TASK-A DMA KiB     | 512   | 64  | 128   | 320 |
| TASK-B Network KiB | 2,048 | 512 | 1,024 | 512 |

The quantities are illustrative.

Remaining is calculated as:

Limit - Reserved - Completed.

7.6.58. C-76.49 - Per-Command Reservation Record

A representative record comprises:

CommandID = CMD-7601.

RootTaskID = TASK-204.

EffectClass = NETWORK_TX_BYTES.

InitialReservation = 8,192.

CompletedQuantity = 0.

RemainingReservation = 8,192.

QueueID = TXQ-3.

AdmissionGeneration = 301.

Status = ADMITTED.

7.6.59. C-76.50 - Protected Counter Update

The controller updates reserved and completed quantities under an atomic or otherwise appropriately serialized operation.

Host-controlled counter writes are not accepted as authoritative.

7.6.60. C-76.51 - Budget Provisioning

A trusted management authority establishes:

AuthorizedEffectClass.

BudgetLimit.

TaskIdentity.

ExpirationOrAccountingInterval.

DelegationRules.

The table may have one or more budget generations.

7.6.61. C-76.52 - Budget Epoch

A Budget Epoch defines the accounting period or authority generation for a task.

Commands remain associated with the epoch under which they were admitted.

The controller does not permit an old command to reuse capacity from a newly restored or improperly reset epoch.

7.6.62. C-76.53 - Budget Increase

An authorized controller may increase a budget limit.

The increase requires a protected configuration transition.

The AI workload cannot obtain an increase merely by creating another queue or resetting a process.

7.6.63. C-76.54 - Budget Reduction

An authorized controller may reduce an effect-budget limit.

If existing completed and reserved quantities exceed the new limit, the controller restricts new admissions.

The treatment of outstanding commands is governed by the selected revocation or cancellation policy.

A budget reduction does not retroactively undo completed effects.

7.6.64. PART VIII - ATOMIC ADMISSION

7.6.65. C-76.55 - Reservation Before Queue Visibility

A command may be staged in host memory.

The controller obtains or reconstructs its effect descriptor and quantity.

It atomically reserves capacity.

Only afterward may the command become visible to the executing hardware queue.

7.6.66. C-76.56 - Admission Transaction

A representative admission operation performs:

1. Authenticate task context. 2. Validate effect class. 3. Determine effect bound. 4. Read protected budget. 5. Check headroom. 6. Atomically reserve effect capacity. 7. Create command reservation record. 8. Publish the command to the effect-capable queue.

The reservation and queue publication order must prevent execution before the reservation becomes authoritative.

7.6.67. C-76.57 - Admission Failure

If insufficient capacity exists:

CommandStatus = DENIED.

No reservation is committed.

The command is not admitted to the governed effect-capable queue.

7.6.68. C-76.58 - Atomic Compare-and-Update

The reservation mechanism may use:

(a) device-local compare-and-swap; (b) protected atomic fetch-and-add with validation; (c) a serialized admission processor; (d) a transaction-capable protected controller; (e) a lock-based protected table update; (f) another equivalent atomic operation.

The implementation must prevent concurrent over-admission.

7.6.69. C-76.59 - Reservation Publication Barrier

A reservation may commit before the device receives the command.

If queue publication fails, the controller must reconcile the reservation.

It may release the capacity only after establishing that the command did not become executable through the governed queue or any relevant duplicate path.

7.6.70. C-76.60 - Duplicate Submission Identity

A host may submit the same command several times.

The controller distinguishes:

1. Duplicate representation of one command. 2. A legitimate retry. 3. Multiple independently executable commands.

A repeated CommandID does not automatically authorize new effectuation using the old reservation.

7.6.71. PART IX - COMPLETION ACCOUNTING

7.6.72. C-76.61 - Full Completion

A command reserved q units.

The hardware confirms that q units reached the defined effect boundary.

The controller updates:

ReservedOutstanding := ReservedOutstanding - q.

CompletedEffects := CompletedEffects + q.

The total charged quantity remains unchanged.

7.6.73. C-76.62 - Partial Completion

A command reserved q units.

The hardware confirms p units effected.

Where 0 ≤ p ≤ q:

ReservedOutstanding := ReservedOutstanding - p.

CompletedEffects := CompletedEffects + p.

The remaining reservation equals:

q - p.

No budget headroom is created merely by transferring a charged quantity from reserved to completed.

7.6.74. C-76.63 - Example Partial Transfer

Initial command reservation:

100 KiB.

Actual confirmed transfer:

40 KiB.

After reconciliation:

Completed = 40 KiB.

Outstanding reservation = 60 KiB.

The total charged quantity remains 100 KiB.

7.6.75. C-76.64 - Verified Cancellation of Remaining Portion

Suppose the controller proves that the remaining 60 KiB can no longer be transmitted.

It may then release 60 KiB of outstanding reservation.

Final command accounting:

Completed = 40 KiB.

Outstanding = 0.

Released unused capacity = 60 KiB.

The completed 40 KiB remains charged.

7.6.76. C-76.65 - Partial Cancellation Without Complete Evidence

Suppose a device reports cancellation but cannot establish how many bytes already crossed the effect boundary.

| The controller may retain the uncertain quantity as charged. It does not automatically release the entire reservation.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.66 - Completion Greater Than Reservation A hardware command must not be allowed to produce a governed effect quantity exceeding its reservation without corresponding authorized additional capacity. An implementation may: 1. Enforce descriptor length bounds. 2. Split commands into separately reserved segments. 3. Stop effectuation before the bound is exceeded. 4. Obtain additional reservation before proceeding. A completion report exceeding the reserved quantity indicates a serious invariant violation or measurement failure and must not merely decrement counters into an invalid state. |
| C-76.67 - Failed Command A command may fail before effectuation. If the controller establishes that no portion can subsequently execute, the entire reservation may be released. If the command failed after partial effectuation, only the verified non-effected remainder may be released.                                                                                                                                                                                                                                                                                                                        |

7.6.77. C-76.68 - Device Completion Semantics

A completion acknowledgment may refer to:

(a) descriptor consumption; (b) DMA completion; (c) internal queue retirement; (d) remote acknowledgment; (e) persistent storage commit.

The controller must use the evidence appropriate to the defined effect class.

Descriptor retirement alone does not necessarily prove that a remote service received or durably stored a transmitted payload.

7.6.78. PART X - COMMAND CANCELLATION

7.6.79. C-76.69 - Cancellation Request State

A command may enter:

CANCEL_REQUESTED.

This state alone does not release its reservation.

7.6.80. C-76.70 - Execution Fence

A hardware cancellation may require an execution fence that prevents the remaining command portion from reaching the effect boundary.

For example:

1. Stop queue dispatch. 2. Revoke descriptor ownership. 3. Wait for in-flight DMA completion. 4. Drain applicable pipeline stages. 5. Determine completed quantity.

6. Confirm remaining work is non-executable.

The actual fence procedure depends upon the device.

7.6.81. C-76.71 - Queue Ownership

A command may have moved from one queue to another.

The controller must identify all relevant execution locations before declaring the command canceled.

Canceling only the original queue entry is insufficient if an alternate execution path remains active.

7.6.82. C-76.72 - Late Completion

A completion event may arrive after a cancellation request.

|                                                                                                                                                                                                                                                                          |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The controller reconciles it against the existing reservation. The completed portion remains charged.                                                                                                                                                                    |
| C-76.73 - Cancellation Race A cancellation request and completion event may occur concurrently. The protected command state machine serializes their accounting effects. The same quantity is not simultaneously released and charged through inconsistent transactions. |
| C-76.74 - No Double Refund A command may receive duplicate cancellation acknowledgments. The controller uses the protected CommandID and accounting generation to prevent repeated release of the same reserved capacity.                                                |

7.6.83. PART XI - NETWORK, SMARTNIC, DPU, AND DMA IMPLEMENTATIONS

7.6.84. C-76.75 - Programmable NIC Admission

A programmable NIC may intercept transmit descriptors before hardware transmission.

The NIC associates each descriptor with a protected task context.

It reserves the applicable transmission budget before making the descriptor eligible for transmission.

7.6.85. C-76.76 - SmartNIC Implementation

A SmartNIC may maintain:

Task budget entries.

Per-queue command identities.

Reservation counters.

Completion counters.

Queue-generation state.

Protected cancellation status.

Its embedded control processor may coordinate accounting across several hardware transmit queues.

7.6.86. C-76.77 - DPU Implementation

A DPU may host the admission controller independently of the AI agent's CPU process.

The DPU receives command submissions from one or more host contexts.

It enforces a shared originating task budget before allowing the relevant network or storage operation.

7.6.87. C-76.78 - DMA Controller Implementation

A DMA controller may regulate memory-copy or peripheral transfer descriptors.

The estimator determines a bounded quantity based upon destination range, transfer length, repetition parameters, and effect class.

The command is admitted only after the corresponding reservation.

| C-76.79 - IOMMU-Associated Protection An IOMMU may provide address translation and isolation. However, ordinary IOMMU address translation does not inherently implement effect-budget accounting. A claimed IOMMU-associated embodiment therefore includes a separate admission or command-metering function that actually maintains and enforces the protected budget state.                       |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.80 - Accelerator Queue Implementation An accelerator command may produce persistent resource changes, DMA transfers, or external device operations. The command admission controller calculates a bounded effect quantity. Where the effect size cannot be established before execution, the accelerator may require segmented or continuously metered execution under protected reservations. |
| C-76.81 - SR-IOV and Virtual Functions Several virtual functions may submit commands to a shared physical NIC. The controller associates their queues with the same originating task when appropriate. The shared budget is enforced across the relevant functions. Assigning a new virtual function must not reset the root task's accumulated exposure.                                           |

7.6.88. C-76.82 - Host Process Aggregation

Two host processes may submit commands through separate rings.

The protected task association maps both to:

RootTaskID = TASK-204.

Both consume the same budget entry.

This implements a principal feature of enforcement point(s) 77.

7.6.89. PART XII - HARDWARE RESET AND RECOVERY

7.6.90. C-76.83 - Persisted Budget State

A controller may maintain durable or recoverable records of:

1. Current budget epoch. 2. Completed quantity. 3. Outstanding reserved quantity. 4. Active command identities. 5. Queue associations. 6. Reservation generations. 7. Delegation context. 8. Recovery status.

The persistence mechanism must support the selected reset and failure guarantees.

7.6.91. C-76.84 - Host Restart

Following a host restart, previously admitted device commands may remain active.

The controller does not rebuild its budget solely from the restarted host's empty software queue state.

It reconciles against device-resident command and effect state.

7.6.92. C-76.85 - Device Controller Reset

A device reset may destroy volatile queue state.

The recovery mechanism determines whether:

(a) all commands were definitively aborted; (b) some effects completed; (c) in-flight effects remain uncertain; (d) another engine retained executable work; or (e) a standby controller may complete the commands.

Budget capacity is not released without the required evidence.

7.6.93. C-76.86 - VM Snapshot Restoration

A VM may restore an old software descriptor queue.

The protected accounting table remains associated with the current budget generation.

Replayed descriptors carrying obsolete submission generations are rejected or reconciled.

The restored VM cannot obtain an earlier unused budget balance merely by reverting its own memory.

7.6.94. C-76.87 - VM Migration

A task may migrate to another host or device.

The system transfers or reestablishes:

RootTaskID.

BudgetGeneration.

CompletedEffects.

OutstandingReservations.

LiveCommandReferences.

DelegationState.

The migration procedure must prevent simultaneous unrestricted command execution under the same full budget on both source and destination devices.

7.6.95. C-76.88 - Source Device Fencing

Before destination activation under a transferred shared budget, the system may fence the source execution domain.

| It verifies that relevant commands cannot continue independently without accounting. Where source commands remain executable, their reservations stay charged.                                                                                                                                                                                                                        |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.89 - Queue Failover A command may be copied to a standby queue. The controller records whether the copy represents: (a) the same logical command with only one permitted execution; or (b) an independently executable duplicate. A failover mechanism that permits both copies to execute must reserve sufficient possible effect quantity or enforce single-execution fencing. |
| C-76.90 - Recovery Epoch A Recovery Epoch identifies the current controller state after restart or failover. Previously released reservations cannot be reused to authorize commands still executable under an older epoch. A monotonic or otherwise rollback-resistant generation mechanism may be employed.                                                                         |

7.6.96. C-76.91 - Uncertain Outstanding Commands

When authoritative queue state is unavailable, the controller may retain the associated reservation.

The command remains classified:

INDETERMINATE.

It cannot be treated as canceled merely because the host no longer recognizes it.

7.6.97. C-76.92 - Recovery Accounting Reconciliation

A representative reconciliation compares:

PersistedBudgetState.

CurrentHardwareQueueState.

CompletionRecords.

KnownCancellationFences.

DelegatedQueueReferences.

FailoverExecutionState.

The controller constructs a conservative current accounting representation before resuming admissions.

7.6.98. PART XIII - COMPLETE 40-STEP WORKFLOW

7.6.99. C-76.93 - Principal Execution Workflow

7.6.100. Step C76-01 - Task identity establishment

Establish an authenticated root task context.

7.6.101. Step C76-02 - Budget-policy retrieval

Obtain the task's authorized effect classes and limits.

7.6.102. Step C76-03 - Hardware budget provisioning

Initialize or locate protected accounting entries.

7.6.103. Step C76-04 - Execution-context association

Bind the host process, worker, or queue to the root task.

7.6.104. Step C76-05 - Delegation verification

Validate applicable descendant task associations.

7.6.105. Step C76-06 - Command generation

The AI workload or delegated component produces a resource-operation command.

7.6.106. Step C76-07 - Command staging

Hold the command outside the effect-capable queue.

7.6.107. Step C76-08 - Submission context authentication

Verify the originating hardware submission context.

7.6.108. Step C76-09 - Root budget identification

Resolve the applicable shared or delegated budget.

7.6.109. Step C76-10 - Effect-class classification

Identify the command's governed resource-effect class.

7.6.110. Step C76-11 - Descriptor validation

Validate lengths, pointers, operation type, and other relevant fields.

7.6.111. Step C76-12 - Effect-bound estimation

Calculate a bounded possible effect quantity.

7.6.112. Step C76-13 - Bound adequacy verification

Confirm that the controller can enforce the declared maximum.

7.6.113. Step C76-14 - Protected budget read

Obtain reserved, completed, and authorized quantities.

7.6.114. Step C76-15 - Capacity evaluation

Determine whether the new command fits within available headroom.

7.6.115. Step C76-16 - Atomic reservation

Increase the outstanding reserved quantity under protected serialization.

7.6.116. Step C76-17 - Reservation record commitment

Bind the reservation to the command and accounting generation.

7.6.117. Step C76-18 - Queue publication

Make the reserved command eligible for hardware execution.

7.6.118. Step C76-19 - Admission outcome recording

Record admitted or rejected status.

7.6.119. Step C76-20 - Hardware execution

The command executes within the governed resource interface.

7.6.120. Step C76-21 - Effect-bound enforcement

Prevent execution beyond the reserved exposure.

7.6.121. Step C76-22 - Completion observation

Obtain authoritative progress or completion information.

7.6.122. Step C76-23 - Partial effect quantification

Determine the confirmed completed quantity.

7.6.123. Step C76-24 - Protected reconciliation

Transfer completed quantity from reserved to completed accounting.

7.6.124. Step C76-25 - Remaining reservation retention

Retain reserved capacity for work that may still execute.

7.6.125. Step C76-26 - Cancellation request handling

Accept cancellation requests without premature release.

7.6.126. Step C76-27 - Execution fencing

Establish whether remaining command work is non-executable.

7.6.127. Step C76-28 - Verified cancellation accounting

Release only the verifiably canceled remainder.

7.6.128. Step C76-29 - Duplicate-event control

Prevent repeated accounting for completion or cancellation reports.

7.6.129. Step C76-30 - Delegated-work aggregation

Charge descendant effects against the applicable root budget.

7.6.130. Step C76-31 - Host restart detection

Identify restarted host or execution context.

7.6.131. Step C76-32 - Controller reset detection

Identify hardware accounting or queue continuity events.

7.6.132. Step C76-33 - Recovery epoch establishment

Create or verify the protected recovery generation.

7.6.133. Step C76-34 - Queue inventory reconstruction

Identify outstanding commands in all relevant execution paths.

7.6.134. Step C76-35 - Persisted state reconciliation

Compare queued commands and completed effects with protected budget state.

7.6.135. Step C76-36 - Alternate-path fencing

Prevent duplicate execution under stale or transferred reservations.

7.6.136. Step C76-37 - Recovery accounting commitment

Record the reconciled protected budget.

7.6.137. Step C76-38 - Current invariant verification

Confirm completed plus reserved exposure does not exceed the authorized limit.

7.6.138. Step C76-39 - Admission resumption

Resume new queue admissions when the required state is consistent.

7.6.139. Step C76-40 - Audit and continuity recording

Retain accounting, delegation, execution, and recovery references.

7.6.140. PART XIV - REFERENCE IMPLEMENTATION ALGORITHMS

7.6.141. C-76.94 - Algorithm A: Protected Task-Context Resolution 

function ResolveProtectedTaskContext(submission):
queue_context = DeviceQueueRegistry.get(
submission.queue_id
)
if queue_context is unavailable:
return DENIED
authenticated_owner = VerifyQueueOwner(
queue_context,
submission
)
if authenticated_owner is invalid:
return DENIED
task_binding = ProtectedTaskRegistry.lookup(
authenticated_owner,
queue_context
)
if not VerifyCurrentTaskBinding(task_binding):
return DENIED
root_task = ResolveOriginatingTask(
task_binding
)
return root_task

The controller does not rely solely upon an untrusted host-supplied TaskID.

7.6.142. C-76.95 - Algorithm B: Effect-Quantity Estimation 

function EstimateBoundedEffect(command, effect_class):
if not VerifyCommandDescriptor(command):
return INVALID
if effect_class == NETWORK_TX_BYTES:
bound = ComputeMaximumTransmittableBytes(command)
else if effect_class == DMA_WRITE_BYTES:
bound = ComputeMaximumDMAWriteLength(command)
else if effect_class == STORAGE_WRITE_BLOCKS:
bound = ComputeMaximumStorageBlockWrites(command)
else if effect_class == ACCELERATOR_OUTPUT_BYTES:
bound = ComputeMaximumAcceleratorOutput(command)
else:
bound = ResolveRegisteredEffectBound(
command,
effect_class
)
if bound is UNKNOWN or UNBOUNDED:
return REQUIRES_BOUNDED_SEGMENTATION
if not CheckedNonnegativeInteger(bound):
return INVALID
if not HardwareCanEnforceEffectBound(command, bound):
return INVALID
return bound

An estimator must not reserve a value smaller than the supported maximum effect quantity.

7.6.143. C-76.96 - Algorithm C: Atomic Hardware Queue Admission 

function AdmitHardwareCommand(command, submission):
task = ResolveProtectedTaskContext(submission)
if task is invalid:
return DENIED
effect_class = ClassifyResourceEffect(command)
quantity = EstimateBoundedEffect(
command,
effect_class
)
if quantity is invalid:
return DENIED
entry = ProtectedBudgetTable.lookup(
task.root_id,
effect_class
)
begin protected_atomic_update(entry)
if entry.status != ACTIVE:
abort
return DENIED
if entry.completed +
entry.reserved +
quantity > entry.limit:
abort
return BUDGET_EXHAUSTED
command_id = AllocateProtectedCommandID()
entry.reserved += quantity
ReservationTable.insert({
command_id: command_id,
root_task: task.root_id,
effect_class: effect_class,
initial_quantity: quantity,
remaining_quantity: quantity,
completed_quantity: 0,
admission_generation: entry.generation,
status: RESERVED_NOT_PUBLISHED
})
commit protected_atomic_update
if not PublishToProtectedExecutionQueue(
command_id,
command
):
ReconcileFailedPublication(command_id)
return ADMISSION_INCOMPLETE
return ADMITTED

Publication occurs only after protected reservation.

7.6.144. C-76.97 - Algorithm D: Protected Budget Invariant Check 

function VerifyBudgetInvariant(entry):
if entry.limit < 0:
return INVALID
if entry.completed < 0:
return INVALID
if entry.reserved < 0:
return INVALID
if ArithmeticOverflowDetected(entry):
return INVALID
if entry.completed + entry.reserved > entry.limit:
return VIOLATION
return VALID

Checked arithmetic is necessary where counters have bounded representations.

7.6.145. C-76.98 - Algorithm E: Partial Completion Reconciliation 

function ReconcilePartialCompletion(
command_id,
hardware_completion
):
if not VerifyHardwareCompletionEvidence(
hardware_completion
):
return DENIED
record = ReservationTable.get(command_id)
begin protected_atomic_update(
record,
ProtectedBudgetTable[record.root_task,
record.effect_class]
)
newly_completed = DetermineNewlyConfirmedQuantity(
record,
hardware_completion
)
if newly_completed < 0:
abort
return INVALID
if newly_completed > record.remaining_quantity:
abort
return ACCOUNTING_VIOLATION
record.completed_quantity += newly_completed
record.remaining_quantity -= newly_completed
budget.completed += newly_completed
budget.reserved -= newly_completed
AdvanceAccountingGeneration(record, budget)
commit protected_atomic_update
return RECONCILED

The quantity transferred from reserved to completed remains charged against the budget.

7.6.146. C-76.99 - Algorithm F: Verified Cancellation 

function CancelHardwareCommand(command_id):
record = ReservationTable.get(command_id)
if record is unavailable:
return DENIED
MarkCancelRequested(record)
fence = RequestHardwareExecutionFence(command_id)
if not VerifyFenceCompletion(fence):
return CANCELLATION_UNCONFIRMED
progress = QueryAuthoritativeEffectProgress(
command_id
)
if progress is UNKNOWN:
return CANCELLATION_UNCONFIRMED
ReconcilePartialCompletion(
command_id,
progress
)
remaining = ReservationTable.get(
command_id
).remaining_quantity
if not VerifyCommandCannotCompleteElsewhere(
command_id
):
return CANCELLATION_UNCONFIRMED
begin protected_atomic_update
budget.reserved -= remaining
record.remaining_quantity = 0
record.status = CANCELED_VERIFIED
MarkReservationReleasedExactlyOnce(
command_id
)
commit protected_atomic_update
return CANCELED_VERIFIED

A cancellation request does not itself release the reservation.

7.6.147. C-76.100 - Algorithm G: Shared Delegated Budget 

function AdmitDelegatedCommand(
descendant_context,
command
):
delegation = ProtectedDelegationRegistry.get(
descendant_context
)
if not VerifyDelegationGeneration(delegation):
return DENIED
root_task = delegation.root_task_id
if not VerifyCommandWithinDelegatedScope(
command,
delegation
):
return DENIED
return AdmitHardwareCommand(
command,
BuildAuthenticatedSubmissionContext(
descendant_context,
root_task
)
)

The delegated worker does not receive a new unrestricted root budget.

7.6.148. C-76.101 - Algorithm H: Cross-Queue Atomic Coordination 

function ReserveAcrossSharedQueues(
root_task,
effect_class,
quantity,
queue_id
):
entry = ProtectedBudgetTable.lookup(
root_task,
effect_class
)
lock(entry)
try:
if entry.completed +
entry.reserved +
quantity > entry.limit:
return DENIED
entry.reserved += quantity
reservation_id = CommitQueueReservation({
task: root_task,
queue: queue_id,
quantity: quantity,
generation: entry.generation
})
return reservation_id
finally:
unlock(entry)

All relevant queues use the same protected accounting serialization point or an equivalent coordinated mechanism.

C-76.102 - Algorithm I: Completion and Cancellation Race Resolution

function ApplyCommandStateEvent(command_id, event):
record = ReservationTable.lock(command_id)
if EventAlreadyApplied(record, event.id):
unlock(record)
return DUPLICATE
if record.status == CANCELED_VERIFIED:
if event reports new effect:
RaiseProtectedConsistencyFailure()
unlock(record)
return VIOLATION
if event.type == EFFECT_PROGRESS:
result = ReconcileVerifiedProgress(record, event)
else if event.type == CANCELLATION_ACK:
result = EvaluateAuthoritativeCancellation(
record,
event
)
else:
result = APPLY_SUPPORTED_STATE_EVENT
MarkEventApplied(record, event.id)
unlock(record)
return result

Events are applied exactly once to the protected accounting state.

7.6.149. C-76.103 - Algorithm J: Host Restart Recovery 

function RecoverAfterHostRestart(task_id):
SuspendNewAdmissions(task_id)
persisted = ProtectedBudgetStore.readCurrent(task_id)
device_queues = EnumerateAuthoritativeDeviceQueues(
task_id
)
reconciled = ReconcileCommandReservations(
persisted,
device_queues,
HardwareCompletionHistory()
)
if reconciled is INCOMPLETE:
KeepAffectedReservationsCharged(task_id)
return RECOVERY_RESTRICTED
if not VerifyBudgetInvariant(reconciled):
return RECOVERY_FAILED
CommitRecoveredBudgetGeneration(reconciled)
ResumeAdmissions(task_id)
return RECOVERED

The restarted host's software queue state is not treated as the sole source of authoritative outstanding-command information.

7.6.150. C-76.104 - Algorithm K: Controller Reset Recovery 

function RecoverAfterControllerReset(controller_id):
BlockEffectCapableQueueAdmissions(controller_id)
generation = AdvanceRecoveryEpoch(controller_id)
persisted = RecoverProtectedAccountingState(
controller_id
)
outstanding = DiscoverSurvivingExecutableCommands(
controller_id
)
remote = QueryApplicableFailoverExecutionPaths(
controller_id
)
reconciled = ConservativeMerge(
persisted,
outstanding,
remote
)
if not CanEstablishSafeCommandContinuity(reconciled):
RetainConservativeReservations(reconciled)
return RESTRICTED_RECOVERY
CommitRecoveredState(
reconciled,
generation
)
return READY_FOR_VERIFIED_ADMISSION

A device reset does not itself prove that all prior effects are canceled.

7.6.151. C-76.105 - Algorithm L: VM Migration with Budget Fencing 

function MigrateTaskBudget(
task_id,
source_controller,
target_controller
):
SuspendNewAdmissions(task_id)
source_state = CaptureProtectedBudgetState(
source_controller,
task_id
)
fence = FenceSourceTaskQueues(
source_controller,
task_id
)
if not VerifySourceFenceOrRetainReservations(fence):
return MIGRATION_RESTRICTED
new_epoch = AllocateProtectedMigrationGeneration()
transferred = TransferAuthenticatedBudgetState({
task_id: task_id,
completed: source_state.completed,
reserved: source_state.reserved,
live_commands: source_state.live_commands,
generation: new_epoch
})
if not VerifyTransferredAccounting(
transferred,
target_controller
):
return MIGRATION_FAILED
ActivateTargetUnderTransferredBudget(
target_controller,
transferred
)
return MIGRATED

The migration must not create independently spendable copies of the same budget.

7.6.152. C-76.106 - Algorithm M: Queue Failover Duplicate Prevention 

function AdmitFailoverCommand(
original_command_id,
standby_queue
):
original = ReservationTable.get(
original_command_id
)
if original is unavailable:
return DENIED
if not VerifyAuthorizedFailoverTransition(
original,
standby_queue
):
return DENIED
if not VerifyOriginalExecutionFenced(
original_command_id
):
if not CanReserveBothPossibleExecutions(
original,
standby_queue
):
return DENIED
BindFailoverQueueToExistingOrExpandedReservation(
original,
standby_queue
)
return FAILOVER_ADMITTED

One reservation may authorize failover only where the device guarantees that the original and standby copies cannot independently produce more effect than the reserved amount.

7.6.153. C-76.107 - Algorithm N: Lost Completion Acknowledgment 

function ReconcileUnknownCommandOutcome(command_id):
record = ReservationTable.get(command_id)
observed = QueryAuthoritativeDeviceEffectState(
command_id
)
if observed == CONFIRMED_COMPLETED:
return ReconcileVerifiedCompletion(record)
if observed == CONFIRMED_NOT_EFFECTUABLE:
return ReleaseVerifiedUnusedReservation(record)
if observed == PARTIALLY_COMPLETED:
return ReconcilePartialCompletion(
record,
observed
)
MarkCommandIndeterminate(record)
RetainUnresolvedEffectQuantity(record)
return RECONCILIATION_REQUIRED

An unknown completion outcome does not create additional budget headroom.

7.6.154. C-76.108 - Algorithm O: Protected Budget Integrity Audit 

function AuditTaskEffectBudget(task_id):
budget_entries = ProtectedBudgetTable.getAll(task_id)
for each entry in budget_entries:
command_records = ReservationTable.query({
root_task: task_id,
effect_class: entry.effect_class
})
expected_reserved = SumRemainingReservations(
command_records
)
expected_completed = SumCompletedEffectCharges(
command_records,
AuthorizedBaselineAccounting(entry)
)
if expected_reserved != entry.reserved:
return ACCOUNTING_INCONSISTENCY
if expected_completed != entry.completed:
return ACCOUNTING_INCONSISTENCY
if not VerifyBudgetInvariant(entry):
return BUDGET_VIOLATION
return ACCOUNTING_CONSISTENT

The audit must handle durable history retention and accounted commands that have been archived or summarized.

7.6.155. PART XV - WORKED TECHNICAL EXAMPLES

7.6.156. C-76.109 - Example A: SmartNIC Network Byte Budget

The following is a hypothetical implementation example.

An AI agent receives a network egress budget of 1 MiB.

The agent has already transmitted 512 KiB.

Another 256 KiB is reserved for queued commands.

The remaining budget is 256 KiB.

A new 128 KiB command may be admitted.

A new 512 KiB command must be rejected or segmented under an appropriate bounded admission policy.

The protected counters are updated before the accepted command becomes eligible for transmission.

7.6.157. C-76.110 - Example B: Partial Network Transmission

A command reserves 100 KiB.

The NIC confirms transmission of 40 KiB.

Cancellation is requested.

The controller reconciles:

Completed = 40 KiB.

Remaining reserved = 60 KiB.

After authoritative fencing proves that the remaining 60 KiB cannot transmit, the controller releases only the 60 KiB.

The completed 40 KiB remains charged.

7.6.158. C-76.111 - Example C: Two Processes Sharing One Budget

An AI agent creates two worker processes.

Each submits network commands through a different transmit ring.

Both are associated with RootTask TASK-204.

The protected table maintains one shared network-effect budget.

Concurrent reservations are atomically serialized.

The workers cannot independently consume the same remaining capacity.

7.6.159. C-76.112 - Example D: NIC Virtual Functions

Two SR-IOV virtual functions are assigned to workloads delegated from the same AI task.

Each virtual function has a distinct submission context.

The hardware admission controller maps both to the root task.

Their queued and completed transmissions contribute to the shared effect-budget entry.

Creating another virtual function does not reset the task's budget.

7.6.160. C-76.113 - Example E: DMA Write Budget

An agent-controlled accelerator submits DMA writes to a designated output buffer.

The task's authorized DMA write budget is 256 KiB.

Before admitting a DMA command, the controller determines its maximum target-write length.

The bounded quantity is reserved.

A command exceeding remaining capacity is rejected or divided into smaller independently reserved segments.

C-76.114 - Example F: Accelerator Command Expansion

A host submits one accelerator command.

The accelerator may generate four DMA output transfers.

The command estimator determines that the total possible output is 128 KiB.

The controller reserves the aggregate 128 KiB before accepting the command into the effectcapable queue.

It does not reserve only one command count when the protected budget is defined in output bytes.

7.6.161. C-76.115 - Example G: Storage Partial Write

A storage command reserves sixteen blocks.

The controller confirms that ten blocks reached the specified storage effect boundary.

The device reports failure before the remaining six blocks complete.

The controller retains ten blocks as completed.

The remaining six blocks may be released only after the device establishes that they cannot subsequently be written.

The distinction between issued, acknowledged, and durable writes follows the selected storage effect definition.

7.6.162. C-76.116 - Example H: Cancellation During DMA

7.6.163. Execution

A DMA controller has accepted a descriptor for 64 KiB.

The host requests cancellation after the transfer begins.

The device confirms that 24 KiB was written.

The remaining transfer is fenced.

The controller records 24 KiB as completed and releases only the verified unused 40 KiB.

A cancellation acknowledgment without the necessary completion evidence would not justify releasing the entire reservation.

C-76.117 - Example I: Host Restart with Active Device Queue

An agent process queues network descriptors.

The host crashes before all descriptors complete.

The network adapter retains active queue state.

After restart, the controller reconstructs outstanding commands from device state and protected accounting records.

It does not treat the host's newly empty process memory as evidence that reserved capacity can be released.

7.6.164. C-76.118 - Example J: VM Snapshot Replay

A virtual machine submits a DMA operation under Budget Generation 31.

It is later restored from an older snapshot containing an earlier software budget view.

The hardware controller retains or reconstructs the current protected accounting generation.

A replayed descriptor using an obsolete submission generation cannot independently obtain fresh budget authority.

7.6.165. C-76.119 - Example K: Queue Failover

A storage command is admitted to Queue A.

The command's acknowledgment is lost.

A failover mechanism attempts to submit the same command through Queue B.

The controller checks whether Queue A can still complete the command.

If it can, the controller either reserves sufficient exposure for both possible executions or prevents Queue B from executing until Queue A is authoritatively fenced.

The original reservation is not automatically released or reused.

| C-76.120 - Example L: Controller Reset A device controller resets while several commands are outstanding. Protected accounting state indicates that 400 units remain reserved. The recovery mechanism determines that some commands may have partially completed. The controller retains unresolved charged exposure while reconstructing queue state. New admissions resume only when the applicable invariant is preserved. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.121 - Example M: Delegated Accelerator Workers An AI task delegates computation to three accelerator workers. Each worker submits output-copy commands. All commands use the originating task's shared output budget. The Delegation-Accounting Controller does not issue an independent full budget for each accelerator worker.                                                                                        |
| C-76.122 - Example N: Concurrent Last-Unit Race A task has one permitted operation unit remaining. Two device submission queues receive commands simultaneously. Both attempt to reserve one unit. The protected atomic counter admits only one request. The second is rejected because the first reservation has already consumed the available capacity.                                                                    |

7.6.166. C-76.123 - Example O: Duplicate Cancellation Acknowledgment

A command reserves 20 KiB.

It is canceled with authoritative proof that no effect occurred.

The controller releases the 20 KiB once.

A duplicate cancellation acknowledgment arrives.

The protected reservation record is already marked released.

The second event does not credit the budget again.

7.6.167. C-76.124 - Example P: Unbounded Hardware Command

An accelerator command contains a repetition parameter with no verified maximum.

The controller cannot establish its worst-case resource effect.

It refuses admission as an unbounded single command.

The host may instead submit bounded segments, each independently reserved before execution.

7.6.168. PART XVI - FAILURE AND ADVERSARIAL CONDITIONS

7.6.169. C-76.125 - Representative Failure Cases

7.6.170. F1 - Queue Admission Before Reservation

A command becomes effect-capable before accounting commits.

The hardware admission barrier prevents execution until reservation is authoritative.

7.6.171. F2 - Software-Only Counter

An agent modifies a host-local budget counter.

The protected controller ignores unauthorized host accounting changes.

7.6.172. F3 - Forged Task Identity

A command enforcement points another task's budget.

Protected submission-context binding rejects the enforcement point.

7.6.173. F4 - Child Process Budget Reset

A descendant process attempts to obtain a new full allowance.

Delegation accounting preserves the originating task limit.

7.6.174. F5 - Alternate Queue Bypass

A workload submits through an ungoverned queue.

The claimed protected effect domain must include the relevant queue or deny that route.

7.6.175. F6 - Concurrent Reservation Race

Two queues simultaneously consume the same apparent headroom.

Atomic admission prevents over-reservation.

7.6.176. F7 - Integer Overflow

The sum of reserved and completed quantities exceeds the counter range.

Checked arithmetic rejects unsafe updates.

7.6.177. F8 - Negative Accounting

A malformed completion event would make the reserved counter negative.

Protected invariant checks reject the transition.

7.6.178. F9 - Underestimated Command Effect

The estimator reserves less than the command can produce.

The admission controller requires enforceable bounds or segmented execution.

7.6.179. F10 - Unbounded Command

A command lacks a finite maximum effect quantity.

It is rejected or divided into bounded units.

7.6.180. F11 - Descriptor Tampering After Admission

The host modifies command length or resource target after reservation.

The controller uses a protected descriptor snapshot or revalidates the actual command before effectuation.

7.6.181. F12 - Scatter-Gather Expansion

Multiple descriptor segments exceed the reserved length.

The estimator accounts for the aggregate maximum.

7.6.182. F13 - Accelerator-Generated Extra Effects

The accelerator expands one command into additional resource operations.

The bounded-effect model includes those operations or restricts expansion.

7.6.183. F14 - Incorrect Unit Conversion

The system confuses bytes with blocks or commands.

Typed effect dimensions prevent incompatible accounting.

7.6.184. F15 - Wrong Completion Boundary

The device reports descriptor retirement but not actual protected effectuation.

The accounting model specifies and verifies its true effect boundary.

7.6.185. F16 - Premature Cancellation Refund

The host requests cancellation while a command remains executable.

Reserved capacity is retained.

7.6.186. F17 - Partial Completion Ignored

The controller releases a whole reservation after partial effectuation.

The reconciliation procedure retains the completed portion.

7.6.187. F18 - Duplicate Completion Event

A completion event is delivered twice.

Stable command and event identity prevent double charging.

7.6.188. F19 - Duplicate Cancellation Event

A cancellation event is delivered twice.

The protected record prevents double refund.

7.6.189. F20 - Completion-Cancellation Race

Completion and cancellation occur concurrently.

Protected serialization preserves consistent accounting.

7.6.190. F21 - Late Hardware Completion

A completion arrives after cancellation was requested.

The controller charges the confirmed effect.

7.6.191. F22 - Canceled Queue Entry Still Executable Elsewhere

The original entry is removed but another queue holds an executable copy.

Capacity is retained until alternate paths are fenced.

7.6.192. F23 - Queue Publication Failure

Reservation succeeds but command publication fails.

The controller establishes non-effectuation before releasing capacity.

7.6.193. F24 - Lost Admission Acknowledgment

The host does not learn whether admission succeeded.

Protected command identity and queue state are queried before retry.

7.6.194. F25 - Lost Completion Acknowledgment

The operation may have effected a resource change.

The corresponding quantity remains charged pending reconciliation.

7.6.195. F26 - Host Restart

Host-local records disappear while the device retains commands.

Protected recovery uses device and durable accounting state.

7.6.196. F27 - Device Reset

Volatile queue state disappears.

The controller does not assume all earlier commands were harmless.

7.6.197. F28 - VM Snapshot Rollback

The VM restores an earlier software allowance.

Protected budget generations prevent reuse of stale authority.

7.6.198. F29 - VM Migration Duplication

Source and destination devices can execute the same command.

Migration fencing or sufficient dual-execution reservation is required.

7.6.199. F30 - Failover Queue Duplicate

A standby queue executes work while the original remains active.

The controller prevents duplicate use of one insufficient reservation.

7.6.200. F31 - Stale Reservation Reuse

A previously released reservation ID is presented again.

Protected generation and terminal-state checks reject reuse.

7.6.201. F32 - Controller State Rollback

The protected budget table is restored to a stale state.

Recovery continuity checks prevent reactivation under invalid accounting.

7.6.202. F33 - Delegation Context Substitution

A descendant worker attempts to switch task attribution.

Authenticated delegation mapping prevents the change.

7.6.203. F34 - Cross-Process Budget Fragmentation

Each process has a separate local counter while sharing one intended task cap.

The controller aggregates against the shared protected root entry.

7.6.204. F35 - Device Virtual Function Reassignment

A queue owner changes without correct task reassociation.

The controller requires a valid current mapping.

7.6.205. F36 - Unauthorized Budget Increase

The workload attempts to raise its authorized limit.

Only the trusted configuration authority may modify the budget.

7.6.206. F37 - Revocation During Execution

The authorized task budget is reduced while commands are outstanding.

New admissions are restricted and pending work is handled according to defined cancellation or completion rules.

7.6.207. F38 - Stale Budget Epoch

A command from an obsolete authority generation is submitted.

The controller rejects or revalidates it.

7.6.208. F39 - Hardware Accounting Memory Corruption

The protected accounting table fails integrity checks.

Affected admissions are suspended pending recovery.

7.6.209. F40 - Controller Firmware Compromise

The trusted hardware admission mechanism is compromised.

The guarantee depends upon the defined controller trust boundary and cannot be assumed to survive compromise of its own trusted computing base.

7.6.210. F41 - Peer-to-Peer Device Bypass

A peripheral can produce effects through an alternate hardware path.

That path must be included in the governed effect domain or separately restricted.

7.6.211. F42 - Multi-Device Shared Budget Inconsistency

Two physical devices independently issue the entire budget.

A consistent shared allocator or disjoint sub-budget model is required.

7.6.212. F43 - Incomplete Recovery Inventory

The controller cannot identify all surviving executable commands.

Uncertain reservations remain charged.

7.6.213. F44 - Unknown Partial Completion

The exact already-effected quantity is unavailable.

The controller retains conservative charged exposure.

7.6.214. F45 - Command Replay Across Epochs

An old command descriptor is submitted under a later recovery generation.

The admission controller rejects unsupported replay.

7.6.215. F46 - Budget Table Counter Wraparound

A long-running task exceeds numeric counter capacity.

Checked arithmetic or suitably wide counters prevent silent wraparound.

7.6.216. PART XVII - IMPLEMENTATION VARIATIONS

7.6.217. C-76.126 - Programmable Network Interface Controller

The controller reserves network-transmission budget before admitting transmit descriptors.

Hardware completion or transmit-boundary evidence reconciles completed quantities.

7.6.218. C-76.127 - SmartNIC Budget Table

A SmartNIC maintains device-local per-task counters shared across multiple transmit rings.

A protected management processor controls configuration and recovery.

7.6.219. C-76.128 - DPU Admission Service

A DPU hosts the protected accounting service and mediates host-generated network or storage commands.

The AI host cannot directly modify the authoritative table.

7.6.220. C-76.129 - DMA Queue Manager

The controller budgets destination write quantities before accepting DMA descriptors.

| The device enforces transfer bounds and reports confirmed completion.                                                                                                                                                                                            |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.130 - IOMMU-Associated Admission The IOMMU provides protected address-space isolation while an associated controller implements actual effect-budget reservation. The implementation does not incorrectly equate IOMMU translation with budget enforcement. |
| C-76.131 - GPU or Accelerator Command Queue A device admission controller reserves bounded output or DMA effect quantities before dispatching accelerator commands. Commands with unbounded output may be segmented or rejected.                                 |
| C-76.132 - Storage Controller A storage controller reserves bounded write or mutation quantities before accepting resource- modifying commands. Completion accounting follows the selected storage effect boundary.                                              |
| C-76.133 - Multi-Process Shared Queue Multiple processes submit commands through one physical queue. The controller maps them to appropriate root task budgets.                                                                                                  |

7.6.221. C-76.134 - Multi-Queue Shared Controller

Several queue pairs use one protected budget table.

The table supports atomic reservations across the queues.

| C-76.135 - SR-IOV Virtual Function Implementation Multiple virtual functions are associated with protected task identities. Their resource effects are charged to the applicable shared budget.                        |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-76.136 - Host-Adjacent Protected Controller A trusted host-side controller mediates commands before effect-capable device queues. The controller is isolated from the less-trusted agent execution context.          |
| C-76.137 - Controller-Local Protected SRAM Budget counters and command reservations are stored in device-local SRAM with restricted host access. Recovery may use an additional durable authenticated state mechanism. |
| C-76.138 - Persistent Protected Ledger The controller maintains a durable record of completed effects, reservations, and command generations. The ledger is used for restart and failover reconciliation.              |

7.6.222. C-76.139 - Distributed Device Budget Allocation

A protected coordination service allocates disjoint device-level budgets under a task's authorized global limit.

Each device enforces its local allocation.

7.6.223. C-76.140 - Optional DAS Finality Integration

The hardware budget controller may operate alongside a PED and Finality Sink.

The PED may authorize a command's resource scope.

The hardware controller may independently limit cumulative and outstanding effect quantities.

The present enforcement point(s) 76 family does not require a portable per-command receipt or separately issued finality capability.

7.6.224. PART XVIII - REPRESENTATIVE TECHNICAL DATA STRUCTURES

7.6.225. C-76.141 - TaskBudgetRecord

Fields may include:

1. BudgetEntryID. 2. RootTaskID. 3. EffectClass. 4. AuthorizedLimit. 5. ReservedOutstandingQuantity. 6. CompletedEffectQuantity. 7. BudgetEpoch. 8. AuthorityGeneration. 9. AccountingGeneration. 10. RecoveryStatus.

7.6.226. C-76.142 - HardwareCommandRecord

Fields may include:

1. CommandID. 2. RootTaskID. 3. SubmittingContextID. 4. QueueID. 5. EffectClass. 6. DescriptorDigest.

7. AdmissionGeneration. 8. InitialReservation. 9. RemainingReservation. 10. CompletedQuantity. 11. CommandStatus.

7.6.227. C-76.143 - TaskContextBindingRecord

Fields may include:

1. ContextBindingID. 2. RootTaskID. 3. ProcessOrVMIdentity. 4. DeviceSubmissionContext. 5. QueueOwnerReference. 6. PASIDOrVirtualFunctionReference. 7. DelegationReference. 8. BindingGeneration. 9. BindingStatus.

7.6.228. C-76.144 - EffectQuantityBoundRecord

Fields may include:

1. CommandID. 2. EffectClass. 3. UnitType. 4. MaximumQuantity. 5. DescriptorLength. 6. SegmentReferences. 7. RepetitionBound. 8. EstimationMethod. 9. BoundEnforcementReference. 10. BoundStatus.

7.6.229. C-76.145 - ProtectedReservationRecord

Fields may include:

1. ReservationID. 2. CommandID. 3. BudgetEntryID.

4. InitialQuantity. 5. RemainingQuantity. 6. CompletedQuantity. 7. ReleasedUnusedQuantity. 8. ReservationGeneration. 9. QueuePublicationStatus. 10. ReservationStatus.

7.6.230. C-76.146 - HardwareCompletionRecord

Fields may include:

1. CompletionID. 2. CommandID. 3. DeviceControllerID. 4. CompletedEffectQuantity. 5. EffectBoundaryClass. 6. CompletionSequence. 7. CompletionEvidenceReference. 8. HardwareGeneration. 9. ReconciliationStatus.

7.6.231. C-76.147 - CancellationFenceRecord

Fields may include:

1. FenceID. 2. CommandID. 3. AffectedQueueIDs. 4. FenceGeneration. 5. ConfirmedCompletedQuantity. 6. RemainingEffectuationCapability. 7. AlternateQueueReferences. 8. FenceVerificationStatus. 9. ReservationReleaseStatus.

7.6.232. C-76.148 - DelegatedTaskAccountingRecord

Fields may include:

1. DelegationID. 2. RootTaskID.

3. DescendantContextID. 4. AuthorizedEffectClasses. 5. SharedBudgetReference. 6. AllocatedSubBudget. 7. DelegationGeneration. 8. CurrentQueueReferences. 9. DelegationStatus.

7.6.233. C-76.149 - QueueRecoveryRecord

Fields may include:

1. RecoveryID. 2. DeviceControllerID. 3. RecoveryEpoch. 4. PersistedBudgetReference. 5. SurvivingQueueReferences. 6. OutstandingCommandIDs. 7. CompletedEffectReferences. 8. IndeterminateCommandSet. 9. ReconciliationOutcome. 10. AdmissionResumeStatus.

7.6.234. C-76.150 - FailoverCommandRecord

Fields may include:

1. FailoverID. 2. OriginalCommandID. 3. OriginalQueueID. 4. StandbyQueueID. 5. RootTaskID. 6. ExistingReservationReference. 7. AdditionalReservationReference. 8. OriginalExecutionFenceStatus. 9. FailoverGeneration. 10. FailoverStatus.

7.6.235. C-76.151 - ProtectedAccountingAuditRecord

Fields may include:

1. AuditID. 2. RootTaskID. 3. EffectClass. 4. AuthorizedLimit. 5. AggregateReservedQuantity. 6. AggregateCompletedQuantity. 7. CommandReservationReferences. 8. CurrentAccountingGeneration. 9. InvariantVerificationOutcome. 10. AuditStatus.

7.6.236. PART XIX - ENGINEERING VERIFICATION TESTS

7.6.237. C-76.152 - Proposed Test Matrix

The following are proposed technical verification tests, not representations of experiments already performed.

7.6.238. Test Condition

T1 Sufficient budget available T2 Budget exhausted T3 Command enters queue before reservation T4 Exact effect bound available T5 Conservative bound required T6 Effect bound unknown T7 Scatter-gather descriptor T8 Repeated accelerator operation T9 Host modifies descriptor after reservation T10 Two queues reserve final unit concurrently T11 Completed quantity increases T12 Partial command completion T13 Partial cancellation T14 Cancellation requested without fence T15 Cancellation acknowledgment duplicated T16 Completion acknowledgment duplicated T17 Completion and cancellation race T18 Hardware reports quantity exceeding

reservation

7.6.239. Expected result

Command admitted Command denied Admission barrier prevents execution Correct reservation Sufficient capacity reserved Command rejected or segmented Aggregate length accounted Maximum effect counted Effect bound remains enforced Only permitted number admitted Reserved quantity correspondingly decreases Completed portion remains charged Only verified remaining portion released Reservation retained No double refund No double charge Accounting remains consistent Invariant violation detected

T19 Lost completion acknowledgment T20 Command fails before effectuation T21 Command fails after partial effectuation T22 Two processes share task T23 Child process created T24 Delegated worker submits command T25 Worker forges TaskID T26 Two SR-IOV virtual functions share task T27 Network queue transmission T28 DMA write command T29 Storage command T30 Accelerator output command T31 Controller-local table unauthorized write T32 Budget increase by agent T33 Trusted budget update T34 Budget reduction during queued work T35 Host restart with live device commands T36 Device reset with uncertain completion T37 VM snapshot restore T38 VM migration T39 Source VM remains active after migration T40 Queue failover T41 Original and standby queue both executable T42 Stale reservation ID replay T43 Recovery epoch rollback T44 Queue state differs from persisted table T45 Incomplete recovery inventory T46 Device memory corruption T47 Counter integer overflow T48 Negative reserved counter attempted T49 Alternate queue bypass T50 Multiple devices share global task budget T51 Duplicate command publication T52 Reservation committed but queue publication

fails T53 Command completes after cancellation

request T54 Cancel acknowledgment arrives before

completion event T55 Effect metric uses wrong unit T56 Descriptor retirement incorrectly treated as

external completion

Conservative reconciliation Verified unused reservation released Partial completion retained Shared budget enforced No fresh root budget Root attribution maintained Submission rejected Aggregate accounting Defined effect boundary measured Bounded writes reserved Native completion semantics used Effect quantity bounded Modification rejected Rejected Versioned authorization New admissions restricted Reservations preserved Unresolved capacity retained Old budget not restored as spendable No duplicate global capacity Fence or dual-execution accounting Existing effect potential accounted Insufficient single reservation rejected Rejected Detected Reconciliation required Admissions remain restricted Accounting integrity failure Prevented Rejected Governed path restricted Coordinated budget allocation Duplicate identity controlled Safe rollback or reconciliation

Completed effect charged

Final quantity reconciled Typed accounting prevents error Effect boundary distinction enforced

T57 Persistent budget state recovered T58 Delegation revoked T59 Existing command survives delegation

revocation T60 Protected table audit T61 Sub-budget returned to parent T62 Peer-to-peer hardware path available T63 Queue failover after partial completion T64 Controller reset during cancellation

Current generation verified Current task binding enforced Outstanding liability retained Command-level sums reconcile Unused capacity proven releasable Protected scope limitation identified or path governed Completed quantity preserved No premature refund

A concrete test harness should specify device architecture, queue topology, trusted submission identity, effect classes, command descriptor formats, accounting units, completion semantics, cancellation fencing, persistence guarantees, and permitted alternate execution paths.

The tests must inspect actual hardware or controller-enforced behavior rather than merely verifying software counter values.

7.6.240. PART XX - Enforcement-Point Mapping and Technical Correspondence

7.6.241. C-76.153 - Independent enforcement point(s) 76

The embodiment provides the following implementation mapping.

enforcement point(s) 76(a): Host execution environment generating or delegating resource-operation

commands attributable to an AI-agent task.

enforcement point(s) 76(b): Hardware-adjacent admission controller associated with network, storage,

DMA, accelerator, peripheral, or IOMMU-associated resource interfaces.

enforcement point(s) 76(c): Protected task-context association binding commands to root or delegated task

identity.

enforcement point(s) 76(d): Hardware-protected effect-accounting table storing authorized effect class,

budget limit, reserved outstanding quantity, and completed quantity.

enforcement point(s) 76(e): Bounded resource-effect estimator operating before command admission.

enforcement point(s) 76(f): Atomic reservation engine increasing outstanding-effect quantity before queue

publication.

enforcement point(s) 76(g): Command-execution controller denying admission when completed plus

reserved plus new requested exposure would exceed the permitted limit.

enforcement point(s) 76(h): Completion-reconciliation engine handling successful completion, partial

completion, cancellation, and failure.

enforcement point(s) 76(i): Delegation-accounting mechanism associating descendant commands with

originating task budgets.

First concluding requirement: Queued and delegated commands reserve effect capacity

before producing the governed external effect.

Second concluding requirement: Reserved capacity is released after cancellation only when

the controller establishes that the corresponding command portion cannot subsequently complete.

Third concluding requirement: The effect-budget limit is enforced without mandating

portable per-command validation receipts or separately issued finality capabilities.

7.6.242. C-76.154 - Dependent enforcement point(s) 77: Network and DMA Queue Admission

The embodiment provides:

1. Programmable network-controller implementations. 2. SmartNIC protected budget tables. 3. DPU admission services. 4. DMA controller implementations. 5. Accelerator queue-manager implementations. 6. Controller-local or hardware-protected accounting memory. 7. Multiple host-process submission contexts. 8. Shared root task attribution. 9. Cross-queue atomic reservation. 10. Virtual-function and device submission-context bindings. 11. Protected admission before hardware queue effectuation. 12. Appropriate effect-bound and completion meters.

7.6.243. C-76.155 - Dependent enforcement point(s) 78: Partial Execution Accounting

The embodiment provides:

1. Initial bounded reservation. 2. Hardware completion evidence.

3. Partial effect quantification. 4. Atomic reserved-to-completed transfer. 5. Retention of completed-effect charges. 6. Remaining reservation tracking. 7. Protected execution fencing. 8. Release of verified unused quantities. 9. Conservative treatment of unknown progress. 10. Cancellation-completion race handling. 11. Duplicate refund prevention. 12. Safe recovery from partial failure.

C-76.156 - Dependent enforcement point(s) 79: Recovery and Queue- State Consistency

The embodiment provides:

1. Persisted protected budget state. 2. Host restart handling. 3. Controller reset handling. 4. VM snapshot restoration checks. 5. VM migration accounting transfer. 6. Queue failover management. 7. Protected recovery generations. 8. Outstanding hardware command inventory. 9. Alternate execution-path discovery. 10. Original queue fencing. 11. Reservation reuse prevention. 12. Reconciliation of completed and outstanding quantities. 13. Conservative retention of indeterminate liabilities. 14. Safe resumption of admissions.

7.6.244. PART XXI - implementer IMPLEMENTATION REQUIREMENTS

7.6.245. C-76.157 - Implementation Checklist

A person having ordinary skill in the art implementing the embodiment identifies:

1. The host AI-agent execution environment. 2. The originating task identity. 3. The delegated task identity representation. 4. The trusted task-association mechanism.

5. The governed hardware resource interface. 6. The effect-capable hardware queue. 7. The hardware-adjacent admission boundary. 8. The protected computing base. 9. The protected budget provisioning authority. 10. The supported effect classes. 11. The resource-effect units. 12. The exact effectuation boundary for each class. 13. The command descriptor schema. 14. The command effect-bound estimator. 15. The treatment of unbounded commands. 16. The protected effect-accounting table. 17. The budget-limit representation. 18. The reserved-effect counter. 19. The completed-effect counter. 20. The atomic reservation procedure. 21. The queue-publication ordering. 22. The reservation-to-command binding. 23. The counter overflow rules. 24. The concurrent queue coordination. 25. The protected hardware completion observer. 26. The partial completion reconciliation procedure. 27. The cancellation request state. 28. The hardware execution fence. 29. The authoritative non-effectuation condition. 30. The verified cancellation refund procedure. 31. The duplicate completion-event control. 32. The duplicate cancellation-event control. 33. The host-process delegation registry. 34. The shared root task budget. 35. The optional disjoint sub-budget allocation scheme. 36. The virtual-function or PASID association. 37. The applicable queue isolation mechanism. 38. The treatment of device-generated effects. 39. The treatment of existing and alternate hardware queues. 40. The persisted budget-state format. 41. The reset-recovery generation. 42. The host restart recovery procedure. 43. The controller reset recovery procedure. 44. The VM migration coordination. 45. The source-device execution fence. 46. The queue failover duplicate-prevention procedure. 47. The replay and rollback protection. 48. The indeterminate command accounting policy. 49. The post-recovery invariant verification. 50. The protected accounting audit mechanism. 51. The engineering tests demonstrating the claimed budget properties.

The selected hardware or protected controller must actually enforce the described admission, reservation, and completion conditions.

A software process that merely observes device activity and increments an ordinary application counter after commands have already become effect-capable does not independently establish the pre-queue hardware budget enforcement of this implementation profile.

7.6.246. C-76.158 - Technical Effect

The disclosed architecture provides a mechanism for enforcing cumulative resource-effect limits on AI-agent workloads at a hardware or hardware-adjacent operation boundary.

A command is admitted to a governed effect-capable queue only after a protected reservation of its bounded effect quantity.

Queued commands therefore consume budget capacity before actual effectuation.

Completed effects remain charged while outstanding reservations represent effects that may still occur.

Atomic reservation prevents concurrent producers from independently consuming the same available budget.

Delegated workers, subordinate processes, and multiple hardware queues may share an originating task budget.

Partial completion accounting prevents cancellation or failure from releasing quantities already effected.

Cancellation fencing prevents outstanding reservations from being refunded while corresponding commands remain executable.

Recovery-generation and queue-continuity mechanisms prevent host restart, device reset, virtual-machine migration, or queue failover from restoring capacity already committed to completed or still-executable work.

The architecture thereby limits resource-effect exposure without mandating a portable percommand protected validation receipt or separately issued finality capability.

Its guarantee depends upon the completeness of the governed effect paths, the accuracy and enforceability of effect bounds, protected accounting integrity, reliable completion evidence, and correct recovery coordination.

7.6.247. C-76.159 - Technical Summary

this implementation profile discloses a hardware-assisted resource-control system for artificialintelligence-agent workloads.

A processor or host execution environment generates or delegates resource-operation commands attributable to an identified AI-agent task.

A hardware-adjacent admission controller mediates submission of those commands to an effect-capable network, storage, DMA, accelerator, or peripheral queue.

A protected task-context association mechanism binds submitted commands to originating or delegated task identities.

A hardware-protected effect-accounting table maintains authorized effect-budget limits, reserved outstanding-effect quantities, and completed-effect quantities.

An effect-bound estimator determines a bounded resource-effect quantity before command admission.

An atomic reservation mechanism increases the outstanding-effect quantity before making the command eligible for execution.

A command-execution controller rejects admission when the aggregate completed and reserved quantities, including the proposed new reservation, would exceed the protected limit.

A completion-reconciliation mechanism transfers confirmed completed quantities from outstanding reservations into completed-effect accounting, preserving their budget charge.

Cancellation releases only the remaining quantity that the protected controller establishes can no longer become effective.

A delegation-accounting mechanism charges descendant process and worker commands to applicable originating task budgets.

A recovery controller reconciles protected accounting state with hardware queue entries after host restart, controller reset, virtual-machine migration, or queue failover.

A protected generation and execution-fencing mechanism prevents old or duplicated commands from using released or restored reservation capacity while the corresponding physical operation remains executable.

The system thereby enforces deferred-effect resource budgets close to the physical or devicemediated effectuation boundary without requiring a portable per-command validation receipt or separate finality capability.

MEMORY-CLASS AUTHORITY ISOLATION FOR PERSISTENT ARTIFICIAL-INTELLIGENCE AGENTS USING TYPED MEMORY ACCESS, SOURCE-CONTEXT ATTRIBUTION, PROTECTED PROCEDURAL

7.6.247.1. ENROLLMENT, AUTHORITY- PRESERVING DERIVATION, CROSS- TENANT MEMORY SEGREGATION, AND RETRIEVAL-TIME POLICY REVALIDATION

7.7. Implementation Profile C-84

Source location: original disclosure pages 1470-1554. Source technical content is presented here for implementation analysis; numbering reflects the original profile family rather than a requirement to implement every profile.

EMBODIMENT C-84 COORDINATED KERNEL AND HARDWARE CONTAINMENT OF ARTIFICIAL-INTELLIGENCE-AGENT WORKLOADS USING EXECUTION- CONTEXT ATTRIBUTION, MONOTONIC CONTAINMENT

7.7.1. GENERATIONS, SOFTWARE ADMISSION FENCING, DEVICE-LEVEL EFFECTUATION RESTRICTIONS, IN- FLIGHT COMMAND SETTLEMENT, AND MIGRATION-SAFE RECOVERY

7.7.2. C-84.1 - Technical Field

this implementation profile relates to artificial-intelligence-agent security, operating-system containment, kernel-level workload observation, hardware-assisted isolation, programmable network interfaces, direct-memory-access control, input/output memory management, accelerator command processing, storage queue protection, device-level execution fencing, and recovery-safe security-state continuity.

More particularly, the embodiment discloses a computer-implemented containment system configured to respond to a detected security deviation associated with an artificialintelligence-agent execution context.

The system coordinates restrictions at two distinct categories of enforcement boundary:

(a) a software execution-control boundary controlling admission of new resource-operation commands; and (b) a hardware effectuation boundary controlling resource operations that may already have been submitted to, fetched by, or accepted into a device or hardware queue.

A containment controller assigns a protected containment generation, identifies the relevant execution context and its accessible hardware-effectuation interfaces, applies corresponding software and hardware restrictions, inventories commands capable of further effectuation,

and determines whether those commands have completed, have been verifiably canceled, or remain unresolved.

Containment is reported complete only when the required software restrictions and hardware restrictions have become effective and no unresolved affected command remains capable of bypassing the intended containment state.

The architecture further preserves containment restrictions across host restart, virtualmachine migration, checkpoint restoration, queue relocation, device reset, and failover.

The invention may be implemented in:

1. AI-agent sandboxes. 2. Containers. 3. Virtual machines. 4. Micro-VMs. 5. Host operating systems. 6. Hypervisors. 7. Cloud execution platforms. 8. SmartNICs. 9. Data-processing units. 10. Programmable network interfaces. 11. DMA controllers. 12. IOMMU-associated controllers. 13. GPU and accelerator command processors. 14. Storage submission controllers. 15. Privileged peripheral interfaces. 16. Distributed AI-agent execution systems.

The embodiment does not depend upon a particular operating system, hypervisor, networkinterface vendor, device architecture, kernel instrumentation framework, or artificialintelligence model.

The required enforcement and completion guarantees must be provided by the actual selected platform.

7.7.3. PART I - TECHNICAL PROBLEM

7.7.4. C-84.2 - Detection Is Not Containment

An AI-agent runtime may be monitored using:

(a) kernel events; (b) eBPF instrumentation;

(c) Linux Security Module hooks;

(d) hypervisor telemetry;

(e) process execution records;

(f) file-access observations;

(g) network socket events;

(h) resource-operation telemetry; or

(i) protected workload instrumentation.

A monitoring system may detect behavior outside an expected security profile.

For example:

An AI agent accesses an unauthorized credential.

An AI agent attempts an unexpected outbound connection.

An AI agent submits an unusual DMA command.

An AI agent invokes an unauthorized tool.

Detection establishes that an event occurred or is occurring.

It does not automatically establish that the affected workload can no longer produce further resource effects.

7.7.5. C-84.3 - Process Termination Is Not Hardware Settlement

A common response to an agent security incident is to terminate the agent process.

However, process termination may occur after commands have already been submitted to hardware.

For example:

AGENT PROCESS

→ OPERATING SYSTEM

→ NIC TRANSMIT RING

→ NIC DMA FETCH

→ PACKET TRANSMISSION.

Terminating the originating process may prevent some future software execution.

It does not necessarily cancel descriptors already consumed by the network device.

Likewise, a storage write, accelerator command, or DMA transfer may continue after the initiating process has exited.

The architecture therefore distinguishes process termination from verified hardware containment.

7.7.6. C-84.4 - Pending Network Transmission

An agent may place network data in an operating-system queue or NIC transmit ring.

At the moment a security incident is detected, different portions may be:

1. Not yet admitted. 2. Staged in software. 3. Accepted into a transmit queue. 4. Fetched by the device. 5. Partially transmitted. 6. Fully transmitted. 7. Awaiting an acknowledgment or completion record.

A request to disable network access may not retroactively stop packets already transmitted.

The system must record completed transmission separately from packets verifiably prevented from leaving the controlled interface.

7.7.7. C-84.5 - Outstanding DMA Access

A device may hold access to host memory through an active DMA mapping.

Revoking a software process's permissions does not necessarily revoke already established device memory access.

A DMA operation may already be:

(a) queued; (b) fetched;

(c) executing;

(d) partially completed;

(e) pending in an interconnect;

(f) awaiting a device completion; or

(g) retained through a device-specific command engine.

The containment system must account for these conditions according to the actual device and IOMMU completion semantics.

7.7.8. C-84.6 - Accelerator Command Continuation

An AI-agent workload may issue a command to an accelerator.

The command may initiate computation, DMA, persistent output, or other consequential operations.

The host application can terminate while the accelerator continues executing admitted work.

The containment controller therefore identifies relevant accelerator queues and applies supported command-submission restrictions, cancellation, reset, quiescence, or resourceaccess fencing.

7.7.9. C-84.7 - Multiple Hardware Access Paths

An agent may access:

NIC Queue A.

NIC Queue B.

DMA Engine C.

Storage Queue D.

Accelerator Queue E.

If containment restricts only one path, another may remain capable of producing effects.

The system identifies the hardware-effectuation interfaces associated with the affected context.

The coverage requirement applies to the designated containment scope.

7.7.10. C-84.8 - Race Between Detection and Restriction

A security event may be detected at time T1.

The containment decision is made at T2.

Software submission may stop at T3.

Hardware restrictions may become effective at T4.

Commands submitted between T1 and T4 may enter hardware queues.

The controller therefore defines a containment generation and admission-fencing sequence.

It must also account for commands that crossed an enforcement boundary before the relevant restriction became effective.

7.7.11. C-84.9 - Incomplete Containment Acknowledgment

A network controller may acknowledge receipt of a containment command.

However, the acknowledgment may mean only that the command was accepted for processing.

It may not prove that:

1. New transmissions are blocked. 2. Existing queues are drained. 3. DMA access is fenced. 4. Already fetched descriptors are settled. 5. Alternate queues are restricted. 6. A standby controller has received the containment generation.

The system distinguishes configuration receipt from effective enforcement.

7.7.12. C-84.10 - Recovery Can Reintroduce Stale Authority

A host may restore an earlier checkpoint containing:

(a) active device queue configurations;

(b) a process state predating containment;

(c) previously available credentials;

(d) old resource mappings;

(e) an earlier access-control policy; or

(f) old device submission descriptors.

A destination host or migrated virtual machine may attempt to resume normal execution using that stale state.

The embodiment prevents such resumption until the current containment generation and unresolved-operation state are reconciled.

7.7.13. PART II - CENTRAL TECHNICAL PRINCIPLE

7.7.14. C-84.11 - Containment Must Reach the Effectuation Boundary

The principal requirement is:

7.7.15. Containment of an AI-agent workload is not complete merely because new software

execution has stopped; previously admitted hardware operations must also be settled or made incapable of bypassing the required restrictions.

The system coordinates:

SOFTWARE ADMISSION CONTROL

x

HARDWARE RESOURCE RESTRICTION x

IN-FLIGHT OPERATION INVENTORY

x

SETTLEMENT OR VERIFIED FENCING

x

RECOVERY STATE CONTINUITY.

7.7.16. C-84.12 - Three Required Completion Conditions

For a containment generation G affecting execution context X, define:

S(G,X) = the required software command-admission restrictions are effective.

H(G,X) = the required hardware restrictions are effective.

Q(G,X) = no unresolved affected command remains capable of bypassing the intended restrictions.

Then:

CONTAINED(G,X) = S(G,X) AND H(G,X) AND Q(G,X).

The containment controller reports completion only after all required predicates are established.

7.7.17. C-84.13 - Meaning of Unresolved Operation

An operation may be classified as unresolved when its exact effectuation outcome is not yet known.

However, unresolved outcome and unresolved ability to produce future effects are different conditions.

A command may have an unknown historical completion result but be authoritatively fenced from any future effectuation.

Such a command can remain historically indeterminate while satisfying the applicable nofurther-bypass condition.

Conversely, a command that might still transmit, write, or actuate cannot be treated as safely settled merely because its execution outcome is unknown.

7.7.18. C-84.14 - No Retroactive Erasure

Containment does not reverse effects that occurred before the restriction became effective.

For example:

Packets already transmitted remain transmitted.

DMA writes already completed remain completed.

Storage mutations already committed remain committed.

Physical actuation already performed remains performed.

The system records those effects and prevents or restricts further effects within its actual enforcement coverage.

Post-effect correction may be handled by a separate remediation architecture.

7.7.19. C-84.15 - No Mandatory Portable Finality Artifact

The embodiment can be implemented through:

1. Runtime observation. 2. Context association. 3. Containment generations. 4. Kernel-level admission restrictions. 5. Device-level queue controls. 6. Hardware access mapping restrictions. 7. Command inventory. 8. Completion and cancellation evidence. 9. Protected recovery state.

It does not necessarily require a separate portable validation receipt or individually minted finality capability for every device command.

Its primary function is coordinated containment following a security deviation.

7.7.20. PART III - PRINCIPAL SYSTEM COMPONENTS

7.7.21. C-84.16 - Agent Execution Environment

An AI-Agent Execution Environment contains the workload whose operations are subject to containment.

A representative environment may be:

AGENT_RUNTIME.

CONTAINER.

MICRO_VM.

VIRTUAL_MACHINE.

HOST_PROCESS_GROUP.

DELEGATED_WORKER_GROUP.

ACCELERATOR_EXECUTION_CONTEXT.

The workload may submit resource-operation commands through multiple software and hardware interfaces.

7.7.22. C-84.17 - Runtime Observation Mechanism

A Runtime Observation Mechanism collects security-relevant workload events.

Possible implementations include:

(a) kernel-level event monitoring; (b) eBPF-based telemetry; (c) LSM-mediated security events; (d) hypervisor observation; (e) protected agent runtime telemetry; (f) process and execution-context monitoring; (g) device command observation; or (h) combinations thereof.

Observation alone is not treated as an enforcement barrier.

7.7.23. C-84.18 - Execution-Context Association Mechanism

An Execution-Context Association Mechanism maps detected events to affected workload identities and accessible resource-operation interfaces.

A representative identity comprises:

BootGeneration.

ProcessNamespace.

ProcessCreationIdentity.

ContainerIdentity.

VirtualMachineIdentity.

AgentTaskID.

ExecutionGeneration.

RelevantDeviceContexts.

The implementation should avoid reliance upon an ordinary process identifier alone where identifier reuse or process migration could cause misattribution.

7.7.24. C-84.19 - Resource-Interface Registry

A Resource-Interface Registry identifies hardware and software effectuation paths accessible to an execution context.

Entries may identify:

NetworkQueueID.

NICVirtualFunctionID.

DMAContextID.

IOMMUDomainID.

StorageQueueID.

AcceleratorContextID.

PrivilegedDeviceInterfaceID.

QueueOwner.

ProtectionCapability.

7.7.25. C-84.20 - Containment-Decision Engine

The Containment-Decision Engine determines whether an observed deviation satisfies a designated containment condition.

Examples include:

UNAUTHORIZED_RESOURCE_ACCESS.

PROTECTED_CREDENTIAL_EXPOSURE.

PROHIBITED_NETWORK_DESTINATION.

UNEXPECTED_PRIVILEGED_TOOL_USE.

UNAPPROVED_DEVICE_COMMAND.

SECURITY_POLICY_DEVIATION.

The decision engine may use deterministic policy, risk scoring, event correlation, or another defined mechanism.

A score alone is not necessarily sufficient to establish a hardware restriction unless the applicable containment policy authorizes the response.

7.7.26. C-84.21 - Containment-State Controller

The Containment-State Controller establishes a containment generation.

A representative record contains:

ContainmentID.

AffectedExecutionContext.

ContainmentGeneration.

RestrictionSet.

AffectedSoftwareInterfaces.

AffectedHardwareInterfaces.

DecisionEvidenceReference.

ContainmentStatus.

7.7.27. C-84.22 - Software Execution-Control Interface

The Software Execution-Control Interface prevents admission of new affected resourceoperation commands.

Possible enforcement mechanisms include:

1. Kernel permission hooks. 2. Resource-controller command admission. 3. Agent tool dispatch denial. 4. Protected connector gating. 5. Hypervisor-mediated I/O submission blocking. 6. Cgroup or device access restrictions. 7. Controlled queue submission interfaces. 8. Other enforceable software-side barriers.

An ordinary telemetry-only eBPF program does not automatically satisfy this requirement.

The selected mechanism must actually prevent applicable commands from reaching the governed queue.

7.7.28. C-84.23 - Hardware Containment Interface

The Hardware Containment Interface applies restrictions to at least one designated hardwareeffectuation mechanism.

Representative targets include:

NETWORK_TRANSMISSION_QUEUE.

DMA_MAPPING.

STORAGE_SUBMISSION_QUEUE.

ACCELERATOR_COMMAND_QUEUE.

PRIVILEGED_DEVICE_INTERFACE.

HARDWARE_RESOURCE_ACCESS_TABLE.

The interface may rely upon a device driver, hypervisor, privileged device controller, hardware management processor, or protected firmware service.

7.7.29. C-84.24 - Network Containment Controller

A Network Containment Controller may:

(a) prevent new affected packet submissions; (b) disable selected transmit queues; (c) fence queue ownership; (d) stop device scheduling of pending descriptors; (e) identify transmitted packets; (f) determine cancelable pending packets; and

(g) coordinate transmit-drain or reset operations.

The controller must use the actual supported NIC semantics.

7.7.30. C-84.25 - DMA and Accelerator Containment Controller

The DMA and Accelerator Containment Controller may:

1. Block new submissions. 2. Fence device command queues. 3. Revoke or restrict device-access mappings. 4. Synchronize relevant translation invalidations. 5. Quiesce outstanding DMA operations. 6. Drain or cancel command work. 7. Record completed operations. 8. Verify remaining access restrictions.

The controller must not assume that merely updating an IOMMU mapping synchronously cancels all previously admitted device transactions.

7.7.31. C-84.26 - In-Flight Operation Inventory

An In-Flight Operation Inventory identifies commands that crossed the software admission boundary before containment became effective.

A representative record includes:

CommandID.

ExecutionContextID.

QueueID.

DeviceID.

SubmissionGeneration.

LastKnownCommandState.

PotentialEffectClass.

EffectQuantityBound.

CompletionEvidence.

CancellationEvidence.

7.7.32. C-84.27 - Operation-Settlement Mechanism

The Operation-Settlement Mechanism classifies affected commands as:

COMPLETED.

VERIFIABLY_CANCELED.

UNRESOLVED.

It may also maintain explanatory substates:

PARTIALLY_COMPLETED.

FENCED_PENDING_RECONCILIATION.

COMPLETION_UNKNOWN.

CANCELLATION_REQUESTED.

These substates do not replace the enforcement point's principal settlement classes.

7.7.33. C-84.28 - Containment-Completion Controller

The Containment-Completion Controller evaluates software restriction acknowledgments, hardware restriction acknowledgments, and the in-flight inventory.

It reports:

CONTAINED_VERIFIED

only after the applicable completion conditions have been established.

Other statuses may include:

CONTAINMENT_REQUESTED.

SOFTWARE_RESTRICTED.

HARDWARE_RESTRICTED.

SETTLEMENT_PENDING.

CONTAINMENT_INCOMPLETE.

RECOVERY_RESTRICTED.

7.7.34. C-84.29 - Recovery Controller

A Recovery Controller preserves containment across:

HOST_RESTART.

DEVICE_RESET.

VM_MIGRATION.

CHECKPOINT_RESTORATION.

QUEUE_RELOCATION.

HOST_FAILOVER.

The destination environment does not restore unrestricted resource access until the transferred state is verified.

7.7.35. C-84.30 - Protected Containment Registry

A Protected Containment Registry maintains current generations, affected contexts, restriction sets, acknowledged hardware state, unresolved commands, and recovery status.

The registry may be implemented in protected host memory, a trusted controller, a durable security service, or another protected execution domain.

The required protection is that a less-trusted AI workload cannot erase its active containment merely by restarting or modifying ordinary process state.

7.7.36. PART IV - EXECUTION-CONTEXT ATTRIBUTION

7.7.37. C-84.31 - Stable Execution Identity

A process identifier may be reused.

Accordingly, a representative stable execution identity includes:

HostBootID.

PIDNamespaceID.

ProcessCreationGeneration.

ProcessID.

ContainerOrVMID.

AgentSessionID.

TaskID.

The system may use equivalent native identifiers where available.

7.7.38. C-84.32 - Hardware Context Mapping

An execution context may be associated with:

NetworkSocket.

TransmitQueue.

DeviceVirtualFunction.

PASID.

IOMMUDomain.

AcceleratorStream.

StorageSubmissionQueue.

DeviceHandle.

The registry records the association and applicable generation.

7.7.39. C-84.33 - Shared Device Queues

Multiple execution contexts may share one hardware queue.

If an affected agent shares a queue with unrelated authorized workloads, the controller must determine whether selective containment is supported.

A command-level or queue-owner distinction may permit selective restriction.

Where safe selective containment is unavailable, the system may restrict the whole queue according to the applicable policy.

It must not enforcement point selective containment while unidentifiable affected commands remain executable.

7.7.40. C-84.34 - Delegated Processes

An agent may spawn workers that submit device commands on its behalf.

The association mechanism may maintain:

RootTaskID.

ParentExecutionContext.

ChildExecutionContext.

DelegationGeneration.

AccessibleDeviceContexts.

Containment may propagate to descendants that retain the relevant effectuation authority.

7.7.41. C-84.35 - Service-Account Indirection

A host connector may submit commands using a service account.

The originating agent's process identity may not appear directly in the device descriptor.

The correlation mechanism therefore may require connector transaction identifiers or authenticated task-context propagation.

A shared service identity alone is insufficient to identify which agent-originated commands should be selectively contained.

7.7.42. C-84.36 - Attribution Failure

If the controller cannot distinguish affected commands from unrelated commands, it may:

(a) conservatively restrict the shared queue; (b) prevent further submissions; (c) defer verified containment completion; (d) invoke a broader authorized device restriction; or (e) escalate.

The system must not invent precise attribution from incomplete telemetry.

7.7.43. PART V - SECURITY DEVIATION AND CONTAINMENT DECISION

7.7.44. C-84.37 - Runtime Security Event

A representative event comprises:

SecurityEventID.

EventClass.

ObservedExecutionContext.

ObservedResource.

ObservedOperation.

ObservationSource.

EventGeneration.

PolicyReference.

EvidenceReference.

7.7.45. C-84.38 - Kernel Observation

A kernel monitor may observe an attempted resource access or process event.

The system must distinguish an attempted operation from a completed resource effect.

For example, a file-open attempt does not by itself prove that file contents were disclosed.

Likewise, a socket connection attempt does not prove that all queued payload data was transmitted.

7.7.46. C-84.39 - eBPF Observation

An eBPF program may observe relevant kernel events through supported attachment points.

Depending upon the kernel and attachment type, some eBPF programs are observational, while others may participate in specific enforcement hooks.

The embodiment does not assume all eBPF tracing programs possess denial authority.

An observational program may trigger a separate containment controller with actual kernel and hardware restriction capabilities.

7.7.47. C-84.40 - Hypervisor Observation

A hypervisor may detect activity involving:

1. Virtual device configuration. 2. 3. 4. 5. 6.

Guest execution. Memory-access mappings. Virtual I/O queues. Device assignment. VM state changes.

The hypervisor may apply or coordinate restrictions where it actually controls the relevant submission or mapping boundary.

7.7.48. C-84.41 - Containment Condition

A security condition may be represented as:

IF ObservedEvent satisfies PolicyCondition

THEN EstablishContainmentGeneration.

The response may depend upon:

(a) event severity; (b) affected resource; (c) agent identity; (d) available effectuation paths; (e) active commands; and (f) containment policy.

7.7.49. C-84.42 - Scope of Containment

A containment decision may target:

ONE_PROCESS.

ONE_AGENT_TASK.

ONE_CONTAINER.

ONE_VM.

ONE_DELEGATED_WORKER_GROUP.

ONE_DEVICE_CONTEXT.

ONE_TENANT_RESOURCE_DOMAIN.

The controller resolves the selected scope into concrete software and hardware restriction targets.

7.7.50. PART VI - CONTAINMENT GENERATION AND STATE MACHINE

7.7.51. C-84.43 - Containment Generation

A Containment Generation identifies the current restrictive state applied to a workload.

For example:

ContainmentGeneration = 47.

AffectedTask = TASK-204.

RestrictionSet = { DENY_NEW_NETWORK_TX, FENCE_DMA_QUEUE, SUSPEND_ACCELERATOR_SUBMISSION }.

7.7.52. C-84.44 - Monotonic Generation

A protected generation is monotonically ordered within its defined continuity domain.

A later active containment generation supersedes an earlier permissive configuration.

A stale configuration cannot restore normal access merely by carrying an old generation number.

7.7.53. C-84.45 - Containment State Machine

A representative state machine is:

NORMAL

→ DEVIATION_DETECTED

→ CONTAINMENT_REQUESTED

→ SOFTWARE_FENCING

→ HARDWARE_FENCING

→ IN_FLIGHT_SETTLEMENT

→ CONTAINED_VERIFIED.

Failure states may include:

CONTAINMENT_INCOMPLETE.

HARDWARE_UNAVAILABLE.

UNRESOLVED_COMMANDS.

RECOVERY_RESTRICTED.

7.7.54. C-84.46 - Restriction Commitment

The controller commits:

1. Affected execution context. 2. New containment generation. 3. Required software restrictions. 4. Required hardware restrictions. 5. Resource-interface inventory. 6. Initial outstanding-command state.

The protected commitment occurs before the system relies upon the new containment status.

7.7.55. C-84.47 - Restriction Distribution

Software and hardware controllers receive the containment generation.

An acknowledgment identifies:

ControllerID.

AppliedGeneration.

AppliedRestrictionSet.

EffectiveStatus.

OutstandingCommandReference.

AcknowledgmentEvidence.

7.7.56. C-84.48 - Receipt Versus Enforcement

A controller may acknowledge:

REQUEST_RECEIVED.

CONFIGURATION_STAGED.

RESTRICTION_APPLIED.

RESTRICTION_EFFECTIVE.

These are different states.

The containment-completion controller requires evidence corresponding to the relevant effective restriction, not merely request receipt.

7.7.57. C-84.49 - Restriction Race

A new command may arrive while containment is being established.

A representative implementation places the software admission gate into a restrictive state promptly and inventories all commands admitted before the gate's effective cutoff generation.

The hardware controller then fences the corresponding queues.

The system establishes an ordering relationship between admission closure and the in-flight inventory.

7.7.58. PART VII - SOFTWARE COMMAND ADMISSION FENCING

7.7.59. C-84.50 - Admission Boundary

The software interface controls new commands submitted through designated resourceoperation paths.

Examples include:

NETWORK_SEND.

DMA_SUBMIT.

STORAGE_WRITE_SUBMIT.

ACCELERATOR_DISPATCH.

DEVICE_CONTROL.

PRIVILEGED_CONNECTOR_REQUEST.

7.7.60. C-84.51 - Software Restriction Rule

A representative rule is:

IF Command.ExecutionContext belongs to AffectedSet

AND Command.EffectClass belongs to RestrictedSet

AND CurrentContainmentGeneration ≥ RequiredGeneration

THEN DENY_ADMISSION.

7.7.61. C-84.52 - Protected Admission Generation

Each software admission decision may be associated with a generation.

Commands admitted before the restrictive cutoff are included in the outstanding-command accounting domain.

Commands arriving after the effective cutoff are denied.

7.7.62. C-84.53 - Kernel Hook Enforcement

A kernel-level hook may deny relevant operations at a supported enforcement point.

For example, a suitable LSM hook or resource-control mechanism may prevent specified device interactions.

The implementation must identify the actual controlled interface and not assume that a generic process-monitoring event blocks every possible hardware submission path.

7.7.63. C-84.54 - Device Driver Submission Control

A device driver may reject new submissions associated with a contained context.

For example:

A contained GPU context may be prohibited from submitting new execution buffers.

The driver-level restriction must be effective against the relevant submission route, including alternative queues and delegated contexts within scope.

7.7.64. C-84.55 - Hypervisor Submission Control

A hypervisor may prohibit a contained VM from creating new affected virtual device submissions.

Where a device is passed through directly, the hypervisor must also coordinate the applicable hardware mapping or queue restrictions.

7.7.65. C-84.56 - Software Fence Acknowledgment

The software controller reports effective enforcement status and the associated generation.

The containment controller does not assume the restriction has taken effect merely because a rule was requested.

7.7.66. PART VIII - HARDWARE CONTAINMENT

7.7.67. C-84.57 - Hardware Restriction Scope

The hardware controller may restrict:

(a) new queue entries; (b) queue scheduling; (c) descriptor fetching; (d) memory-access mappings;

(e) hardware resource permissions;

(f) accelerator execution contexts;

(g) virtual-function access;

(h) privileged device commands.

7.7.68. C-84.58 - Device Restriction Semantics

Different devices provide different capabilities.

A device may support:

STOP_NEW_SUBMISSIONS.

PAUSE_QUEUE.

DRAIN_QUEUE.

CANCEL_PENDING.

ABORT_CONTEXT.

RESET_ENGINE.

INVALIDATE_MAPPING.

FENCE_ACCESS.

The selected operation must provide the required security effect according to device documentation and verified behavior.

7.7.69. C-84.59 - Hardware Restriction Acknowledgment

A protected or authoritative controller may report:

DeviceID.

QueueID.

ContainmentGeneration.

RestrictionOperation.

EffectiveBarrierSequence.

PendingCommandCount.

OutstandingAccessState.

RestrictionStatus.

The containment-completion controller evaluates this information against the required restriction set.

7.7.70. C-84.60 - Queue Stop Versus Queue Drain

Stopping new queue dispatch is not necessarily equivalent to draining in-flight operations.

A queue may be stopped while the device still processes commands already fetched.

The controller therefore separately evaluates outstanding work.

7.7.71. C-84.61 - Hardware Reset

A reset may terminate some device execution.

However, its precise effects depend upon the device and interconnect.

A reset acknowledgment does not universally prove that every previously issued memory write or network transmission was canceled.

The controller uses the relevant completion and fencing semantics to establish the required result.

7.7.72. PART IX - NETWORK TRANSMISSION

7.7.73. CONTAINMENT

7.7.74. C-84.62 - Network Effect Boundary

For enforcement point(s) 85, the network containment mechanism distinguishes packets that have irreversibly left the controlled interface from packets still preventable from transmission.

The implementation must define the observable transmission boundary.

For example:

NIC_EGRESS_BOUNDARY.

PHYSICAL_TRANSMIT_COMPLETION.

ANOTHER_VERIFIABLE_DEVICE_EGRESS_STATE.

Transmission from the NIC does not automatically prove receipt by a remote application.

| C-84.63 - Network Queue Inventory The controller identifies: 1. Transmit descriptors not yet fetched. 2. Device-fetched descriptors. 3. Packets scheduled for transmission. 4. Partially transmitted data. 5. Packets already transmitted. 6. Packets canceled before transmission. 7. Commands with uncertain completion.              |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-84.64 - Preventing New Network Submission The software controller denies new affected send operations. The hardware controller prevents the affected queue from accepting or executing further work beyond the permitted containment policy. Both restrictions may be necessary.                                                      |
| C-84.65 - Pending Packet Cancellation Where the NIC supports cancellation of queued packets, the controller requests cancellation. It verifies that the packets were prevented from crossing the defined egress boundary. A packet removed from host software memory is not necessarily canceled if its descriptor was already fetched. |

7.7.75. C-84.66 - Already Transmitted Packets

Packets already transmitted are recorded separately.

They are not included among verifiably canceled packets.

The system may retain:

PacketOrDescriptorID.

TransmitQueueID.

EffectQuantity.

TransmissionEvidence.

TransmissionStatus.

7.7.76. C-84.67 - Partial Network Completion

A command may represent several packets or a segmented transmission.

Some packets may have transmitted while others remain queued.

The controller accounts separately for the completed and canceled portions.

7.7.77. C-84.68 - Packet Transmission Race

A packet may leave the NIC while containment is being applied.

The controller establishes whether the packet crossed the egress boundary before the effective restriction.

It does not retroactively classify the packet as canceled.

7.7.78. C-84.69 - Shared Network Interface

A SmartNIC may serve several workloads.

The containment controller may use per-queue, per-virtual-function, per-tenant, or percommand restrictions.

Where the device does not support sufficiently precise isolation, broader interface restriction may be required.

7.7.79. PART X - DMA AND IOMMU CONTAINMENT

7.7.80. C-84.70 - DMA Access Context

A DMA operation may be associated with:

DeviceID.

PASID.

IOMMUDomain.

AddressSpaceID.

CommandID.

QueueID.

TransferRange.

SubmissionGeneration.

7.7.81. C-84.71 - Mapping Revocation

An IOMMU-related controller may invalidate or remove a mapping permitting a device to access selected memory.

The implementation must consider whether:

(a) the device caches address translations; (b) invalidation acknowledgment is required; (c) transactions already issued may still complete; (d) outstanding posted writes exist; (e) alternate mappings remain valid; and

(f) an ATS or related device translation facility is in use.

7.7.82. C-84.72 - Mapping Invalidation Is Not Always Quiescence 

| A mapping update may prevent future address translations. It does not necessarily prove that all previously translated or issued accesses have settled. The containment-completion controller therefore requires the applicable device and interconnect quiescence or completion evidence.                                                                               |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-84.73 - DMA Queue Fencing The controller may: 1. Deny new DMA descriptors. 2. Suspend queue processing. 3. Abort supported pending descriptors. 4. Revoke device access. 5. Synchronize mapping invalidations. 6. Await outstanding completion. 7. Record unresolved accesses.                                                                                         |
| C-84.74 - Partially Completed DMA A DMA command may write only part of its target region before containment. The system records confirmed completed portions where available. It does not claim that already written memory has automatically returned to its earlier state. If correction is necessary, it constitutes a separate resource-state remediation operation. |

7.7.83. C-84.75 - Device Translation Cache

A device may retain translations or other access state beyond the host's immediate mapping modification.

The controller applies the required invalidation and synchronization protocol.

Containment remains incomplete where the device may continue making unauthorized accesses.

7.7.84. C-84.76 - Unresolved DMA Access

If a DMA operation may still access protected memory and no effective fence is established, the command remains an unresolved containment blocker.

The controller cannot report full containment merely because the host process has been terminated.

7.7.85. PART XI - ACCELERATOR CONTAINMENT

7.7.86. C-84.77 - Accelerator Command Context

A GPU or other accelerator may maintain:

ExecutionContextID.

CommandQueueID.

CommandBufferID.

DMAOutputReference.

DeviceMemoryMapping.

SubmissionGeneration.

OutstandingWorkCount.

7.7.87. C-84.78 - New Accelerator Submission Restriction

The software controller blocks new affected command buffers or kernel submissions.

The accelerator controller restricts the corresponding hardware execution queue.

7.7.88. C-84.79 - Already Executing Accelerator Work 

| An accelerator operation may continue after host submission is blocked. The controller determines whether the supported hardware can: (a) preempt the operation; (b) suspend the context; (c) abort the command; (d) fence output access; (e) wait for completion; or (f) reset the relevant engine.                                                                                                                     |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-84.80 - Output Effect Isolation A running accelerator may produce outputs in device-local memory. Whether this constitutes an external resource effect depends upon the selected boundary. For example, a kernel producing private intermediate registers may be less consequential than one completing a DMA write to a protected host resource. The controller identifies which output interfaces must be contained. |
| C-84.81 - Shared Accelerator Several agents may use a shared accelerator. The controller must identify which commands belong to the affected execution context. If command-level selective cancellation is unavailable, the implementation may require a broader hardware reset or queue restriction.                                                                                                                    |

7.7.89. PART XII - IN-FLIGHT OPERATION INVENTORY

7.7.90. C-84.82 - Inventory Purpose

The inventory identifies previously admitted commands that may still produce effects after containment begins.

The inventory is not restricted to commands still visible in an ordinary host process queue.

It may include device-fetched or downstream queued work.

7.7.91. C-84.83 - Command State

A representative command state comprises:

NOT_SUBMITTED.

SOFTWARE_STAGED.

HARDWARE_QUEUED.

DEVICE_FETCHED.

EXECUTING.

PARTIALLY_COMPLETED.

COMPLETED.

CANCELLATION_REQUESTED.

VERIFIABLY_CANCELED.

UNRESOLVED.

7.7.92. C-84.84 - Inventory Cutoff

The system establishes a cutoff associated with the effective software admission fence.

All commands admitted before the cutoff that remain potentially executable must be accounted for.

A command cannot be omitted merely because its initiating process has exited.

7.7.93. C-84.85 - Queue Enumeration

The controller queries applicable queue or device state.

It may use:

Driver submission ledgers.

Hardware descriptor indexes.

Queue producer-consumer pointers.

Completion rings.

Device context tables.

DMA tracking state.

Accelerator work registries.

Protected submission records.

7.7.94. C-84.86 - Inventory Completeness

The controller establishes whether the inventory covers all affected queues and resource interfaces required by the containment policy.

If a necessary queue cannot be inspected, the controller may require a broader execution fence or mark containment incomplete.

7.7.95. C-84.87 - Command Identity

Each command may have a protected or uniquely associated identity.

A representative identity comprises:

DeviceID.

QueueID.

CommandGeneration.

DescriptorSequence.

ExecutionContextID.

LogicalOperationID.

This supports settlement and prevents duplicate accounting.

7.7.96. PART XIII - OPERATION SETTLEMENT

7.7.97. C-84.88 - Completed Operation

A command is classified COMPLETED when authoritative evidence establishes its completion according to the selected effect boundary.

The completed effect remains recorded.

7.7.98. C-84.89 - Verifiably Canceled Operation

A command is classified VERIFIABLY_CANCELED when the controller establishes that its remaining relevant effect cannot occur.

Evidence may include:

1. An authoritative hardware cancellation. 2. An effective command execution fence. 3. Queue removal plus proof of non-fetch. 4. Device context quiescence. 5. Required DMA invalidation and outstanding-access settlement. 6. Other native device proof of non-effectuation.

7.7.99. C-84.90 - Unresolved Operation

An operation is UNRESOLVED when the system lacks sufficient evidence to classify completion or cancellation.

The controller additionally determines whether the unresolved command remains capable of bypassing the containment restrictions.

7.7.100. C-84.91 - Unresolved but Fenced

A command may have unknown historical completion status while the affected device context is now fully fenced.

The controller may record:

SettlementClass = UNRESOLVED.

FutureBypassCapability = VERIFIED_ABSENT.

Such a command does not necessarily block the no-further-bypass condition, but it remains unresolved for historical accounting or remediation.

7.7.101. C-84.92 - Unresolved and Still Executable

A command may remain:

SettlementClass = UNRESOLVED.

FutureBypassCapability = POSSIBLE.

In this case, verified containment is withheld.

7.7.102. C-84.93 - Settlement Record

A representative record comprises:

CommandID.

ContainmentGeneration.

EffectClass.

LastObservedState.

CompletedEffectReference.

CancellationEvidenceReference.

FutureExecutionCapability.

SettlementClass.

SettlementGeneration.

7.7.103. C-84.94 - Settlement Race

Completion and cancellation evidence may arrive concurrently.

The settlement mechanism serializes state updates and prevents a command from being simultaneously recorded as wholly completed and wholly canceled contrary to actual partialeffect evidence.

7.7.104. PART XIV - VERIFIED CONTAINMENT COMPLETION

7.7.105. C-84.95 - Completion Barrier

The containment-completion controller evaluates:

SOFTWARE_FENCE_EFFECTIVE.

HARDWARE_RESTRICTIONS_EFFECTIVE.

IN_FLIGHT_BYPASS_ABSENT.

All three must hold.

7.7.106. C-84.96 - Software Restriction Evidence

The evidence identifies:

AppliedContainmentGeneration.

AffectedExecutionContext.

RestrictedOperationClasses.

EffectiveAdmissionCutoff.

EnforcementController.

VerificationStatus.

7.7.107. C-84.97 - Hardware Restriction Evidence

The evidence identifies:

DeviceID.

AffectedQueueOrMapping.

AppliedContainmentGeneration.

RestrictionClass.

RestrictionEffectiveState.

OutstandingAccessStatus.

VerificationStatus.

7.7.108. C-84.98 - In-Flight Settlement Evidence

The evidence identifies:

1. Previously admitted commands. 2. Confirmed completed effects. 3. Verified canceled commands. 4. Unresolved operations. 5. Commands incapable of future effectuation. 6. Commands still capable of bypass.

7.7.109. C-84.99 - Completion Decision

A containment-completion controller may return:

CONTAINED_VERIFIED.

CONTAINMENT_INCOMPLETE.

SETTLEMENT_PENDING.

HARDWARE_RESTRICTION_UNVERIFIED.

SOFTWARE_RESTRICTION_UNVERIFIED.

RECOVERY_RESTRICTED.

A favorable response requires the specified effective conditions.

7.7.110. C-84.100 - Unknown Hardware State

Where required hardware state is unknown, the controller does not declare verified containment solely because no further events are observed.

Absence of telemetry is not proof of quiescence.

7.7.111. C-84.101 - Containment Scope Report

A containment report may identify:

ContainmentGeneration.

AffectedExecutionContexts.

RestrictedSoftwarePaths.

RestrictedHardwarePaths.

CompletedOperations.

CanceledOperations.

UnresolvedOperations.

ResidualHistoricalEffects.

VerificationStatus.

The report should distinguish the covered scope from uncontrolled systems or external destinations.

7.7.112. PART XV - MIGRATION, RESTART, AND FAILOVER

7.7.113. C-84.102 - Containment Across Host Restart

A restarted host may recreate process or device state.

Before allowing normal execution, the Recovery Controller checks the protected current containment generation.

Old process state does not override the active restriction.

7.7.114. C-84.103 - Checkpoint Restoration

A restored checkpoint may contain:

Old device mappings.

Old queue registrations.

Old process permissions.

Old network configuration.

The restore mechanism applies or reconciles the current containment generation before enabling effect-capable interfaces.

7.7.115. C-84.104 - Virtual-Machine Migration

A migrating VM may contain an affected agent workload.

The destination receives:

AffectedExecutionContext.

ContainmentGeneration.

RestrictionSet.

InFlightCommandState.

RelevantDeviceMappings.

VerificationStatus.

The destination applies and verifies the required restrictions before normal resumption.

7.7.116. C-84.105 - Source-Host Fencing

A migrated workload may remain partly executable at the source host.

The migration protocol must ensure that the old and new environments cannot both execute affected commands in violation of the containment state.

The source may be fenced before destination activation.

If source state cannot be conclusively determined, destination resumption remains restricted according to the policy.

7.7.117. C-84.106 - Queue Relocation

A queue may move to a different hardware controller.

The new controller receives or reconstructs the active containment generation.

Previously restricted commands are not reclassified as unrestricted solely because their queue identity changed.

7.7.118. C-84.107 - Hardware Failover

A standby device may take over a resource-operation queue.

Before accepting normal commands, the standby verifies the current containment restrictions.

Old failover snapshots or queue descriptors must not restore an unrestricted execution state.

7.7.119. C-84.108 - Device Reset Recovery

Following a device reset, the Recovery Controller identifies:

1. Current containment generation. 2. Surviving mappings. 3. Recreated queues.

4. Previously admitted command status. 5. Unresolved effects. 6. Current hardware restriction state.

Normal operation remains restricted until consistency is established.

7.7.120. C-84.109 - Containment Generation Rollback

A checkpoint or database snapshot may restore an earlier generation.

The protected registry or generation authority rejects an obsolete state where a later containment remains active.

7.7.121. C-84.110 - Recovery Restriction

A destination environment may accept migrated data for recovery purposes without allowing unrestricted effectuation.

For example:

Memory state may be restored.

Device queues may remain disabled.

Native resource access may remain denied.

Containment verification must precede normal effect-capable execution.

7.7.122. PART XVI - PRINCIPAL 40-STEP

7.7.123. WORKFLOW

7.7.124. C-84.111 - Complete Containment Workflow

7.7.125. Step C84-01 - Agent environment initialization

The system establishes identifiable agent execution contexts and relevant resource-operation interfaces.

7.7.126. Step C84-02 - Device association registration

Accessible queues, mappings, and hardware control interfaces are associated with their execution contexts.

7.7.127. Step C84-03 - Runtime observation

A kernel, eBPF, hypervisor, or protected telemetry mechanism observes security-relevant events.

7.7.128. Step C84-04 - Security event normalization

An observed event is converted into a machine-readable event record.

7.7.129. Step C84-05 - Execution context attribution

The event is associated with the affected agent or delegated workload.

7.7.130. Step C84-06 - Containment-condition evaluation

The decision engine determines whether the event satisfies a designated security condition.

7.7.131. Step C84-07 - Affected resource scope determination

The controller identifies resource-operation classes and interfaces requiring restriction.

7.7.132. Step C84-08 - Containment generation allocation

A new protected containment generation is assigned.

7.7.133. Step C84-09 - Containment state commitment

The affected context and restriction set are recorded.

7.7.134. Step C84-10 - Software admission restriction issuance

The software controller is instructed to stop admitting new affected commands.

7.7.135. Step C84-11 - Software enforcement activation

The required kernel, hypervisor, driver, or tool-dispatch restriction becomes effective.

7.7.136. Step C84-12 - Software fence acknowledgment

The controller obtains effective restriction evidence and an admission cutoff.

7.7.137. Step C84-13 - Hardware interface enumeration

The system identifies relevant NIC, DMA, storage, accelerator, and device interfaces.

7.7.138. Step C84-14 - Hardware restriction issuance

Corresponding device restrictions are requested.

7.7.139. Step C84-15 - Hardware restriction application

Device queues and mappings are restricted.

7.7.140. Step C84-16 - Hardware effective-state verification

The controller confirms the required hardware barriers are active.

7.7.141. Step C84-17 - Pre-fence command inventory

Commands admitted before the software cutoff are identified.

7.7.142. Step C84-18 - Queue ownership reconciliation

Relevant driver and hardware command states are reconciled.

7.7.143. Step C84-19 - Command identity verification

Command records are associated with the affected execution context.

7.7.144. Step C84-20 - Completed operation identification

Confirmed completed commands are classified.

7.7.145. Step C84-21 - Pending operation identification

Commands that have not completed are identified.

7.7.146. Step C84-22 - Supported cancellation evaluation

The controller determines which pending operations can be canceled.

7.7.147. Step C84-23 - Network queue settlement

Affected packets are classified as transmitted, canceled, or unresolved.

7.7.148. Step C84-24 - DMA access settlement

Outstanding memory accesses are quiesced, completed, or canceled where supported.

7.7.149. Step C84-25 - Accelerator settlement

Applicable accelerator commands are drained, canceled, or otherwise fenced.

7.7.150. Step C84-26 - Partial completion reconciliation

Completed portions of affected commands are recorded.

7.7.151. Step C84-27 - Residual command capability evaluation

The controller determines whether any unresolved command can still bypass containment.

7.7.152. Step C84-28 - Broader restriction if required

Where selective control is insufficient, a suitable broader hardware restriction is applied.

7.7.153. Step C84-29 - Final software verification

The software restriction is confirmed current.

7.7.154. Step C84-30 - Final hardware verification

The hardware restriction is confirmed current.

7.7.155. Step C84-31 - In-flight bypass verification

The controller verifies that no unresolved affected command remains capable of bypass.

7.7.156. Step C84-32 - Containment completion decision

The controller reports verified containment or an incomplete status.

7.7.157. Step C84-33 - Containment evidence commitment

Applied generations, command states, and verification references are recorded.

7.7.158. Step C84-34 - Restart or migration detection

The system detects an applicable recovery transition.

7.7.159. Step C84-35 - Protected generation retrieval

The current containment generation is obtained from the protected registry.

7.7.160. Step C84-36 - Destination restriction application

The destination environment installs the required restrictions.

7.7.161. Step C84-37 - Outstanding operation reconciliation

Migrated or surviving commands are inventoried and reconciled.

7.7.162. Step C84-38 - Destination consistency verification

The current queues and mappings are checked against the transferred containment state.

7.7.163. Step C84-39 - Restricted or authorized resumption

The destination permits only execution consistent with the verified containment generation.

7.7.164. Step C84-40 - Recovery audit commitment

The final recovery and containment state is recorded.

7.7.165. PART XVII - REFERENCE IMPLEMENTATION ALGORITHMS

7.7.166. C-84.112 - Algorithm A: Security Event Attribution 

function AssociateSecurityEventWithAgent(event):
source = VerifyObservationSource(event)
if source is invalid:
return UNVERIFIED_EVENT
identity = ResolveStableExecutionIdentity({
host_boot_id: event.host_boot_id,
process_namespace: event.pid_namespace,
process_creation_id: event.creation_id,
container_or_vm_id: event.workload_id,
task_reference: event.task_id
})
if identity is unresolved:
return ATTRIBUTION_INCOMPLETE
interfaces = ResourceInterfaceRegistry.lookup(
identity
)
return {
execution_context: identity,
hardware_interfaces: interfaces,
event_reference: event.id
}

A process identifier alone is not necessarily a stable workload identity.

7.7.167. C-84.113 - Algorithm B: Containment Decision 

function EvaluateContainmentCondition(
security_event,
execution_context
):
policy = ResolveCurrentContainmentPolicy(
execution_context
)
outcome = EvaluateSecurityDeviation(
security_event,
policy
)
if outcome does not satisfy containment_condition:
return NO_CONTAINMENT_REQUIRED
restriction_set = DeriveAffectedRestrictions({
event: security_event,
context: execution_context,
policy: policy
})
return {
decision: CONTAINMENT_REQUIRED,
restrictions: restriction_set
}

7.7.168. C-84.114 - Algorithm C: Establish Protected Containment Generation 

function EstablishContainment(
execution_context,
restriction_set
):
begin protected_transaction
generation = AdvanceMonotonicContainmentGeneration(
execution_context
)
containment_id = AllocateContainmentID()
record = ProtectedContainmentRegistry.commit({
containment_id: containment_id,
execution_context: execution_context,
generation: generation,
restrictions: restriction_set,
state: CONTAINMENT_REQUESTED
})
commit protected_transaction
return record

The agent cannot select an earlier permissive generation.

7.7.169. C-84.115 - Algorithm D: Software Command Admission Fence 

function ApplySoftwareContainment(containment):
targets = ResolveSoftwareAdmissionInterfaces(
containment.execution_context,
containment.restrictions
)
acknowledgments = EmptySet()
for each target in targets:
result = target.applyRestriction({
context: containment.execution_context,
generation: containment.generation,
denied_operation_classes:
containment.restrictions
})
acknowledgments.add(result)
if not AllRequiredRestrictionsEffective(
acknowledgments,
containment.generation
):
return SOFTWARE_FENCE_INCOMPLETE
cutoff = ResolveAuthoritativeAdmissionCutoff(
acknowledgments
)
return {
status: SOFTWARE_FENCE_EFFECTIVE,
admission_cutoff: cutoff
}

The admission cutoff is used to identify commands requiring hardware settlement.

7.7.170. C-84.116 - Algorithm E: Hardware Restriction Application 

function ApplyHardwareContainment(containment):
interfaces = ResourceInterfaceRegistry.lookup(
containment.execution_context
)
results = EmptySet()
for each interface in interfaces:
if not InterfaceAffectedByRestriction(
interface,
containment.restrictions
):
continue
result = HardwareControlService.apply({
interface_id: interface.id,
containment_generation: containment.generation,
restriction: ResolveDeviceRestriction(
interface,
containment
)
})
results.add(result)
if not VerifyRequiredHardwareEffectiveState(
results,
containment.generation
):
return HARDWARE_FENCE_INCOMPLETE
return HARDWARE_RESTRICTIONS_EFFECTIVE

An acknowledgment of a requested configuration is not necessarily evidence of effective hardware fencing.

7.7.171. C-84.117 - Algorithm F: In-Flight Command Inventory 

function InventoryAffectedCommands(
containment,
software_cutoff
):
interfaces = ResourceInterfaceRegistry.lookup(
containment.execution_context
)
inventory = EmptySet()
for each interface in interfaces:
commands = QueryAuthoritativeCommandState({
interface: interface,
execution_context:
containment.execution_context,
admitted_before: software_cutoff
})
if commands are unavailable:
inventory.markIncomplete(interface)
continue
for each command in commands:
inventory.add({
command_id: command.id,
queue_id: command.queue_id,
device_id: command.device_id,
effect_class: command.effect_class,
execution_state: command.state,
completion_reference:
command.completion_evidence
})
return inventory

The inventory includes previously admitted work, including device-fetched commands where observable.

7.7.172. C-84.118 - Algorithm G: Command Settlement Classification 

function ClassifyInFlightCommand(command):
completion = VerifyAuthoritativeCompletion(command)
if completion == CONFIRMED_COMPLETED:
return {
class: COMPLETED,
future_bypass: FALSE
}
cancellation = VerifyAuthoritativeCancellation(command)
if cancellation == CONFIRMED_CANCELED:
return {
class: VERIFIABLY_CANCELED,
future_bypass: FALSE
}
fencing = VerifyEffectiveExecutionFence(command)
if fencing == FENCE_EFFECTIVE:
return {
class: UNRESOLVED,
future_bypass: FALSE,
evidence: fencing
}
return {
class: UNRESOLVED,
future_bypass: POSSIBLE
}

Unknown historical completion may coexist with a verified absence of future effectuation capability.

7.7.173. C-84.119 - Algorithm H: Network Transmission Settlement 

function SettleNetworkQueue(containment, queue):
ApplyTransmitQueueRestriction(
queue,
containment.generation
)
packets = QueryNICTransmitState(queue)
result = {
transmitted: EmptySet(),
canceled: EmptySet(),
unresolved: EmptySet()
}
for each packet in packets:
if VerifyPacketCrossedEgressBoundary(packet):
result.transmitted.add(packet)
else if VerifyPacketCanceledBeforeEgress(packet):
result.canceled.add(packet)
else:
result.unresolved.add(packet)
return result

Already transmitted packets are not represented as canceled.

7.7.174. C-84.120 - Algorithm I: DMA and IOMMU Settlement 

function ContainDMAContext(
containment,
dma_context
):
BlockNewDMASubmissions(dma_context)
ApplyRequiredIOMMUMappingRestriction(
dma_context,
containment.generation
)
SynchronizeRequiredTranslationInvalidations(
dma_context
)
FenceDeviceExecutionContext(dma_context)
outstanding = QueryOutstandingDMAOperations(
dma_context
)
settlement = EmptySet()
for each operation in outstanding:
settlement.add(
ClassifyInFlightCommand(operation)
)
if AnyOperationCanStillBypass(settlement):
return DMA_CONTAINMENT_INCOMPLETE
return {
status: DMA_CONTAINED,
settlement: settlement
}

The algorithm depends upon actual device and IOMMU capabilities and completion semantics.

7.7.175. C-84.121 - Algorithm J: Accelerator Queue Containment 

function ContainAcceleratorContext(
containment,
accelerator_context
):
DenyNewAcceleratorSubmissions(
accelerator_context
)
restriction = ApplySupportedAcceleratorFence(
accelerator_context,
containment.generation
)
if restriction is not effective:
return CONTAINMENT_INCOMPLETE
commands = InventoryAcceleratorCommands(
accelerator_context
)
results = EmptySet()
for each command in commands:
results.add(
ClassifyInFlightCommand(command)
)
if AnyOperationCanStillBypass(results):
return CONTAINMENT_INCOMPLETE
return ACCELERATOR_CONTAINED

7.7.176. C-84.122 - Algorithm K: Final Containment Barrier 

function VerifyContainmentCompletion(containment):
software = VerifySoftwareRestrictionEffective(
containment
)
if software != TRUE:
return SOFTWARE_CONTAINMENT_INCOMPLETE
hardware = VerifyHardwareRestrictionsEffective(
containment
)
if hardware != TRUE:
return HARDWARE_CONTAINMENT_INCOMPLETE
inventory = LoadCurrentInFlightInventory(
containment
)
if not InventoryCoverageSufficient(inventory):
return INVENTORY_INCOMPLETE
for each command in inventory:
result = ClassifyInFlightCommand(command)
if result.future_bypass != FALSE:
return SETTLEMENT_PENDING
ProtectedContainmentRegistry.commitStatus({
containment_id: containment.id,
generation: containment.generation,
status: CONTAINED_VERIFIED
})
return CONTAINED_VERIFIED

This implements the three-part completion condition of enforcement point(s) 84.

7.7.177. C-84.123 - Algorithm L: Restart-Safe Recovery 

function RecoverContainedWorkload(workload_id):
current = ProtectedContainmentRegistry.getCurrent(
workload_id
)
if current is unavailable:
return RESTRICTED_RECOVERY
PreventUnrestrictedResourceAccess(workload_id)
ApplySoftwareContainment(current)
ApplyHardwareContainment(current)
inventory = ReconcileCurrentHardwareCommands(
workload_id,
current
)
if not VerifyContainmentStateConsistency(
current,
inventory
):
return RESTRICTED_RECOVERY
return ALLOW_ONLY_CONTAINMENT_COMPATIBLE_EXECUTION

7.7.178. C-84.124 - Algorithm M: Migration and Destination Verification 

function MigrateContainedExecutionContext(
workload_id,
source,
destination
):
state = ProtectedContainmentRegistry.getCurrent(
workload_id
)
if state is unavailable:
return DENIED
SuspendUnrestrictedSourceExecution(
source,
workload_id
)
transfer = BuildAuthenticatedContainmentTransfer({
workload_id: workload_id,
generation: state.generation,
restrictions: state.restrictions,
unresolved_commands:
state.unresolved_command_references
})
destination.enterRestrictedRecovery(workload_id)
destination.applyContainmentTransfer(transfer)
if not destination.verifyCurrentQueuesAndMappings(
transfer
):
return DESTINATION_RESTRICTED
if not VerifySourceExecutionFenced(
source,
workload_id
):
return MIGRATION_INCOMPLETE
return MIGRATED_WITH_CONTAINMENT

A destination does not resume unrestricted effectuation merely because migration data was copied successfully.

7.7.179. C-84.125 - Algorithm N: Stale Generation Rejection 

function ValidateRestoredExecutionState(
workload_id,
restored_state
):
current_generation =
ProtectedContainmentRegistry.currentGeneration(
workload_id
)
if restored_state.generation < current_generation:
return STALE_RESTORE_DENIED
if not VerifyRestoredRestrictionSet(
restored_state,
current_generation
):
return RESTRICTED_RECOVERY
if not VerifyOutstandingCommandReconciliation(
restored_state
):
return RESTRICTED_RECOVERY
return RESTORE_CONTAINMENT_COMPATIBLE

7.7.180. C-84.126 - Algorithm O: Containment Evidence Reconciliation 

function ReconcileContainmentEvidence(containment):
software = CollectSoftwareFenceEvidence(containment)
hardware = CollectHardwareFenceEvidence(containment)
commands = CollectCommandSettlementEvidence(containment)
if not VerifyGenerationConsistency({
software,
hardware,
commands
}):
return GENERATION_MISMATCH
if not VerifyEvidenceCoverage({
software,
hardware,
commands
}):
return INCOMPLETE_EVIDENCE
return CommitContainmentEvidence({
containment_id: containment.id,
generation: containment.generation,
software_evidence: software,
hardware_evidence: hardware,
command_settlement: commands
})

7.7.181. PART XVIII - WORKED TECHNICAL EXAMPLES

7.7.182. C-84.127 - Example A: Agent Credential Exposure Followed by NIC Containment

The following is a hypothetical implementation example.

An AI-agent process accesses a protected credential outside its permitted task scope.

A runtime monitor detects the event.

The Containment-Decision Engine establishes Generation 47.

The software controller denies new affected network transmissions.

The NIC controller restricts the associated transmit queue.

The in-flight inventory identifies:

1. Two packets already transmitted. 2. Three packets verifiably canceled. 3. One packet with unresolved status.

The unresolved packet remains capable of transmission.

The controller reports containment incomplete.

After an effective hardware fence prevents the remaining packet from leaving the interface, containment may be verified.

The two previously transmitted packets remain recorded as completed effects.

7.7.183. C-84.128 - Example B: Process Terminated While NIC Queue Remains Active

An AI agent submits several transmit descriptors.

The host terminates the process after a security deviation.

The NIC has already fetched part of the queue.

The containment controller identifies outstanding descriptors and restricts the hardware queue.

The system does not declare containment complete merely because the process is absent from the host process table.

7.7.184. C-84.129 - Example C: DMA Mapping Revocation

An agent-controlled device context has an active DMA mapping.

A security event triggers containment.

The software controller prevents new DMA submissions.

The hardware controller revokes the applicable mapping and performs required invalidation synchronization.

Outstanding DMA operations are inventoried.

The controller waits for completion, cancellation, or sufficient quiescence evidence.

The containment status is withheld until the hardware-side condition is established.

7.7.185. C-84.130 - Example D: GPU Command Continues After Host Termination

An AI-agent process dispatches an accelerator command.

The process is then terminated.

The accelerator continues executing the command.

The containment controller restricts new submissions and identifies the outstanding accelerator work.

If hardware abort or fencing is supported, it applies the appropriate control.

If the command cannot be canceled, the controller may wait for completion while maintaining restrictions on further output or DMA operations.

Verified containment requires establishing that remaining work cannot bypass the intended controls.

7.7.186. C-84.131 - Example E: Shared NIC Queue

Two workloads share one physical network queue.

Workload A is associated with a security deviation.

Workload B remains authorized.

The controller attempts selective restriction using available queue ownership or command attribution.

If affected commands cannot be isolated reliably, it applies an appropriately broader queue restriction under the selected policy.

The system does not report selective containment while unidentifiable Workload A descriptors remain executable.

7.7.187. C-84.132 - Example F: Software Restriction Succeeds, Hardware Restriction Fails

The kernel successfully denies new device submissions.

However, the NIC does not acknowledge an effective queue restriction.

Previously queued commands may still execute.

The containment controller reports:

HARDWARE_RESTRICTION_UNVERIFIED.

It does not report full containment.

C-84.133 - Example G: Hardware Restriction Succeeds, Software Restriction Fails

The device controller restricts the affected queue.

However, a separate host submission path remains active.

The software interface has not established its required command-admission restriction.

The containment controller reports incomplete containment.

A later command cannot be assumed harmless merely because one previously identified hardware queue was restricted.

7.7.188. C-84.134 - Example H: Partial Packet Transmission

An AI-agent command contains a batch of packets.

Before containment becomes effective, some packets leave the NIC.

Other packets remain queued.

The network controller records transmitted packets separately from those it verifiably cancels.

No packet already transmitted is counted as canceled.

7.7.189. C-84.135 - Example I: eBPF Detection Without Enforcement

An eBPF tracing program identifies a prohibited access.

It emits a security event.

The eBPF program itself is configured only for observation.

A separate privileged containment controller applies an actual kernel admission restriction and corresponding hardware fencing.

The implementation does not confuse tracing with enforcement.

7.7.190. C-84.136 - Example J: VM Snapshot Restoration

A virtual machine is contained under Generation 52.

An administrator later restores a checkpoint created before containment.

The checkpoint contains an old virtual-device configuration.

The hypervisor checks the protected current containment generation.

It does not permit normal resource access under the checkpoint's earlier permissive state.

Required restrictions are applied before device queues become active.

7.7.191. C-84.137 - Example K: Migration to Another Host

A contained AI-agent VM migrates to another host.

The destination receives the active containment generation and unresolved-command references.

The destination initializes in a restricted state.

It reconciles its device queues and memory-access mappings with the transferred restrictions.

The source environment is fenced.

The destination resumes only containment-compatible execution.

7.7.192. C-84.138 - Example L: Device Failover

A SmartNIC is replaced by a standby controller.

The standby has an earlier stored device policy.

The recovery controller obtains the latest protected containment generation.

It applies the corresponding restrictions to the standby queues.

The stale device snapshot does not restore the contained agent's unrestricted transmission authority.

C-84.139 - Example M: Unknown Historical Completion but Effective Fence

A DMA command has an indeterminate earlier completion outcome.

The controller establishes that all affected access mappings are now restricted and outstanding transactions cannot produce further protected writes.

The command remains classified:

UNRESOLVED.

However:

FutureBypassCapability = VERIFIED_ABSENT.

The controller may satisfy the no-further-bypass condition while retaining the historical uncertainty for accounting and remediation.

7.7.193. C-84.140 - Example N: Unknown Completion and No Effective Fence

A DMA command has an indeterminate completion outcome.

The device controller cannot confirm quiescence.

The command may still write to protected memory.

The containment controller reports:

SETTLEMENT_PENDING.

It does not declare full containment.

7.7.194. C-84.141 - Example O: Delegated Worker with Separate Queue

An AI agent delegates execution to a worker process.

The worker uses a separate accelerator queue.

The root task is contained after a security deviation.

The execution-context association registry identifies the delegated worker and its device queue.

The containment restriction applies to the affected delegated execution path.

Creating the worker does not remove the root task's containment.

7.7.195. C-84.142 - Example P: Network and DMA Containment Together

An agent accesses an unauthorized resource and has outstanding network transmissions and DMA writes.

The software controller restricts both network and DMA command admission.

The NIC controller fences relevant transmit queues.

The DMA controller restricts the affected mapping and settles outstanding access.

The containment-completion controller evaluates all required interfaces before reporting success.

Verification of the NIC alone is insufficient when the DMA interface remains within the designated containment scope.

7.7.196. PART XIX - FAILURE AND ADVERSARIAL CONDITIONS

7.7.197. C-84.143 - Representative Failure Cases

7.7.198. F1 - Detection Treated as Containment

A security event is logged, but no execution restrictions are applied.

The system must distinguish alert generation from effective containment.

7.7.199. F2 - Process Termination Only

The agent process exits while hardware commands remain active.

In-flight hardware operations require separate settlement or fencing.

7.7.200. F3 - eBPF Telemetry Misclassified as Enforcement

An observational program detects a deviation but cannot deny commands.

An actual enforcement interface is required.

7.7.201. F4 - Missing Execution-Context Attribution

The event cannot be reliably associated with an agent.

The system must not invent precise hardware command ownership.

7.7.202. F5 - PID Reuse

A new process receives the same numeric PID as the contained process.

Stable context identity prevents misattribution.

7.7.203. F6 - Delegated Worker Omitted

A child or delegated worker retains an effectuation queue.

The affected context registry must include relevant delegation paths.

7.7.204. F7 - Shared Queue Attribution Failure

A shared device queue contains commands from several workloads.

Selective containment is withheld or broadened where attribution is insufficient.

7.7.205. F8 - Software Fence Race

New commands enter after the containment decision but before the restriction becomes effective.

The admission cutoff and in-flight inventory must include the relevant commands.

7.7.206. F9 - Hardware Fence Race

A device fetches additional descriptors while restrictions are being applied.

The controller accounts for commands admitted before the effective device barrier.

7.7.207. F10 - Configuration Receipt Mistaken for Effectiveness

A hardware controller acknowledges the request but has not activated the restriction.

Containment completion requires effective-state evidence.

7.7.208. F11 - Queue Stop Without Drain

The queue stops accepting new entries while fetched commands continue executing.

In-flight settlement remains necessary.

7.7.209. F12 - NIC Packet Already Transmitted

A packet crossed the egress boundary before cancellation.

It remains classified as transmitted.

7.7.210. F13 - NIC Cancellation Not Confirmed

A cancellation request is accepted but the packet may still transmit.

The command remains unresolved.

7.7.211. F14 - Partial Packet Transmission

Part of a batch transmits before containment.

Completed and canceled portions are recorded separately.

7.7.212. F15 - NIC Alternate Queue

The agent can transmit through another queue.

The containment scope must address the relevant alternate interface.

7.7.213. F16 - NIC Virtual Function Bypass

A virtual function retains unrestricted transmit authority.

Appropriate virtual-function or device-level restrictions are required.

7.7.214. F17 - DMA Mapping Revoked Without Synchronization

A mapping is changed but device translations remain usable.

Required invalidation and quiescence semantics must be enforced.

7.7.215. F18 - Outstanding DMA Posted Write

A previously issued write may still complete.

The controller does not assume mapping revocation retroactively cancels it.

7.7.216. F19 - Device Translation Cache Stale

A device retains old address translations.

The relevant invalidation and synchronization procedure is required.

7.7.217. F20 - Accelerator Command Continues

Host submission is blocked but accelerator work remains active.

Hardware command settlement is required.

7.7.218. F21 - Accelerator Reset Ambiguity

The accelerator reports reset but prior output effects are uncertain.

The result is reconciled according to device completion semantics.

7.7.219. F22 - Storage Submission Queue Continues

A storage command submitted before containment remains executable.

The hardware restriction must account for the command.

7.7.220. F23 - Incorrect Completion Semantics

The controller treats descriptor retirement as proof of completed external effect.

The implementation must use the defined resource-effect boundary.

7.7.221. F24 - Incomplete Command Inventory

A required hardware queue cannot be enumerated.

Containment completion is withheld unless a broader effective fence establishes the nobypass condition.

7.7.222. F25 - Duplicate Command Records

The same command appears in multiple logs.

Stable identity prevents incorrect settlement accounting.

7.7.223. F26 - Lost Completion Acknowledgment

The outcome of a command is unknown.

The system retains unresolved classification and evaluates future execution capability.

7.7.224. F27 - Unresolved Command Still Executable

A command might still produce a protected effect.

Verified containment is withheld.

7.7.225. F28 - Unresolved Command Effectively Fenced

Historical completion is unknown but future execution is impossible.

The controller distinguishes historical uncertainty from future-bypass risk.

7.7.226. F29 - Cancellation-Completion Race

A command completes while cancellation is requested.

Settlement reflects actual confirmed effectuation.

7.7.227. F30 - Software Restriction Stale

The software gate still enforces an older generation.

Containment completion is withheld.

7.7.228. F31 - Hardware Restriction Stale

The device reports a prior generation.

The new containment state has not been established.

7.7.229. F32 - Mixed Restriction Generations

Software and hardware acknowledgments refer to incompatible generations.

The containment evidence is not accepted as consistent.

7.7.230. F33 - Agent Recreates Process

The contained workload restarts under a new PID.

Protected task identity and generation controls retain the restriction.

7.7.231. F34 - Agent Reopens Device Handle

A new device handle attempts to bypass containment.

The relevant resource interface remains restricted.

7.7.232. F35 - Container Restart

The container restarts with previously allowed device permissions.

Current containment state is reapplied.

7.7.233. F36 - VM Snapshot Rollback

A VM restores pre-containment configuration.

Stale generation checks prevent unrestricted resumption.

7.7.234. F37 - VM Migration Without State Transfer

The destination lacks the current containment generation.

It remains restricted.

7.7.235. F38 - Source VM Remains Active After Migration

The source continues executing affected commands.

Source fencing or equivalent coordination is required.

7.7.236. F39 - Queue Relocation

Commands are moved to another device queue.

The containment restriction follows the relevant operation context.

7.7.237. F40 - Hardware Failover to Stale Standby

The standby controller has old access policy.

Current containment generation is required before activation.

7.7.238. F41 - Device Reset Clears Restriction Register

Reset returns hardware access to a permissive state.

Recovery reinstalls the current restriction before accepting affected commands.

7.7.239. F42 - Protected Registry Unavailable

The current containment state cannot be verified.

Recovery remains restricted.

7.7.240. F43 - Containment Generation Rollback

A stale snapshot attempts to restore an older generation.

Monotonic continuity checks reject it.

7.7.241. F44 - Forged Hardware Acknowledgment

An untrusted component fabricates an effective-state acknowledgment.

The selected controller trust and integrity mechanisms reject unsupported evidence.

7.7.242. F45 - Unknown Device Interface

The workload has an effectuation path omitted from the resource registry.

The implementation cannot enforcement point comprehensive containment over that path.

7.7.243. F46 - Telemetry Loss

Security observations stop arriving.

Absence of new alerts does not prove that containment is effective.

7.7.244. F47 - Containment Controller Crash

The coordinator crashes during containment.

Protected state and recovery rules preserve or reestablish the restrictions.

7.7.245. F48 - False Full-Containment Report

A controller reports success while unresolved commands remain able to bypass.

The completion barrier rejects the report.

7.7.246. PART XX - IMPLEMENTATION VARIATIONS

7.7.247. C-84.144 - Linux Kernel and eBPF Observation

An implementation may use eBPF telemetry to identify security events and invoke a separately enforceable kernel or hardware containment controller.

The architecture does not require tracing eBPF alone to provide mandatory access control.

7.7.248. C-84.145 - Linux Security Module Enforcement

A suitable LSM mechanism may deny selected future operations.

Hardware queues already containing work remain subject to the separate device settlement procedure.

| C-84.146 - Hypervisor Containment A hypervisor coordinates guest execution restrictions with assigned or emulated device interfaces. It preserves current containment state across VM restart and migration.                   |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| C-84.147 - Container Runtime Containment A container runtime or privileged host controller restricts new resource operations and coordinates device-level restrictions for affected containers.                                |
| C-84.148 - SmartNIC Containment A SmartNIC maintains or applies queue-specific transmission restrictions and supplies authoritative evidence concerning affected queued and transmitted packets.                               |
| C-84.149 - DPU-Hosted Containment Controller A DPU coordinates network and storage restrictions independently of the agent's ordinary host process. It records effective containment generation and outstanding command state. |

7.7.249. C-84.150 - IOMMU-Associated DMA Containment

A controller restricts mappings and coordinates device quiescence.

Mapping invalidation alone is not presumed sufficient for settlement.

7.7.250. C-84.151 - GPU Command-Queue Containment

The system restricts new submissions and applies supported accelerator command cancellation, suspension, reset, or output-access fencing.

| C-84.152 - Storage Controller Containment The controller restricts storage queue admissions and inventories outstanding write or mutation commands. Completion classification follows the native storage controller's semantics.          |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| C-84.153 - Multi-Device Containment A common generation is distributed to several software and device enforcement points. Containment completion requires effective restrictions across the selected set.                                 |
| C-84.154 - Multi-Agent Containment Several agents may share processes or queues. The system uses protected task attribution and applies selective or broader containment according to available isolation.                                |
| C-84.155 - Cross-Host Recovery A distributed containment registry preserves current generation and unresolved-command references across host failover. The destination does not resume normal effectuation until consistency is verified. |

7.7.251. C-84.156 - Hardware Controller Without Fine-Grained Cancellation

Some devices may not support per-command cancellation.

The system may use queue-wide or device-wide restriction where authorized and necessary.

The embodiment does not require an unsupported precision of hardware control.

7.7.252. C-84.157 - Optional DAS Finality Integration

A DAS Finality Sink may independently validate authorization for future external effects.

The present containment embodiment may additionally fence software and hardware interfaces following an observed security deviation.

The mechanisms are complementary.

However, enforcement point(s) 84 does not require every command to carry a separately issued DAS finality capability.

7.7.253. PART XXI - REPRESENTATIVE TECHNICAL DATA STRUCTURES

7.7.254. C-84.158 - SecurityEventRecord

Fields may include:

1. SecurityEventID. 2. ObservationSourceID. 3. EventClass. 4. EventGeneration. 5. ObservedExecutionContext. 6. ResourceReference. 7. OperationClass. 8. PolicyReference. 9. EvidenceReference. 10. EventVerificationStatus.

7.7.255. C-84.159 - ExecutionContextAssociationRecord

Fields may include:

1. 2. 3. 4. 5. 6. 7. 8. 9.

ExecutionContextID. AgentTaskID. HostBootID. ProcessCreationIdentity. ContainerOrVMID. DelegationReferences. DeviceContextReferences. AssociationGeneration. AttributionStatus.

7.7.256. C-84.160 - ResourceInterfaceRecord

Fields may include:

1. InterfaceID. 2. DeviceID. 3. QueueID. 4. InterfaceClass. 5. OwnerExecutionContext. 6. SubmissionControlReference. 7. HardwareRestrictionCapability. 8. EffectiveConfigurationGeneration. 9. InterfaceStatus.

7.7.257. C-84.161 - ContainmentStateRecord

Fields may include:

1. ContainmentID. 2. ExecutionContextID. 3. ContainmentGeneration. 4. TriggeringSecurityEventID. 5. RestrictionSet. 6. SoftwareTargetSet. 7. HardwareTargetSet. 8. ContainmentState. 9. DecisionEvidenceReference. 10. StateGeneration.

7.7.258. C-84.162 - SoftwareFenceRecord

Fields may include:

1. 2. 3. 4. 5. 6. 7. 8. 9.

SoftwareFenceID. ContainmentID. ExecutionContextID. EnforcementInterface. AppliedRestrictionSet. AppliedGeneration. AdmissionCutoffReference. EffectiveStatus. VerificationEvidence.

7.7.259. C-84.163 - HardwareFenceRecord

Fields may include:

1. HardwareFenceID. 2. ContainmentID. 3. DeviceID. 4. QueueOrMappingID. 5. RestrictionClass. 6. AppliedGeneration. 7. DeviceAcknowledgment. 8. EffectiveBarrierSequence. 9. OutstandingAccessStatus. 10. VerificationStatus.

7.7.260. C-84.164 - InFlightCommandRecord

Fields may include:

1. CommandID. 2. ExecutionContextID. 3. DeviceID. 4. QueueID. 5. AdmissionGeneration. 6. CommandEffectClass. 7. LastKnownExecutionState. 8. CompletionEvidenceReference. 9. CancellationEvidenceReference. 10. FutureBypassCapability.

7.7.261. C-84.165 - OperationSettlementRecord

Fields may include:

1. SettlementID. 2. CommandID. 3. ContainmentGeneration. 4. SettlementClass. 5. CompletedEffectReference. 6. CancellationEvidenceReference. 7. RemainingEffectCapability. 8. SettlementGeneration. 9. SettlementVerificationStatus.

7.7.262. C-84.166 - NetworkSettlementRecord

Fields may include:

1. NetworkSettlementID. 2. NICID. 3. TransmitQueueID. 4. PacketOrDescriptorIDs. 5. ConfirmedTransmittedSet. 6. VerifiedCanceledSet. 7. UnresolvedPacketSet. 8. EgressBoundaryReference. 9. ContainmentGeneration. 10. SettlementStatus.

7.7.263. C-84.167 - DMAContainmentRecord

Fields may include:

1. DMAContainmentID. 2. DeviceID. 3. PASIDOrIOMMUDomain. 4. AffectedMappingReferences. 5. TranslationInvalidationReference. 6. OutstandingDMACommandSet. 7. QuiescenceEvidence. 8. AppliedContainmentGeneration. 9. ContainmentStatus.

7.7.264. C-84.168 - ContainmentCompletionRecord

Fields may include:

1. CompletionRecordID. 2. ContainmentID. 3. ContainmentGeneration. 4. SoftwareFenceEvidence. 5. HardwareFenceEvidence. 6. InFlightInventoryReference. 7. UnresolvedBypassAssessment. 8. CompletionDecision. 9. CompletionGeneration. 10. VerificationReference.

7.7.265. C-84.169 - RecoveryContinuityRecord

Fields may include:

1. RecoveryID. 2. WorkloadID. 3. SourceEnvironmentID. 4. DestinationEnvironmentID. 5. CurrentContainmentGeneration. 6. TransferredRestrictionSet. 7. UnresolvedOperationReferences. 8. SourceFenceStatus. 9. DestinationQueueReconciliation. 10. RecoveryAuthorizationStatus.

7.7.266. PART XXII - ENGINEERING VERIFICATION TESTS

7.7.267. C-84.170 - Proposed Test Matrix

The following are proposed engineering verification tests, not completed experimental results.

7.7.268. Test Condition

T1 Kernel security event detected T2 eBPF telemetry identifies deviation T3 Observation lacks enforcement capability T4 Stable execution context available T5 PID reused after process exit

7.7.269. Expected result

Event recorded Containment decision evaluated No false containment enforcement point Correct agent attributed No misattribution

T6 Delegated worker has active queue T7 Security condition not met T8 Security condition met T9 Agent attempts old-generation restoration T10 Software gate active T11 Software gate not yet effective T12 Hardware restriction requested T13 Hardware restriction effective T14 Hardware acknowledgment only staged T15 Existing NIC descriptors remain queued T16 Packet transmitted before containment T17 Packet canceled before NIC egress T18 Packet cancellation unverified T19 Partial packet batch transmitted T20 NIC queue stopped but prefetched work

active T21 Alternate NIC queue remains active T22 Shared NIC queue attribution available T23 Shared NIC queue attribution missing T24 DMA submissions blocked T25 IOMMU mapping revoked T26 Device translation remains cached T27 Outstanding DMA write remains possible T28 DMA command fully completed T29 DMA command verifiably canceled T30 DMA command outcome unknown but

effectively fenced T31 DMA command unknown and still executable Completion withheld T32 GPU submission stopped T33 GPU command already executing T34 Accelerator output path remains active T35 Storage queue command outstanding T36 Software fence succeeds, hardware fails T37 Hardware fence succeeds, software fails T38 All required fences effective, no bypassing

command T39 Required queue inventory incomplete T40 Completion event duplicated T41 Cancellation and completion race T42 Controller receives forged device

acknowledgment

Worker included in affected scope No unnecessary containment generation Generation established Stale state rejected New affected commands denied Completion withheld Request state distinct from effective state Restriction evidence recorded Completion withheld Inventory identifies them Recorded as transmitted Recorded as canceled Remains unresolved Completed and canceled sets separated Settlement required Bypass detected Selective containment evaluated Broader restriction or incomplete status New DMA commands denied Current mapping restriction established Quiescence not prematurely assumed Containment incomplete Completed classification Canceled classification Historical uncertainty retained, future bypass absent

New accelerator commands denied Inventory includes it Hardware containment required Settlement required Incomplete containment Incomplete containment Verified containment Conservative result No inconsistent settlement Correct state classification Integrity verification

T43 Controller crashes during containment T44 Host restarts after containment T45 VM checkpoint predates containment T46 VM migration transfers current state T47 VM migration omits unresolved commands T48 Source VM still effect-capable T49 Queue relocated to new device T50 Standby device has stale policy T51 Device reset clears hardware restriction T52 Protected containment registry unavailable T53 Containment generation rollback attempted T54 Two hardware interfaces affected T55 Software and device generations inconsistent Completion denied T56 Unresolved command cannot bypass due to

effective fence T57 Unresolved command may bypass T58 Process termination occurs before hardware

settlement T59 Hardware reset does not prove remote

reversal T60 Agent creates new device context after

containment T61 Agent reopens device handle T62 Shared service connector retains work T63 NIC egress and remote delivery differ T64 Historical completion unknown

Recovery preserves restriction Current generation reapplied Normal access blocked Destination restrictions applied Destination remains restricted Migration completion withheld Restriction continuity verified Current generation required Restricted recovery reapplies it Unrestricted restoration denied Rejected Both checked

No-further-bypass predicate satisfied Containment incomplete No false completion

Completed external effects preserved

New access denied Current restriction enforced Relevant commands included Correct effect boundary used Report retains uncertainty

A concrete verification harness should specify:

1. Runtime observation hooks. 2. Security deviation rules. 3. Stable execution-context identifiers. 4. Device queue topology. 5. Hardware restriction interfaces. 6. Driver and firmware versions. 7. Command submission and completion semantics. 8. NIC transmission boundary. 9. DMA translation and invalidation behavior. 10. Accelerator command cancellation behavior. 11. Containment generation persistence. 12. Host restart and migration procedures. 13. Actual command settlement evidence. 14. Expected containment-completion decisions.

Testing must verify actual enforcement or authoritative device state, not merely the presence of a security alert or software status flag.

7.7.270. PART XXIII - Enforcement Points-TO- EMBODIMENT SUPPORT

7.7.271. C-84.171 - Independent enforcement point(s) 84

The embodiment provides the following technical implementation support.

enforcement point(s) 84(a): Runtime Observation Mechanism using kernel, eBPF, hypervisor, or protected

workload telemetry.

enforcement point(s) 84(b): Execution-Context Association Mechanism identifying the affected agent and

accessible resource-operation queues or hardware interfaces.

enforcement point(s) 84(c): Containment-Decision Engine evaluating designated security deviation

conditions.

enforcement point(s) 84(d): Protected Containment-State Controller assigning containment generations and

restriction sets.

enforcement point(s) 84(e): Software Execution-Control Interface preventing admission of new affected

resource-operation commands.

enforcement point(s) 84(f): Hardware Containment Interface applying restrictions to network, DMA,

storage, accelerator, privileged-device, or hardware-access interfaces.

enforcement point(s) 84(g): In-Flight Operation Inventory identifying previously admitted commands

capable of further effectuation.

enforcement point(s) 84(h): Operation-Settlement Mechanism classifying completed, verifiably canceled,

and unresolved operations.

enforcement point(s) 84(i)(i): Verification that the software admission restrictions are effective.

enforcement point(s) 84(i)(ii): Verification that the required hardware restrictions are effective.

enforcement point(s) 84(i)(iii): Verification that no unresolved affected command can bypass the intended

containment restrictions.

enforcement point(s) 84(j): Recovery Controller preventing stale pre-containment execution or queue state

from restoring unrestricted resource access.

Concluding requirement: Containment results from coordinated software and hardware

effectuation control rather than solely process termination or runtime alert generation.

7.7.272. C-84.172 - Dependent enforcement point(s) 85: Network Transmission Containment

The embodiment provides:

1. Programmable NIC control. 2. Network transmit queue restriction. 3. Software send-admission denial. 4. Hardware queue scheduling restrictions. 5. Packet and descriptor inventory. 6. NIC egress boundary definition. 7. Already-transmitted packet identification. 8. Verifiable pending-packet cancellation. 9. Partial transmission settlement. 10. Unresolved transmission classification. 11. Queue-specific containment generations. 12. Actual hardware transmission evidence.

7.7.273. C-84.173 - Dependent enforcement point(s) 86: DMA and Accelerator Containment

The embodiment provides:

1. IOMMU-associated restrictions. 2. DMA context identification. 3. Hardware mapping revocation. 4. Translation invalidation synchronization. 5. Accelerator command queue restrictions. 6. New submission denial. 7. Outstanding access inventory. 8. Device quiescence checks. 9. Completed DMA classification. 10. Verifiable cancellation classification. 11. Incomplete containment for still-executable accesses. 12. Device-specific completion semantics.

7.7.274. C-84.174 - Dependent enforcement point(s) 87: Containment Across Migration and Failover

The embodiment provides:

1. Containment generation continuity. 2. Host restart restrictions. 3. VM checkpoint restoration checks. 4. VM migration state transfer. 5. Queue relocation support. 6. Host failover coordination. 7. Source execution fencing. 8. Destination restriction establishment. 9. Unresolved-operation transfer or reconciliation. 10. Device mapping and queue consistency checks. 11. Stale generation rejection. 12. Prevention of normal execution before verified containment-state consistency.

7.7.275. PART XXIV - implementer IMPLEMENTATION REQUIREMENTS

7.7.276. C-84.175 - Implementation Checklist

A person having ordinary skill in the art implementing the embodiment identifies:

1. The AI-agent execution environment. 2. The runtime observation mechanism. 3. The supported kernel or hypervisor events. 4. The distinction between telemetry and enforcement. 5. The security deviation policy. 6. The execution-context identity scheme. 7. The root task or workload association. 8. The delegation association mechanism. 9. The resource-interface registry. 10. The protected containment decision service. 11. The containment generation format. 12. The protected generation continuity mechanism. 13. The software command-admission interface. 14. The software restriction semantics. 15. The effective software fence cutoff. 16. The hardware containment interface. 17. The device queue identities. 18. The hardware restriction operations. 19. The hardware effective-state acknowledgment. 20. The hardware command inventory mechanism. 21. The stable command identity format. 22. The relevant effectuation boundary. 23. The completed-command evidence.

24. The verifiable cancellation evidence. 25. The unresolved-command classification. 26. The future-bypass capability assessment. 27. The containment-completion barrier. 28. The network queue restriction method. 29. The NIC egress observation method. 30. The DMA mapping restriction method. 31. The IOMMU invalidation requirements. 32. The accelerator command restriction method. 33. The storage command settlement method, where used. 34. The treatment of shared hardware queues. 35. The treatment of unidentifiable commands. 36. The treatment of device reset and incomplete state. 37. The protected recovery registry. 38. The host restart protocol. 39. The VM checkpoint restoration protocol. 40. The VM migration transfer protocol. 41. The source-environment execution fence. 42. The destination queue verification process. 43. The hardware failover procedure. 44. The stale generation rejection rule. 45. The audit and settlement evidence format. 46. The treatment of irreversible completed effects. 47. The policy for incomplete containment. 48. The verification procedures demonstrating actual hardware restriction.

The implementation must establish actual control over the selected software and hardware effectuation paths.

A system that detects a security event, raises an alert, or terminates the agent process without coordinating relevant outstanding hardware operations does not implement the complete coordinated-containment architecture described here.

7.7.277. C-84.176 - Technical Effect

this implementation profile provides a hardware-assisted containment system that responds to AI-agent security deviations across both software submission interfaces and physical or device-mediated effectuation boundaries.

The system establishes a protected containment generation associated with an affected execution context.

Software execution-control mechanisms prevent new affected resource-operation commands from being admitted.

Hardware containment interfaces restrict corresponding network, DMA, storage, accelerator, or privileged-device operations.

Previously admitted commands are inventoried and classified according to completion, verified cancellation, and unresolved status.

The containment-completion controller refuses to declare successful containment where a required software restriction is absent, a required hardware restriction is ineffective, or an unresolved affected command may still bypass the intended controls.

The system separately identifies already-completed effects that cannot be retroactively prevented.

Protected generation and recovery controls prevent restart, checkpoint restoration, migration, and failover from restoring stale unrestricted access.

The technical guarantee depends upon accurate execution-context attribution, complete coverage of the designated effectuation interfaces, authoritative command completion evidence, effective hardware restrictions, and correct containment-state continuity.

7.7.278. C-84.177 - Technical Summary

this implementation profile discloses a computer-implemented coordinated kernel and hardware containment architecture for artificial-intelligence-agent workloads.

A Runtime Observation Mechanism detects security-relevant events through kernel-level monitoring, eBPF instrumentation, hypervisor observation, or protected workload telemetry.

An Execution-Context Association Mechanism links the observed event to an affected agent workload and its accessible hardware-effectuation interfaces.

A Containment-Decision Engine determines whether a designated security deviation requires containment.

A Containment-State Controller establishes a protected containment generation and identifies required restrictions.

A Software Execution-Control Interface prevents admission of new affected resourceoperation commands.

A Hardware Containment Interface applies corresponding restrictions to network transmission queues, DMA mappings, storage queues, accelerator command processors, privileged device interfaces, or hardware resource-access tables.

An In-Flight Operation Inventory identifies commands submitted before containment that may remain capable of producing effects.

An Operation-Settlement Mechanism classifies those commands as completed, verifiably canceled, or unresolved.

A Containment-Completion Controller reports verified containment only after required software restrictions and hardware restrictions are effective and no unresolved affected command can bypass the intended containment state.

For programmable network interfaces, the system distinguishes packets already transmitted from packets verifiably canceled before transmission.

For DMA and accelerator interfaces, the controller revokes or fences the appropriate command and memory-access paths while accounting for actual outstanding access and completion semantics.

A Recovery Controller preserves the current containment generation and unresolvedoperation state across restart, checkpoint restoration, migration, queue relocation, device reset, and failover.

The destination execution environment remains restricted until the transferred containment state is reconciled against its current device queues and resource mappings.

The system thereby establishes coordinated containment across software and hardware effectuation surfaces without requiring that each original command carry a portable percommand protected validation receipt or separately issued finality capability.

END OF EMBODIMENT C-84 EMBODIMENT C-88 DISTRIBUTED AGENT AUTHORITY CONTRACTION WITH ENFORCEMENT-CONVERGENCE BARRIERS USING MONOTONIC POLICY GENERATIONS, OPERATION- PATH DEPENDENCY ANALYSIS,

7.7.279. EFFECTIVE ENFORCEMENT ACKNOWLEDGMENTS, STALE- AUTHORITY FENCING, ASYNCHRONOUS OPERATION

7.7.279.1. CONTROL, AND COMPENSATING UPSTREAM RESTRICTIONS

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. Hardware isolation does not on its 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

[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, , <https://datatracker.ietf.org/doc/draft-das-agent-execution-finality/>.
[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, , <https://datatracker.ietf.org/doc/draft-das-distributed-agent-authority-finality/>.
[I-D.das-sandbox-credential-egress-finality]
Das, S., "Protected Execution Finality for Sandboxed AI Agents, Credential Mediation, Process Lineage, and Network Egress", Work in Progress, Internet-Draft, draft-das-sandbox-credential-egress-finality-00, , <https://datatracker.ietf.org/doc/draft-das-sandbox-credential-egress-finality/>.

Author's Address

Sangam Kumar Das
Independent Inventor
Balasore
Odisha
India