Independent

Balasore Odisha India info@sangamdas.com

Security Independent Submission agentic AI execution finality tool-call safety Finality Sink non-bearer authority two-instance binding DAS Protocols Decoupled Authorisation System AI safety infrastructure Agentic AI systems now call tools, write memory, move money, change infrastructure, and trigger physical actions. Most safety layers still decide permission upstream and then trust the downstream path. Once that path is compromised, or once the approved request is widened, replayed, or substituted, the act becomes real before any audit can stop it. This document specifies a protected execution-finality architecture of the Decoupled Authorisation System (DAS). It is built on four mechanisms: (1) two-instance binding that separates collection-time evidence from execution-time validation, (2) mutually load-bearing, cross-committed protected evidence so that no single artifact authorizes effectuation, (3) scoped non-bearer finality authority whose possession alone is never enough, and (4) independent Finality Sink reconstruction that re-derives the actual pending operation at the effectuation boundary and permits the act only when every required condition still matches. A Candidate Act remains in a Non-Effective State until the Finality Sink has reconstructed the operation, verified the protected evidence against sink-local monotonic state, and advanced that state. Failure at any step produces fail-closed denial before effectuation rather than post-event remediation. The architecture is applicable to agentic tool use, MCP and connector frameworks, RAG and vector-memory systems, cloud control planes, financial settlement, telecom routing, and cyber-physical control. The document elaborates the problem space, compares the approach with representative existing techniques, presents the detailed solution and its advantages, supplies JSON Schema definitions for core protected objects, and includes an industry-relevance section. Related Indian provisional applications and PCT filings appear in the final appendix.

Introduction The Internet solved communication; it never solved authority . Modern AI systems no longer only generate text. They invoke tools, write to memory, issue API calls, change cloud resources, route network traffic, settle payments, and command physical devices. The moment such an operation becomes capable of producing its intended consequence is the moment of effectuation. Existing safety and authorization layers rarely control that precise boundary. This document describes a protected execution-finality architecture of the Decoupled Authorisation System (DAS). In this architecture a Candidate Act is held in a Non-Effective State until independent protected enforcement stages confirm that the act is authorized, bounded, current, non-replayed, and identical to the operation that is about to become consequence-bearing. Final authority arises only at the effectuation boundary after two-instance binding, cross-committed validation evidence, scoped non-bearer capability release, and independent Finality Sink reconstruction have all succeeded. The architecture is designed so that upstream approval is never treated as effectuation. A policy decision, model decision, or token issuance may contribute protected evidence, but it does not by itself complete the transition from computation to consequence. That transition is controlled at the boundary where the consequence would actually occur.

Problem Space

Technical Field The present disclosure relates to computer systems, artificial-intelligence execution systems, distributed computing systems, secure hardware and protected-state enforcement systems, telecom and network control systems, cloud infrastructure, financial settlement systems, data-governance systems, and cyber-physical control systems. More particularly, it relates to systems and methods for preventing a computed, generated, routed, delegated, transmitted, written, actuated, settled, emitted, disclosed, committed, or otherwise effect-capable operation from becoming consequence-bearing unless independent protected enforcement stages confirm that the operation is authorized, bounded, current, non-replayed, and identical to the operation permitted to reach an effectuation boundary.

Background and the Escalation Path from Computation to Consequence Modern digital systems increasingly perform actions that cause external, durable, financial, physical, legal, administrative, safety-relevant, network-visible, machine-visible, or user-visible effects. Such actions include AI-agent tool calls, database writes, cloud-control-plane operations, telecom routing instructions, financial settlements, memory commits, actuator commands, model-output releases, data exports, credential releases, access-control changes, enterprise workflow approvals, marketplace communications, satellite commands, and other effect-capable operations. Existing authorization systems commonly evaluate permission at an upstream stage. A software policy engine, application-layer access-control component, trusted execution environment, hardware security module, agent-governance middleware, gateway, or approval service may determine that a request appears permitted. After this upstream approval, a downstream component may simply accept the approval result and complete the requested operation. This creates a structural gap. The system that decides “this looks allowed” is often not the same system that finally makes the act real, and the evidence used for the decision is often not re-verified against the actual pending operation at the moment of effectuation. The result is an escalation path from computation to consequence that can be exploited by replay, substitution, widening, stale policy, or compromise of an intermediate path.

Core Technical Weaknesses of Upstream-Only Authorization The following weaknesses recur across conventional designs:

