Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and Industrial Agents

Introduction This document describes a hardware-rooted execution-finality architecture in which a proposed consequence-bearing operation generated by a neural model or autonomous agent is represented as a Candidate Act and maintained in a Non-Effective State until protected validation and independent Finality Sink verification succeed. The architecture separates computation, authentication, sandbox membership, connector permission, application permission, model approval, and upstream authorization from authority for the resulting consequence. The central security principle is: COMPUTATION IS NOT AUTHORITY. This -01 revision narrows the document to neural, agentic, and industrial-agent deployments. Broader motivational material on consumer GPS, 6G sensing, and adjacent infrastructure domains that appeared in -00 is reduced to short industrial examples so that the load-bearing protocol and the surfaces that frontier-model and enterprise operators actually ship remain in the foreground. This -02 revision adds , which documents a runnable, vendor-neutral reference implementation of the architecture -- test methodology, system environment, policy and cryptographic parameters, benchmark method and measured local latency, and the limitations of the reference code -- and adds a corresponding source-code reference, . No other normative text changes.

Scope and Non-Goals This document specifies a pre-effectuation control plane for neural and agentic systems. It is in scope to bind a generated tool call, computer-use action, memory write, data export, payment instruction, or accelerator egress to act-specific authority that is verified at the consequence boundary. This document does not specify a new model-alignment technique, a content classifier, an age-estimation protocol, a 6G radio interface, or a single global privacy statute. Policy engines, Responsible Scaling evaluations, MCP authorization profiles, OAuth/GNAP grants, and RATS attestations MAY supply predicates to the Protected Enforcement Domain. They do not replace Finality Sink verification.

Why Neural Systems Need a Distinct Finality Layer

From Access Security to Consequence Security Traditional controls answer: who may enter, who may read, which application has permission, which connector is allowlisted, and whether this process may invoke this API. Those questions remain necessary. Execution finality answers a later question: should this particular generated operation become an actual consequence, in this state, for this purpose, at this destination, under this policy epoch, at this moment? The security problem has moved from controlling only access to controlling the transition from COMPUTATION to CONSEQUENCE.

Why This Layer Was Less Necessary a Decade Ago A decade ago most deployed neural systems were analytical, classificatory, or advisory. The recommendation did not itself make the payment. The generated text did not normally invoke tools, operate a browser, execute a shell command, write enterprise memory, call another agent, or modify a physical system. Authentication, OS permissions, application-layer security, and human review remained practical final barriers. That boundary has disappeared. An industrial agent can now move through a chain such as user instruction, model reasoning, tool selection, MCP server, another agent, enterprise API, database, payment rail, or production repository without returning to a human-controlled decision point before each real-world consequence.

What Frontier and Industrial Deployments Already Show Public engineering practice around production agents has converged on a set of necessary but incomplete controls: sandboxes and VMs that bound what an agent can reach; connector allowlists that bound which MCP servers exist; per-tool and per-action permission policies that choose between auto-allow and ask-the-user; credential isolation so that raw secrets never enter the model sandbox; and proxies that inspect tool outputs before they re-enter context. Those controls are important. They do not close the consequence boundary. An allowlisted MCP server can still advertise a new write verb after review. A session-level "always_allow" policy can still cover an act the user never saw. A human who approved 93 percent of permission prompts is not performing act-specific authorization. Computer-use paths that click, type, and navigate outside the sandbox have weaker gates than file or code-execution tools. An audited connector is not audited data: retrieved content can carry an indirect instruction that changes the next Candidate Act. Intelligence uplift alone has been observed to cause an agent to attempt a production change that the previous model version did not attempt, with no change to tools, permissions, or prompts. The missing control is therefore not another model-output filter and not another session permission dialog. It is a fail-closed boundary that asks, immediately before effectuation: even though this operation has been generated and upstream-approved, is this specific act authorized to become effective now?

Resulting Distinctions AUTHENTICATION IS NOT FINALITY. SANDBOX MEMBERSHIP IS NOT FINALITY. CONNECTOR ALLOWLISTING IS NOT FINALITY. SESSION PERMISSION IS NOT FINALITY. MODEL APPROVAL IS NOT FINALITY. TOOL SELECTION IS NOT TOOL-EFFECTUATION AUTHORITY. TOOL ADVERTISEMENT IS NOT TOOL-EXECUTION AUTHORITY. COMPUTER-USE PERMISSION IS NOT UNRESTRICTED UI AUTHORITY. DATA ACCESS IS NOT DATA-EXPORT AUTHORITY. SUCCESSFUL INFERENCE IS NOT ACCELERATOR-EGRESS AUTHORITY. AGENT DELEGATION IS NOT CUMULATIVE CONSEQUENCE AUTHORITY. COMPUTATION IS NOT AUTHORITY.

Core Execution-Finality Protocol

Architectural Invariant A Candidate Act MUST NOT become consequence-bearing merely because it has been generated, computed, selected, routed, scheduled, delegated, authenticated, sandboxed, or permitted by an upstream application or AI system. A Candidate Act MUST remain in a Non-Effective State until all of the following succeed:

a Protected Enforcement Domain validates the applicable act-specific predicates;
protected validation evidence is generated or committed;
scoped non-bearer finality authority is released;
an applicable Finality Sink independently verifies that authority immediately before effectuation; and
the finality authority and associated protected state are consumed, invalidated, advanced, or otherwise made unsuitable for unauthorized replay.

This is a two-boundary architecture. The first boundary determines whether scoped finality authority may be created. The second determines whether the consequence may actually occur. PED approval alone MUST NOT make the Candidate Act effective.

Terminology

