When Data Leaves Its Originating Jurisdiction, Who Controls It? Digital Sovereignty Without Data Localisation by Separating the Compute Plane from the Authority Plane Independent Inventor
Present Address: Kolkata, West Bengal, India Permanent Address: Balasore, Odisha, India Kolkata West Bengal India info@sangamdas.com
Security Consider a simple case: data concerning U.S. citizens is processed in infrastructure located outside the United States. The foreign jurisdiction may have its own lawful-access, surveillance, disclosure, retention, or national-security rules. Even where contractual commitments, privacy policies, regional settings, or enterprise agreements specify how that data should be handled, the infrastructure executing the workload may ultimately operate under legal and technical authority outside the originating jurisdiction. The same problem applies in reverse to European, Indian, Japanese, Canadian, Australian, or other data processed through globally distributed infrastructure. This creates a deeper architectural problem than ordinary data localisation. If control over data automatically follows the physical location of compute, then moving computation across borders can also move practical authority over the resulting data, operations, and disclosures. Privacy may be the first concern, but the same architectural dependency can later affect economic security, critical infrastructure, sensitive enterprise information, government workloads, and national security. This is where policy alone begins to reach its limit. Contracts, privacy policies, adequacy mechanisms, access-control rules, cloud-region settings, and audit requirements remain important. However, they primarily describe what an actor is permitted or expected to do. They do not necessarily create a technical condition that prevents a prohibited external effect from occurring in the first place. Although this document uses the term "digital sovereignty," it does not attempt to standardize national policy, determine which jurisdiction's law should prevail, or prescribe where data must be stored. Its focus is technical: defining an interoperable mechanism by which deployment-selected policy and trust inputs can be bound to a specific Candidate Act and enforced at the effectuation boundary before that act becomes externally effective. In this document, "sovereignty" therefore refers to retained execution authority, not to the standardization of geopolitical or regulatory policy. The architecture described here addresses this problem through a different model of digital sovereignty: separate the Compute Plane from the Authority Plane. The Compute Plane may remain globally distributed. Data may be stored, transformed, analysed, routed, or processed using infrastructure located in another jurisdiction. The architecture therefore does not require that all data remain physically local, nor does it assume that sovereign computing requires complete national isolation from global cloud, telecom, AI, or platform infrastructure. Instead, the Authority Plane remains independently governed. A remote compute environment may perform computation, but computation alone does not grant authority to produce a protected external consequence. A proposed cross-jurisdiction operation is represented as a Candidate Act and remains in a Non-Effective State until the required policy, identity, purpose, destination, jurisdiction, runtime, revocation, and other applicable predicates have been validated. Protected validation may produce a LAVR or equivalent validation commitment and a scoped Finality Authority bound to the particular Candidate Act. At the relevant Finality Sink — the first point at which the protected operation would become externally effective — the authority is independently verified. Only after successful verification and appropriate consumption or reservation of that authority may the external effect occur. The resulting model is therefore: Compute Anywhere -> Authority Remains Independently Governed -> Candidate Act -> Protected Validation -> Scoped Finality Authority -> Finality-Sink Verification -> External Effect. If the required authority is missing, stale, revoked, mismatched, replayed, or inconsistent with the governing jurisdictional policy: No Valid Authority -> No Protected External Effect. This permits a form of digital sovereignty without mandatory data localisation. A jurisdiction, enterprise, regulated institution, or other authorised policy owner does not necessarily need to operate every processor, cloud region, network, or AI system that performs the computation. Instead, it can retain technical control over the conditions under which specified externally effective acts are permitted. The architecture therefore separates two questions that are commonly treated as one: Where is the computation performed? Who has authority over the resulting external effect? Those questions need not have the same answer. A U.S. workload could execute outside the United States while specified sensitive external effects remain subject to U.S.-controlled or enterprise-controlled authorization conditions. An EU workload could similarly use infrastructure outside a particular Member State while retaining independently governed finality requirements. The same mechanism could apply to India, Japan, Singapore, Australia, Canada, multinational enterprises, sovereign clouds, regulated industries, or private data spaces. The architecture does not prescribe which country's policy should prevail and does not attempt to resolve conflicts of law. Its contribution is narrower and technical: cross-border computation does not have to imply cross-border surrender of execution authority. This turns digital sovereignty from a primarily location-centred concept into an authority-centred execution model. The objective is not to fragment the Internet or exclude global technology providers. On the contrary, separating the Compute Plane from the Authority Plane could allow hyperscale cloud providers, AI platforms, telecom operators, CDNs, satellite networks, and other global infrastructure providers to continue supplying efficient distributed computation while supporting stronger jurisdiction-specific, enterprise-specific, or regulated execution guarantees. In this model, sovereignty does not require saying that the data must never leave. It can instead mean: the computation may occur elsewhere, but this protected external effect cannot occur without the required authority. That is the central architectural proposition of this document.
Introduction Consider data concerning persons, enterprises, public bodies, or regulated workloads that originates in one jurisdiction but is processed through infrastructure located in another. The receiving jurisdiction may impose its own lawful-access, disclosure, retention, cybersecurity, surveillance, national-security, or regulatory requirements. The same structural problem can arise regardless of whether the originating jurisdiction is the United States, a Member State of the European Union, India, Japan, Singapore, Canada, Australia, or another jurisdiction. The resulting problem is broader than data localisation. If practical control over protected data automatically follows the physical or logical location of compute, cross-border computation can also move practical authority over disclosures, transmissions, tool calls, model outputs, replication, or other externally effective consequences. The architectural proposition in this document is that cross-border computation need not imply cross-border surrender of execution authority.
Why Policy Alone Is Not an Execution Boundary Law, contracts, privacy policies, data-processing agreements, organisational controls, cloud configuration, IAM, routing policy, encryption, monitoring, and audit remain indispensable. The issue addressed here is not whether those mechanisms matter. The issue is that a rule describing what an actor is permitted or expected to do is not necessarily identical to a technical boundary that prevents a prohibited protected effect from occurring. This distinction becomes increasingly important as automated systems acquire greater computational capability, autonomy, tool access, parallelism, and speed. AI systems and software agents can select tools, call APIs, manipulate files, trigger workflows, initiate communications, operate through multiple services, and create externally effective actions at machine speed. Human review, contractual enforcement, or post-hoc audit can remain useful, but those mechanisms do not by themselves provide complete mediation at the point of effect. The intended security principle is therefore:
Policy remains indispensable, but policy is not complete mediation.
Digital Sovereignty Without Mandatory Data Localisation The proposed model separates the location of computation from the location of authority. The Compute Plane may remain globally distributed, while the Authority Plane can remain independently governed by a provider, enterprise, regulated institution, sovereign-cloud operator, trust service, public authority, or a multi-party combination selected by policy.
Compute Plane The Compute Plane may store, transform, analyse, route, infer, execute, or otherwise process data using infrastructure located in one or more jurisdictions. A deployment is not required to treat physical localisation of all computation as the sole mechanism for digital sovereignty.
Authority Plane The Authority Plane determines whether a protected Candidate Act is authorised to become externally effective. Compute can prepare an action, but compute alone does not necessarily possess final authority to effectuate that action.
Core Separation The model separates two questions:
  • Where is the computation performed?
  • Who has authority over the resulting protected external effect?