1. Collapsed separation of duties. The same component that collects or binds relevant data may also validate downstream execution, so a single compromise or logic error can both fabricate evidence and authorize the corresponding effect.
2. Blind trust of upstream results. A downstream component may merely trust an upstream approval result without independently reconstructing the actual pending operation at the effectuation boundary.
3. Bearer or weakly bound authority. A token, receipt, capability, or validation result may be replayed, copied, widened, substituted, delegated, rerouted, or used in a stale session.
4. Policy and revocation drift (TOCTOU). Policy or revocation state may change after approval. A system that checks once and executes later may effectuate a consequence that is no longer valid under current protected state.
5. Misbinding and operation substitution. Data or descriptors may be misbound to an unrelated operation. The operation observed upstream may differ from the operation actually presented at the final effectuation boundary.
6. Post-event remediation instead of pre-effectuation denial. Many systems rely on audit, logging, rollback, compensation, or human review after an operation has already become effective. These mechanisms may provide evidence, but they do not prevent the unauthorized effect from occurring in the first instance.

There is therefore a need for an execution-finality architecture in which authority is not completed merely because an upstream component approves a request, issues a token, or validates a policy. There is a need for a system in which a candidate operation remains technically non-effective until protected evidence, protected state, and an independent finality-boundary reconstruction all agree on the same operation, scope, state, sink, and effect.

Specific Risks in Agentic AI and Tool-Using Systems Agentic systems amplify the above weaknesses because they chain tools, memory writes, delegations, and external effects. Representative failure modes include:

• Tool-supply-chain substitution: a tool definition, connector, or MCP server identity differs from the one that was approved.
• Schema or parameter widening: the actual arguments presented at dispatch exceed the scope that was validated.
• Memory and retrieval operationalization: readable embeddings or documents are immediately usable for inference, training, or tool influence without a separate authority check for that operational primitive.
• Multi-agent delegation drift: a downstream agent widens, replays, or re-targets authority that was scoped only for an upstream task.
• Long-running workflow branch effects: a parallel subagent or scheduled run effectuates an action under stale or incomplete context.

Limitations of Representative Existing Approaches

Policy Engines and Upstream Authorization Policy engines and access-control systems answer whether a principal is allowed to request an operation. They do not, by themselves, guarantee that the operation that reaches the effectuation boundary is the same operation that was approved, that the policy epoch is still current, or that the downstream path has not been substituted. An allow decision can therefore travel further than the conditions under which it was issued.

Bearer Tokens and Capability Objects Ordinary bearer tokens or capability objects authorize by possession. Once copied, stolen, forwarded, or replayed they can authorize operations outside the original context. They typically lack mandatory binding to an independently reconstructed operation descriptor at the final boundary and lack mandatory consumption against sink-local monotonic state.

Trusted Execution Environments Alone TEEs and HSMs can protect computation and secrets. They do not inherently enforce a two-instance separation between collection-time binding and execution-time validation, nor do they force independent reconstruction of the pending operation at every effectuation boundary. Protected computation without boundary-local reconstruction still leaves a trust gap at the moment of effectuation.

AI Moderation, Guardrails, and Output Filtering Content moderation and guardrail models may suppress certain generations. They do not control the machine boundary at which a tool call, memory write, or actuator command becomes effective. A moderated text can still reach an effectuation interface through another path, and moderation scores are not the same as operation-specific, sink-verified finality.

Logging, Monitoring, and Post-Hoc Audit Audit systems record what already happened. They support accountability and forensics, but they do not prevent an unauthorized effect from occurring. The architecture described here requires fail-closed denial before effectuation rather than remediation after the fact.

Agent Frameworks and Tool-Calling Middleware Many agent runtimes, MCP servers, plugin systems, and orchestration layers treat a successful policy check or model decision as sufficient to dispatch a tool. They rarely require independent sink-side reconstruction of the actual pending tool identity, schema, parameters, and destination before dispatch. As a result, tool substitution, schema widening, and endpoint replacement remain practical attack and failure modes.

Simulation and Digital-Twin Checks Alone Simulation can estimate consequences but is often advisory. Without binding the simulation result into protected, mutually load-bearing evidence and without requiring Finality Sink verification, a simulated-safe act can still be effectuated through a different path or under changed state.

Proposed Solution: Protected Execution-Finality Architecture The Decoupled Authorisation System (DAS) architecture maintains every effect-capable operation as a Candidate Act in a Non-Effective State until four cooperating mechanisms succeed. Final authority is not completed upstream; it arises only at the effectuation boundary.

Key Concepts Candidate Act — any proposed effect-capable operation held in a Non-Effective State until verified finality authority permits it to become consequence-bearing. Non-Effective State — a technical state in which the Candidate Act may be generated, staged, buffered, simulated, or prepared, but is not permitted to become consequence-bearing. Effectuation — the first protected transition by which a Candidate Act becomes capable of producing its intended consequence. Finality Sink — a component positioned at, within, or proximate to the effectuation boundary that independently reconstructs the actual pending operation and permits effectuation only when protected evidence and sink-local state agree.