Candidate Act: An operation that has been generated, selected, requested, staged, scheduled, routed, or otherwise prepared but has not yet been permitted to become consequence-bearing. In neural systems this includes a tool call, MCP invocation, function-call argument set, computer-use action, shell command, browser action, memory write, vector-store commit, payment instruction, data-export payload, or accelerator egress.
Non-Effective State: A state in which the Candidate Act may exist, be evaluated, staged, queued, hashed, transformed, or prepared, but the protected consequence cannot yet become externally effective. An implementation MUST preserve the Non-Effective State whenever a required element of the chain is absent, invalid, stale, expired, revoked, replayed, already consumed, act-mismatched, scope-mismatched, policy-mismatched, or Finality-Sink-mismatched.
Protected Enforcement Domain (PED): A protected validation environment that evaluates whether a Candidate Act is eligible to receive scoped finality authority. It MAY be implemented as a TEE, secure enclave, HSM, protected OS service, confidential-computing environment, secure controller, or equivalent. The defining function is protected validation before finality authority is released, not a particular hardware product.
Protected Validation Evidence: Evidence committed by the PED establishing the validation state associated with a Candidate Act. It MAY take the form of a Ledger-Anchored Validation Receipt (LAVR) or an equivalent protected commitment using hashes, signatures, MACs, sealed state, monotonic counters, Merkle commitments, or secure audit registers. External ledger anchoring MAY occur later on a cold path. Protected validation evidence MUST exist before, or atomically with, release of scoped finality authority.
Scoped Non-Bearer Finality Authority: An act-specific enablement artifact that permits a particular Candidate Act to cross a particular effectuation boundary only under its validated scope. Possession alone MUST NOT be sufficient to cause effectuation. The authority SHOULD be bound to Candidate Act identity or digest, protected validation evidence, nonce or freshness, policy epoch, revocation epoch, permitted scope, permitted consequence class, destination, and intended Finality Sink identity. An authority issued for one act, sink, tool, destination, precision, or policy state MUST NOT be reusable as authority for another consequence.
Finality Sink: The functional boundary at which a Candidate Act would become externally, operationally, financially, or physically consequential. Examples in neural deployments include an MCP invocation interface, tool dispatcher, computer-use bridge, shell-execution interface, browser-control interface, memory-write controller, API gateway, payment rail, GPU or interconnect egress controller, and data-egress controller. A gateway, firewall, policy engine, or safety classifier is not a Finality Sink merely because it performs checks. It must control the consequence such that the consequence is technically non-completable without successful finality verification.
Consequence Class: The kind of external effect being proposed: for example TOOL_INVOKE, MCP_CALL, COMPUTER_USE, SHELL_EXEC, MEMORY_WRITE, DATA_EXPORT, PAYMENT, ACCELERATOR_EGRESS, or ACTUATOR. Authority for one class MUST NOT automatically imply authority for a higher-impact class.

Candidate Act Descriptor A conforming implementation SHOULD create or derive a machine-verifiable descriptor for the Candidate Act before effectuation. The precise serialization is implementation-specific in this version. A conceptual descriptor for a neural or agentic act contains: CandidateAct { version candidate_act_id act_type act_digest initiator_id application_id agent_id model_id model_or_runtime_state_ref tool_id mcp_server_id function_or_verb instruction_provenance purpose permitted_scope consequence_class arguments_digest resource_or_data_class destination_id jurisdiction data_precision nonce creation_time expiration_time policy_epoch authority_epoch revocation_epoch protected_state_ref finality_sink_id effectuation_boundary_id } Not every field is required for every domain. Tool-or-function identity, MCP server identity, argument digest, instruction provenance, and consequence class are first-class for agentic AI. Data precision is first-class for sensitive egress. Destination and jurisdiction are first-class for cross-boundary export. Implementations MUST ensure that changing a load-bearing attribute invalidates previously issued authority. A Candidate Act SHOULD have a stable digest over its load-bearing attributes so that substitution of tool, arguments, destination, amount, precision, or sink fails verification.

First Boundary: PED Validation Upon receiving or resolving a Candidate Act, the PED MUST keep that act non-effective while validation is performed. The PED SHOULD evaluate all predicates required by the applicable consequence class. For neural and agentic acts those predicates MAY include:

agent, model, and runtime identity;
instruction provenance and retrieval/memory provenance;
tool, MCP server, verb, and argument scope;
purpose and permitted consequence class;
destination, jurisdiction, and data residency;
data precision and cumulative disclosure state;
user or enterprise authorization still current;
policy epoch and revocation epoch;
nonce and freshness;
delegation depth and cumulative consequence envelope;
Finality Sink identity.

If validation succeeds, the PED MUST establish or confirm the applicable protected-state transition, generate or commit protected validation evidence, bind that evidence to the Candidate Act, bind the permitted scope and Finality Sink, and release scoped non-bearer finality authority only after, or atomically with, the evidence commitment. The Candidate Act remains non-effective at this stage. If validation fails, the PED MUST NOT release usable finality authority. The implementation SHOULD create protected denial state sufficient to prevent unauthorized retry, replay, rollback, substitution, or stale reuse where those risks apply. The Candidate Act MUST remain non-effective. The system MUST NOT treat a Boolean ALLOW=TRUE as sufficient execution-finality authority. Validation state is part of the consequence-control mechanism, not merely an audit trail.

Scoped Non-Bearer Finality Authority Following successful protected evidence commitment, the PED MAY release an Execution Handle, capability fragment, protected enablement state, or equivalent scoped non-bearer finality authority. A conforming authority SHOULD be act-bound, evidence-bound, state-bound, scope-bound, nonce- or freshness-bound, epoch-bound, sink-bound, and non-bearer. Copying, observing, storing, forwarding, or possessing it MUST NOT by itself create authority for effectuation. Where single-use effectuation is intended, the authority MUST be consumed, invalidated, burned, or rendered unusable before or atomically with successful effectuation.

Second Boundary: Independent Finality Sink Verification The Finality Sink MUST NOT merely trust that the PED previously approved the Candidate Act. It MUST independently verify the applicable finality authority immediately before effectuation, including authority validity, Candidate Act digest, protected evidence and state, scope, destination, nonce, freshness, policy and revocation epochs, consumption state, consequence class, and sink identity. A failed Finality Sink verification MUST prevent effectuation. It MUST NOT merely create an alert while allowing the consequence to proceed. For neural deployments this means: the tool call remains non-effective; the MCP invocation is not dispatched; the computer-use action is not injected; the memory write is not committed; the payment does not settle; the accelerator output does not leave the holding region.

