An Execution Interlock at the AI Model-to-External-Effect Boundary

Introduction

From Model Capability to External Effect Increasing model capability widens the gap between what an AI system can compute or propose and what it is authorized to make externally effective. An operation generated by a model may be syntactically valid, operationally executable, and within the model's available tool interface, and may nevertheless be unauthorized for the specific purpose, target, parameters, context, or time in which it would execute. Existing controls act on the production of the operation. This document acts on its effectuation. The problem statement is:

What prevents a consequential AI-generated operation from becoming externally effective until independently verifiable authorization conditions for that exact operation have been satisfied?

This is a different problem from determining whether the model should have generated the operation at all.

Relationship to Model-Level Safety Controls Alignment, monitoring, sandboxing, interpretability, and policy enforcement reduce the probability that an unsafe or unauthorized operation is generated. An execution architecture cannot rely on those controls succeeding in every case, and this document does not propose replacing them. The two approaches address different points in the lifecycle. Model-level controls constrain what is produced. Execution-finality controls constrain whether what has been produced can acquire the authority required to cause a consequence.

What Is Enforced An operation emitted by an AI system is treated as a proposal rather than as authority to execute. It remains without external effect while authorization and execution conditions are evaluated by a component the requester cannot influence. Successful validation produces protected validation evidence and a narrowly scoped, non-transferable execution capability bound to that specific operation. At the boundary where the operation could first produce an externally consequential effect, an enforcement point reconstructs the effect that is about to occur and verifies it against the validated capability. Divergence between the authorized effect and the actual effect fails closed. Generation, computation, tool selection, prior approval, or possession of a general-purpose credential does not, in itself, permit crossing that boundary.

Capability Release as a Consequence Boundary The boundary is not limited to physical or financial actuation. Where the governed resource is model capability itself, the response-release boundary is the point of consequence: a model obtained under one declared purpose may be prompted to yield capability applicable to a different and prohibited purpose, without any downstream tool call occurring. Publicly reported misuse cases illustrate the timing property that motivates this work. Where such misuse has been identified through provider threat-intelligence and account-level enforcement, identification followed release. The capability conveyed in the responses had already left the system. This is not evidence that provider controls failed; it is evidence that those controls operate downstream of the boundary specified here.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Core Architecture Terms

Candidate Act: An operation produced by an AI system that, if effectuated, would cause an effect outside the system's computational environment. A Candidate Act is a proposal. Its existence conveys no authority. It includes the operation's target, parameters, declared purpose, and invocation context, since authorization is evaluated against the specific instance, not the operation class.
Non-Effective State: The condition of a Candidate Act between its production and its authorization. In this state the Candidate Act MUST NOT produce any effect observable outside the enforcement domain. Non-Effective State is the default; effectiveness is the exception that must be earned.
Consequence Boundary: The point at which a Candidate Act would first produce an externally observable or irreversible effect. Examples include transmission of a message, settlement of a payment, mutation of infrastructure state, actuation of a device, modification of an access control, and release of a model response to a requester. Every path capable of producing the protected effect is itself a Consequence Boundary; an unguarded path is a bypass, not an exception.
Protected Enforcement Domain (PED): The validation environment, isolated from the AI system that produced the Candidate Act. The distinguishing property is non-influence: the model, its tool layer, and the requester MUST NOT be able to alter the PED's inputs, policy, keys, or decision. A validator that can be argued with by the system it validates is not a PED.
Independent Validation: Evaluation of a Candidate Act inside the PED against an authority predicate the requester cannot manufacture. Validation is act-specific. Approval of a similar act, an earlier act, or the same act under different parameters is not approval of this act.
Execution Handle: The artifact issued on successful validation. An Execution Handle is act-bound, being cryptographically bound to the digest of the specific Candidate Act; non-bearer, in that possession alone is insufficient and presentation requires proof of the binding, so a captured handle is not usable by a different holder or for a different act; scoped, being constrained to a named Finality Sink, boundary, and validity window; and single-consequence, authorizing one crossing rather than a standing permission.
Finality Sink: The enforcement point at the Consequence Boundary. The Finality Sink verifies the Execution Handle immediately before the effect occurs, and MUST fail closed on absent, expired, mismatched, replayed, or unverifiable evidence. The Finality Sink is the last component with the ability to withhold consequence.
Reconstructed Actual Effect: The effect the Finality Sink determines it is about to produce, derived from the operation as it exists at the boundary, not from the request as it was authorized. Verification compares the reconstructed actual effect against the effect bound into the Execution Handle. This comparison is what distinguishes execution finality from a conventional policy enforcement point, which checks a token against a request and cannot detect divergence introduced after the decision.
Authority Predicate: The condition that must hold for a Candidate Act to be authorized. It MUST be verifiable by the PED and MUST NOT be assertable by the requester. Where the only evidence for the predicate is a claim made by the requesting system, the architecture is inapplicable.
Validation Record: The tamper-evident, hash-chained record of validation decisions. It establishes after the fact which acts crossed the boundary, under which authority, and on what evidence. Absent lineage is UNKNOWN, not EMPTY, and MUST fail closed.