Two-Instance Binding A first Protected Enforcement Domain performs Collection-Time Binding. It associates input material, context, source, purpose, scope, logic, behavioral envelope, provenance, and permitted effect with protected descriptors at or near the point of collection or ingestion. Collection-Time Binding does not authorize effectuation; it creates protected evidence that later stages must verify. A second, independent Protected Enforcement Domain performs execution-time validation of the Candidate Act prepared for possible effectuation. It produces protected validation evidence only when the Candidate Act remains within the scope originally bound. The two domains are separated by hardware root, execution instance, trust domain, key material, protected-state namespace, or equivalent isolation so that compromise of one does not automatically forge the evidence of the other.

Mutually Load-Bearing, Cross-Committed Validation Evidence The collection-time binding artifact and the execution-time validation artifact are mutually load-bearing. Neither alone can authorize effectuation. They cross-commit through hashes, signatures, MACs, chained commitments, monotonic counters, policy epochs, revocation epochs, or protected-state references. Alteration, substitution, or reuse of one artifact without the other is detectable. In stronger embodiments a sequence of Ledger-Anchored Validation Receipts forms a chained, replay-resistant validation path in which no individual receipt is sufficient by itself.

Scoped Non-Bearer Finality Authority Upon successful validation a Scoped Non-Bearer Capability, Execution Handle, or Execution Authority Receipt may be generated. Possession of the artifact alone does not authorize effectuation. The artifact is bound to operation identity, purpose, jurisdiction, sink identity, policy epoch, revocation epoch, and related constraints. It may be single-use, limited-use, non- transferable, non-delegable, and sink-bound. The Finality Sink treats the artifact as insufficient by possession and requires correspondence with the reconstructed pending operation and sink-local protected state.

Independent Finality Sink Reconstruction A Finality Sink is positioned at, within, or proximate to the boundary where the Candidate Act would otherwise become consequence-bearing. The Finality Sink independently reconstructs descriptor elements of the actual pending operation (operation type, payload commitment, destination, tool identity, schema, parameters, recipient, account, actuator target, etc.) and compares the reconstructed descriptor against the protected evidence, the scoped non-bearer authority, and sink-local monotonic protected state. Effectuation is permitted only when the reconstructed operation matches the authorized scope and required sink-local protected-state transitions succeed. If any required condition is missing, stale, inconsistent, replayed, revoked, unverifiable, unreconstructable, non-monotonic, mismatched, or incomplete, the Candidate Act remains in a Non-Effective State and is denied before effectuation. Associated pending authority may be poisoned, burned, marked spent, quarantined, or revoked to prevent replay or probing.

Additional Embodiments and Strengthening Mechanisms The base architecture can be strengthened by one or more of the following embodiments:

• Measurement-path attestation. When the Finality Sink obtains descriptor elements through a measurement path (register, bus, sensor, driver, network-egress observation, etc.), it may require attestation of that path before relying on the reconstructed values.
• Atomic verify-and-effectuate. Verification and the first consequence-producing transition can be bound into a single protected operation (compare-and-commit, write-once release, protected latch, etc.) so that a verified act cannot be replaced before commit.
• Operational inertness of readable data. Data, memory objects, or retrieval results may remain readable while still being denied for high-risk operational primitives (indexing, training admission, export, cross-tenant serving) until a scoped non-bearer authority is verified for that primitive.
• Share-based and distributed finality. Multiple independent share-producing nodes may contribute partial enablement shares; effectuation requires satisfaction of a share policy in addition to sink verification.
• Sink-side finality evidence for subsequent operations. After effectuation or denial, the Finality Sink may emit sink-rooted evidence that subsequent workflow steps, memory updates, or downstream agents must verify before continuing.
• Boundary-local policy and revocation epochs. The Finality Sink maintains its own policy and revocation epochs and rejects authority artifacts that are stale relative to those local epochs.

Core Rule Final authority arises only at the effectuation boundary, after independent protected evidence corroborates the Candidate Act, after the Finality Sink reconstructs the actual pending operation, after sink-local protected state is advanced, and only where the operation permitted to become effective is the operation that was bound and validated.

Detailed Finality Sequence A representative end-to-end sequence is as follows.