Successful Effectuation and Fail-Closed Requirement If Finality Sink verification succeeds, the implementation MUST ensure that the finality authority cannot be reused outside its permitted semantics. For single-use operations, consumption or protected-state advancement SHOULD occur before or atomically with effectuation. The implementation SHOULD create sink-side finality evidence identifying the completed protected consequence. A conforming implementation MUST fail closed for a protected consequence when required execution-finality state cannot be verified. Timeout, cache miss, policy miss, network failure, or uncertainty MUST NOT be converted into permission to effectuate.

Industrial Neural-AI Embodiments The physical or logical location of the Finality Sink changes according to the consequence being controlled. The protocol invariant does not.

Embodiment A: MCP and Agentic Tool Dispatch This is the primary industrial surface. An agent may call an API, invoke an MCP tool, write a file, update a CRM, query a warehouse, open a ticket, or issue a refund. Generation of a syntactically valid tool-call argument set is not authority to cause the tool's consequence. A consequential tool request SHOULD first be represented as an Agent Candidate Act, for example: Act-Type: TOOL_CALL / MCP_CALL Agent-ID: enterprise-agent-27 Model-ID: model-build-X MCP-Server-ID: payments-mcp-3 Tool-ID: customer-payment-api Function: issue_refund Requested-Amount: 500 Customer-ID: 18422 Instruction-Source: authenticated support workflow Purpose: customer refund Policy-Epoch: 481 Finality-Sink: mcp-dispatcher / payment-api-dispatcher The PED MAY validate agent identity, model or runtime state, instruction provenance, MCP server identity, tool and verb, argument scope, user authorization, delegation authority, memory and retrieval provenance, policy and revocation epochs, purpose, destination, and sink identity. If the required predicates are not satisfied, no usable finality authority is released. The applicable Finality Sink MAY be placed at the tool dispatcher, MCP invocation interface, function-call gateway, API gateway, or equivalent consequence boundary. The resulting principle is: tool selection is not tool-execution authority; an MCP server being allowlisted is not authority for this verb, these arguments, and this destination. Industrial implications that existing MCP and enterprise agent controls do not close by themselves:

A connector allowlist answers which servers exist. It does not bind this call's arguments.
A two-gate admin-then-user authorization answers who may attach a connector. It does not re-verify the act at dispatch.
A permission policy of always_allow or always_ask is session- or toolset-scoped. It is not act-digest-scoped, nonce-bound, or sink-bound.
A reverse proxy that injects credentials so the sandbox never holds secrets is necessary credential hygiene. It is not independent verification that this Candidate Act may consume those injected credentials.
New tools advertised by an already-approved MCP server MUST NOT inherit prior finality authority.

Embodiment B: Computer Use, Browser Control, and Shell Computer-use and host-side UI control are high-blast-radius neural actions. Unlike a sandboxed code-execution tool, a computer-use path can click, type, and navigate in the user's actual desktop, and a link opened in an approved application can reach an application that was never approved. Shell execution and browser control are the same class of problem: the model produces an action descriptor; the host injects it. Each computer-use step that can change external state SHOULD be a Candidate Act bound to application identity, action class (click, type, navigate, download, submit), target surface, and permitted consequence class. The Finality Sink is the computer-use bridge, input-injection controller, or browser-control interface. Session permission to "use the computer" MUST NOT be treated as unrestricted authority for every subsequent UI action. Where a product already requires per-application permission or per-deletion confirmation, those signals MAY be consumed as PED predicates. They remain insufficient unless the sink verifies act-bound authority immediately before injection.

Embodiment C: Memory, Knowledge Stores, and Enterprise Writes Persistent memory, vector stores, CRM records, ticket systems, and production repositories convert a generated string into a durable enterprise fact. A hallucinated or prompt-injected write that later becomes retrieval context is a delayed consequence. The write itself is already a consequence. A memory-write or record-update Candidate Act SHOULD bind the destination store, record class, write versus delete verb, provenance of the content being written, and the agent that produced it. The Finality Sink is the memory-write controller, database commit boundary, or repository push interface. Industrial deployments SHOULD treat "write to prod" and "delete" as distinct consequence classes from "read" and "draft".

Embodiment D: GPU, Accelerator, and Confidential-Computing Egress In large industrial inference systems the relevant consequence may occur before an output reaches an application-layer gateway: GPU memory release, DMA, device-to-host transfer, interconnect transfer, or tool dispatch directly from an inference runtime. A Neural Candidate Act MAY be staged in a protected holding region (confidential bounce buffer, sealed memory, protected DMA target, GPU/HBM/VRAM region, SmartNIC or DPU memory). The staged output may already have been computed. The system withholds Completion Material -- plaintext release, write-enable, transmit-enable, or commit-enable -- until validation and Finality Sink verification succeed. Where inference spans multiple GPUs, nodes, shards, or expert partitions, the PED MAY require evidence that participating devices belong to the approved computation. Successful inference does not itself authorize accelerator egress.

Embodiment E: Industrial Payments and Settlement An agent or automated workflow may generate a valid payment instruction while the transaction has become unauthorized by the time settlement is attempted. Relevant state may change because of revocation, limits, sanctions, jurisdiction, duplicate detection, stale authorization, or counterparty state. An upstream model or application approval is not settlement authority. The Finality Sink MAY be positioned at wallet signing, the payment rail, banking switch, clearing interface, CBDC ledger boundary, or settlement interface. The sink independently verifies act-bound authority for amount, currency, counterparties, purpose, nonce, and current epochs before settlement occurs.

Embodiment F: Precision-Bounded Industrial Data Egress Industrial agents routinely possess high-precision data they do not need to externalize: exact location for a field-service dispatch, exact customer identifiers for a summary, exact schematic values for a maintenance answer. Local access is not export authority. Precision is itself an authorization dimension. The PED MAY deny exact export while allowing a coarsened representation (region rather than coordinate, last-four rather than full identifier, aggregate rather than row). The Finality Sink MUST enforce that the exact value does not escape through another field, URL parameter, telemetry channel, or alternate path subject to the same policy. Cumulative disclosure state MAY change the decision even when a single record would have been permitted. This embodiment replaces the long consumer-GPS motivation of -00. The protocol point is identical and is not limited to location: any high-resolution industrial data class can be scoped this way.

Protocol Operation, Verification, and Failure Handling

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. Failure to establish current finality authority MUST NOT be converted into permission to effectuate.