Those questions need not have the same answer.
Execution-Finality Architecture
Candidate Act A proposed protected cross-boundary operation is represented as a Candidate Act. Load-bearing attributes can include source identity, protected object or payload reference, requested operation, purpose, destination, jurisdictional context, policy identifier, security epoch, runtime state, and other deployment-defined predicates.
Non-Effective State A Candidate Act remains in a Non-Effective State while required validation is performed. Computation, preparation, serialization, inference, encryption, or routing preparation may occur without yet granting authority for the protected external effect. The architectural invariant is:
Computation is not authority.
Protected Enforcement Domain A Protected Enforcement Domain, or PED, evaluates deployment-selected predicates. Such predicates can include identity, purpose, destination, policy, jurisdiction, runtime state, security epoch, revocation, freshness, replay status, and protected platform state.
Protected Validation Evidence and LAVR Successful validation can produce protected validation evidence. A LAVR can commit to the Candidate Act and relevant validation state before, or in protected coordination with, effectuation. The LAVR is not intended to be merely a post-hoc audit log.
Scoped Finality Authority Successful protected validation can enable issuance of a scoped Finality Authority. The authority can be bound to the Candidate Act, destination, purpose, policy, epoch, Finality Sink, protected identity, revocation state, and bounded-use or single-use conditions. High-assurance implementations can make the authority non-bearer such that possession of an artifact alone is insufficient to exercise the authority from an arbitrary context.
Finality Sink The Finality Sink is the first usable release or effectuation boundary at which the protected external consequence can become effective. It is a functional role and need not correspond to one specific physical component. Examples can include a cloud egress controller, telecom gateway, external API boundary, satellite gateway, storage replication boundary, inter-region transfer boundary, or another protected release point.
Finality-Sink Verification The Finality Sink verifies that the Finality Authority remains valid for the Candidate Act that is actually about to become externally effective. Verification can include Candidate-Act binding, destination, purpose, policy, jurisdiction, security epoch, revocation, sink scope, replay state, and consumption state. Where appropriate, the sink can reconstruct load-bearing Candidate-Act attributes rather than relying solely on an upstream assertion.
Consumption or Reservation Before Effectuation A bounded authority should not remain reusable after enabling a protected external effect. High-assurance implementations can durably consume or reserve authority before, or atomically with, commitment of the external effect. A conceptual lifecycle can be represented as:
ISSUED -> ARMED -> COMMITTING -> EFFECT-COMMITTED -> CONSUMED
The security property is more important than the state names: crashes, retries, concurrency, or replay should not convert one bounded authority into unintended additional effects.
Fail-Closed Behaviour Where strict enforcement is selected, failure of a required finality predicate leaves the Candidate Act non-effective. Failures can include missing authority, invalid binding, policy mismatch, destination mismatch, stale epoch, revocation, jurisdictional evidence failure, replay, sink mismatch, or unavailable required evidence.
Anti-Bypass Closure Finality enforcement is ineffective if a protected external effect can use an alternate unmediated path. Every release path capable of producing the protected externally effective consequence therefore needs to terminate at the same Finality Sink or at an equivalent protected enforcement boundary. Potential bypass paths can include alternate network interfaces, file export, IPC, shared memory, storage replication, vendor HALs, accelerator paths, secondary gateways, external APIs, or other deployment-specific channels.
Jurisdiction and Location Evidence The architecture does not assume that a cloud-region label, IP geolocation result, GNSS reading, or any single signal constitutes infallible proof of physical jurisdiction.
Declared or Network-Derived Evidence
  • Cloud-region identity
  • Routing domain
  • Service-region metadata
  • IP or network geolocation assertions
  • Gateway identity
  • VPC or network context