1. An effect-capable output or request is generated (model output, agent plan, automation request, sensor-triggered instruction, etc.).
2. The system converts it into a Candidate Act and places it in a Non-Effective State. No consequence-bearing transition is permitted yet.
3. The first Protected Enforcement Domain performs Collection-Time Binding and produces a Collection-Time Binding Artifact that commits input, context, source, purpose, scope, and related descriptors.
4. The second Protected Enforcement Domain performs execution-time validation against the bound scope and produces an Execution-Time Validation Artifact that is cross-committed to the collection-time artifact.
5. Optional intermediate Ledger-Anchored Validation Receipts are generated at validation points and chained so that no single receipt is sufficient.
6. If validation succeeds, a Scoped Non-Bearer Execution Handle is released. The handle is bound to the operation digest, sink identity, epochs, and permitted effect, and is not usable by possession alone.
7. At the effectuation boundary the Finality Sink independently reconstructs a descriptor of the actual pending operation from the boundary-local view (payload, destination, tool identity, schema, parameters, etc.).
8. The Finality Sink verifies the reconstructed descriptor against the protected evidence, the Execution Handle, and sink-local monotonic protected state (including policy and revocation epochs).
9. On success, the sink advances protected state and permits effectuation (optionally under an atomic verify-and-effectuate primitive). On failure, the Candidate Act remains non-effective, the handle may be burned, and the act is denied before any consequence occurs.
10. Sink-rooted evidence of the outcome may be emitted for use by subsequent workflow steps, memory updates, or downstream agents.

Non-Completability and Authority-Withholding Embodiments In stronger embodiments the Finality Sink is not merely instructed to refuse unauthorized acts; it is technically unable to complete the Candidate Act unless protected finality validation supplies, reconstructs, unseals, or activates missing execution material. Readable data or staged results may remain operationally inert for selected primitives even when the underlying bytes are accessible. Authority-withholding therefore separates the presence of data or computation from the authority to make that data or computation consequential. This is particularly relevant for RAG stores, vector indexes, agent memory, and tool result caches: storage and inspection can be allowed while indexing, context injection, training admission, and export remain gated by scoped non-bearer authority verified at a Finality Sink.

Comparison and Betterment Relative to Existing Approaches The following table summarizes the principal differences between typical existing approaches and the DAS execution-finality architecture. Comparison of Approaches

Aspect	Typical Existing Approach	This Architecture (DAS)
When authority is completed	Upstream policy or token issuance	Only at Finality Sink after reconstruction
Binding of evidence	Often single-stage or loosely bound	Two-instance, mutually load-bearing, cross-committed
Token / capability semantics	Frequently bearer	Scoped non-bearer; possession insufficient
Operation identity at boundary	Trusted from upstream	Independently reconstructed by Finality Sink
Policy / revocation freshness	Often checked once	Epochs re-verified against sink-local state
Failure mode	Often post-event audit or rollback	Fail-closed denial before effectuation
Agent tool / MCP dispatch	Usually policy + model decision	Sink reconstructs tool identity, schema, parameters
Memory / RAG operational use	Readable data often immediately usable	Readable data may remain operationally inert
Multi-agent delegation	Often trusts upstream scope	Each step bound; sink verifies before effectuation
Measurement integrity	Often assumed	Optional measurement-path attestation

The architecture therefore improves on existing techniques by moving the decisive authority point to the effectuation boundary, requiring independent reconstruction of the pending operation, making evidence mutually load-bearing, eliminating bearer semantics for finality enablement, and enforcing fail-closed behavior before any consequence occurs.

JSON Schema Definitions for Core Protected Objects Illustrative JSON Schema (draft 2020-12) definitions. Implementations may extend these schemas while preserving the required binding, non-bearer, and cross-commitment properties.

Candidate Act

Collection-Time Binding Artifact

Execution-Time Validation Artifact

Scoped Non-Bearer Execution Handle

Ledger-Anchored Validation Receipt

Representative Workflows

Agentic Tool Dispatch Workflow An AI agent proposes a tool call. The proposal is converted into a Candidate Act and placed in a Non-Effective State. Collection-time binding captures the originating model or agent identity, the declared tool identity, the intended schema and parameter commitments, the purpose, and the policy and revocation epochs. Execution-time validation confirms that the Candidate Act remains within the bound scope and produces cross-committed validation evidence. A scoped non-bearer Execution Handle is issued only after mutual corroboration. At the tool-dispatch boundary the Finality Sink reconstructs the actual tool identity, server or connector identity, schema, parameters, and destination, compares them with the protected evidence and sink-local state, and only then permits dispatch. Mismatch, staleness, or missing evidence causes fail-closed denial and may burn the handle.