End-to-End Workflow Act Generator PED Finality Sink | | | |-- Candidate Act ---->| | | NON-EFFECTIVE | | | |-- validate predicates | | |-- commit evidence | | | | | | [DENY] remain | | | NON-EFFECTIVE | | | | | | [ALLOW] scoped | | | finality authority | |---------------------- authority --------------->| | verify act | | verify scope | | verify nonce | | verify epochs | | verify sink | | [FAIL] no effect | [PASS] consume |<---------------- permitted consequence ---------|

PED Processing function PED_VALIDATE(candidate): if candidate is malformed: return DENY(MALFORMED_ACT) if candidate.nonce is not fresh: return DENY(REPLAY_OR_STALE) if policy_epoch mismatch: return DENY(POLICY_EPOCH_MISMATCH) if revocation_epoch mismatch: return DENY(REVOCATION_STATE_MISMATCH) if sink is not authorized: return DENY(SINK_NOT_AUTHORIZED) if purpose/scope/jurisdiction fail: return DENY(...) if tool/MCP/verb/arguments fail: return DENY(SCOPE_DENIAL) if provenance or runtime checks fail: return DENY(PROVENANCE_OR_RUNTIME) evidence = COMMIT_PROTECTED_VALIDATION(candidate) authority = ISSUE_SCOPED_FINALITY_AUTHORITY( candidate, evidence, current_protected_state) return ALLOW(authority) The pseudocode is illustrative. An implementation MAY evaluate additional predicates including runtime behavioral descriptors, neural-state integrity, data residency, accelerator identity, financial state, or cumulative disclosure state.

Finality Sink Verification function FINALITY_SINK_VERIFY(candidate, authority): if authority is absent or integrity fails: return DENY if HASH(candidate) != authority.digest: return DENY(ACT_MISMATCH) if authority.sink_id != THIS_SINK: return DENY(SINK_MISMATCH) if expired, consumed, or nonce-stale: return DENY if epoch or protected-state mismatch: return DENY if scope, destination, or precision exceed authority: return DENY ATOMICALLY: consume(authority) advance_replay_state() permit_effectuation() return EFFECTUATED

Replay, Revocation, and Policy Epochs Single-use authority MUST be consumed or otherwise made unusable before or atomically with effectuation. Replay protection MAY use nonce consumption, monotonic counters, sequence numbers, protected consumed flags, short expiration windows, or epoch advancement. A previously issued authority MUST NOT override a newer revocation state. Revocation SHOULD be checked at the Finality Sink, not merely when the authority was created. The same principle applies to policy epochs: an authority issued before a material policy change -- tool revoked, write verb removed, destination blocked, model version withdrawn, data-residency rule changed -- SHOULD NOT silently inherit authority under the new state.

Hot Path and Cold Path Not every Candidate Act requires identical validation cost. A hot path MAY use local protected state, fresh nonce state, cached policy, short-lived authority, and a known sink for frequent, previously bounded, low-risk acts. A hot-path operation MUST still perform Finality Sink verification. "Hot path" does not mean "skip finality." A Candidate Act SHOULD be escalated to a cold or higher-assurance path for high-value settlement, exact sensitive-data export, new or unknown tool delegation, changed destination, runtime anomaly, production writes, or computer-use actions outside a pre-bound envelope. Cache miss, policy miss, revocation uncertainty, or network failure MUST escalate or deny. They MUST NOT default to allow. A successful cold-path evaluation MAY establish a bounded policy envelope for subsequent low-latency operations (approved model, approved tool, approved purpose, maximum precision, destination, epochs, sink, short validity). If any bound condition changes, the system SHOULD escalate again. Representative industrial hot-path budgets in related implementations are on the order of 1-20 ms for local protected checks. These figures are examples, not protocol requirements. External ledger anchoring belongs on the cold path and MUST NOT retroactively authorize an act that was not valid when effectuation occurred.

Failure Codes and Denial Behavior The following identifiers are protocol-design suggestions, not IANA assignments: EF-001 MALFORMED_ACT; EF-002 NO_FINALITY_AUTHORITY; EF-003 INVALID_AUTHORITY; EF-004 STALE_AUTHORITY; EF-005 AUTHORITY_ALREADY_USED; EF-006 REPLAY_DETECTED; EF-007 NONCE_FAILURE; EF-010 ACT_MISMATCH; EF-012 SCOPE_MISMATCH; EF-013 PURPOSE_MISMATCH; EF-014 CONSEQUENCE_CLASS_MISMATCH; EF-020 DESTINATION_MISMATCH; EF-021 JURISDICTION_MISMATCH; EF-023 PRECISION_MISMATCH; EF-030 POLICY_EPOCH_MISMATCH; EF-031 REVOCATION_STATE_MISMATCH; EF-032 PROTECTED_STATE_MISMATCH; EF-040 SINK_MISMATCH; EF-050 ATTESTATION_FAILURE; EF-053 INSTRUCTION_PROVENANCE_FAILURE; EF-060 VALIDATION_TIMEOUT; EF-061 AUTHORITY_UNCERTAIN; EF-070 ESCALATION_REQUIRED; EF-071 HUMAN_REVIEW_REQUIRED; EF-080 FAIL_CLOSED. A denial MAY specify remediation: downgrade precision, redact, quarantine, require fresh authority, or escalate to a cold path. A timeout MUST NOT be interpreted as approval.

Alternate-Path Closure An implementation MUST consider alternate paths capable of producing the same protected consequence. For an agentic act those paths include the normal tool dispatcher, a direct API call, shell execution, browser control, IPC, memory write, an alternate plugin, or a computer-use detour around a blocked MCP verb. Moving the act to a different path MUST NOT remove the execution-finality requirement if that path can produce the same protected consequence.

