> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/iv.-verifiable-execution/tee-infrastructure.md). # TEE Infrastructure ## Trusted Execution Environments in the Nexus Sovereignty Framework: Hardware-Isolated Clause Execution, Remote Attestation, Enclave-Governed Compute, CAC Generation, and Verifiable Governance Runtime Infrastructure ### Why TEE Infrastructure Matters for NSF Trusted Execution Environments matter because the Nexus Sovereignty Framework requires more than well-written clauses, signed registries, deterministic runtimes, and audit logs. It also requires execution environments where high-consequence logic can run with stronger guarantees that code, inputs, intermediate state, and outputs are protected from unauthorized access or tampering. In NSF, Smart Clauses may operate over sensitive disaster data, climate-risk models, public health records, critical infrastructure telemetry, community-protected knowledge, AI agent governance states, Project SPV evidence rooms, finance-readiness evidence, insurance-readiness evidence, credential issuance logic, simulation outputs, and cross-border risk signals. These workloads often cannot be safely executed in ordinary cloud runtimes without additional isolation, attestation, and governance controls. A conventional server can be secured, monitored, and access-controlled, but it often requires trust in the host operator, cloud administrator, operating system, hypervisor, runtime, logging stack, and network perimeter. That is insufficient for a system designed to operate across sovereign nodes, regional consortia, public-good registries, enterprise evidence rooms, AI agents, and multi-jurisdictional data zones. Sensitive clause execution needs a stronger trust model: the ability to prove what code ran, what environment ran it, what inputs were committed, what output was generated, whether execution occurred inside an isolated runtime, and whether the runtime matched an approved measurement. Trusted Execution Environments (TEEs) provide hardware-backed isolation for workloads. They allow code and data to run inside protected enclaves or confidential virtual machines, with remote attestation proving to external verifiers that the expected workload was loaded in a genuine protected environment. In NSF, TEEs help support **Clause-Attested Compute (CAC)**: the proof-bearing output unit that records clause identity, input commitments, output status, runtime measurement, attestation evidence, jurisdictional context, and audit references. TEE infrastructure is especially important where raw data cannot move. In Sovereign Data Zones, community data environments, public health systems, critical infrastructure environments, controlled rooms, and Project SPV evidence rooms, the rule should move to the data, not the data to the rule. TEEs can support compute-to-data by allowing a verified clause workload to execute near protected data while producing only proof-scoped outputs. However, TEEs are not magic. A TEE can help prove that a particular workload ran in a protected environment. It does not prove that the clause is legally valid, that the model is correct, that the data is true, that the output is safe, that a public authority adopted it, that finance is approved, or that insurance coverage exists. TEE evidence must be bound to governance records, clause hashes, input provenance, credential state, simulation status, public-safe rules, and correction pathways. The core doctrine is: **A TEE is an execution-integrity anchor, not a source of governance authority. It strengthens trust in how a clause ran, but the meaning of the result depends on clause governance, data provenance, simulation validity, credential scope, jurisdiction, and lawful adoption.** ### TEEs as Execution Trust Anchors, Not Trust Substitutes The role of TEE infrastructure in NSF is to reduce trust assumptions, not eliminate governance. A TEE can isolate memory, bind execution to a measured workload, generate attestation evidence, and protect inputs or outputs while processing. These are important properties. But a TEE cannot decide whether a clause should exist, whether a threshold is legitimate, whether a public output is safe, whether a credential action is fair, whether a simulation is valid, whether a Project SPV evidence package is financeable, or whether a public authority should act. This distinction prevents cryptographic overclaim. A CAC produced from a TEE proves that an execution occurred under a specified measurement and proof profile. It does not prove universal truth or authority. The CAC says: this clause package, under this runtime measurement, with these input commitments, produced this output in this jurisdictional context. It does not say: the output is legally binding, certified, regulator-approved, investable, insurable, or official. This is why NSF pairs TEEs with the full control stack: Clause Registry, Credential Layer, Data Layer, Simulation Layer, Audit Layer, Communication Layer, Governance Layer, Safe-Mode Logic, and public-safe constraints. TEE isolation is one layer in a defense-in-depth architecture. A mature TEE doctrine should therefore avoid saying “trusted” as if the environment is universally trustworthy. The stronger formulation is: **attested, isolated, measured, and governed execution**. ### Core Properties of an NSF-Compatible TEE An NSF-compatible TEE must provide several core properties before it can support Smart Clause execution. It must provide isolation. Clause code and sensitive data must be protected from unauthorized access by other processes, host administrators, co-tenants, compromised operating system components, or external actors, within the limits of the TEE technology and threat model. It must provide measured execution. The TEE must generate a cryptographic measurement of the workload, runtime, configuration, and relevant dependencies so that verifiers can confirm that the expected clause runner loaded. It must provide remote attestation. A remote verifier must be able to validate a quote, report, or attestation evidence showing that the workload ran in a genuine protected environment and matched an approved measurement. It must provide memory protection. Inputs, intermediate state, and outputs inside the protected environment must be shielded according to the technology’s guarantees. It must provide sealed storage or protected state handling where persistent secrets, keys, model parameters, or cached registry snapshots are needed. It must support input and output commitments. Inputs should be hashed or committed before execution. Outputs should be signed, sealed, or committed as part of CAC generation. It must support deterministic execution profiles where required. Clause logic must not depend on uncontrolled clocks, nondeterministic system calls, unmediated network access, or untracked external state. It must support workload identity. The runtime must know which clause hash, dependency graph, SCL interpreter, compiler profile, and execution policy are loaded. It must support key management. Keys used for signing CACs, decrypting inputs, sealing outputs, and communicating with registries must be bound to node credentials and governance policy. It must support audit integration. Execution events, attestation evidence, CAC metadata, failure states, and safe-mode triggers must flow into the Audit Layer. It must support revocation and suspension. If a node, hardware platform, attestation key, runtime version, or workload measurement is compromised or deprecated, the Registry Layer must be able to block future execution. It must support jurisdictional constraints. Some workloads may execute only in specific sovereign environments, SDZs, national nodes, controlled rooms, or enterprise evidence rooms. The TEE must enforce or report execution location and governance scope as required. It must support side-channel risk management. TEEs can be vulnerable to side-channel attacks. NSF-compatible profiles should include mitigation requirements, patch status, workload risk classification, and restricted use for high-sensitivity workloads where side-channel risks are unacceptable. The TEE is valid for NSF use only within its declared threat model and conformance profile. A TEE profile that is acceptable for low-risk credential checks may not be sufficient for public health data, critical infrastructure secrets, or sensitive Project SPV evidence. ### Supported TEE and Confidential Compute Types NSF should support a plural TEE architecture rather than relying on one hardware vendor or one enclave model. Different jurisdictions, cloud providers, sovereign data centers, edge nodes, and enterprise environments will use different confidential computing technologies. Relevant TEE and confidential compute categories may include Intel SGX-style enclave execution, Intel TDX-style confidential virtual machines, AMD SEV-SNP-style confidential VMs, ARM TrustZone and ARM Confidential Compute Architecture, RISC-V confidential compute efforts, cloud confidential computing services, HSM-backed secure execution, trusted platform modules for measured boot, secure elements for edge devices, and isolated enclaves in specialized hardware. Each TEE type has different strengths and limits. Enclave-based systems may provide strong process-level isolation but face memory limits and side-channel complexity. Confidential VMs may support larger workloads but depend on hypervisor and platform attestation models. Edge secure elements may support key protection but not complex clause execution. HSMs may protect keys but not run full simulations. Mobile TEEs may support field credentials but require careful threat modeling. Sovereign data centers may combine measured boot, confidential VMs, HSMs, and SDZ policies. NSF should not treat all TEEs as equivalent. It should define execution profiles and conformance benchmarks. A profile may be appropriate for clause replay, another for sensitive data evaluation, another for embedded simulation, another for Project SPV controlled evidence rooms, another for edge disaster operations. The seed refers to “NSF Certification Benchmarks.” Unless a formal certification program is created, safer language is **NSF conformance benchmarks**, **NSF execution profile tests**, or **NSF-compatible runtime benchmarks**. These benchmarks can evaluate memory protection, sealing, remote attestation, deterministic execution, runtime integrity, performance, audit integration, reproducibility, key management, side-channel posture, and open-source audibility where applicable. TEE support should be vendor-neutral. NSF should define the proof and governance interface, not lock the ecosystem into a single hardware stack. ### Runtime Abstraction and the Role of Enarx A TEE ecosystem becomes difficult to govern if every hardware platform requires a completely different application model. NSF therefore needs a runtime abstraction layer that allows Smart Clause workloads to run across different TEE technologies while preserving consistent semantics, attestation evidence, input sealing, output signing, and CAC generation. Enarx is a useful model for this abstraction because it is designed to run applications inside TEEs using WebAssembly, with a goal of reducing application dependence on specific hardware technologies. In an NSF context, an Enarx-like runtime abstraction could compile or package clause logic into WebAssembly, run it across supported confidential computing environments, integrate remote attestation, mediate inputs and outputs, and provide a standard interface for CAC generation. The important design principle is not that one project must be the permanent runtime for all NSF execution. The principle is that NSF needs a **standardized, auditable, cross-platform confidential runtime abstraction**. Enarx or comparable WASM-based confidential runtimes can support this by separating clause logic from hardware-specific enclave APIs. A mature NSF runtime abstraction should support: SCL-to-IR-to-WASM compilation or equivalent deterministic execution packaging. Remote attestation integration across supported hardware backends. Governance-controlled workload scheduling. Input binding and sealing. Output signing and CAC generation. Deterministic runtime restrictions. No unauthorized network access unless declared as an input binding. Registry resolution for clause hashes, dependencies, parameters, credentials, and model status. Audit event generation. Safe-mode failure handling. Runtime versioning and reproducible builds. Open-source review where feasible. A WASM-based abstraction is attractive because WebAssembly can provide a portable execution target, sandboxed runtime semantics, and deterministic profiles. However, WASM alone does not create trust. Trust comes from the full package: clause hash, runtime hash, TEE attestation, input commitments, output signature, credential scope, registry status, and governance record. NSF should therefore treat Enarx or similar runtimes as execution infrastructure, not governance authority. ### Attestation Infrastructure Attestation is the mechanism by which a TEE proves to a remote verifier that a specific workload ran inside a genuine protected environment. In NSF, attestation is central to CAC generation. Every TEE node should generate attestation evidence, often called a quote, report, or attestation token depending on platform. This evidence should include a measurement hash of the enclave or confidential workload, relevant runtime measurement, platform evidence, hardware-backed certificate chain or attestation chain, configuration metadata, security version, and node identity. For NSF, attestation evidence should also bind governance-specific metadata. This may include Clause ID, Clause Hash, runtime hash, SCL interpreter or compiler version, dependency graph hash, jurisdiction, SDZ identifier where applicable, node credential, execution profile, policy version, and CAC reference. A remote verifier should be able to validate that the attestation chain is legitimate, hardware security version is acceptable, workload measurement matches an approved runtime, node is registered, node credential is active, clause is authorized for that node, jurisdictional scope is correct, and execution time falls within attestation validity. Attestation quotes should be included in CAC metadata or referenced through a hash and audit pointer if full quotes are large or sensitive. They should be signed and timestamped. They should be anchored in the Audit Layer. Optional public anchoring may be used for non-sensitive commitments, but public chains should not expose sensitive execution metadata. Attestation should also support revocation. If a hardware vendor revokes a platform certificate, if a TEE vulnerability is disclosed, if a node credential is suspended, or if a runtime measurement is deprecated, execution should stop or route to safe mode. Attestation proves measured execution. It does not prove the clause was correct. CAC interpretation must preserve that boundary. ### Attestation Verification and Validator Roles Attestation must be verified by authorized actors or automated verification services. In NSF, verifiers may include registry validators, national nodes, regional nodes, controlled-room reviewers, credential issuers, enterprise evidence rooms, simulation validators, public-safe systems, or AI agent runtimes. Verification should not depend on informal trust in a single operator. The verification process should be standardized and auditable. A validator should check hardware chain, TEE type, security version, runtime measurement, workload measurement, node registration, node credential, clause authorization, jurisdictional scope, and revocation status. For high-consequence workloads, multiple validators may be required. A national SDZ execution may require national node verification. A Project SPV evidence execution may require enterprise evidence room verification and public-good reference compatibility. A community-sensitive execution may require community-controlled approval. A cross-border simulation may require regional validator quorum. Attestation validation records should be audit-linked. The CAC should identify whether attestation was verified automatically, by a quorum, by a national node, by an enterprise evidence room, by a controlled-room reviewer, or by a public-safe workflow. The seed references remote validators, DAOs, or third-party auditors. A safer and stronger formulation is: **remote validators, governance quorums, national nodes, controlled-room reviewers, credential issuers, registry stewards, or qualified independent reviewers where applicable**. DAO tooling may support verification workflows, but the authority is role-bound. ### TEE Provisioning and Governance Onboarding Before a node may execute NSF clauses, it must be provisioned and onboarded into the Registry Layer. TEE onboarding is not merely technical registration. It is governance admission for a compute actor. Provisioning begins with node identity. The node must have a unique identity, hardware profile, platform type, operator identity, jurisdiction, hosting environment, SDZ association where applicable, network location class, key material, attestation method, runtime profile, and governance role. The node must undergo proof-of-attestation. It must demonstrate that it can generate valid attestation evidence under the expected TEE profile. It must run baseline clause test suites to prove deterministic execution, input binding, parameter resolution, credential checks, CAC generation, audit logging, and safe-mode failure behavior. The governance body or registry steward assigns execution scope. Scope may include domains, jurisdictions, data classes, risk classes, clause families, simulation types, credential actions, public-safe outputs, enterprise evidence room tasks, or AI agent workloads. A node approved for low-risk public reference replay may not be approved for public health data or Project SPV confidential evidence. The node receives an execution credential, such as `TEEExecutorVC`, `ConfidentialComputeNodeVC`, `SovereignComputeNodeVC`, or `ControlledRoomTEEVC`, depending on role. The credential should specify issuer, scope, jurisdiction, valid period, allowed clause types, allowed data classes, attestation requirements, audit obligations, and revocation conditions. Provisioning should include hardware fingerprinting where appropriate, jurisdictional constraints, governance-assigned workload types, attestation frequency, quote expiration, key rotation policy, audit triggers, incident reporting obligations, and decommissioning rules. A node that fails onboarding should not execute production clauses. A node whose credential is suspended should be rejected by execution schedulers and clause runtimes. TEE provisioning makes compute a governed participant in the NSF ecosystem. ### Node Scope, Jurisdiction, and Workload Eligibility Not every TEE node may execute every clause. Workload eligibility must be governed. A node may be eligible only for specific jurisdictions. For example, a national public health clause may run only inside a domestic SDZ. A community data clause may run only under community-controlled compute. A Project SPV evidence clause may run only in a controlled evidence room. A regional simulation may run only on approved regional nodes. A public reference clause may run broadly. A node may be eligible only for specific data classes. Public data, restricted data, sovereign-sensitive data, personal data, community-sensitive data, critical infrastructure data, market-sensitive data, and confidential enterprise data require different controls. A node may be eligible only for specific clause actions. It may run validation clauses but not credential issuance clauses. It may run simulations but not public-safe publication. It may generate CACs but not contract-trigger evidence. It may support AI agent checks but not Project SPV evidence. A node may be eligible only for specific risk classes. High-risk clauses should require stronger profiles, more frequent attestation, stricter audit, and possibly quorum verification. Workload eligibility should be checked before execution. A scheduler should not dispatch a clause to a node merely because it is available. It must verify scope, credential, jurisdiction, risk class, data policy, runtime profile, and current node status. This prevents compute convenience from overriding sovereignty. ### Clause Runtime Determinism Enforcement in TEEs TEEs must enforce deterministic execution profiles for clause logic. Isolation is not enough. A protected runtime can still produce nondeterministic outputs if system calls, clocks, random sources, network calls, file access, floating-point behavior, concurrency, or mutable state are uncontrolled. A TEE runtime should prohibit or mediate nondeterministic system calls. External clock access should be mediated through execution context and recorded timestamps. Randomness should be prohibited unless explicitly declared, bounded, seeded, and recorded. External network access should be blocked unless declared as input binding. File system access should be restricted to sealed inputs, declared dependencies, and runtime-managed state. Dependency versions must be pinned. Locale, timezone, numeric precision, and serialization order must be canonical. Inputs should be hashed or committed before entering the enclave. Sensitive inputs may be decrypted inside the enclave only after attestation verification and policy checks. Outputs should be signed and sealed before leaving the enclave. Intermediate state should not be exposed. If persistent state is needed, it should be sealed and versioned. Remote parties should be able to replay inputs or verify proof commitments depending on replay class. If exact replay is not possible because sensitive inputs remain sealed, proof verification or controlled-room replay should be available. This produces execution that is not only isolated, but replayable, auditable, and deterministic under declared scope. ### Execution Path from Trigger to CAC A standard TEE-backed NSF execution path begins with a trigger or invocation. The trigger may come from a sensor, credential request, governance vote, timer, simulation output, registry event, AI agent action, public-safe review, enterprise system, or manual authorized request. The Communication Layer authenticates the trigger and routes it to the execution scheduler. The scheduler resolves the clause ID, verifies clause status, checks risk class, identifies input bindings, determines jurisdiction, and selects an eligible TEE node based on governance scope. The TEE node generates or presents attestation evidence. The scheduler or verifier confirms node credential, hardware profile, runtime measurement, quote validity, and workload eligibility. If attestation fails, execution does not proceed. The runtime loads clause logic, metadata, dependency graph, parameter snapshot, credential resolution policy, public-safe rules, proof profile, and safe-mode logic. It validates that the clause is active and authorized for the node. Inputs are sealed, decrypted, or committed according to data policy. The runtime verifies input hashes, source signatures, credential states, simulation outputs, registry state, and parameter values. It enforces jurisdictional constraints and SDZ rules. The clause executes inside the enclave. It produces output status, bounded actions, proof receipt content, and failure state if applicable. Outputs are sealed, signed, and bound to the enclave measurement. A CAC is generated. The CAC includes Clause ID, Clause Hash, input commitments, output, attestation quote or quote hash, runtime hash, node credential, timestamp, jurisdiction, parameter values, credential snapshot, simulation run references, public-safe status, proof scope, and audit anchor. The CAC is stored in the Audit Layer or referenced through governed storage. It may be made available to credential issuers, public-safe systems, governance dashboards, controlled rooms, Project SPV evidence rooms, simulation reviewers, or authorized enterprise actors depending on scope. Optional public anchoring may record non-sensitive hash commitments. The CAC may support credential updates, review routing, public-safe outputs, AI agent decisions, enterprise workflows, or lawful smart contract interfaces. It does not itself create authority beyond its scope. This execution path turns clause runtime into proof-bearing compute. ### CAC Content from TEE Execution A TEE-backed CAC should include enough information to verify execution without exposing protected data. Its structure should include: Clause ID and Clause Hash. Canonical clause package hash. Runtime profile and runtime hash. TEE platform type and attestation evidence reference. Node ID and node credential. Execution timestamp, event timestamp, and attestation timestamp. Jurisdiction and SDZ context. Input hashes, commitments, or controlled-room references. Parameter values, parameter IDs, and parameter hashes. Credential snapshots and recognition status. Simulation package IDs, model run IDs, output commitments, and uncertainty labels where applicable. Trigger metadata for Reactive Clauses. Output value and output semantics. Public-safe classification. Proof scope and replay class. Bounded actions requested or blocked. Safe-mode status if failure occurred. Audit record ID. Signatures. The CAC should distinguish what is proved and what is not proved. For example, it may prove that a clause ran inside a measured enclave with committed inputs. It does not prove that the data was true beyond validation rules, that the model was correct beyond simulation status, or that any legal or financial decision is approved. CACs must be claims-disciplined. ### Multi-Tier TEE Architecture for NSF NSF should support a multi-tier TEE architecture because different workloads require different execution locations and trust envelopes. A global reference compute tier may run public reference clauses, standards mappings, public test suites, documentation generation, low-sensitivity replay, and open simulation examples. It is useful for interoperability and developer testing, but should not process sovereign-sensitive or confidential data. A regional compute tier may run cross-border simulations, corridor risk models, shared hazard analysis, regional registry operations, and mutual recognition workflows. It should respect national data boundaries and use compute-to-data where raw data cannot move. A national sovereign compute tier may run domestic clauses, national SDZ workloads, public authority support workflows, national credential checks, domestic public-safe outputs, and national registry operations. It preserves jurisdictional control. A community-controlled compute tier may run protected knowledge clauses, local public-safe mapping, community data governance, participatory monitoring, and local safeguard review. It should follow community data governance and public-safe rules. An enterprise or Project SPV evidence compute tier may run confidential asset monitoring, finance-readiness evidence, insurance-readiness evidence, contract evidence, engineering simulations, and controlled-room review. It remains enterprise-scoped and does not imply public-good endorsement or regulated approval. An edge compute tier may run offline or constrained clauses in disaster zones, field devices, IoT gateways, ships, aircraft, clinics, utilities, farms, and remote infrastructure. It requires signed cached state, strict degraded-mode rules, and synchronization. A high-assurance controlled-room tier may run highly sensitive workloads involving protected health data, critical infrastructure, sanctions-sensitive data, security-sensitive clauses, market-sensitive Project SPV evidence, or community-protected knowledge. It may combine TEEs with human review, HSMs, access control, and monitored rooms. Each tier has specific credentialing, logging, attestation, jurisdiction, data classification, replay, public-safe, and recovery rules. This architecture allows TEEs to support many contexts without flattening sovereignty. ### TEE Scheduling and Workload Governance Execution scheduling is a governance function. A scheduler decides where a clause runs. If it chooses the wrong node, data sovereignty may be violated, public-safe rules may fail, or trust assumptions may break. An NSF scheduler should be policy-aware. It should check clause authority class, risk class, data class, jurisdiction, SDZ requirements, node credentials, node attestation, runtime profile, node load, model availability, public-safe constraints, and enterprise scope. It should avoid dispatching workloads to nodes outside their approved scope. Scheduling decisions should be audit-recorded. A CAC should identify why a node was eligible. If no eligible node exists, execution should return blocked or review required, not silently route to an unauthorized node. For high-risk workloads, scheduling may require quorum approval, national node approval, community steward approval, or controlled-room authorization. For low-risk workloads, automated policy scheduling may be sufficient. Governance-controlled scheduling prevents infrastructure from becoming invisible authority. ### TEE Key Management and Sealing TEE execution requires key management. Keys may be used to decrypt sealed inputs, sign CAC outputs, authenticate to registries, access model packages, seal intermediate state, or communicate with subscribers. Weak key management can undermine the entire system. Keys should be generated, stored, rotated, revoked, and audited under governance policy. Where possible, keys should be bound to enclave measurements, node credentials, and execution scope. A key for one clause family should not be usable for unrelated workloads. A key for one jurisdiction should not decrypt data from another jurisdiction unless policy permits. A key used for test execution should not sign production CACs. Sealed storage should protect persistent state. But sealed state can create replay and rollback risks. The runtime must track sealed state version, monotonic counters where available, registry state, and audit logs. If rollback is detected, execution should fail safe. Key compromise should trigger safe mode. Affected nodes, CACs, credentials, and outputs may require review. Key rotation should preserve historical verification. TEE security is only as strong as its key lifecycle. ### TEE Threat Model and Limitations A serious NSF architecture must state TEE limitations. TEEs reduce certain risks, but they do not eliminate all threats. Potential threats include side-channel attacks, speculative execution vulnerabilities, supply-chain compromise, malicious firmware, compromised attestation services, rollback attacks, denial-of-service, flawed enclave code, insecure input handling, dependency vulnerabilities, host-controlled I/O manipulation, traffic analysis, memory safety bugs, microarchitectural leakage, and misuse of attestation claims. TEEs also do not verify source data truth. A spoofed but signed input can still produce a valid enclave output if source governance fails. TEEs do not validate legal authority. They do not ensure fairness. They do not make models correct. They do not guarantee availability. They do not prevent all host interference. A malicious host may deny execution even if it cannot read memory. NSF should define TEE risk profiles. High-sensitivity workloads may require additional safeguards: multi-party validation, redundant execution across independent nodes, ZK proofs, controlled-room review, HSM-backed keys, human oversight, public-safe restrictions, and jurisdictional review. TEE attestation should therefore be interpreted as one proof component, not a universal trust guarantee. ### TEE Failure and Safe-Mode Integration TEE execution must integrate Safe-Mode Logic. If attestation fails, runtime measurement mismatches, node credential is revoked, quote expires, hardware vulnerability status changes, sealed input hash mismatches, output signing fails, or replay fails, the clause should enter a safe-mode path. Failure actions may include blocking execution, freezing node workload eligibility, notifying registry stewards, suspending node credential, routing to compute governance review, marking CAC invalid or disputed, triggering rescheduling to another node, or requiring controlled-room replay. If a vulnerability affects a TEE platform, the Registry Layer should identify affected nodes and CACs. Some executions may remain historically valid under then-current threat model, while future execution is blocked. High-risk outputs may require review. TEE safe mode ensures that compute trust is continuously governed. ### TEEs, ZK, and Hybrid Proof Architectures TEEs and zero-knowledge proofs solve different problems. TEEs protect execution environments and can support complex workloads. ZK proofs can prove specific statements without revealing inputs, but may be limited by computational complexity. NSF should use them together where appropriate. A hybrid pattern may run a complex simulation inside a TEE and generate a CAC with enclave attestation, while a ZK proof verifies a simpler threshold statement derived from the output. Another pattern may use TEE execution for input preprocessing and ZK proof for credential eligibility. A third pattern may use multiple TEEs and compare output commitments, then issue an aggregated attestation. Hybrid proof architecture supports stronger privacy and trust. It also requires clear proof scope. A TEE proof and a ZK proof do not mean the policy is right. They mean defined computational statements were executed or proven under defined conditions. NSF should define proof profiles that specify when TEE, ZK, multi-sig attestation, controlled-room review, or public hash anchoring is appropriate. ### TEEs for Embedded Simulations Embedded simulations may require confidential compute. Models may use sensitive data, proprietary parameters, national risk datasets, critical infrastructure data, or Project SPV evidence. TEEs can allow these models to run under protected execution while producing proof-scoped outputs. A simulation CAC should include model ID, model version, simulation bundle, input commitments, runtime measurement, output summary, uncertainty, jurisdiction, and attestation evidence. If the simulation uses sensitive data, raw inputs remain sealed or controlled. TEE-backed simulations must still satisfy model governance. The TEE proves execution integrity, not model validity. The Simulation Layer must maintain model review, drift monitoring, scope, and uncertainty. If a model is quarantined, the TEE should not run it for production clauses. TEEs help protect embedded simulation, but governance gives the simulation meaning. ### TEEs for AI Agent Governance AI agent governance can use TEEs to enforce tool-use rules, protect prompts and context where appropriate, verify model execution, mediate access to restricted evidence rooms, and generate proof that agent actions followed policy. A TEE may run an agent policy gate that checks model credential, user role, data class, tool scope, and public-safe status before allowing an agent action. However, running an AI model inside a TEE does not make the model safe. It only protects and attests execution. AI safety still requires model evaluation, tool restrictions, memory governance, output review, incident monitoring, and human oversight. TEE-backed AI governance is useful for controlling access and proving execution constraints. It should not be framed as proving AI correctness. ### TEEs for Project SPVs, Finance-Readiness, and Insurance-Readiness Evidence Project SPVs and enterprise evidence workflows often involve confidential asset, financial, engineering, insurance, legal, operational, and climate-risk data. TEEs can support controlled evaluation of evidence without exposing raw data broadly. A Project SPV evidence clause may run inside a TEE to verify that required evidence fields exist, asset telemetry is within tolerance, maintenance records are current, climate simulation output is linked, and public-safe summary is allowed. The resulting CAC can support review by authorized actors without disclosing sensitive details. Finance-readiness and insurance-readiness evidence can benefit from TEE-backed proof. But boundaries must remain clear. A TEE-backed CAC is evidence support. It is not finance approval, investment advice, underwriting, coverage, claims determination, or insurability. TEEs make evidence more verifiable. They do not make regulated decisions. ### TEEs Across GNC, RNC, and NNC Architecture TEE infrastructure should align with the Nexus multiscale architecture. At the global level, the Global Nexus Consortium may maintain reference runtime profiles, conformance tests, proof schemas, CAC formats, public-good runtime specifications, and interoperability patterns. It supports common infrastructure grammar without centralizing all execution. At the regional level, Regional Nexus Consortiums may operate or coordinate regional confidential compute nodes for shared simulations, corridors, hazards, mutual recognition, and cross-border evidence. Regional TEEs support coordination while respecting national data boundaries. At the national level, National Nexus Consortiums may operate sovereign TEE nodes inside national SDZs for domestic clauses, public authority support workflows, national registries, public health, disaster risk, infrastructure, and credential systems. National TEE nodes preserve jurisdictional control. At the community level, community governance bodies may use controlled TEEs for protected knowledge, public-safe maps, local risk data, and community evidence. Community control must govern disclosure. At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, insurers, investors, and contractors may run enterprise TEEs for lawful delivery and controlled evidence review. Enterprise TEEs remain implementation infrastructure, not public-good authority. This architecture prevents the TEE layer from becoming centralized compute sovereignty. ### TEE Boundary Statement TEE infrastructure supports isolated execution, memory protection, workload measurement, remote attestation, input sealing, output signing, CAC generation, compute-to-data, confidential simulation, AI policy gating, Project SPV evidence evaluation, and audit traceability. It does not by itself create legal authority, certify compliance, approve public policy, issue public warnings, approve finance, provide investment advice, underwrite insurance, determine claims, approve procurement, establish treaty compliance, prove data truth, prove model correctness, or guarantee safety. A TEE attestation proves a bounded execution claim under a defined threat model. The institutional meaning of that execution depends on clause governance, source authority, data provenance, simulation review, credential scope, jurisdiction, public-safe rules, and applicable law. A TEE quote is not certification. A CAC is not legal approval. An enclave output is not truth by itself. A confidential simulation is not prediction certainty. A finance-readiness CAC is not finance approval. An insurance-readiness CAC is not underwriting. A public-safe output from a TEE is not an official public warning unless competent authority provides that status. This boundary must be embedded in CAC records, registry entries, runtime documentation, public-safe outputs, and governance dashboards. ### TEEs as the Hardware Root of Verifiable Governance In NSF, Smart Clauses define governed logic. Simulation provides foresight. Credentials define authority. Registries define status. Audit records preserve memory. TEEs provide a hardware-backed execution trust anchor. Together, they make Clause-Attested Compute possible. The TEE is where a clause can run under isolation. The Registry is where its identity is resolved. The Credential Layer is where authority is checked. The Data Layer is where inputs are bound. The Simulation Layer is where model dependencies are governed. The Audit Layer is where execution becomes memory. The Governance Layer is where activation and scope are defined. The Safe-Mode Layer is where failure becomes recoverable. The CAC is the output that binds these together. This is how TEEs become part of public-good governance infrastructure. Not as magical trust machines. Not as substitutes for law, institutions, or judgment. But as measured, attested, policy-bound compute environments that allow sensitive clauses to execute with stronger integrity, stronger privacy, stronger auditability, and stronger sovereignty. TEE infrastructure turns compute into a governed participant in NSF. It makes execution isolatable. It makes runtime measurable. It makes outputs attestable. It makes sensitive data less exposed. It makes compute-to-data practical. It makes AI agent controls more enforceable. It makes Project SPV evidence more reviewable. It makes CACs stronger. It makes failures more detectable. It makes governance more verifiable at the hardware layer. That is the role of Trusted Execution Environments in the Nexus Sovereignty Framework: to provide the hardware-level substrate for clause-attested, jurisdiction-scoped, audit-ready, public-good-aligned execution, while keeping authority where it belongs, in governed institutions, lawful processes, credentialed roles, and correctionable records. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/iv.-verifiable-execution/tee-infrastructure.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.