Memory and Retrieval Operational-Use Workflow A memory object, embedding, or retrieved document may be stored and remain readable. High-risk operational primitives (indexing into a production index, injection into an agent context that can trigger tools, admission into a training pipeline, cross-session reuse, or export) remain denied until a scoped non-bearer authority artifact is verified for that specific primitive. The Finality Sink reconstructs the requested operational use and the target of influence before permitting the primitive. Readable does not mean operationally effective.

Multi-Agent Delegation Workflow When a Candidate Act is delegated across agents, each delegation step is bound to a protected delegation artifact that includes delegating actor, receiving actor, delegated scope, permitted and prohibited effects, purpose, epochs, and prior artifact digests. A downstream agent cannot widen, replay, substitute, or self-effectuate delegated authority without Finality Sink verification at the boundary where the delegated effect would occur.

Cloud Control-Plane Mutation Workflow An AI-assisted or automated request to mutate cloud resources is held as a Candidate Act. Collection-time binding captures the requested resource identity, environment, action type, and authorization scope. Execution-time validation and cross-committed evidence confirm continued consistency with that scope. The Finality Sink at the control-plane boundary reconstructs the actual resource identifier, environment, and mutation parameters before permitting the change. Stale or widened requests are denied before the control plane commits the mutation.

Threat Model Notes and Residual Risks The architecture targets threats in which an upstream approval is valid at one time but the effectuation path is later abused through replay, substitution, widening, stale epochs, or compromise of an intermediate component that is not the Finality Sink. It also targets cases in which readable data is misused for high-risk operational primitives without separate authority. Residual risks include full compromise of every Protected Enforcement Domain and every Finality Sink simultaneously, physical attacks outside the assumed hardware root, and social or procedural bypasses that route an effect through an unprotected alternate path. Implementations MUST close alternate effectuation paths or bring them under equivalent Finality Sink control.

Industry Relevance and Applicability The Decoupled Authorisation System (DAS) architecture is industrially applicable across multiple domains in which an AI-generated or automated decision can produce real-world consequence.

Agentic AI, MCP, and Tool Ecosystems Teams building agentic systems at Anthropic, OpenAI, Google DeepMind, Microsoft, Meta, Amazon, xAI, Cohere, Mistral, and other frontier and enterprise AI organizations can place a Finality Sink at every tool-dispatch, Model Context Protocol (MCP) server, plugin, or connector boundary. The sink reconstructs tool identity, schema, parameters, and destination before dispatch, preventing tool-supply-chain substitution, schema widening, and unauthorized escalation. Memory and retrieval objects can remain operationally inert until a scoped non-bearer authority is verified for the specific operational primitive (indexing, context injection, training admission, etc.).

Cloud Control Planes and DevOps / CI-CD Cloud resource mutations, infrastructure-as-code changes, container deployments, and secret accesses generated by AI agents or automation at Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud, and enterprise DevOps platforms can be held non-effective until the Finality Sink reconstructs the actual resource identity, environment, and permitted effect. This reduces the risk of an upstream policy decision being widened or replayed against production.

Financial Settlement and Digital Assets Payment initiation, settlement, procurement, and marketplace transactions proposed by AI agents can be required to pass sink-side reconstruction of merchant, amount, account, and contractual terms before funds move. This is relevant to payment networks, digital-asset platforms, and financial institutions that integrate agentic automation. The non-bearer property and epoch checks limit replay and stale-authority attacks.

Telecom, 5G/6G, and Network Control Routing instructions, network-configuration changes, and control-plane actions at operators and vendors in the 5G/6G and O-RAN ecosystem can be treated as Candidate Acts. The Finality Sink at the forwarding or control boundary reconstructs the actual instruction and verifies it against protected evidence and sink-local state before the network acts.

Cyber-Physical, Robotics, OT/ICS, and Satellites Actuator commands, robotic motion, industrial-control instructions, and satellite commands can be held non-effective until the Finality Sink reconstructs the actual target, command parameters, and permitted effect. Atomic verify-and-effectuate primitives further reduce the window for substitution. This applies to robotics, autonomous systems, OT/ICS/SCADA, and space-operations environments.

Data Governance, Privacy, and Regulated Systems Readable data can remain operationally inert for high-risk primitives (export, join, training admission, cross-tenant serving) until a scoped non-bearer authority is verified. This supports data-residency, privacy, and regulated-use constraints in healthcare, financial services, and other regulated industries without requiring every byte to be inaccessible for low-risk inspection.

Security Considerations The architecture assumes that the Protected Enforcement Domains and the Finality Sink (or their critical sub-components) remain uncompromised under the applicable threat model. Simultaneous compromise of every protected domain and every alternate effectuation path falls outside the claimed assurance. Implementations MUST enforce fail-closed behaviour. Possession of a binding artifact, validation artifact, or Execution Handle MUST NOT be treated as sufficient authority without verification of the reconstructed operation, epochs, sink identity, and sink-local protected state. Spent, poisoned, or revoked handles MUST be rejected. Measurement paths used for reconstruction SHOULD be attested where the threat model includes tampering with observation interfaces. Atomic verify-and- effectuate primitives are RECOMMENDED for high-impact effectuation boundaries.