Worked Example: Industrial Agent with MCP and Sensitive Egress User: "Find field technicians near the outage and open a dispatch ticket." The agent obtains precise device or asset coordinates locally and proposes two acts. Act 1 is an MCP search call. The PED determines that the external discovery service requires only coarse locality. Exact coordinates are denied; a regional representation is allowed. Authority is bound to purpose=dispatch-discovery, precision=REGION, destination=search-provider-X, sink=egress-controller. If the outgoing payload still contains exact coordinates, the sink fails closed with EF-023 PRECISION_MISMATCH. Act 2 is an MCP write: open_ticket(severity=P1, assignee=crew-14, location=...). The PED validates verb, destination system, argument scope, and current authorization. The MCP dispatcher is the Finality Sink. A prompt-injected escalation that changes severity to a production-shutdown command, or redirects the write to an unapproved tracker, fails digest or destination verification and remains non-effective. The agent can reason over precise information internally. It does not acquire unrestricted authority to externalize that precision or to invoke an unvalidated write.

Security Considerations The principal security objective is that a protected consequence MUST remain technically non-effective unless current, act-specific, scoped authority is verified at the applicable Finality Sink.

Replay and Substitution An attacker may reuse a previously valid authority or substitute a different operation under a valid authority (coarse location becomes exact; refund of 50 becomes 5,000; Tool A becomes Tool B; approved MCP server becomes a look-alike server). The Finality Sink MUST verify that the actual consequence corresponds to the digest bound to the authority. Authority issued for one sink MUST NOT be usable at another sink, including a shell or computer-use path used to launder a blocked tool call.

Prompt Injection and Instruction Laundering The proposed Candidate Act may have been influenced by content that was never intended to function as an instruction: retrieved documents, webpages, email, screen-visible text, tool responses, MCP resource bodies, database content, persistent memory, vector-store records, multimodal inputs, malicious plugins, or another agent. An audited connector is not audited data. A PED MAY therefore evaluate instruction provenance, retrieval provenance, memory provenance, runtime behavior, or equivalent trust signals before releasing finality authority. The protocol does not require the model itself to detect every injection. It requires that a consequential operation influenced by such a condition still cannot become effective unless the required finality predicates succeed.

Tool Poisoning, MCP Substitution, and Verb Creep An MCP server, plugin, or tool description may change after the session or enterprise review that allowlisted it. New verbs, widened argument schemas, or a substituted server endpoint MUST NOT inherit prior finality authority. Tool metadata and marketplace discovery MUST NOT themselves be treated as authority for consequence-bearing invocation.

Agentic Cascade and Delegation A trusted agent may delegate to another agent, which delegates again, creating a chain whose cumulative consequence exceeds the original task. Discovery of an external agent or advertised capability MUST NOT by itself establish trust to receive credentials, data, payment authority, file access, or execution privileges. An implementation MAY maintain cumulative delegation depth, resource use, tool-call count, execution velocity, or consequence state, and withhold further finality authority when the permitted envelope is exceeded.

Permission Fatigue and Session-Scoped Allow Human approval of a session, a toolset, or a high fraction of permission prompts is not act-specific authorization. Implementations that offer always_allow for trusted toolsets SHOULD still bind each high-consequence act to sink-side verification. Auto-approval of "safer" classes MUST be represented as a bounded policy envelope, not as the absence of a Finality Sink.

Compromised Application, SDK, or Host Bridge Ordinary application-layer software, an SDK, a local MCP server, or a computer-use bridge MAY be compromised. Security MUST NOT depend solely on the application, SDK, browser, or model saying ALLOW. A malicious component with valid session access SHOULD NOT be able to bypass a protected Finality Sink for the same consequence.

Protected-State Integrity and Component Failure High-assurance implementations SHOULD use protected monotonic state, sealed storage, secure counters, or authenticated state transitions where rollback of consumed nonces, policy epochs, or revocation epochs could produce a consequence. If PED integrity cannot be established, the implementation SHOULD NOT release finality authority for protected consequence classes. An upstream PED cannot compensate for a sink that permits consequence without checking authority. The elements of the chain are mutually load-bearing.

Agentic-AI Threat Model A representative industrial neural-agent deployment SHOULD consider at least: T1 Direct prompt injection; T2 Indirect prompt injection through retrieved or on-screen content; T3 Poisoned retrieval; T4 Poisoned persistent memory; T5 Malicious tool response; T6 Tool substitution; T7 MCP or server substitution; T8 Unauthorized delegation; T9 Recursive agent escalation; T10 Stale user or enterprise authority; T11 Destination substitution; T12 Cross-jurisdiction export; T13 Over-disclosure of high-precision industrial data; T14 Replay of previous authority; T15 Cross-sink authority reuse including computer-use laundering; T16 Runtime or model-state deviation, including capability uplift that attempts new acts under unchanged permissions; T17 Alternate-path effectuation; T18 Verb creep on an allowlisted connector; T19 Credential injection misuse (proxy-held secrets applied to an unauthorized act); T20 Production write or delete presented as a draft or search.

Privacy Considerations Execution-finality metadata itself may contain sensitive information: agent identity, purpose, destination, data class, financial consequence, or behavioral information. Implementations SHOULD minimize information exposed outside protected validation boundaries and MAY use hashes, commitments, attestations, or confidential-computing evidence rather than raw descriptors. Validation of neural and runtime state SHOULD be possible without exposing model weights, private prompts, confidential user data, internal activations, or sensitive inference traces.

Relationship to Existing Industrial Controls The architecture is intended to coexist with systems already present in frontier-model and enterprise agent stacks. It MAY consume decisions or evidence from identity providers, OAuth and GNAP grants, RBAC, MCP authorization profiles, connector allowlists, policy engines, safety classifiers, attestation systems, DLP/DSPM, human approval, and risk engines. Those systems provide inputs to finality validation. They do not replace Finality Sink verification. GNAP already separates grant negotiation from grant use and supports fine-grained, per-request access. The scoped non-bearer authority described here is compatible with a GNAP access token scoped to a single operation, with the addition that the grant decision is made against externally verified binding records rather than client-supplied claims, and that the consequence boundary independently verifies the grant. RATS establishes that a piece of code is running in an expected state. That answers a different question than whether that code is authorized for a specific consequence. Attestation MAY be a PED predicate. It is not finality. OAuth 2.0 , JSON Web Tokens , and OAuth 2.0 Resource Indicators address related but narrower audience- and scope-restriction problems. This document's Execution Handle generalizes those restrictions to a per-Candidate-Act, non-bearer grant consumed at a named sink. MCP authorization and enterprise-managed connector control answer which servers and verbs an agent may see. This document answers whether a particular generated invocation may become effective.

