> 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/secure-multitenancy.md). # Secure Multitenancy ## Secure Multitenancy in the Nexus Sovereignty Framework: Enclave-Scoped Workload Isolation, Jurisdiction-Aware Scheduling, Tenant-Bound CACs, Fault Containment, and Sovereign Shared Compute ### The Problem of Resource Contention in Sovereign Execution As the Nexus Sovereignty Framework scales across jurisdictions, domains, institutions, risk systems, public-good registries, enterprise evidence rooms, AI agents, simulation networks, and Sovereign Data Zones, execution infrastructure cannot assume one actor, one node, one data owner, one jurisdiction, or one workload at a time. The system must support many governance actors using shared physical infrastructure while preserving privacy, sovereignty, deterministic execution, runtime attestation, auditability, and institutional trust. This is a hard problem. Conventional cloud multitenancy is built for efficiency. It allows many customers to share compute, storage, networking, scheduling, accelerators, and orchestration layers. But global risk governance requires more than efficiency. A disaster-risk clause, public health clause, climate simulation, Project SPV evidence check, AI agent control clause, community data safeguard, emissions evidence clause, insurance-readiness workflow, and finance-readiness evidence review may all require different legal boundaries, data classifications, proof requirements, public-safe rules, runtime profiles, and governance scopes. They may run near each other physically, but they must not contaminate each other institutionally or technically. Traditional multitenancy introduces several risks. Memory leakage can expose confidential inputs across tenants. Side-channel attacks can infer sensitive information from timing, cache use, branch patterns, resource contention, or workload shape. Co-tenant poisoning can manipulate shared services, dependencies, queues, caches, registries, or accelerators. Resource starvation can delay emergency workloads. Noisy-neighbor effects can break deterministic runtime expectations. Scheduler opacity can route sovereign workloads to unauthorized nodes. Shared logs can leak metadata. Shared networking can reveal sensitive event timing. Shared accelerators can create difficult proof and isolation questions. Shared model services can mix data contexts. Shared cloud control planes can defeat claims of sovereign control if administrative authority sits outside the governed scope. NSF addresses this through **secure multitenancy**: a model in which shared infrastructure can host multiple workloads only when each execution is isolated, measured, credential-scoped, jurisdiction-aware, audit-traced, and bounded by governance policy. Multitenancy is not treated as an infrastructure convenience. It is treated as a governance condition. In NSF, the question is not simply whether a node has capacity. The question is whether a specific workload may lawfully and safely execute on that node, beside those other workloads, under that TEE profile, in that jurisdiction, with that data class, under that governance scope, producing that CAC, with that audit and recovery path. The core doctrine is: **Shared compute is acceptable in NSF only when tenancy is cryptographically isolated, jurisdictionally scoped, governance-authorized, audit-visible, and incapable of changing the meaning, confidentiality, or integrity of another tenant’s execution.** ### Secure Multitenancy Is Not Ordinary Cloud Sharing NSF secure multitenancy must be distinguished from ordinary cloud multitenancy. Ordinary multitenancy optimizes utilization. NSF multitenancy optimizes verifiable separation under shared infrastructure. A standard cloud tenant may trust contractual controls, platform security, IAM, virtual networks, container isolation, logging, and compliance assurances. These are useful but insufficient for NSF’s highest-value workloads. NSF requires proof that the clause package, runtime, input bindings, tenant scope, jurisdiction, node credential, and output signature are bound together. It requires the ability to show that a disaster-risk execution for one national node did not share unauthorized memory state with a finance-readiness workflow from another Project SPV, that a health workload did not run on a node prohibited for health data, that a community data safeguard did not co-locate with unauthorized analytics, that a treaty-aligned evidence clause did not execute outside the authorized region, and that an AI agent did not access another tenant’s sealed inputs. This does not mean every workload requires maximum isolation. Public test clauses, reference documentation, open simulations, and low-risk registry queries may use lighter profiles. But high-consequence workloads need tenant isolation that is technically enforced and governance-recorded. Secure multitenancy is therefore a spectrum of profiles. At the low end, logical isolation and deterministic runtime controls may be sufficient. At the high end, NSF may require dedicated sovereign nodes, controlled-room TEEs, no co-location, multi-enclave validation, hardware partitioning, jurisdictional residency, accelerator isolation, and human oversight. The architecture must support both efficiency and sovereignty without pretending they are always compatible. ### NSF Multitenancy Model Overview In NSF, multitenancy is not primarily process-based. It is **execution-scope-based** and, where required, **enclave-scoped**. Each material execution instance is treated as a separate governed workload with its own tenant identity, clause identity, execution ID, runtime measurement, input commitments, jurisdictional scope, proof profile, and CAC output. A tenant in NSF may be a national node, Regional Nexus Consortium, Global Nexus reference function, community steward body, public-safe review body, enterprise evidence room, Project SPV, credential issuer, simulation governance function, AI agent runtime, or other authorized governance or implementation actor. The seed refers to DAOs, states, and treaties. In mature NSF language, these are broader: governance bodies, sovereign nodes, national registries, regional consortia, community stewards, treaty-aligned review functions, enterprise evidence domains, and credentialed institutional tenants. DAO tooling may support workflows, but tenancy should not be limited to DAO identity. Each execution instance should bind to: A single clause or clause graph. A tenant identity. A governance domain. A jurisdictional or SDZ scope. A data classification. A runtime profile. A time-limited execution ID. A proof profile. A CAC output address or audit destination. A safe-mode policy. Multiple tenants may submit workloads to shared TEE clusters. They may be scheduled concurrently. They may use the same physical host, cloud region, national data center, regional compute fabric, edge cluster, or enterprise evidence room. But each workload must execute under isolation controls appropriate to its profile. No workload should access another tenant’s memory, keys, sealed input, runtime state, output buffer, private logs, or CAC signing context. This is the basic NSF multitenancy model: shared infrastructure, separate governed executions. ### Enclave-Oriented Tenant Segregation Enclave-oriented tenant segregation means that each high-consequence workload receives a protected execution boundary. The boundary may be an enclave, confidential VM, WASM sandbox inside a TEE, secure container, ZK proof context, controlled-room process, or hybrid environment depending on profile. The important feature is that the tenant’s execution state is scoped, measured, and isolated. Each execution should carry tenant metadata, for example: ```json { "tenant": { "governance_scope": "ClimateEvidenceReview", "tenant_id": "DEU::ClimateNode", "jurisdiction": "DEU", "clause_id": "UNFCCCRef::Emissions::CarbonEvidenceClause@2.3.0", "authority_class": "evidence-support", "data_class": "restricted-national", "execution_profile": "TEE-National-SDZ@1.0" } } ``` The seed example uses `ClimateDAO` and `UNFCCC::CarbonCap`. For claims safety, reference identifiers should avoid implying official UNFCCC enforcement or adoption unless authorized. `UNFCCCRef::Emissions::CarbonEvidenceClause` or `UNFCCCAligned::Emissions::ReportingEvidenceProfile` is safer for reference mapping. Tenant metadata should be included in scheduling decisions, runtime initialization, audit records, CACs, failure notices, billing or resource accounting where applicable, public-safe rules, and dispute routing. The tenant identity should not be a mere label. It should determine which nodes are eligible, what data may be loaded, what public-safe rules apply, what credentials are accepted, what proof profile is required, and what recovery path governs failure. Tenant segregation also means key segregation. One tenant’s input decryption keys, CAC signing keys, sealing keys, model access keys, and audit channels should not be shared with another tenant unless explicitly authorized. Key scope should align with clause, tenant, jurisdiction, and execution profile. A tenant-scoped enclave is therefore not only a technical container. It is a governance container. ### Execution Scope Enforcement at Runtime Before any clause is loaded into a TEE or verifiable runtime, the scheduler must enforce execution scope. The scheduler is not merely an infrastructure component. It is a governance policy gate. The scheduler should validate the submitting tenant’s credential. This may be a NationalNodeExecutionVC, RegionalConsortiumExecutionVC, CommunityStewardExecutionVC, ProjectSPVEvidenceRoomVC, PublicSafeReviewVC, TEEExecutorVC, or equivalent role-bound credential. A tenant credential should specify which workloads the tenant may submit, which jurisdictions apply, which data classes are permitted, which proof profiles are required, and which nodes may be used. The scheduler should verify clause metadata. It should confirm clause status, Clause Hash, version, authority class, risk class, execution profile, data policy, public-safe requirements, dependency graph, parameter requirements, credential requirements, simulation dependencies, and safe-mode policy. The scheduler should verify governance metadata. It should confirm whether the tenant is allowed to execute that clause in that jurisdiction, whether a fork is required, whether a national or community override applies, whether public-safe restrictions block execution, whether the node is eligible, and whether co-location rules permit the workload. The scheduler should instantiate a runtime with explicit execution scope. This includes memory bounds, CPU and accelerator limits, network policy, filesystem policy, time policy, randomness policy, input sealing policy, output signing policy, tenant ID, clause ID, governance scope, jurisdiction, execution ID, CAC destination, and audit channel. The runtime should load sealed inputs only after attestation and policy checks. It should not allow unmediated external calls. It should not allow one execution to inspect another execution’s memory or state. It should not persist tenant secrets after execution unless sealed under policy. It should clear state on completion or failure. No clause should ever see or influence another tenant’s workload. More precisely, no workload should gain unauthorized access to another tenant’s inputs, outputs, intermediate state, keys, audit payloads, model parameters, or execution controls. It may observe aggregate resource availability only if such telemetry is public-safe and governance-approved. Runtime scope enforcement is how multitenancy becomes trustworthy. ### Tenant Isolation in WASM and Enarx-Like Runtimes An Enarx-like confidential WebAssembly runtime can support secure multitenancy by instantiating tenant workloads as separate WASM modules inside hardware-backed or confidential compute environments. This allows clause logic to be packaged in a portable, auditable runtime format while preserving isolation from host and co-tenants. The benefits of a WASM-based confidential runtime include portable execution, sandboxed module boundaries, deterministic runtime profiles, reduced hardware coupling, reproducible builds, and easier audit of runtime behavior. When combined with TEE attestation, the runtime can prove which module, runtime, and configuration loaded. For NSF, an Enarx-like runtime should support per-tenant WASM sandbox instantiation, hardware-backed attestation of runtime configuration, workload segregation, stateless execution where possible, per-execution sealing, CAC output signing, deterministic system call mediation, and no unauthorized persistence of secrets. The seed says this makes it possible to run thousands of governance workloads in parallel with verifiable separation. That is a useful goal, but should be framed as an architectural capacity objective rather than a guarantee. Actual throughput depends on hardware, memory limits, simulation complexity, attestation overhead, input size, proof profile, and risk class. High-sensitivity workloads may deliberately avoid dense co-location. The mature formulation is: An Enarx-like runtime makes high-volume confidential governance execution feasible by standardizing workload packaging, attestation, sandboxing, and CAC generation across heterogeneous TEE backends, while allowing NSF governance policies to decide which workloads may share infrastructure. The runtime abstraction supports scale. Governance decides the conditions of scale. ### Stateless Execution and Secret Hygiene Secure multitenancy depends on careful state management. A major risk in shared compute is leftover state: keys, decrypted inputs, cached model parameters, temporary files, memory pages, logs, token credentials, or output fragments persisting after execution. NSF should prefer stateless enclave execution where possible. In stateless execution, each workload receives sealed inputs, executes, produces CAC output, clears memory, destroys ephemeral keys, and exits. Persistent state should be avoided unless required. If state is required, it should be sealed, versioned, tenant-scoped, and rollback-protected. Secret hygiene should include ephemeral keys, per-execution key derivation, memory zeroization, no shared temporary directories, no shared unencrypted logs, no shared model cache unless public and approved, no tenant secrets in crash dumps, no raw sensitive inputs in scheduler logs, and no reuse of output signing keys across unauthorized scopes. If a workload fails, runtime reset should remove tenant state. The failure notice should include commitments and metadata, not raw secrets. Secret hygiene turns tenant isolation into operational discipline. ### Resource Scheduling and Quality of Service Secure multitenancy must also handle resource contention. If many workloads compete for the same TEE nodes, emergency and high-risk workloads must not be starved by low-priority workloads. At the same time, priority scheduling must not become arbitrary or politicized. NSF should support governance-aware scheduling and quality-of-service policies. These may include priority queues, jurisdictional quotas, tenant quotas, risk-class priority, emergency escalation, public-safe queue separation, simulation workload windows, edge fallback, overflow routing, retry policies, and audit-tracked denial logs. A disaster response workload may receive priority over planning simulations. A public health emergency may receive priority over routine registry checks. A credential revocation safety check may receive priority over documentation generation. A national SDZ workload may be restricted to in-country nodes even if external nodes have capacity. A community-sensitive workload may require dedicated compute. A Project SPV evidence workflow may use enterprise-funded capacity without displacing public-good emergency workloads. The seed references DAO bandwidth tokens for fair usage. This can be reframed as **resource credits**, **capacity quotas**, **governance-priority allocations**, or **workload entitlements**. Token language can be misunderstood as financialized governance or tradable authority. In NSF, resource allocation should not allow actors to buy governance power over public-good execution. If credits exist, they should allocate compute usage, not authority. Scheduling decisions should be audit-tracked. If execution is denied or delayed, the system should record reason: no eligible node, jurisdictional restriction, quota exceeded, attestation unavailable, risk-class priority conflict, public-safe restriction, or safe-mode state. Quality of service in NSF is not only performance. It is fairness, sovereignty, and resilience under contention. ### Governance Policy Filters in Scheduling Scheduling must apply governance policy filters before resource optimization. A node may be fast and available but still ineligible. Policy filters may include: Do not schedule national health workloads outside approved national SDZs. Do not schedule community-sensitive geospatial workloads on non-community-approved nodes. Do not schedule finance-readiness Project SPV evidence on public reference nodes. Do not schedule critical infrastructure clauses on nodes without high-assurance TEE profile. Do not schedule AI agent tool-use clauses on nodes with expired runtime profile. Do not schedule public-safe publication clauses without public-safe runtime and review channel. Do not co-locate restricted health workloads with unrelated high-throughput analytics if policy forbids co-location. Do not schedule workloads using deprecated attestation profiles. Do not schedule clauses whose fork is disputed. Do not schedule simulations requiring GPU isolation on shared GPU infrastructure lacking approved partitioning. These policies should be machine-readable and registry-linked. Scheduler outputs should record policy checks. The scheduler should optimize only after governance filters pass. ### CAC Generation with Tenant Metadata Every CAC generated in a multitenant environment should include tenant metadata. This metadata enables audit, dispute mapping, resource accounting, workload attribution, and jurisdictional review. A tenant segment may look like: ```json { "tenant_info": { "tenant_id": "KEN::DisasterRiskNode", "governance_scope": "FloodReadinessEvidenceReview", "jurisdiction": "KEN", "resource_class": "Disaster::Flood@v1", "workload_id": "exec-0x83719d", "execution_profile": "TEE-National-SDZ@1.0", "co_location_policy": "restricted-co-location", "scheduler_decision_hash": "0x..." } } ``` The seed uses `WFP-RegionalDAO`. This should be used only if a WFP-aligned governance workflow actually exists. Safer language is `FoodSecurityRegionalEvidenceReview`, `HumanitarianRegionalNode`, or `WFPReferencedFoodSecurityProfile` unless authorization exists. Tenant metadata supports post-processing. A tenant can retrieve its CACs. A national node can identify domestic executions. A regional consortium can compare outputs without seeing restricted payloads. A public-safe dashboard can verify which tenant generated an output. A Project SPV evidence room can map execution to its controlled review. A dispute body can route challenges to the correct jurisdiction or governance scope. Tenant metadata may also support billing or resource accounting where appropriate. But billing must not be confused with governance authority. Paying for compute capacity does not buy clause approval, recognition, public-good endorsement, finance approval, insurance readiness status, or public authority standing. Tenant-aware CACs make shared infrastructure accountable. ### Multitenancy Fault Isolation and Escalation Paths Fault isolation is one of the most important properties of secure multitenancy. If one workload fails, it should not compromise other tenants, leak data, poison shared state, or destabilize unrelated executions. A workload may fail because of invalid input, simulation error, credential conflict, runtime attestation failure, memory limit, timeout, trigger overload, public-safe block, policy conflict, or downstream dependency failure. The failure should be contained inside the tenant’s execution scope. The runtime should reset to a clean state. Secrets should be destroyed. The failure notice should be written to the tenant’s audit trace and any authorized governance monitor. Other tenants should not receive sensitive failure details. The seed says cross-tenant spillover is cryptographically impossible by design. That is too absolute. A safer and more technically credible formulation is: **NSF designs multitenant execution so that cross-tenant spillover is prevented by isolation, attestation, scheduling policy, memory hygiene, key separation, audit monitoring, and safe-mode controls; no system should claim impossibility against all hardware, side-channel, supply-chain, or operational failures.** Fault isolation must also include scheduler-level protections. If a node experiences repeated failures, it may be removed from scheduling. If a tenant workload triggers resource exhaustion, quota enforcement and throttling should prevent harm to others. If a TEE vulnerability affects co-located workloads, affected tenants should be notified under public-safe and confidentiality rules. Retry should be governed. A failed workload should not automatically retry indefinitely. Retry may require policy authorization, corrected input, new attestation, or review. High-risk failures should not retry until governance permits. Fault isolation converts multitenancy from shared risk into bounded risk. ### Cross-Tenant Side-Channel Risk Management Side-channel risk is one of the hardest problems in secure multitenancy. Even if memory is isolated, co-tenants may infer information from timing, cache contention, branch prediction, power use, shared accelerators, memory access patterns, network timing, storage behavior, or scheduling latency. NSF should treat side-channel management as part of the execution profile. For low-risk workloads, ordinary TEE isolation may be sufficient. For high-risk workloads, NSF may require dedicated cores, no simultaneous multithreading, cache partitioning, constant-time algorithms where relevant, noise controls, workload padding, dedicated accelerators, no co-location, hardened enclave profiles, or controlled-room execution. Sensitive workload classes may require anti-co-location policies. For example, public health workloads, sanctions-sensitive workflows, critical infrastructure telemetry, community-protected geospatial data, high-value Project SPV evidence, or security-sensitive AI controls may prohibit co-location with unauthorized tenants or require dedicated nodes. GPU and accelerator multitenancy require special attention. Many AI and simulation workloads use GPUs. GPU memory isolation, side-channel controls, driver trust, model cache separation, and deterministic scheduling are difficult. NSF should define accelerator profiles and not assume that CPU enclave guarantees automatically extend to GPUs. Side-channel risk cannot be eliminated universally. It must be classified, mitigated, disclosed, and governed. ### Co-Location Policies Co-location policies specify which workloads may share physical or logical infrastructure. They are essential for sovereign execution. A co-location policy may allow public reference workloads to share broadly. It may allow same-jurisdiction workloads to share. It may allow same-tenant workloads to share. It may prohibit health workloads from sharing with finance workflows. It may prohibit community-sensitive data from sharing with external analytics. It may require dedicated nodes for critical infrastructure. It may restrict treaty-aligned evidence workflows to participating jurisdictions. It may prohibit co-location with tenants lacking reciprocal recognition. It may require 3 independent enclaves for high-stakes outputs. The seed examples include: “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 are useful policy examples, but should be expressed as governance policy options, not universal rules. Co-location policies should be enforced at provisioning time, execution queue time, runtime initialization, and CAC validation time. If a CAC shows execution occurred under prohibited co-location, it should be flagged disputed or invalid for the affected use. Co-location is not an infrastructure afterthought. It is a sovereignty rule. ### Governance Policy Controls on Multitenancy Governance bodies should define multitenancy policies according to domain, jurisdiction, data class, risk class, tenant identity, and execution purpose. A national node may require all domestic public health clauses to run in-country. A regional consortium may require cross-border flood simulations to execute across three independent national nodes. A community steward body may require protected knowledge clauses to run only on community-approved compute. A Project SPV may require evidence checks to run inside its controlled evidence room. A public-safe function may prohibit co-location between public-facing output generation and restricted intelligence workflows. A simulation review body may require high-risk embedded simulations to run on audited nodes with dedicated accelerators. These policies should be machine-readable, registry-indexed, signed, versioned, and auditable. They should be linked to clauses, tenants, nodes, and execution profiles. They should be testable in CI/CD pipelines and enforced by schedulers. Policy enforcement occurs at multiple points: TEE provisioning determines what a node may host. Execution queue filtering determines what may be scheduled. Runtime initialization enforces memory, I/O, key, and network policy. CAC validation verifies that the execution matched policy. Audit review monitors repeated violations or drift. Safe-mode logic responds to violations. This layered enforcement prevents a single scheduler bug from undermining sovereignty. ### Tenant Identity, Credentials, and Trust Domains Tenant identity must be formalized. A tenant should not be a free-text organization name. It should be represented by a DID or equivalent identifier, governance credential, registry entry, legal or institutional profile where relevant, jurisdictional scope, and trust domain. A tenant trust domain defines what the tenant controls and what others may rely on. A national node trust domain may include national SDZs, domestic registries, national credential schemas, and public authority mappings. A regional consortium trust domain may include regional simulations and shared registries, but not domestic raw data. A community trust domain may include protected knowledge governance. An enterprise trust domain may include Project SPV evidence, asset telemetry, and implementation records. Tenant credentials should define execution rights, data rights, scheduling rights, CAC visibility, audit obligations, and recovery responsibilities. If a tenant credential is suspended, the scheduler should block submissions or restrict workloads. Trust domains are how NSF prevents shared compute from erasing institutional boundaries. ### Denial, Retry, and Resource Dispute Handling In a shared system, workloads may be denied, delayed, throttled, or rerouted. These events must be visible and governed. A denial may occur because no eligible node exists, co-location policy blocks execution, tenant quota is exceeded, runtime profile unavailable, attestation invalid, jurisdictional constraint fails, data classification incompatible, clause suspended, public-safe review missing, or safe-mode freeze active. Retry may be allowed after transient failure, but bounded. The retry policy should define maximum attempts, delay, alternative node eligibility, input freshness, new attestation requirement, and audit logging. Resource disputes may arise if a tenant claims unfair denial, priority misclassification, quota misallocation, or inappropriate co-location restriction. The Audit Layer should provide scheduler decision records. Governance review can determine whether policy was applied correctly. Resource governance is important because compute access can affect institutional power. NSF should avoid letting infrastructure scarcity become hidden governance. ### Secure Multitenancy for AI and Simulation Workloads AI and simulation workloads create special multitenancy concerns. They may use GPUs, large memory, shared model caches, vector databases, retrieval systems, and large datasets. They may also involve probabilistic outputs, model weights, prompts, embeddings, and sensitive evidence. An AI agent workload should not share prompt context, memory, retrieval cache, tool credentials, or output buffers with another tenant. A simulation workload should not leak model parameters, scenario inputs, or protected data through shared caches. Vector databases should be tenant-scoped. Embedding spaces can leak information and should not be casually shared across sensitive tenants. Model serving infrastructure must enforce tenant isolation. If shared foundation models are used, NSF must distinguish model access from data isolation. A tenant may use the same model provider as another tenant, but retrieval data, prompts, tool outputs, memory, and CAC records must remain separated. High-sensitivity tenants may require dedicated model instances or local model execution. Simulation workloads may require dedicated accelerators or batch windows to avoid resource contention affecting determinism. Secure multitenancy for AI requires more than enclave isolation. It requires memory governance, tool governance, retrieval governance, and model-status governance. ### Secure Multitenancy Across GNC, RNC, and NNC Architecture Secure multitenancy operates differently across the Nexus multiscale architecture. At the global level, the Global Nexus Consortium may define reference execution profiles, multitenancy conformance tests, CAC tenant metadata schemas, scheduling vocabularies, co-location policy templates, and public-good interoperability standards. It should not centrally control all multitenant execution. At the regional level, Regional Nexus Consortiums may operate shared TEE clusters for regional simulations, corridor risk, shared hazards, cross-border evidence, and mutual recognition. Regional clusters must enforce national and community data boundaries. At the national level, National Nexus Consortiums may operate sovereign TEE clusters inside national SDZs. They may serve multiple domestic agencies, research institutions, operators, communities, and Project SPVs under national governance. National clusters preserve domestic jurisdiction. At the community level, community-controlled nodes may host protected knowledge workloads, local public-safe reviews, and community evidence under strict co-location rules. At the enterprise layer, National Consortium Companies, Project SPVs, operators, providers, insurers, investors, and contractors may use enterprise TEE clusters for lawful delivery and controlled evidence review. Enterprise multitenancy remains implementation-scoped and does not imply public-good endorsement, public authority status, finance approval, or insurance underwriting. This architecture allows shared infrastructure without centralizing execution authority. ### Secure Multitenancy Boundary Statement Secure multitenancy supports shared compute infrastructure, enclave-scoped execution, tenant isolation, jurisdiction-aware scheduling, governance policy enforcement, resource allocation, CAC tenant metadata, fault containment, side-channel risk management, public-safe auditability, AI workload isolation, Project SPV evidence processing, finance-readiness evidence, and insurance-readiness evidence. It does not by itself create legal compliance, public authority, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, or proof that co-tenant risk is impossible. Multitenancy controls provide technical and governance evidence that workloads were isolated under declared profiles. The institutional meaning of outputs still depends on clause authority, data provenance, credentials, jurisdiction, governance review, public-safe rules, and applicable law. A shared TEE node is not a shared authority. Tenant isolation is not legal certification. A co-location policy is not regulatory approval. Resource accounting is not governance voting power. A multitenant CAC is not finance approval. An insurance-readiness execution is not underwriting. A public-safe multitenant output is not an official public warning unless competent authority provides that status. This boundary must appear in runtime profiles, CAC records, scheduler policies, audit dashboards, and public documentation. ### Secure Multitenancy as Institutional Compute Infrastructure NSF secure multitenancy makes shared infrastructure usable without surrendering sovereignty. It allows many actors to benefit from high-assurance compute, confidential runtimes, simulation capacity, AI governance infrastructure, and CAC generation without forcing every jurisdiction, community, institution, or Project SPV to build entirely separate stacks for every workload. But it does so under conditions. Every tenant is identified. Every workload is scoped. Every clause is registry-resolved. Every node is credentialed. Every runtime is measured. Every input is sealed or committed. Every output is signed. Every co-location rule is enforced. Every scheduler decision is auditable. Every failure is contained. Every CAC carries tenant metadata. Every dispute has a trace. Every resource policy is governed. This transforms multitenancy from a vulnerability into a verifiable optimization. It allows sovereigns, regional bodies, research networks, NGOs, public-good registries, communities, and enterprise implementation actors to share infrastructure while preserving separation, auditability, and control. Secure multitenancy is therefore not just a cloud architecture. It is institutional compute architecture for a world where governance must be distributed, risk-aware, data-sensitive, AI-mediated, and proof-bound. That is the role of secure multitenancy in the Nexus Sovereignty Framework: to make shared execution possible at scale without making trust shared by assumption, sovereignty diluted by convenience, or public-good governance dependent on opaque infrastructure. --- # 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/secure-multitenancy.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.