IANA Considerations This document has no IANA actions.

Conclusion Upstream approval is not effectuation. By separating collection-time binding from execution-time validation, making evidence mutually load-bearing, issuing only scoped non-bearer finality authority, and requiring independent Finality Sink reconstruction of the actual pending operation, the Decoupled Authorisation System (DAS) architecture ensures that a Candidate Act becomes consequence-bearing only when every required condition still holds at the boundary where the consequence would occur. The result is fail-closed protection for agentic tool calls, memory writes, cloud mutations, financial settlements, network actions, and cyber-physical commands — before the unauthorized effect, not after it.

Normative References Informative References Applicant

Frequently Asked Questions (Critical Technical Concerns) This section addresses questions that implementers, reviewers, and standards participants commonly raise regarding latency, legacy integration, and operational practicality of the execution-finality architecture.

Q1. Does Finality Sink reconstruction add unacceptable latency? A. Reconstruction cost is bounded and can be engineered to fit the effectuation class. Descriptor reconstruction is not a full re-execution of the AI model; it is a boundary-local derivation of operation type, payload commitment, destination, tool identity, schema digest, and related fields already present at the dispatch interface. For low-latency paths (e.g., in-process tool dispatch), the Finality Sink can run co-located with the dispatch boundary, reuse digests computed during Candidate Act formation, and perform constant-time or near-constant- time comparisons against pre-bound evidence. Cryptographic verification can use hardware acceleration (AES-NI, SHA extensions, HSM offload) where available. Atomic verify-and-effectuate primitives further avoid a second round-trip between “check” and “commit.” High-impact effectuation classes (financial settlement, cloud control-plane mutation, physical actuation) already tolerate or require stronger checks; the added finality step is typically small relative to the cost of an incorrect consequence. Implementations SHOULD profile sink latency per boundary class and MAY apply graduated finality (lighter checks for low-risk, full reconstruction for high-risk) without abandoning the non-effective-until-verified rule.

Q2. How does this work with legacy systems that cannot host a Finality Sink? A. Legacy effectuation endpoints need not be rewritten in full. A Finality Sink can be deployed as a mediating gateway, sidecar, proxy, or adapter immediately in front of the legacy interface so that every consequence-bearing call still passes through reconstruction and verification. The legacy system continues to perform its existing commit or dispatch logic; it simply never receives an unauthorized Candidate Act. Where mediation is impossible, a compromise path is to treat the legacy boundary as an intermediate hop and place the Finality Sink at the last controllable point before the unprotected interface, combined with strict network and identity controls so that no alternate path reaches the legacy endpoint. Completely open, unmediated legacy paths remain out of scope for the strongest guarantees; the architecture’s value is highest when all effectuation paths are brought under sink control or equivalently gated.

Q3. What is the performance impact of two-instance binding and cross-committed evidence? A. Collection-time binding and execution-time validation can be pipelined with existing request handling. Binding artifacts are typically small (digests, epochs, identifiers, nonces) rather than full payloads. Cross-commitment is hash- and MAC-oriented and amortizes well across batch or streaming agent workflows. Ledger-anchored receipts, where used, can be appended asynchronously for audit while the critical path only requires the receipts needed for the current finality decision. The dominant cost is intentional: verification at the moment of effectuation. That cost is the price of closing TOCTOU and substitution windows that purely upstream checks leave open.

Q4. Why not just use existing capability tokens or OAuth-style tokens? A. Bearer and many capability tokens authorize by possession and are evaluated away from the final effectuation boundary. They do not require independent reconstruction of the actual pending operation at the sink, nor mandatory consumption against sink-local monotonic state. A stolen, replayed, or widened token can still drive effectuation. Scoped non-bearer handles in this architecture remain insufficient by possession; the Finality Sink must still match the reconstructed operation and advance protected state.

Q5. What happens if the Finality Sink or protected domains are unavailable? A. The default is fail-closed: if required evidence, epochs, or sink verification cannot be completed, the Candidate Act remains in a Non-Effective State and is denied. Operators MAY define explicit, narrowly scoped degraded modes (for example, human-approved emergency actuation under a separate protected path), but those modes must themselves be sink-visible and auditable. Silent fail-open behavior would reintroduce the very escalation path the architecture is designed to close.