IANA Considerations This version of the document requests no IANA actions. The EF-xxx failure identifiers are illustrative protocol-design identifiers and are not IANA assignments. If later versions standardize wire-format fields, error codes, consequence classes, or capability types, an IANA registry MAY be proposed at that time.

Intellectual Property Considerations Certain technical concepts described in this document are associated with pending patent applications in the DAS Protocols family, including PCT/IB2026/054453, PCT/IB2026/055615, PCT/IB2026/055760, PCT/IB2026/055870, PCT/IB2026/056058, and PCT/IB2026/053385. These filings disclose related elements including non-bearer execution handles, protected enforcement domains, neural candidate acts, AI-output finality, device-side enforcement, agentic tool-use enforcement, and Algorithmic Logic Fingerprints. Any IETF intellectual-property disclosure required in connection with standardization of this work should be handled separately in accordance with applicable IETF IPR procedures . This section is informational and does not define licensing terms.

Reference Implementation This section documents a runnable, vendor-neutral reference implementation of the Candidate Act / Non-Effective State / Protected Enforcement Domain (PED) / scoped non-bearer finality authority / independent Finality Sink sequence specified in this document. The implementation is published at . It is provided to support interoperability review, adversarial testing, and reproducible evaluation. It is informational and does not itself constitute a normative requirement of this specification.

Purpose and Tested Sequence The reference implementation exercises the following sequence: Candidate Act, Non-Effective State, Protected Enforcement Domain, act-specific predicate validation, protected validation evidence, scoped non-bearer finality authority, holder proof-of-possession, independent Finality Sink verification, atomic single-use consumption, and external effect. The property under test is that successful computation, model output, tool selection, application permission, connector authorization, or PED approval is not by itself sufficient to cause the external consequence; the effectuation callback is reached only after independent Finality Sink verification succeeds.

Implementation Language and Environment The reference implementation is written in Python 3.11+ and declares a runtime dependency on cryptography >= 41 and a test-only dependency on pytest >= 8. It was created and validated using Python 3.13.5 on x86_64 Linux, kernel 6.18.35, glibc 2.41, on an Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80 GHz, with cryptography 46.0.4, pytest 9.0.2, and SQLite 3.46.1. Python was chosen so that each security state transition is easy to inspect, reproduce, modify, and independently test. Python is not asserted to be a required or recommended production language; equivalent implementations could be built in Rust, C, C++, Go, Java, protected OS services, TEE/enclave code, HSM-integrated services, DPU/SmartNIC services, accelerator runtimes, firmware, or protected device controllers.

Baseline Test Configuration The principal automated tests use a reproducible Candidate Act representing an agent-generated MCP payment/refund operation: act type MCP_CALL; tool customer-payment-api; function issue_refund; purpose customer-refund; destination payments-prod; jurisdiction US; data precision EXACT; default amount 50 USD against a maximum permitted amount of 500 and a cold-path threshold of 250; policy epoch 481, authority epoch 9, revocation epoch 12; Finality Sink mcp-dispatcher at effectuation boundary dispatch-boundary-1; and a Candidate Act lifetime of 10 seconds. Candidate IDs and nonces are generated uniquely per execution, and the runtime validation context begins approximately 1 ms after Candidate Act creation unless a test intentionally varies time or state. The baseline PED policy permits only the above tool, destination, consequence class, purpose, and maximum precision, caps the amount at 500 with a cold-path threshold at 250, caps delegation depth at 3, and requires both attestation and instruction provenance. Baseline authentication for the deterministic test configuration uses HMAC-SHA-256 with separate keys for PED/evidence/authority authentication and for holder proof-of-possession; these are test keys and are not production credentials.

Non-Bearer Authority Test The implementation does not treat possession of the finality authority as sufficient for effectuation. The authority is bound to the Candidate Act and other validated state, and the Finality Sink additionally requires a separate holder proof-of-possession, such that a copied authority combined with no valid holder key is denied. The suite tests the correct holder, an incorrect holder key, an incorrect holder identity, proof binding, and sink challenge binding. In a production implementation the holder key should ideally be non-exportable and bound to a protected workload, process, device, enclave, HSM, hardware root, or equivalent protected execution identity.

Test Suite Summary The validation suite contains 58 collected tests, 58 passed, 0 failures, distributed across four groups: core execution-finality and sink tests (25); PED/policy/fail-closed tests (20); implementation and deployment variations (12); and a failure-code catalog test (1). Parameterized tests are counted individually, which is why the number of executed tests exceeds the number of Python test functions. The core group verifies the full successful path from Candidate Act through PED validation, evidence generation, authority issuance, holder proof, independent Finality Sink verification, consumption, and single-execution external effect at the baseline amount of 50. It also verifies: replay protection (a second submission of an already-consumed authority is denied as AUTHORITY_ALREADY_USED); denial on a wrong holder key or wrong holder identity; STALE_AUTHORITY after the authority's expiration; POLICY_EPOCH_MISMATCH and REVOCATION_STATE_MISMATCH when the respective epoch advances after issuance; PROTECTED_STATE_MISMATCH on a protected-state rollback or change; and denial on an authority-epoch change before effectuation. Candidate Act mutation testing issues authority for an original act and then alters a load-bearing parameter -- destination, purpose, data precision, nonce, tool ID, function or verb, MCP server ID, model ID, agent ID, Finality Sink ID, jurisdiction, protected-state reference, or arguments -- after issuance; the Finality Sink must reject the previously issued authority against the modified act, since the modification invalidates the Candidate Act digest/binding. Signature tampering tests separately alter a valid finality-authority signature and a valid protected-validation-evidence signature, each producing denial. Finality Sink substitution tests present authority issued for one sink (mcp-dispatcher) to a different sink (shell-bridge), which must be rejected as SINK_MISMATCH, since finality authority is not a general-purpose capability transferable among consequence boundaries. The PED/policy group verifies SCOPE_MISMATCH on an unauthorized tool, DESTINATION_MISMATCH on an unauthorized destination, PURPOSE_MISMATCH on a mismatched purpose, PRECISION_MISMATCH on a precision value above the permitted maximum, CONSEQUENCE_CLASS_MISMATCH when the requested consequence class lacks policy authorization, denial above the maximum permitted amount, denial above the maximum delegation depth, ATTESTATION_FAILURE and INSTRUCTION_PROVENANCE_FAILURE when the corresponding runtime predicates fail, denial when policy or revocation state is unavailable (unknown state does not imply permission; inability to verify does not imply allow), VALIDATION_TIMEOUT on an injected timeout, and STALE_AUTHORITY for a Candidate Act presented past its expiration or carrying a stale policy epoch, revocation epoch, or protected state. Hot-path/cold-path boundary tests confirm classification on both sides of, and exactly at, the configured cold-path threshold (amounts of 1 and 249.99 classify hot; 250 and 500 classify cold), while confirming that a hot-path operation must still pass Finality Sink verification -- hot path does not mean skipped finality; cold path means an implementation can require additional assurance such as fresh attestation, human approval, sanctions/counterparty refresh, remote policy decision, additional provenance analysis, new-tool review, or higher-assurance audit commitment, none of which are simulated as production services in the reference implementation.