Protected or Independently Verifiable Evidence
  • Hardware attestation
  • Protected platform identity
  • Trusted time
  • Serving-network or PLMN evidence
  • Gateway or facility attestation
  • Protected infrastructure topology
  • Radio-derived observations where applicable
  • Satellite-related observations where applicable
Cryptographic Binding, Not Cryptographic Geography Cryptography does not itself prove physical location. It can bind the evidence that was evaluated, the Candidate Act, the applicable policy, the validating environment, the destination, the security epoch, and the resulting authorization.
Protected evidence concerning jurisdiction, execution state, and destination can be cryptographically bound to the authorization decision that governs the external effect.
Governance Model The mechanism is jurisdiction-neutral and does not require a single governance model. Authority can be held by an infrastructure provider, enterprise customer, regulated institution, sovereign-cloud operator, trust service, public authority, or a multi-party combination.
Single-Authority Deployment A single policy authority can define the predicates that must be satisfied before a protected Candidate Act is authorised.
Multi-Party or Co-Signed Deployment A high-assurance deployment can require policy authorization from more than one entity. For example, an infrastructure provider and a regulated enterprise or sovereign authority can jointly define or authorize the protected policy bundle.
Protocol Neutrality The mechanism does not determine which jurisdiction's law should prevail, whether a specific transfer is lawful, or which governmental or private entity should control a policy. Those questions remain legal, contractual, organisational, and political matters outside the protocol mechanism.
Machine-Verifiable Finality Receipts A Finality Sink can produce protected evidence describing an authorization or denial result and the corresponding effectuation state. Such evidence can commit to the Candidate Act, policy version, validation state, Finality Sink identity, authorization result, consumption state, and effectuation result. Verifiability does not require globally public disclosure of sensitive transfer metadata. Deployments can use selective disclosure, encrypted receipts, permissioned logs, cryptographic commitments, protected audit systems, or other privacy-preserving verification techniques.
Technical Clarification: Latency, Legacy Deployment, and Historical Feasibility A likely deployment concern is whether cryptographic validation, protected-state transitions, attestation, and independently governed authorization introduce unacceptable latency for cloud, telecom, AI-agent, storage, CDN, or high-throughput network systems. This concern is valid if the architecture is implemented as a synchronous remote approval service placed in the critical path of every packet or every internal computation. That is not the intended performance model.
The architecture separates expensive trust establishment from the local finality decision, and it applies finality to protected externally effective acts rather than blindly re-authorizing every packet or intermediate computation.
The Performance Principle: Do Not Put a WAN Round Trip in Every Effect A design that requires a remote governmental, enterprise, or provider authorization server to answer synchronously for every packet, storage write, AI model token, or tool-dispatch step will not scale across many high-throughput systems. Network round-trip time, availability coupling, queueing, and remote-service failure would dominate the finality decision. The scalable construction separates a cold path from a hot path.
Cold Path: Expensive Operations Are Amortized Operations that are comparatively expensive, infrequent, or dependent on remote trust services SHOULD occur outside the per-effect hot path where the selected security model permits. Examples include:
  • remote platform attestation;
  • certificate-chain construction and validation;
  • policy retrieval and signature validation;
  • trust-anchor establishment;
  • key provisioning or key rotation;
  • registration of Finality Sinks and Protected Enforcement Domains;
  • jurisdiction-evidence source registration;
  • negotiation of supported cryptographic suites;
  • establishment of a policy epoch;
  • revocation-state synchronization; and
  • creation of bounded, protected local validation state derived from the currently authorized policy.