AI-Specific Terms

Inference Boundary: The boundary between model computation and delivery of its output to any consumer, human or programmatic. Where the protected object is model capability rather than a downstream action, the Inference Boundary is the Consequence Boundary.
Generation and Release: Distinct events. Generation is the production of output within the enforcement domain. Release is its delivery across the Inference Boundary. Output that has been generated but not released has caused no consequence and may still be withheld.
Protected Capability: Capability embodied in model outputs that is itself the governed resource, for example capability whose release is restricted by law, licence, or declared purpose, independent of whether the recipient subsequently acts on it.
Declared Purpose: The purpose asserted by the requester at invocation. A Declared Purpose is an input to validation, never an authorization. It is requester-assertable and therefore cannot serve as an Authority Predicate.
Capability Laundering: Obtaining a system under one Declared Purpose and eliciting capability applicable to a different, unauthorized purpose. The defining property is that no boundary violation is visible in any single request; the violation is in the relationship between the declared scope and the capability released.
Tool Invocation Candidate Act: A tool call emitted by a model, for example a tool_use block or a function-call object, treated as a Candidate Act. Emission of the call is not invocation of the tool. The dispatch point between the model's emitted call and the tool's execution is a Consequence Boundary.
Agentic Continuation: Autonomous production of subsequent Candidate Acts from the result of a prior one. Each continuation is a separate Candidate Act requiring separate validation; authorization does not propagate along a chain.

Known Limits Two properties are not addressed by this architecture and are stated here rather than left implied.

Consequential-act classification. Determining which acts are consequential is itself a decision. If that classification is influenced by the AI system, the architecture fails open at its entry point. The classifier MUST reside inside the PED.
Decomposition and aggregation. An objective that is prohibited in aggregate may be decomposed into requests that are each individually authorized. Per-act validation does not detect this, and cross-session mosaic aggregation remains open.

Relationship to Existing IETF Work This section states what existing mechanisms provide and what they do not, so that the delta is explicit rather than implied.

Bearer Semantics and Key-Bound Tokens OAuth 2.0 and the Bearer Token Usage specification define credentials where possession is sufficient: any party holding the token may exercise it. Proof-of-possession semantics , certificate-bound tokens , and DPoP narrow this by binding a token to a key or a client instance. Difference. These bind a credential to who is presenting it. None bind a credential to which operation is about to occur. A key-bound token held by the legitimate client remains usable for any operation within its scope, including one the model composed after the token was issued. An Execution Handle is bound to the digest of a single Candidate Act and authorizes one crossing.

Fine-Grained Authorization Rich Authorization Requests allow an authorization request to carry structured authorization_details describing actions, locations, and data types. GNAP generalizes the delegation model and removes the requirement for pre-registered clients, with resource-server-facing connections defined separately . Difference. Both describe the operation at authorization time, as the client states it. Neither requires the resource server to reconstruct the effect it is about to produce and compare it against what was authorized. Where the requesting party is generative, the gap between the described operation and the executed operation is the attack surface, and it opens after the authorization decision is made.

Policy Enforcement Points The PDP/PEP model is long established , with COPS as a transport for policy decisions and the AAA authorization framework describing pull, push, and agent sequences. Token introspection allows a resource server to validate a token at time of use. Difference. Three, and they are the substance of this document.

The decision evaluates the request. This architecture requires verification against the reconstructed actual effect at the boundary, which detects divergence introduced after the decision.
No existing framework requires the decision point to be non-influenceable by the requesting entity. In conventional deployments the requester is a client; here it is a system capable of composing inputs to the policy evaluation itself. The Protected Enforcement Domain requirement is not an implementation preference.
Enforcement is conventionally placed at the admission or access point. This document places it at the consequence boundary, and requires that every path capable of producing the protected effect carry a sink.