Cryptographic, Replay-Store, and Consequence-Boundary Variations Two PED authentication approaches are tested: HMAC-SHA-256 as the primary deterministic reference mode (simple, reproducible, and useful for test vectors, but requiring a shared secret between issuer and verifier and therefore not necessarily appropriate for internet-scale trust distribution); and an end-to-end Ed25519 variant in which the PED holds the signing capability and the Finality Sink holds the corresponding public verification capability, demonstrating asymmetric separation. A production deployment could protect an Ed25519 signing key in a TEE, HSM, secure enclave, or equivalent hardware-backed environment. Two replay-state implementations are tested: an in-memory store (process-local, lock-protected, fast, non-persistent across process loss) used for the default benchmark; and a SQLite store in WAL mode with authority-ID uniqueness that survives reopening the same local database, demonstrating atomic single-use behavior. Neither substitutes for hardware monotonic counters, protected state, cross-region consensus, or distributed transactional replay protection. Replay protection is also tested under concurrency: 100 concurrent attempts across 16 thread workers against the in-memory store, and 32 concurrent attempts across 8 thread workers against the SQLite store, each required to yield exactly one successful consumption. Eight consequence-boundary variations are instantiated with representative tool, destination, and Finality Sink triples: MCP call, data export, payment, accelerator egress, memory write, computer use, shell execution, and actuator (PLC). Each follows the same invariant -- generate, keep non-effective, validate, issue scoped authority, prove holder possession, verify at the consequence boundary, consume, and effectuate -- showing that the physical location of the Finality Sink can vary without changing the core protocol invariant. The reference implementation defines 25 EF failure identifiers spanning malformed acts, missing or invalid authority, stale authority, replay, nonce failure, Candidate Act mismatch, scope/purpose/consequence-class/destination/ jurisdiction/precision mismatch, policy-epoch and revocation-state mismatch, protected-state mismatch, sink mismatch, attestation and provenance failure, timeout, uncertain authority, escalation, human review, and fail-closed state. The suite verifies the catalog's expected count and uniqueness. These are implementation/reference identifiers and are not IANA-assigned protocol codes.

Benchmark Method and Measured Reference Latency A reproducible local microbenchmark measures the complete local software finality sequence in three stages -- PED validation, evidence creation, and authority issuance; holder proof-of-possession generation; and Finality Sink verification plus atomic replay consumption -- and reports total hot-path latency. Default configuration uses 500 warm-up and 5,000 measured iterations, the HMAC-SHA-256 reference authenticator, an in-memory atomic-lock replay store, and time.perf_counter_ns() as the clock source, with garbage collection performed before measurement, disabled during measured iterations, and re-enabled afterward. p50, p95, p99, mean, minimum, and maximum are reported. A fresh Candidate Act and runtime context are created for each iteration; network operations and external consequence I/O are excluded. On the environment described above, measured stage latencies were: PED issuance (policy evaluation, evidence generation, and authority issuance) p50 0.1943 ms, p95 0.2339 ms, p99 0.3086 ms, mean 0.2067 ms, min 0.1880 ms, max 2.9351 ms. Holder proof-of-possession: p50 0.0189 ms, p95 0.0214 ms, p99 0.0414 ms, mean 0.0207 ms, min 0.0178 ms, max 2.2148 ms. Finality Sink verification and consumption: p50 0.1701 ms, p95 0.2098 ms, p99 0.2825 ms, mean 0.1812 ms, min 0.1647 ms, max 3.1286 ms. The complete local hot-path total was p50 0.3937 ms, p95 0.4580 ms, p99 0.6236 ms, mean 0.4085 ms, min 0.3738 ms, max 3.3413 ms, showing sub-millisecond median latency for the reference state machine in this particular local software test environment. These results do not establish equivalent latency for a production hardware-rooted deployment. The repository defines a software regression target of total local hot-path p95 <= 5 ms; the measured p95 of 0.4580 ms passes that target. This 5 ms figure is a repository engineering/regression target used to catch future implementation changes that introduce large local overhead -- it is not a protocol requirement or an IETF conformance requirement. For deployment purposes, latency is better divided into a hot path -- for which an illustrative engineering comparison band of approximately 1-20 ms for protected local checks is suggested, without the hot path ever meaning that Finality Sink verification is skipped -- and cold-path operations such as fresh remote attestation, human approval, sanctions or counterparty refresh, remote enterprise policy decision, or higher-assurance audit commitment, for which no universal latency target is claimed because cost depends on deployment architecture. External ledger anchoring, where used, is likewise treated as cold-path or post-decision evidence anchoring rather than a mandatory remote round trip for every local effectuation, since the execution decision must already be valid at the moment of consequence and a later ledger record cannot retroactively authorize an unauthorized act.