Such state MUST remain constrained by the policy, epoch, destination classes, permitted purposes, revocation conditions, sink identity, and other applicable limits. Amortization MUST NOT silently convert an act-scoped finality decision into an unrestricted bearer credential.
Hot Path: Keep the Finality Decision Local and Compact Immediately before a protected external effect, the hot path can be reduced to operations that are suitable for local execution at or adjacent to the Finality Sink. Depending on the deployment, the hot path can include:
  • canonicalization of the load-bearing Candidate-Act attributes;
  • calculation or verification of a compact Candidate-Act digest;
  • verification of LAVR binding or equivalent protected validation evidence;
  • verification of the scoped Finality Authority;
  • local comparison of destination, purpose, jurisdiction, policy epoch, and sink scope;
  • local revocation or freshness checks against synchronized protected state;
  • replay-state lookup;
  • durable consume-or-reserve transition; and
  • commit of the authorized external effect.
The performance objective is therefore not zero cryptographic cost. The objective is to eliminate unnecessary remote dependency from the critical effectuation path and to keep per-effect work bounded, local, hardware-accelerable, and proportional to the protected act.
Finality Is Per Protected Effect, Not Necessarily Per Packet The architecture does not require an independent sovereign authorization transaction for every Ethernet frame, IP packet, QUIC packet, storage block, model token, or CPU instruction. The protected object is the externally effective Candidate Act defined by the deployment. For example, the protected act can be creation of an outbound cross-jurisdiction flow, release of a protected dataset, invocation of a foreign API with protected content, creation of a replication relationship, dispatch of an agentic tool operation, or another security-relevant release event. Once a specifically authorized effect has entered a protected committed state, ordinary packetization or transport of that already-authorized effect need not repeat the complete policy-validation procedure for every packet, provided that transport cannot be substituted, redirected, expanded, or repurposed beyond the authority that was validated.
Large Payloads Need Not Be Rehashed in Full on the Critical Path A Candidate-Act commitment does not necessarily require rereading and hashing an entire multi-gigabyte or multi-terabyte object immediately before egress. Where integrity of the payload is relevant, the architecture can bind to a protected content digest, object version, immutable storage identifier, Merkle root, authenticated manifest, or equivalent integrity value that was maintained by the protected storage or processing path. The Finality Sink can then verify the load-bearing commitment and the relationship between that commitment and the object being released. The integrity mechanism must prevent an attacker from substituting a different object after authorization.
Public-Key Cryptography Need Not Dominate Every Hot-Path Decision Public-key signatures are useful at trust, policy, delegation, attestation, and cross-administrative-domain boundaries. An implementation need not perform a complete remote attestation exchange and full certificate-chain validation for every protected act. A validated policy epoch and protected local state can allow subsequent act-bound decisions to use compact cryptographic verification appropriate to the negotiated security profile. Implementations can also use hardware acceleration for hashing, authenticated encryption, public-key verification, secure key handling, and protected state management. The protocol should therefore remain cryptographically agile rather than prescribing one expensive operation for every deployment.
Receipts Should Not Block the Effect Unless Policy Requires It Generation of a machine-verifiable finality receipt is logically distinct from remote publication or regulatory ingestion of that receipt. The Finality Sink can create or commit the protected evidence locally as part of the effectuation transaction while transmission, indexing, aggregation, or auditor retrieval occurs asynchronously. A deployment that requires synchronous external notarization can select that stronger model, but such a requirement is not inherent to the base architecture.
Legacy Deployment Profile Existing systems can deploy a software-mediated Finality Sink in an egress proxy, service mesh gateway, API gateway, host networking layer, hypervisor boundary, storage gateway, or telecom control element without immediately replacing all underlying hardware. A software-only deployment can provide useful policy binding, act scoping, replay protection, durable state, and receipts. Its assurance is lower if a privileged administrator or compromised host can bypass that software path. The architecture should therefore distinguish deployment assurance profiles rather than claiming that a legacy software gateway and a hardware-enforced non-bypassable boundary provide identical guarantees. A migration path can be represented as:
Software gateway -> hypervisor or confidential-compute enforcement -> hardware-assisted I/O enforcement -> protected sink-local finality
Approximately Ten Years Ago: Technically Possible, Operationally Heavy Around 2016, the basic ingredients for parts of this architecture already existed: hardware-assisted symmetric cryptography, TPMs, HSMs, secure boot, emerging processor enclaves, programmable network appliances, and conventional policy engines. A protected finality mechanism was therefore technically possible for selected high-value, relatively low-rate operations such as financial authorization, key release, controlled database export, or dedicated gateway enforcement. The limiting factors were not an absence of cryptography. The practical limitations were integration cost, limited enclave capacity and deployment maturity, centralized policy services, less pervasive hardware offload, fewer standardized confidential-computing abstractions, weaker support for protected I/O paths, and the operational difficulty of placing strong mediation directly into general-purpose cloud and network data paths. A universal per-act finality layer across hyperscale distributed infrastructure would therefore have been substantially more difficult and expensive to deploy than a specialized high-value transaction gate.
Approximately Five Years Ago: Practical for Selected Cloud and Confidential-Compute Workloads By approximately 2021, confidential-computing services, cloud attestation, hardware-isolated enclaves, SR-IOV-based I/O virtualization, programmable SmartNICs, increasingly capable service-mesh and policy infrastructure, and stronger cloud key-management integration made protected local enforcement materially more deployable. This period made it practical to separate an untrusted or less-trusted host environment from a protected validation environment for selected workloads. It also made attestation-backed key release and protected processing available as commercial cloud capabilities rather than only specialized laboratory or appliance designs. Important constraints remained: heterogeneous hardware support, enclave memory and I/O limitations on some platforms, remote-attestation complexity, cross-cloud interoperability, and the cost of placing public-key or remote-service operations directly in very high-rate hot paths.
Current High-End Hardware: Move Enforcement Closer to the I/O Boundary Contemporary server and network platforms provide architectural options that were less mature or less widely deployable a decade ago. These include integrated cryptographic accelerators, hardware roots of trust, confidential-computing environments, larger protected memory domains, hardware-assisted network and storage encryption, SmartNICs and DPUs capable of inline security processing, high-speed DMA and SR-IOV paths, and protected key storage adjacent to network or storage interfaces. These capabilities allow an implementation to move parts of finality verification away from a centralized software service and toward the host, DPU, NIC, gateway, secure processor, or other component that already participates in the I/O path. Current hardware does not make cryptographic validation free, and it does not eliminate the need for benchmarking. It changes the engineering question from whether protected enforcement is possible at all to where the enforcement state should reside, which operations belong on the hot path, which operations can be amortized, and which assurance profile is appropriate for the workload.
Illustrative Technology Evolution Is Not a Protocol Dependency Commercial examples of this broader evolution include cloud confidential-computing environments, hardware-isolated enclave services, integrated server cryptographic accelerators, hardware I/O offload systems, modern DPUs and SmartNICs with inline cryptographic capabilities, and Arm confidential-computing mechanisms. These examples demonstrate feasibility trends; they are not normative dependencies. The protocol architecture must remain implementable across multiple processor vendors, cloud providers, network technologies, accelerators, operating systems, and jurisdictions.
Why AI Changes the Latency Discussion Accelerated AI and agentic systems do not merely increase compute performance. They can increase the rate at which software proposes consequential actions. A model can generate tool calls, API operations, file actions, communications, code execution, retrieval requests, cross-agent messages, and other Candidate Acts faster than a human governance loop can review each act individually. The response should not be to place a human or remote policy server synchronously in every action path. The scalable response is to compile or distribute authorized policy into protected machine-verifiable state and enforce the selected invariant at the local effectuation boundary.
Faster computation increases the need for a faster enforcement boundary; it does not justify removing the enforcement boundary.
Latency Budget Should Be Measured by Component A conforming implementation should report latency separately for the major components rather than publishing one undifferentiated "cryptographic overhead" number. Useful measurements include:
  • Candidate-Act canonicalization and digest cost;
  • policy lookup cost;
  • protected-state transition cost;
  • Finality Authority verification cost;
  • revocation and replay-state lookup cost;
  • durable consume-or-reserve cost;
  • Finality-Sink processing cost;
  • receipt commitment cost;
  • cold-path attestation and policy-establishment cost; and
  • incremental end-to-end latency relative to the same effect without finality enforcement.
