| Internet-Draft | Computation Is Not Authority | September 2026 |
| Das | Expires 13 March 2027 | [Page] |
Neural AI systems -- large language models, vision-language models, and other learned decision systems -- now move directly from computation to consequence. A model output becomes a tool call; a tool call becomes an API transaction, memory write, payment, file mutation, browser action, or actuator signal; an agent delegates to another agent. Successful inference, sandbox containment, connector allowlisting, session permission, or upstream model approval does not by itself establish authority for that particular real-world consequence. A model may be authorized to compute while remaining unauthorized to act.¶
This document specifies a hardware-rooted execution-finality architecture for neural and agentic systems. A proposed consequence-bearing operation is represented as a Candidate Act and held in a Non-Effective State until a Protected Enforcement Domain validates act-specific predicates and an independent Finality Sink verifies scoped, non-bearer finality authority immediately before the operation becomes externally effective. If that authority is absent, stale, replayed, revoked, or mismatched to the act being attempted, the Candidate Act remains non-effective and the operation fails closed.¶
The architecture is model- and vendor-neutral. It is written for the industrial surfaces that now dominate production agent deployments: Model Context Protocol (MCP) tool dispatch, computer use, code execution, enterprise connectors, memory and knowledge-store writes, GPU and confidential-computing egress, and settlement. The same invariant applies to those surfaces: computation is not authority; tool selection is not tool-effectuation; a connector allowlist is not per-act finality.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 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.¶
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.¶
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.¶
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?¶
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.¶
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:¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
The physical or logical location of the Finality Sink changes according to the consequence being controlled. The protocol invariant does not.¶
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:¶
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.¶
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".¶
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.¶
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.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Failure to establish current finality authority MUST NOT be converted into permission to effectuate.¶
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 ---------|¶
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.¶
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¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 [RFC9635] 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 [RFC9334] 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 [RFC6749], JSON Web Tokens [RFC7519], and OAuth 2.0 Resource Indicators [RFC8707] 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.¶
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.¶
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 [BCP79]. This section is informational and does not define licensing terms.¶
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. [DAS-PURPOSE-EXECUTION-FINALITY] develops cross-domain data-purpose enforcement; [DAS-EU-AI-ACT] applies the architecture to EU AI Act high-risk system enforcement; [DAS-GLOBAL-PRIVACY] applies it to general-purpose privacy-execution enforcement; and [DAS-PRECISION-EGRESS] applies it to precision-bounded data egress. A vendor-neutral cross-domain framing also appears in [DAS-EXEC-FINALITY]. Policy discussion of the same architecture appears in [FUTURIUM-PURPOSE-LAUNDERING] and [FUTURIUM-PAPER-COMPLIANCE].¶
Foundational and cross-domain treatments appear in [DAS-CANDIDATE-ACT-FINALITY] and [DAS-PROTOCOL-LAYER]. Telecommunications and non-terrestrial applications appear in [DAS-AI-NATIVE-6G], [DAS-6G-CVID], [DAS-MAP-DISCOVERY], and [DAS-NTN-RF]. Neural, agentic, and model-governance applications appear in [DAS-RATS-EXTRACT], [DAS-RATS-OPENAI-ANTHROPIC], [DAS-RATS-ATTESTATION-BND], [DAS-CHILD-SAFE-RENDERING], [DAS-AI-INTEROP], [DAS-ENTERPRISE-AI-OUTPUT], [DAS-PROTOCOLS-ENTERPRISE-AI], [DAS-AGENTIC-TOOL-BINDING], [DAS-AGENTIC-EXECUTION-FINALITY], and [DAS-AGENTIC-AI-TOOL-EXEC]. Sovereignty, settlement, and operational-technology applications appear in [DAS-DIGITAL-SOVEREIGNTY], [DAS-PAYMENT-FINALITY], and [DAS-OT-ACTUATION].¶
Runnable reference implementations accompanying the series include [DAS-PRIVACY-FINALITY-IMPL], [DAS-HALLUCINATION-IMPL], [DAS-LOCATION-EGRESS-IMPL], [DAS-NTN-IMPL], [DAS-GPU-IMPL], and [DAS-6G-ORAN-IMPL].¶
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.¶