Q6. Will this break interactive agent UX with many small tool calls? A. Interactive agents often issue many low-risk tool calls. Implementations can classify effectuation boundaries by risk and apply lighter finality profiles (cached scope, short-lived handles, co-located sinks) to low-risk classes while retaining full reconstruction for high-risk classes (payments, production mutations, external communications, credential release). The architecture does not require identical latency budgets for every tool; it requires that no class skips the non-effective-until-verified rule without an explicit, controlled degradation policy.

Q7. How does Finality Sink work in a distributed multi-region deployment? A. Each effectuation boundary that can produce consequence needs sink coverage in the region or path where the consequence occurs. Sinks do not require a single global coordinator for every check; they require local ability to reconstruct the pending operation and verify against protected evidence and sink-local monotonic state. Cross-region policy and revocation epochs can be propagated with standard secure distribution; the critical property is that effectuation does not proceed on stale local state. Handles remain sink-bound or sink-class-bound so that a handle issued for region A is not blindly accepted in region B without explicit scope.

Q8. How does this apply to Model Context Protocol (MCP) and plugin servers? A. MCP servers, plugin hosts, and connector gateways are natural Finality Sink placement points. Before tool dispatch, the sink reconstructs tool identity, server identity, declared schema, parameter commitments, and destination, then compares them to the protected evidence bound to the Candidate Act. Schema widening, endpoint replacement, and tool-supply-chain substitution are denied at the boundary rather than discovered after the tool has already run.

Q9. Can streaming or partial outputs be handled without holding everything non-effective? A. Yes, with segment-level or cumulative-budget finality. Stream segments that are not yet consequence-bearing (e.g., partial text for display) can be released under a lighter profile, while any segment that would trigger a tool call, memory write, payment, or external commit remains a Candidate Act subject to full sink verification. Cumulative disclosure or effect budgets can be enforced so that many small releases cannot silently assemble an unauthorized high-impact consequence.

Q10. Where does human approval fit? A. Human approval is modeled as a protected finality predicate, not as a free-floating click. A Protected Human Approval token can be bound to the specific Candidate Act, predicted consequence, approver identity, time, and epochs, and is verified by the Finality Sink together with other evidence. Stale, unbound, or replayed approvals do not satisfy finality. Escalated Conditional Finality modes can require human approval only for elevated-risk classes while leaving low-risk classes on automated sink paths.

Q11. Does this require new cryptographic primitives or global key infrastructure? A. No new exotic primitives are required. Standard digests, MACs, signatures, monotonic counters, and optional HSM/TEE sealing suffice for binding, cross-commitment, and non-bearer handles. Key management can follow existing enterprise or cloud KMS patterns. The novelty is the placement of verification at the effectuation boundary and the mutual load-bearing relationship among artifacts, not a new public-key system.

Q12. How does this relate to audit and compliance logging? A. Audit remains valuable but is not a substitute for pre-effectuation denial. Sink-rooted evidence and Ledger-Anchored Validation Receipts can feed compliance logs with a high-integrity record that the operation effectuated (or was denied) under specific evidence and epochs. The architecture prioritizes preventing unauthorized consequence; audit then records what the sink actually allowed or denied.

Q13. Can multiple Finality Sinks be composed in a workflow? A. Yes. A pipeline may have sinks at tool dispatch, at memory commit, and at external egress. Each sink governs its own boundary. Downstream steps can require sink-side evidence from upstream steps so that a later agent or tool cannot continue a workflow that was never finalized upstream. Composition is by evidence chaining, not by collapsing all authority into one upstream decision.

Q14. What about false denials and operational brittleness? A. Fail-closed systems can deny on missing evidence or clock/epoch skew. Mitigations include careful epoch distribution, health checks on sink components, staged rollout by risk class, and explicit break-glass paths that are themselves sink-visible and heavily logged. Brittleness is reduced by making low-risk paths fast and co-located, not by silently skipping verification on high-risk paths.

Q15. Why is this proposed as an Internet-Draft rather than only as product architecture? A. Effectuation boundaries increasingly cross organizational and vendor lines (MCP servers, shared tool marketplaces, multi-cloud control planes, delegated agents). Interoperable notions of Candidate Act, non-bearer finality handles, and sink verification improve safety when the component that generates the act is not the same as the component that effectuates it. An Informational discussion of the problem and architecture helps align implementers even before any protocol is standardized.

Q16. Is a TEE or confidential VM mandatory? A. No. TEEs and HSMs can strengthen Protected Enforcement Domains and sink-local state, but the architecture is defined by binding, cross-commitment, non-bearer handles, and boundary reconstruction—not by a specific hardware enclave. Software-isolated deployments are possible where the threat model allows; hardware roots raise assurance against host compromise.