Measurements should distinguish software-only, TEE-assisted, accelerator-assisted, DPU or SmartNIC-assisted, and other hardware-enforced deployment profiles. Throughput, tail latency, failure behaviour, recovery cost, and concurrency should be reported in addition to average latency.
Target Engineering Invariant The intended performance-security compromise can be stated compactly:
Remote trust establishment MAY be amortized. Protected finality verification MUST remain bound to the actual Candidate Act at the effectuation boundary.
Moving expensive operations off the hot path is an optimization. Moving the final act-to-effect binding off the protected effectuation boundary would weaken the security property that the architecture is intended to provide.
What the Architecture Does Not Claim About Performance The architecture does not claim zero overhead, universal sub-millisecond latency, identical performance on legacy and hardware-assisted systems, or suitability for every packet of every Internet flow. Performance depends on the cryptographic suite, hardware, protected-state mechanism, storage durability model, policy complexity, failure model, network topology, and definition of the Candidate Act. Concrete latency claims require implementation-specific benchmarks. The architectural claim is narrower: modern systems provide sufficient local cryptographic, trusted-computing, and I/O-offload capability to make pre-effectuation enforcement a practical engineering option for selected high-consequence acts without requiring a remote policy round trip for every effect.
Technical FAQ and Adversarial Review
FAQ 1: Why Is Law, Contract, and Audit Not Sufficient? Those mechanisms remain essential because they define obligations, accountability, remedies, and governance. They are not always equivalent to a machine-level invariant that prevents a prohibited protected effect before it occurs. The architecture adds a technical enforcement point rather than attempting to replace law or contract.
FAQ 2: Why Is This More Important in the AI Era? Automated systems can perform large numbers of consequential operations at machine speed, including tool calls, API invocation, file manipulation, model-driven workflow execution, agent-to-agent interaction, and parallel actions. The gap between policy review speed and execution speed therefore becomes more significant. Machine-speed action benefits from machine-speed enforcement at the effectuation boundary.
FAQ 3: Is IAM or OAuth Already the Authorization Layer? IAM and OAuth commonly authorize principals, sessions, scopes, resources, or classes of API operations. Finality authorization addresses whether a particular protected Candidate Act, with specific purpose, destination, jurisdiction, policy, runtime state, and epoch, may become externally effective. Existing IAM and OAuth mechanisms can remain upstream inputs.
FAQ 4: Why Not Use DLP, CASB, Firewalls, or VPC Egress Rules? Those controls can be strong and can provide important predicates. The additional requirement is to bind the actual protected Candidate Act to a scoped finality decision at the first usable effectuation boundary. The contribution is therefore not another firewall rule; it is the binding of Candidate Act, protected validation, scoped authority, and effectuation.
FAQ 5: Why Is Encryption Alone Not Sufficient? Encryption protects confidentiality while data remains unavailable to unauthorized parties. It does not govern every externally effective consequence after legitimate decryption, computation, inference, or transformation. Finality governs whether the protected effect is authorised, while encryption protects the payload and transport.
FAQ 6: How Can Digital Sovereignty Exist Without Data Localisation? The model separates compute location from execution authority. Computation can occur in a foreign or distributed environment while selected protected external effects remain subject to independently governed authorization conditions.
Cross-border computation does not have to imply cross-border surrender of execution authority.
FAQ 7: Can the Architecture Override Foreign Law? No. The architecture does not resolve conflicts of law or invalidate sovereign legal powers. It provides a technical mechanism by which a deployment can require selected conditions before a covered external effect occurs. A jurisdiction can still regulate, prohibit, compel, or otherwise affect the deployment through law.
FAQ 8: Who Controls the Authority Plane? Control is deployment-defined. It can reside with a provider, enterprise, regulated entity, sovereign-cloud operator, trust service, public authority, or multi-party combination. Standardization can define representation, scoping, verification, consumption, and failure behaviour without deciding which actor deserves authority.
FAQ 9: How Can Jurisdiction Be Reliably Determined? No single location signal is assumed to be universally trustworthy. High-assurance deployments can combine multiple evidence classes and define an evidence threshold through policy. Cryptography binds the evaluated evidence to the authorization decision; it does not transform weak evidence into physical truth.
FAQ 10: What Prevents Replay of a Valid Finality Authority? The authority can be bound to the Candidate Act, destination, purpose, policy, security epoch, Finality Sink, protected identity, nonce, and consumption state. Sink-side verification and durable consumption or reservation prevent a captured authorization from functioning as a generic reusable bearer credential.
FAQ 11: How Is Time-of-Check to Time-of-Use Avoided? Finality-Sink verification occurs at the boundary where the protected effect becomes possible. Load-bearing Candidate-Act attributes can be reconstructed or revalidated at that boundary. Material changes in destination, purpose, policy epoch, payload identity, or protected state invalidate authority issued for a different act.
FAQ 12: What Happens During Crashes, Retries, or Parallel Agent Execution? A bounded authority can be durably reserved or consumed before, or atomically with, effect commitment. The implementation must ensure that concurrency, retries, failover, or crashes cannot transform one bounded authority into multiple unintended externally effective actions.
FAQ 13: What Prevents Bypass Through Another Egress Path? The architecture requires anti-bypass closure for protected effects. Alternate network interfaces, file exports, IPC paths, shared memory, storage replication, vendor HALs, accelerator paths, secondary gateways, or equivalent release channels must terminate at the same Finality Sink or an equivalent protected enforcement boundary.
FAQ 14: Why Are Logs and Post-Hoc Audit Not Enough? Logs are valuable for accountability, forensic analysis, incident response, and regulatory review. A log records or proves an event that may already have become irreversible. Finality addresses prevention at the effectuation boundary. Receipts and logs remain complementary evidence after the pre-effectuation decision.
FAQ 15: Why Is This Particularly Relevant to Agentic AI? Agentic systems can collapse part of the traditional separation between decision-making and execution by selecting tools, composing operations, invoking APIs, manipulating resources, initiating communications, and coordinating with other agents. As autonomy and computational capability increase above the enforcement boundary, deterministic and independently governed finality below that boundary becomes more important for high-consequence effects.
Intelligence may remain probabilistic. Execution authority does not have to be.
Comparison with Predominantly Policy-Centred Enforcement A simplified policy-centred sequence can be represented as:
Policy -> Configuration -> Effect -> Audit
The execution-finality sequence is instead:
Candidate Act -> Non-Effective State -> Protected Validation -> Scoped Finality Authority -> Finality-Sink Verification -> Consume or Reserve -> External Effect
The difference is not the removal of policy. The difference is making selected policy predicates a technical precondition of the protected effect.
Benefits to Global Cloud, Telecom, and Platform Providers The architecture is not intended to be anti-cloud, anti-platform, anti-American, anti-European, or anti-global-compute. It can provide an additional capability for infrastructure providers serving customers subject to differing sovereignty and regulatory requirements. Potential use cases include stronger sovereign-cloud assurances, independently verifiable residency controls, regulated-industry infrastructure, confidential-computing integration, machine-verifiable compliance evidence, enterprise policy enforcement, multi-cloud governance, telecom interconnection, satellite systems, and cross-domain AI execution. In such deployments, the infrastructure provider can continue supplying globally distributed compute while the customer or another designated authority retains control over selected externally effective operations.
Residual Trust Boundary The architecture does not eliminate all trust assumptions. A Protected Enforcement Domain can depend on processor hardware, firmware, secure boot, trusted execution environments, attestation infrastructure, certificate authorities, vendor signing systems, and key-management systems. Failure or compromise at those layers can weaken higher-level assurance. This is a general trusted-computing-base problem and is not specific to one vendor or jurisdiction. Execution-finality therefore addresses authority and effectuation at a selected enforcement boundary; it does not by itself solve semiconductor sovereignty, fabrication sovereignty, or every root-of-trust problem.
Threat Model Relevant threats include misconfiguration, malicious or compromised workloads, excessive privilege, confused-deputy behaviour, replay, stale authority, destination substitution, policy substitution, jurisdiction-evidence manipulation, compromised agents, tool misuse, alternate egress paths, concurrency races, crash-retry duplication, and compromised components inside the trusted computing base. The architecture does not assume that all infrastructure operators are malicious. It is intended to reduce the amount of discretionary trust required for selected protected effects.
Security Considerations Security depends on correct Candidate-Act canonicalization, protected predicate evaluation, integrity of policy distribution, authority scoping, revocation, freshness, sink verification, durable consumption state, anti-replay protection, anti-bypass closure, and the integrity of the trusted computing base. An implementation that validates an operation upstream but permits unmediated effectuation through another path does not satisfy the intended complete-mediation property. Cryptographic binding must not be presented as proof that the underlying physical, geographic, hardware, or legal assertions are inherently true. Assurance is bounded by the quality of the evidence sources and the trustworthiness of the components producing them.
Privacy Considerations Jurisdiction evidence, workload identity, destination information, policy identifiers, and finality receipts can themselves reveal sensitive information. Implementations should minimize retained metadata and can use selective disclosure, pseudonymous identifiers, encrypted evidence, cryptographic commitments, permissioned verification, or other privacy-preserving mechanisms. The architecture should not require unnecessary publication of individual transfer events or sensitive infrastructure topology.
Authority Plane and Existing Trust Infrastructure The Authority Plane is not intended to replace IAM, OAuth, GNAP, RATS, EAT, PKI, attestation infrastructure, policy engines, or existing cryptographic trust mechanisms. Those mechanisms answer important but different questions and can provide inputs to the Authority Plane. IAM, OAuth, OAuth Token Exchange, GNAP, and related authorization systems can establish identity, delegation, resource access, scopes, roles, or other upstream authorization context. RATS, EAT, and related attestation mechanisms can provide evidence concerning the identity, integrity, configuration, or protected state of a workload, Protected Enforcement Domain, Finality Sink, or related execution environment. Policy systems can determine which jurisdictional, organizational, contractual, security, purpose, destination, or operational conditions apply. The Authority Plane can consume these inputs. Its narrower function is to determine whether, given the applicable identity, authorization, attestation, policy, runtime, destination, jurisdictional, freshness, revocation, and other required inputs, a particular Candidate Act is permitted to become externally effective. The Authority Plane therefore provides the architectural point at which upstream trust and authorization inputs can be combined into an act-scoped finality decision. The Finality Sink performs the later effectuation-boundary check: it verifies that the resulting authority remains valid for the Candidate Act that is actually about to become externally effective.
Existing trust and authorization mechanisms can establish relevant inputs. The Authority Plane binds those inputs to the particular Candidate Act, and the Finality Sink verifies that binding at the effectuation boundary.
Relationship to Existing IETF Protocols and Future Protocol Realization The architecture described in this document is intended to compose with, rather than replace, existing IETF security, authorization, attestation, representation, and cryptographic mechanisms. Remote-attestation mechanisms, including architectures based on RATS and EAT, can provide evidence concerning the identity, integrity, configuration, or protected state of a Protected Enforcement Domain or related execution environment. Such evidence can serve as an input to protected validation. Attestation evidence alone, however, does not necessarily constitute authority for a particular Candidate Act to become externally effective. OAuth, OAuth Token Exchange, GNAP, enterprise IAM, or equivalent authorization systems can provide upstream identity, delegation, resource, scope, or policy context. Such mechanisms can participate in policy derivation or authority establishment. Execution finality adds a narrower act-to-effect binding: authorization is associated with the particular Candidate Act and is revalidated at the Finality Sink before the protected external effect is committed. Concrete protocol realizations can use existing IETF representation and cryptographic mechanisms, including CBOR, CDDL, and COSE, to encode and protect Candidate Acts, validation evidence, scoped Finality Authorities, and Finality Receipts. Transport-specific profiles can subsequently define integration with HTTP, RPC, messaging, telecom, storage, or other protocol environments. A follow-up protocol specification can define:
  • canonical Candidate-Act representation and digest calculation;
  • LAVR or equivalent protected-validation-evidence representation;
  • scoped Finality-Authority representation;
  • Finality-Sink processing and verification rules;
  • replay, freshness, revocation, reservation, and consumption semantics;
  • denial and protocol error codes;
  • Finality-Receipt representation;
  • cryptographic algorithm profiles and agility requirements; and
  • transport-specific bindings.