Limitations of the Reference Implementation The reference code is not itself a hardware security boundary: the PED, holder, and Finality Sink are Python objects executing in an ordinary software environment, so the repository demonstrates protocol mechanics, state transitions, cryptographic binding, and failure and replay behavior, but not physical hardware isolation. A production implementation would need to protect the relevant state using a TEE, HSM, secure enclave, protected OS service, secure controller, DPU, SmartNIC, accelerator security domain, hardware monotonic state, or an equivalent protected execution mechanism. HMAC-SHA-256 requires a shared secret between issuer and verifier and should not be read as the preferred production architecture; the Ed25519 variant demonstrates asymmetric separation, but production systems still require key provisioning, rotation, revocation, hardware protection, certificate or identity binding, and lifecycle management. The reference holder key exists in normal process memory, so the implementation demonstrates the non-bearer protocol property without establishing a hardware-enforced non-exportable key; production holder keys should be bound to hardware, an enclave, a process, workload or device identity, a session, mTLS identity, a DPoP-like proof, or a protected runtime. The attestation_ok field is a validation input, not a complete RATS verifier, EAT parser/verifier, TPM evidence verifier, GPU attestation verifier, confidential-VM verifier, or vendor-specific attestation service; the attestation result is modeled, not fully implemented. The reference implementation consumes replay state before executing the consequence callback; in a real external system a crash between consuming the authority and committing the external consequence could create ambiguous state, so a production design should use transactional commit, idempotency keys, write-ahead state, a two-phase or equivalent commit protocol, protected device state, hardware atomicity, or payment-specific transaction semantics as appropriate. A software library cannot prove that every path to a real-world consequence has been protected; if the same protected consequence is reachable through a direct API, shell, browser automation, IPC, an alternate plugin or MCP server, direct database access, a memory write, DMA, or a device interface, those paths must also be routed through an enforcing Finality Sink or made technically unable to bypass it -- primarily a deployment-architecture property. The current repository does not implement cluster-wide replay consensus, multi-region monotonic state, cross-region revocation synchronization, Byzantine consensus, HSM quorum, global clock synchronization, or distributed transactional effectuation; the SQLite variation demonstrates local persistence only. The reference policy engine intentionally covers a limited predicate set (tool, destination, purpose, consequence class, precision, amount, delegation depth, attestation result, provenance result, policy epoch, revocation epoch, protected state, availability, and freshness) and is not a complete enterprise policy language; real deployments may integrate OAuth, GNAP, workload identity, enterprise PDPs, ABAC/RBAC, RATS evidence, DLP, DSPM, risk engines, sanctions systems, data-residency policy, model/runtime assurance, or human approval as predicate sources, none of which by themselves replace Finality Sink verification. The code has been executed and tested but has not been mechanically proven with TLA+, Coq, Isabelle, Lean, model checking, or formal cryptographic proof; 58 of 58 passing tests demonstrate the implemented scenarios and invariants and do not constitute a mathematical proof of security. The measured benchmark is specifically an in-process Python software-reference microbenchmark and must not be described as TEE, HSM, GPU, DPU, SmartNIC, confidential-computing, network, MCP-production, or payment-network latency. Passing the reference tests does not establish regulatory compliance, legal authorization, AI safety certification, cybersecurity certification, payment certification, IETF conformance, or hardware security certification; the repository is an engineering reference implementation intended for protocol discussion, interoperability experiments, standards-oriented review, adversarial testing, implementation comparison, and research.

Reproducing the Reference Tests and Benchmark The published repository documents reproduction steps (create and activate a Python virtual environment, install the package with its test extra, and run pytest, expected to report 58 passed) together with a demonstration script and the latency benchmark script, whose iteration counts, warm-up count, and reference p95 target are configurable via environment variables (defaults: 5,000 measured iterations, 500 warm-up iterations, 5 ms reference p95 target). A recommended production benchmark matrix additionally records CPU/device, OS/kernel, firmware, runtime/compiler or native binary version, TEE/HSM/device security mode, cryptographic algorithm, key location, attestation profile, replay-state backend, policy backend, clock source, network topology, Finality Sink type, iteration and warm-up counts, concurrency level, p50/p95/p99/maximum, and failure rate, repeated across local HMAC and asymmetric signing, HSM-backed signing, enclave/TEE PED, remote attestation, persistent replay storage, concurrent requests, MCP dispatch, database commit, payment authorization, GPU/DPU egress, and failure/timeout paths.

Interpretation The most important result of the reference implementation is not the sub-millisecond benchmark but the mechanically testable separation it demonstrates between computation and authority to cause a consequence: a Candidate Act may be fully generated and evaluated while remaining non-effective, and changing a load-bearing parameter, using stale authority, changing epochs, replaying an authority, using the wrong sink, failing proof-of-possession, losing policy certainty, failing attestation, or exceeding scope prevents the consequence from becoming effective. This reflects the invariant stated throughout this document: Candidate Act is not authority; PED approval is not effectuation; possession of authority is not effectuation; and successful computation is not external consequence. Only successful independent verification at the applicable Finality Sink permits the protected transition from computation to consequence.

Related Execution-Finality Drafts and Implementation This document is part of a series applying the same Candidate Act / Non-Effective State / Protected Enforcement Domain / scoped non-bearer authority / independent Finality Sink architecture to different domains. develops cross-domain data-purpose enforcement; applies the architecture to EU AI Act high-risk system enforcement; applies it to general-purpose privacy-execution enforcement; and applies it to precision-bounded data egress. A vendor-neutral cross-domain framing also appears in . Policy discussion of the same architecture appears in and . Foundational and cross-domain treatments appear in and . Telecommunications and non-terrestrial applications appear in , , , and . Neural, agentic, and model-governance applications appear in , , , , , , , , , and . Sovereignty, settlement, and operational-technology applications appear in , , and . A runnable, vendor-neutral reference implementation of the architecture specified in this document, summarized in , is published at . Runnable reference implementations accompanying the wider series include , , , , , and .

Conclusion Neural systems increasingly move from computation into external action through tool calls, MCP servers, computer use, memory writes, payments, and accelerator egress. Sandboxes, connector allowlists, session permissions, and model-level safety reduce blast radius. They do not make an unauthorized consequence technically non-completable at the moment of effectuation. The architecture in this document introduces a distinct boundary: Candidate Act, Non-Effective State, protected validation, protected evidence, scoped non-bearer authority, independent Finality Sink verification, then consequence. Its central principle remains: computation is not authority. For agentic systems: tool selection is not tool-effectuation authority. For industrial MCP deployments: a connector allowlist is not per-act finality. For computer use: session permission is not unrestricted UI authority. For inference hardware: successful generation is not egress authority.