Q17. How are replay and rollback of protected state prevented? A. Sink-local monotonic counters, spent-handle registries, and advancing policy/revocation epochs make reuse of old handles detectable. Cross-committed receipts bind validation to a specific operation digest and epoch. On denial, handles can be burned or poisoned. Implementations MUST reject non-monotonic or already-consumed state rather than re-accepting historical approvals.

Q18. What is explicitly out of scope for the strongest guarantees? A. Completely unmediated legacy paths that can effectuate without any sink, simultaneous compromise of all protected domains and sinks, and social/procedural bypasses that route work around technical controls. The architecture reduces the technical escalation path from computation to consequence; it does not claim to eliminate every non- technical failure mode. Operators remain responsible for closing alternate effectuation paths or accepting residual risk on those paths.

Acknowledgements This document is part of the broader Decoupled Authorisation System (DAS) Protocols body of work.

Appendix A. Intellectual Property Disclosure — Related Applications The present document is technically related to subject matter disclosed in one or more of the following applications. This statement is provided for architectural and transparency context. Any claim of priority is made only to the extent that the respective application is validly and expressly identified in the official filing record of a corresponding patent application.

A.1. Related Indian Provisional Applications

1. Indian Patent Application No. 202531123959, filed 9 December 2025;
2. Indian Patent Application No. 202531123977, filed 9 December 2025;
3. Indian Patent Application No. 202531125643, filed 12 December 2025;
4. Indian Patent Application No. 202531129538, filed 20 December 2025;
5. Indian Patent Application No. 202531130168, filed 22 December 2025;
6. Indian Patent Application No. 202531130665, filed 23 December 2025;
7. Indian Patent Application No. 202631000572, filed 3 January 2026;
8. Indian Patent Application No. 202631001586, filed 7 January 2026;
9. Indian Patent Application No. 202631002990, filed 12 January 2026;
10. Indian Patent Application No. 202631004331, filed 16 January 2026;
11. Indian Patent Application No. 202631005583, filed 20 January 2026;
12. Indian Patent Application No. 202631005645, filed 20 January 2026;
13. Indian Patent Application No. 202631006616, filed 22 January 2026;
14. Indian Patent Application No. 202631007467, filed 26 January 2026;
15. Indian Patent Application No. 202631009579, filed 30 January 2026;
16. Indian Patent Application No. 202631011216, filed 3 February 2026;
17. Indian Patent Application No. 202631011630, filed 3 February 2026;
18. Indian Patent Application No. 202631016797, filed 16 February 2026;
19. Indian Patent Application No. 202631018571, filed 18 February 2026;
20. Indian Patent Application No. 202631024957, filed 3 March 2026;
21. Indian Patent Application No. 202631030760, filed 14 March 2026;
22. Indian Patent Application No. 202631034260, filed 21 March 2026;
23. Indian Patent Application No. 202631035846, filed 24 March 2026;
24. Indian Patent Application No. 202631038227, filed 27 March 2026;
25. Indian Patent Application No. 202631041923, filed 1 April 2026;
26. Indian Patent Application No. 202631043195, filed 4 April 2026;
27. Indian Patent Application No. 202631043507, filed 6 April 2026;
28. Indian Patent Application No. 202631046689, filed 11 April 2026;
29. Indian Patent Application No. 202631046739, filed 12 April 2026;
30. Indian Patent Application No. 202631047382, filed 14 April 2026;
31. Indian Patent Application No. 202631049021, filed 17 April 2026; and
32. Indian Patent Application No. 202631051652, filed 23 April 2026.

A.2. Related International (PCT) Applications

1. PCT/IB2026/053385, filed 7 April 2026;
2. PCT/IB2026/054453, filed 5 May 2026;
3. PCT/IB2026/055615, filed 4 June 2026 (Mothership Application);
4. PCT/IB2026/055760, filed 7 June 2026;
5. PCT/IB2026/055870, filed 10 June 2026;
6. PCT/IB2026/056058, filed 13 June 2026;
7. PCT/IB2026/056353, filed 22 June 2026;
8. PCT/IB2026/056771, filed 1 July 2026;
9. PCT/IB2026/056809, filed 1 July 2026;
10. PCT/IB2026/056941, filed 6 July 2026; and
11. PCT/IB2026/057198, filed 12 July 2026.

A.3. Relationship to the Mothership Application PCT/IB2026/055615 discloses a broader execution-finality architecture. The present document develops a focused embodiment based on two-instance binding, cross-committed validation evidence, scoped non-bearer finality authority, and independent Finality Sink reconstruction of the actual pending operation at the effectuation boundary.