The architectural contribution of this document is therefore not a replacement for existing identity, authorization, attestation, policy, or cryptographic protocols. It defines an interoperable act-to-effect boundary at which those inputs can be bound to the actual Candidate Act and independently verified before a protected external consequence is permitted to occur. This document defines the architectural model. Concrete object encodings, cryptographic bindings, processing rules, error semantics, and transport profiles can be specified in separate protocol documents.
IETF Scope and Non-Goals The protocol mechanism does not determine which jurisdiction's law should prevail, whether any specific international transfer is lawful, or which public or private entity should control a deployment policy. The technical objective is to define interoperable mechanisms by which a deployment-selected policy can be bound to a protected Candidate Act and verified at the relevant Finality Sink before the covered external effect becomes effective. The architecture is intended to remain jurisdiction-neutral and provider-neutral.
IANA Considerations This document has no IANA actions at this time.
Core Proposition The architecture does not claim that data must never leave its originating jurisdiction, that cloud-region labels are inherently unreliable, or that cryptography can prove the physical location of every byte. The narrower technical proposition is:
A deployment-defined cross-boundary policy can be made a protected pre-effectuation condition, such that a covered Candidate Act does not become externally effective until the required evidence, authorization, and Finality-Sink predicates have been successfully verified.
In compact form:
Compute anywhere. Keep authority independently governed.
Acknowledgements Technical review and discussion from the Internet engineering, security, privacy, cloud, telecommunications, distributed-systems, and AI-safety communities are welcomed.