# TEE Infrastructure

#### **4.1.1 Why TEE Infrastructure Matters for NSF**

Smart Clauses in NSF often govern:

* High-stakes financial flows
* Disaster response mechanisms
* Treaty-bound thresholds
* Risk-model-driven simulations
* Multi-agent decision-making

To be trusted, execution must occur:

* In **verifiably isolated runtimes**
* With **cryptographic attestation**
* With **no unauthorized access to memory, state, or output**
* Under **formal governance boundaries**

Trusted Execution Environments (TEEs) provide **hardware-enforced isolation**, enabling **Clause-Attested Compute (CAC)**—the foundational output unit of the NSF execution layer.

***

#### **4.1.2 Core Properties of a TEE**

A valid NSF-supported TEE must:

| Property                     | Description                                                              |
| ---------------------------- | ------------------------------------------------------------------------ |
| **Isolated memory**          | Clause logic and data are inaccessible to the host OS or hypervisor      |
| **Sealed storage**           | Internal secrets (keys, config) remain encrypted outside the enclave     |
| **Remote attestation**       | External parties can verify enclave identity and runtime state           |
| **Deterministic execution**  | Input-output behavior is fully traceable and reproducible                |
| **Cryptographic sealing**    | CAC outputs are signed with enclave-specific keys and proof of integrity |
| **Governance scope tagging** | Execution must reference DAO, jurisdiction, and credential context       |

***

#### **4.1.3 Supported TEE Types in NSF**

| TEE Type            | Vendor / Stack                 | Status in NSF                                                   |
| ------------------- | ------------------------------ | --------------------------------------------------------------- |
| **Intel SGX**       | Intel                          | Widely supported; attestation + ecosystem maturity              |
| **AMD SEV-SNP**     | AMD                            | Enabled for multi-node deployments; strong isolation guarantees |
| **Arm TrustZone**   | Arm                            | Used for edge and mobile nodes; constrained but useful          |
| **Enarx**           | OSS (Confidential WebAssembly) | NSF preferred abstraction layer; hardware-agnostic, OSS-first   |
| **RISC-V Keystone** | Experimental                   | Roadmap inclusion for sovereign hardware support                |

Each TEE type must pass **NSF Certification Benchmarks** for:

* Memory protection
* Sealing
* Remote attestation
* Performance
* Open-source audibility (if applicable)

***

#### **4.1.4 Enarx as Default NSF Runtime Abstraction**

NSF adopts **Enarx** as the standardized runtime for cross-platform TEE execution:

* Compiles clause logic into **WebAssembly (WASM)**
* Runs in SGX, SEV, TrustZone, and more
* Supports **governance-controlled workload scheduling**
* Integrates with **remote attestation services**
* Enforces **input/output sealing for CAC generation**
* Open-source and auditable
* Designed for confidential governance applications

***

#### **4.1.5 Attestation Infrastructure**

Every TEE node must:

* Generate a **quote** proving the enclave’s measurement hash
* Include a **certificate chain** to hardware manufacturer (Intel, AMD)
* Include enclave-specific metadata (clause ID, DAO, jurisdiction, runtime hash)
* Be verifiable by **remote validators**, DAOs, or third-party auditors

Quotes must be:

* Included in **CAC metadata**
* Signed and timestamped
* Anchored to Audit Layer and optionally to public blockchains

***

#### **4.1.6 TEE Provisioning and Governance Onboarding**

Before a node may execute clauses:

1. **TEE is registered** in the NSF Registry Layer
2. Node undergoes **proof-of-attestation** and **baseline clause test suite**
3. Governance DAO **assigns scope** (domain, jurisdiction, role)
4. Node receives **execution credential**: `TEEExecutorVC`

Provisioning includes:

* Hardware fingerprinting
* Jurisdictional constraints
* Governance-assigned workload types
* Attestation policies (frequency, quote expiration, audit triggers)

***

#### **4.1.7 Clause Runtime Determinism Enforcement**

TEEs must ensure:

* No non-deterministic system calls
* No external clock access without mediation
* All random inputs (e.g., sampling) are **bounded and seed-anchored**
* Inputs/outputs are hashed and sealed before leaving enclave
* Remote parties can **replay inputs to validate outputs**

This guarantees that every clause execution in a TEE is:

* **Trusted**
* **Verifiable**
* **Auditable**
* **Repeatable**

***

#### **4.1.8 Execution Path from Trigger to CAC**

1. Trigger fires (sensor, DAO vote, timer, simulation output)
2. Execution scheduler assigns clause + inputs to available TEE node
3. TEE loads clause logic and validates execution scope
4. Clause runs inside enclave with input sealing and output signing
5. CAC is generated: clause ID, input hash, output, attestation quote, jurisdiction
6. CAC is:
   * Stored in the Audit Layer
   * Available to credential issuers
   * Anchored to public chains (optional)
   * Used to trigger smart contracts, credential updates, or DAO workflows

***

#### **4.1.9 Multi-Tier TEE Architecture for NSF**

NSF supports:

| TEE Tier                  | Description                                                                  |
| ------------------------- | ---------------------------------------------------------------------------- |
| **Core Executors**        | Primary clause runners for high-value or treaty-bound logic                  |
| **Edge Executors**        | Sensor-close nodes for early warning and real-time response                  |
| **Validator Runners**     | Independent third-party enclave verifiers for CAC replication                |
| **Confidential Copilots** | Agent-local TEEs for user governance interfaces and privacy-preserving logic |
| **Sim Nodes**             | Dedicated TEE nodes for forecast model execution and risk analytics          |

Each tier has specific governance, credentialing, and logging rules.

***

#### **4.1.10 TEEs as the Hardware Root of Verifiable Governance**

In NSF:

* Code = policy
* Simulation = foresight
* TEE = execution trust anchor

Together, they enable **Clause-Attested Compute (CAC)** that is:

* Isolated
* Enclave-attested
* Governance-approved
* Agent-executable
* Jurisdiction-scoped

This turns TEEs into the **hardware-level substrate for global governance**—cryptographically secure, policy-bound, and publicly auditable.


---

# Agent Instructions: 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:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/iv.-verifiable-execution/tee-infrastructure.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.