Message Integrity HTTP Message Signatures provide integrity over a message as composed and transmitted. TLS 1.3 with channel bindings binds a credential presentation to a transport channel. Difference. These establish that the message received is the message sent, and that it arrived over the expected channel. They cannot establish that the message, however faithfully transmitted, is an authorized act. Integrity is not authority; a correctly signed instruction to do the wrong thing verifies successfully.

Remote Attestation The RATS architecture defines Attester, Verifier, and Relying Party roles, producing evidence about the state of an entity. Difference. Attestation answers whether a system is in a known-good configuration. It does not answer whether a specific operation emitted by that system is authorized. A model running on fully attested hardware, in an attested software stack, can emit an unauthorized Candidate Act; the attestation remains valid throughout. Attestation is a useful input to validation and an inadequate substitute for it. This document uses attestation to establish the integrity of the Protected Enforcement Domain, not the legitimacy of the act.

Delegation Chains Token Exchange defines impersonation and delegation, including actor chains where authority is conveyed onward. Difference. Propagation of authority along a chain is precisely what Agentic Continuation forbids. Each act derived from the result of a prior act is a new Candidate Act requiring independent validation. A chain in which step n inherits authority from step n-1 permits an agent to reach, through legitimate individual steps, a state no single authorization contemplated.

Constrained Environments The ACE framework carries the OAuth model into constrained devices. Difference. The same gap applies, transposed: the authorization server decides, the resource server enforces possession, and nothing verifies the actuation about to occur against the actuation authorized.

Summary Binding, basis, and timing of verification

Mechanism	Binds	Verified against	Verified when
Bearer tokens	Nothing	Possession	At request
PoP, mTLS, DPoP	Key or client	Presenter identity	At request
RAR, GNAP	Described operation	Stated request	At authorization
Message signatures	Message bytes	Transmission integrity	At receipt
Attestation	Entity state	Known-good configuration	At appraisal
This document	Specific act	Reconstructed actual effect	At consequence

Statement of the Delta No existing specification requires that the effect an enforcement point is about to produce be reconstructed and compared against the effect that was authorized, immediately before the effect occurs, with fail-closed behaviour on divergence. Terminology in this document is used consistently with where corresponding terms exist.

Relevance to IETF Working Groups This section identifies where the work intersects existing IETF and IRTF efforts, and what would be required from each. It is offered to assist venue determination, not to assert charter fit.

DISPATCH DISPATCH is the venue for the initial question. Following the conclusion of SECDISPATCH, DISPATCH provides the standing venue for new-work proposals across the ART and SEC areas, so a security-area architecture proposal now enters there rather than through a separate security dispatch process. The question for DISPATCH is whether an enforcement boundary defined at the point of external effect, rather than at admission, authorization, or transport, is within IETF scope, and if so which group should develop it. The work is security-area in substance: it concerns credential semantics, enforcement placement, and fail-closed behaviour, not application semantics. Where the outcome is a profile of existing mechanisms rather than a new protocol, the relevant group is likely OAUTH.

OAUTH The most direct implementation path. An act-bound, single-consequence credential could plausibly be expressed as a constrained profile over existing OAuth machinery: authorization_details carrying the Candidate Act digest, DPoP or mTLS binding supplying the non-bearer property, and a new confirmation claim expressing the act binding. What is missing from OAuth today and would need definition: a requirement that the resource server reconstruct the effect it is about to produce and compare it to the bound digest, with divergence failing closed. This is a resource-server-side obligation, which OAuth has historically specified sparingly.

GNAP Specifications The GNAP working group has concluded. Its published specifications remain relevant as material to profile rather than as a venue: the negotiated grant model and its explicit resource-server-facing connections accommodate multi-party, per-act grants more naturally than OAuth's client-centric model. An agent requesting authority for one operation, with the grant terminating on use, is closer to GNAP's shape than to a scoped access token. Work building directly on OAuth 2.0 is directed to the OAuth working group.

RATS Two distinct roles. First, attestation establishes the integrity of the Protected Enforcement Domain, namely the claim that the validator is running the expected code and that the AI system cannot influence it. Second, and separately, this document argues that a valid attestation of the emitting system says nothing about the legitimacy of an act that system emits. RATS would be the venue for the first and the group most likely to challenge the second, which is why the distinction is stated explicitly in .

