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.

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.

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 . Runnable reference implementations accompanying the 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.