# Secure Multitenancy in TEEs

#### **4.4.1 The Problem of Resource Contention in Sovereign Execution**

As NSF scales across:

* Jurisdictions (e.g., WFP, ICAO, UNDRR, EU, WHO)
* Domains (health, finance, environment, security)
* Institutions (DAOs, treaty bodies, sovereign nodes)

Clause execution infrastructure must support **secure multitenancy**:

> Multiple governance actors using the same physical nodes—without ever compromising privacy, execution fidelity, or attestation integrity.

Traditional cloud-based multitenancy introduces risks:

* Memory leakage
* Side-channel attacks
* Co-tenant poisoning
* Resource starvation
* Non-deterministic behavior under contention

NSF introduces **TEE-based secure multitenancy** with:

* Cryptographic workload isolation
* DAO-scoped runtime enforcement
* Per-clause scheduling constraints
* Verifiable workload audit trails

***

#### **4.4.2 NSF Multitenancy Model Overview**

In NSF, multitenancy is **not process-based**, it is **enclave-scoped**.

Each execution instance runs in a separate, attested enclave container, bound to:

* A **single clause**
* A **governance domain**
* A **jurisdictional scope**
* A **time-limited execution ID**

Multiple tenants (DAOs, states, treaties) can:

* Submit workloads to shared TEE clusters
* Be scheduled concurrently
* Retain full isolation with **hardware, runtime, and memory separation**

***

#### **4.4.3 Enclave-Oriented Tenant Segregation**

| Isolation Layer | Enforcement Mechanism                                       |
| --------------- | ----------------------------------------------------------- |
| **Memory**      | Hardware-enforced boundary (SGX/SEV page-level encryption)  |
| **Filesystem**  | Sealed storage per workload instance                        |
| **Runtime**     | Single-tenant Enarx/SGX enclave per clause execution        |
| **Networking**  | No direct access; all I/O mediated via secure runtime layer |
| **Keys**        | Per-tenant attestation keys; not shared between DAOs        |
| **Audit trail** | Tenant-specific logs, stored and hashed separately          |

Each execution is tagged with:

```json
"tenant": {
  "dao": "ClimateDAO",
  "jurisdiction": "DEU",
  "clause_id": "UNFCCC::CarbonCap@2.3.0"
}
```

***

#### **4.4.4 Execution Scope Enforcement at Runtime**

Before any clause is loaded into a TEE, the scheduler:

1. Validates tenant’s **execution credential (TEEExecutorVC)**
2. Verifies clause and governance metadata
3. Instantiates an **enclave runtime** with:
   * Execution scope
   * Memory bounds
   * Clause and DAO identifiers
4. Assigns a **unique execution ID + CAC output address**
5. Starts the workload under sealed input conditions

No clause can ever “see” or influence another tenant’s workload.

***

#### **4.4.5 Tenant Isolation in Enarx**

NSF’s preferred runtime abstraction—**Enarx**—supports:

* Per-tenant WebAssembly sandbox instantiation
* Hardware-backed attestation of runtime config
* Auditable workload segregation
* Stateless enclave execution (no lingering secrets)
* Per-execution sealing and CAC output signing

This makes it possible to run 1000s of governance workloads in parallel—**with verifiable separation**.

***

#### **4.4.6 Resource Scheduling and QoS for Multi-DAOs**

NSF supports:

* **Governance-priority queues** (e.g., disaster > finance > planning)
* **Jurisdictional quotas**
* **DAO bandwidth tokens** (for fair usage)
* **Peak load overflow routing to secondary nodes**
* **Audit-tracked denial/retry logging**

The scheduler operates under:

* Cryptographically enforced tenancy metadata
* Dynamic workload telemetry
* Governance policy filters (e.g., “don’t schedule health clauses on unverified nodes”)

***

#### **4.4.7 CAC Generation with Tenant Metadata**

Each CAC includes a tenant segment:

```json
"tenant_info": {
  "dao": "WFP-RegionalDAO",
  "jurisdiction": "KEN",
  "resource_class": "Disaster::Flood@v1",
  "workload_id": "exec-0x83719d..."
}
```

This enables:

* DAO-specific post-processing
* Jurisdictional dispute mapping
* Billing or token accounting
* Node workload attribution

***

#### **4.4.8 Multitenancy Fault Isolation and Escalation Paths**

If one workload fails (e.g., due to input error, runtime fault, or simulation failure), NSF ensures:

* No side-channel data leakage
* Failure is logged only in tenant’s audit trace
* Runtime is reset to zero state
* No retry until governance policy re-authorizes
* Optional notification to parent DAO or treaty monitor

Cross-tenant spillover is **cryptographically impossible** by design.

***

#### **4.4.9 Governance Policy Controls on Multitenancy**

DAOs may define policies such as:

* “Only execute in nodes operated in-country”
* “Disallow co-location with unauthorized treaty participants”
* “Require attestations from 3 independent enclaves”
* “Never run health workloads with finance triggers on same node”

These rules are enforced at:

* TEE provisioning time
* Execution queue time
* CAC validation time

***

#### **4.4.10 Secure Multitenancy as the Future of Institutional Compute**

NSF’s multitenancy model makes it possible for:

* Sovereigns
* Treaties
* DAOs
* Research networks
* NGOs

To share infrastructure **without compromising sovereignty, compliance, or trust**.

Multitenancy becomes:

* Not a vulnerability
* But a **verifiable optimization** for running the future of global risk governance—at scale, and with cryptographic integrity.


---

# 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/secure-multitenancy-in-tees.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.