SCITT The Validation Record is an append-only, hash-chained, tamper-evident log of authorization decisions, structurally the same object SCITT specifies for supply-chain statements. Reusing SCITT's transparency service and receipt semantics, rather than defining a parallel log format, would be the preferable path if the shapes align.

WIMSE Where the emitting entity is an autonomous workload rather than a user-delegated client, workload identity is the substrate on which act-binding sits. The question WIMSE work raises for this document: an agent's identity is stable across the acts it emits, so identity alone cannot distinguish an authorized act from an unauthorized one emitted by the same identity. Act-level binding is complementary to workload-level identity, not a substitute.

ACE Where the consequence boundary is physical actuation in a constrained environment, the same requirement applies under tighter resource limits. The reconstructed-effect comparison must be cheap enough to run on the actuating device, which constrains the design more sharply than any other deployment class.

HTTPBIS and HTTPAPI If act-bound authority is conveyed over HTTP, a header field and its processing rules require definition, including behaviour on absence, which must be rejection rather than pass-through. This is the concrete wire-format work, and its absence is the most common objection to architecture-level drafts.

TLS Channel bindings are one component of the presentation binding described in , preventing a valid presentation from being replayed on a different connection. No TLS change is proposed.

IRTF PEARG is relevant where the protected effect is disclosure of personal data and the authority predicate is a purpose constraint. Broader questions, namely whether effect-level enforcement is tractable for systems whose outputs are not enumerable in advance, and the decomposition and aggregation limits stated in , are research questions rather than engineering ones, and are offered as such.

Questions to the Community

Is the gap real: is there an existing mechanism that verifies the effect about to be produced against the effect authorized, at the point of effect?
If it is real, is it IETF work or does it belong to implementers of individual systems?
If it is IETF work, which of the above is the venue, and should the first deliverable be a profile of existing mechanisms rather than a new protocol?

Architecture Overview

Candidate Act to External Effect proceed divergence --> fail closed | +---------------------------+----------------------------+ | v ###################### # External Effect # ###################### ]]>

Contrast with Conventional Enforcement

Conventional enforcement compared with execution finality [ decide on the REQUEST ] --> token | [ PEP: is this token valid? ] --> effect The described request and the produced effect are never compared. This document: candidate act --> [ decide on THIS ACT ] --> act-bound handle | [ sink: is the effect I am about to produce the effect that was authorized for this act? ] --> effect Divergence introduced after the decision is detected at the boundary, not assumed absent. ]]>

Resources and Companion Work

Primary Reference Implementation (Non-Normative) The runnable implementation of the architecture described in this document is the Execution-Finality Reference Implementation for AI agents, GPUs, confidential computing, and zero-trust automation . This repository is the practical companion to this document. It implements the Candidate Act, Protected Enforcement Domain, act-bound Execution Handle, and Finality Sink described in and as executable code, and is the reference a reviewer should consult before concluding that the architecture is unimplementable or that its cost is prohibitive. Measurements reported there reflect the environments in which they were run; readings may vary elsewhere.

Technical Background "The Internet Solved Communication. It Never Solved Authority" provides technical background, an architectural explanation, diagrams, use cases, and supporting material on execution finality. This document specializes the general statement made there to the AI model-to-external-effect boundary. "Declared Purpose Is Not Authorization: Capability Laundering and Execution Finality at the AI Inference Boundary" treats model capability as the governed resource and the response-release boundary as the Finality Sink.

Foundational Companion Drafts draft-das-execution-finality-protocol-layer defines the shared vocabulary this document uses, and the cold-path and hot-path split. Related foundational work includes draft-das-protocols-candidate-act-finality and draft-das-hardware-enforced-execution-finality.

AI and Agentic Profiles draft-das-agentic-tool-binding binds the Candidate Act profile onto tool_use, function calling, and MCP tools/call, and is the concrete dispatch-point specification for the Tool Invocation Candidate Act defined in . Further companion drafts are draft-das-agentic-execution-finality; draft-das-purpose-execution-finality, which addresses capability laundering and the Declared Purpose and Authority Predicate distinction; draft-das-enterprise-ai-output-finality and draft-das-protocols-enterprise-ai, which present the same mechanism from the missing-layer and compromised-workload entry points respectively; draft-das-execution-finality-ai-interoperability, which specifies challenge-bound presentation and exact-effect binding; draft-das-rats-frontier-model-extraction; and draft-das-rats-attestation-bnd-execution-finality.

