Home

Secure Multitenancy in TEEs

Enabling Multi-DAO, Multi-Jurisdictional Execution on Shared Infrastructure Without Compromising Trust Domains

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:

"tenant": {
  "dao": "ClimateDAO",
  "jurisdiction": "DEU",
  "clause_id": "UNFCCC::[email protected]"
}

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:

"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.

PreviousProof-of-ExecutionNextClause-Attested Compute Rollups

Last updated

Was this helpful?