Regulatory and Domain Profiles draft-das-eu-ai-act-execution-enforcement, draft-das-global-privacy-execution-enforcement, draft-das-digital-sovereignty-finality, draft-das-child-safe-rendering-finality, draft-das-payment-execution-finality, draft-das-ot-actuation-finality, draft-das-precision-bounded-egress, draft-das-ai-native-6g-execution-finality, draft-das-ntn-rf-execution-finality, draft-das-map-discovery-communication-finality, and draft-das-6g-query-scoped-communication-handles.

Frequently Raised Questions Questions commonly raised about this architecture, including performance and latency under each enforcement topology, hardware-enforcement and attestation cost, binding integrity and lineage continuity, replay and time-of-check to time-of-use handling, and the treatment of missing lineage as UNKNOWN rather than EMPTY, are addressed in the reference implementation and in the engineering-considerations material carried by the companion drafts listed above. They are not restated here. Critical review is invited, including on points where the treatment in those materials may be inaccurate or incomplete.

Security Considerations

Compromise of the Protected Enforcement Domain The architecture reduces to the security of the Protected Enforcement Domain. An adversary who can alter the PED's policy, keys, inputs, or decision output can authorize arbitrary Candidate Acts, and every downstream verification will pass correctly. No property claimed in this document survives PED compromise. The PED therefore MUST be isolated from the AI system that produces Candidate Acts, including from its tool layer, its retrieval surfaces, and any content the model can influence. Attestation of the PED establishes that it is running the expected code; it does not establish that the AI system is trustworthy, and the two claims are not interchangeable.

Classification of Consequential Acts The decision of which acts are consequential is the entry point to the entire mechanism. If that classification is influenced by the AI system, the architecture fails open before any validation occurs: an act classified as inconsequential never reaches a sink. The classifier MUST reside inside the PED. Classification MUST default to consequential where the determination is uncertain, since the cost of validating an inconsequential act is latency and the cost of missing a consequential one is unbounded.

Unguarded Paths The guarantee holds only if every path capable of producing the protected effect carries a Finality Sink. A single unguarded path is a bypass, not a gap in coverage: an adversary needs one, and the presence of sinks elsewhere provides no compensating protection. Deployments MUST enumerate the paths capable of producing each protected effect. Where enumeration is not possible, the guarantee is not available and SHOULD NOT be claimed.

Availability and Fail-Closed Behaviour Denial of service against the PED prevents validation and therefore prevents consequence. This is the intended behaviour: unavailability MUST result in denial, never in pass-through. This is the one respect in which the mechanism resembles a fuse rather than an interlock: loss of the enforcement path leaves the system unable to produce external effects until the path is restored. Deployments in which unavailability is less acceptable than unauthorized action are outside the scope of this document, and the trade-off MUST be made explicitly rather than by configuring a fallback that degrades to permit. Operators face real pressure to add such a fallback under load. A deployment that permits on validation failure provides none of the properties described here.

Divergence Detection Bounds The comparison described in is only as strong as the fidelity of the reconstructed actual effect. Where the sink cannot fully reconstruct the effect it is about to produce, because the effect depends on state resolved after the sink or on an interpretation performed downstream, the comparison verifies a proxy, and divergence introduced beyond the reconstruction point is undetected. The sink MUST be positioned at the last point at which the effect is fully determined.

Replay, Freshness, and Binding Execution Handles are single-consequence. Implementations MUST reject presentation of a handle that has already been consumed, MUST enforce a validity window, and MUST bind the presentation to the channel and the named sink, so that a valid presentation cannot be replayed elsewhere. Distinct replay classes, namely the same act to a different sink, the same handle for a second crossing, and replay after expiry, MUST be distinguished in the Validation Record rather than collapsed into a single failure code. Time-of-check to time-of-use conditions between validation and the boundary are addressed by act binding: a mutation after validation changes the reconstructed effect and fails the comparison.

Absent Evidence Missing validation evidence, missing lineage, and missing binding material are UNKNOWN, not EMPTY. Each MUST fail closed. An implementation that treats an absent field as an unconstrained one inverts the property this document specifies.

Properties Not Provided This document does not prevent an authorized act with harmful consequences where the authority predicate was satisfied; decomposition of a prohibited objective into individually authorized acts; cross-session aggregation, where no single act is unauthorized but their union is; or anything occurring inside the AI system prior to the production of a Candidate Act. These are stated so that deployments do not rely on protection that is not offered.

IANA Considerations This document has no IANA actions.