> 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/remote-attestation-and-state-commitments.md).

# Remote Attestation and State Commitments

## Remote Attestation in the Nexus Sovereignty Framework: Verifiable Runtime Identity, State Commitments, Attestation Registries, Multi-Node Validation, Revocation, and Zero-Trust Execution Provenance

### The Purpose of Remote Attestation in NSF

Remote Attestation is the cryptographic handshake between governance intent and compute execution. It allows a remote verifier to determine whether a clause execution environment is what it claims to be before trusting the output it produces. In a decentralized, multijurisdictional, sovereign, and multi-tenant governance architecture, this capability is indispensable. Smart Clauses may execute on infrastructure not physically controlled by the relying party. A national node may verify execution on a regional node. A credential issuer may rely on a CAC generated inside an enterprise evidence room. A public-safe dashboard may rely on an output produced by a TEE cluster. A Project SPV reviewer may rely on confidential compute operated by a third party. An AI agent may need proof that a runtime policy gate is genuine before accepting a tool-use decision.

Without Remote Attestation, every actor would have to trust the operator of the machine, the cloud provider, the container image, the runtime logs, the deployment process, the administrator, the network, and the output API. That is not enough for NSF. A system designed around zero-trust governance must not assume that a node is trustworthy because it says so. It must require the node to prove its runtime identity, code measurement, configuration, credential status, jurisdictional scope, execution policy, and output binding.

Remote Attestation provides this proof. It enables a node, enclave, confidential VM, secure runtime, ZK prover service, or hybrid execution environment to generate a signed statement about the software and configuration it is running, the hardware or proof root supporting it, the runtime measurement, the clause or workload identity, the node identity, the governance scope, the input commitment, and the jurisdictional context. A verifier can then decide whether to accept, reject, restrict, or dispute the resulting execution.

Remote Attestation is therefore a prerequisite for trust in distributed NSF execution. It allows infrastructure to be geographically distributed, institutionally diverse, and operationally shared without forcing blind trust in any one operator.

The core doctrine is:

**No high-consequence NSF execution should be accepted unless the execution environment proves its identity, measurement, scope, and state commitments through verifiable attestation before its output is relied upon.**

### Remote Attestation Is Proof of Runtime State, Not Proof of Governance Authority

Remote Attestation must be interpreted with precision. It proves that a runtime environment matches a measured configuration under a defined attestation system. It does not prove that the clause is legally binding, that the input data is true, that the model is correct, that the output is safe, that a public authority endorsed it, that finance is approved, that insurance is underwritten, or that a regulatory determination occurred.

An attestation statement can say: this enclave or confidential workload loaded this runtime hash, this clause hash, this input commitment, and this execution policy under this node credential and jurisdictional scope. It cannot say: this execution has legal effect everywhere. That meaning comes from clause governance, credential schemas, jurisdiction, institutional adoption, public-safe review, and applicable law.

This boundary matters because attestation can easily be overclaimed. A “secure enclave” can become a marketing label. A “verified runtime” can be confused with verified truth. A hardware quote can be mistaken for institutional legitimacy. NSF must prevent that. Remote Attestation is a trust-minimization mechanism, not a sovereignty substitute.

A mature NSF attestation statement should always be proof-scoped.

### What Is Remote Attestation?

Remote Attestation is a protocol through which a computing environment produces cryptographic evidence about its current state and identity for verification by another party. In NSF, the attesting environment may be a TEE, confidential VM, secure enclave, Enarx-like runtime, WASM confidential runtime, sovereign node, secure edge device, controlled-room runtime, ZK prover backend, or hybrid proof system.

The attestation statement typically includes a measurement of the code or runtime, configuration values, hardware or platform evidence, signer identity, key material, timestamp, and workload-specific metadata. In NSF, it should also include clause identity, governance scope, jurisdiction, execution policy, input commitments, runtime hash, node credential, and proof profile.

Remote Attestation allows a verifier to ask: is this the runtime we approved? Is this the clause hash we expected? Is the node credential active? Is the jurisdiction correct? Is the platform supported? Is the attestation fresh? Is the runtime configured correctly? Is the input commitment bound to the execution? Is the output signed by the attested environment? Is the node eligible for this workload?

The answer determines whether a CAC can be accepted, rejected, limited, disputed, or routed to review.

### The NSF Remote Attestation Lifecycle

The NSF Remote Attestation lifecycle begins before execution. A node is registered in the Registry Layer with identity, operator credential, jurisdiction, hardware profile, runtime profile, allowed workloads, data classes, attestation method, key material, and revocation policy. The node receives a credential such as `TEEExecutorVC`, `ConfidentialComputeNodeVC`, `SovereignComputeNodeVC`, or `ControlledRuntimeExecutorVC`, depending on role and scope.

When a workload is scheduled, the node starts an enclave, confidential VM, secure runtime, or proof environment. The runtime loads the approved clause package or execution workload. It generates a measurement report, such as an SGX quote, SEV-SNP attestation report, TrustZone evidence, confidential VM attestation token, Enarx attestation artifact, secure element statement, ZK prover metadata, or equivalent proof object.

The enclave or secure runtime binds the attestation to execution metadata. It signs or commits to Clause ID, Clause Hash, governance scope, tenant, jurisdiction, input hash, runtime hash, execution policy, node identity, execution ID, and timestamp. This prevents a valid platform quote from being reused for an unrelated clause.

The attestation statement is sent to the NSF Attestation Registry, verifier service, national node, regional verifier, controlled-room verifier, credential issuer, or other authorized relying party. The verifier validates the hardware or proof root, runtime measurement, node credential, revocation status, workload eligibility, jurisdictional scope, timestamp freshness, and execution policy.

If the attestation verifies, execution may proceed or the CAC may be accepted. If verification fails, safe-mode logic applies. The CAC may be rejected, marked disputed, blocked from credential effects, or routed for review.

The verified attestation is logged in the Audit Layer and linked to the CAC, node, clause, tenant, credential actions, rollups, and any downstream governance decisions.

This lifecycle ensures that attestation is not a one-time platform check. It is part of every material execution pathway.

### Required Fields in NSF Attestation Statements

NSF-compliant attestation statements should include standardized fields so they can be verified across runtimes, nodes, jurisdictions, and proof systems. A simplified statement may look like:

```json
{
  "attestation_schema": "NSFAttestationStatement@1.0",
  "runtime_type": "TEE",
  "enclave_type": "SGX-compatible",
  "measurement_hash": "0xabc123",
  "runtime_hash": "0xdef456",
  "workload_hash": "0x...",
  "clause_id": "WaterRef::Safety::WaterSafetyEvidenceClause@2.1.0",
  "clause_hash": "0x...",
  "signer_did": "did:nsf:tee-node:27",
  "signer_credential": "TEEExecutorVC@1.0",
  "jurisdiction": "ZAF",
  "governance_scope": "AgriWaterEvidenceReview",
  "execution_policy": "deterministic-tee",
  "input_commitment": "0x...",
  "execution_id": "exec-0x...",
  "timestamp": "2025-04-30T18:32:00Z",
  "signature": "0xDEADBEEF"
}
```

The seed uses `dao_scope`. The mature NSF field should be `governance_scope`, with optional `workflow_type` or `governance_tooling` if DAO tooling is used. This avoids implying that all NSF governance is DAO-based.

Required fields should include attestation schema, runtime type, platform or enclave type, measurement hash, runtime hash, workload hash, clause ID, clause hash, signer identity, signer credential, jurisdiction, tenant or governance scope, execution policy, input commitment, execution ID, timestamp, nonce or replay-protection field, proof profile, and signature.

Optional fields may include SDZ identifier, node location class, hardware security version, microcode or firmware version, runtime configuration, public key, verifier set, output commitment, simulation bundle, credential schema, public-safe class, co-location policy, and rollup reference.

These fields are included or referenced in CAC metadata, TEE registration proofs, rollup signing, credential evidence fields, and audit records.

Standardized fields are what make attestation interoperable.

### Verification of Attestation Statements

Verification is the process of determining whether an attestation statement should be trusted for a defined execution purpose. NSF verifiers should not accept an attestation merely because it is syntactically valid. They must verify the complete governance and runtime context.

The verifier should check that the runtime hash matches a registry-recognized runtime profile. It should confirm that the measurement hash is approved for the clause, domain, risk class, and data class. It should verify that the signer DID maps to an active node credential. It should check node revocation, platform revocation, runtime deprecation, hardware vulnerability status, and execution policy. It should confirm that the governance scope matches clause permissions. It should confirm that the jurisdiction and SDZ scope are eligible. It should ensure the timestamp is fresh and within the execution window. It should verify the input commitment, nonce, and execution ID. It should verify that the proof profile is sufficient for the workload.

If any component fails, the CAC output should be rejected, marked disputed, or routed to safe-mode review. If a component is valid but incomplete, the CAC may be accepted only under limited scope. For example, a public reference execution may accept a weaker runtime profile, but a public health or critical infrastructure clause may require stronger attestation.

Verification should produce a verification record. The record should include verifier identity, verifier credential, verification time, verification result, checked fields, warnings, limitations, and audit reference.

Attestation verification is therefore both technical validation and governance scope checking.

### Attestation Registries

The Attestation Registry is the system that stores and resolves node identities, runtime measurements, platform profiles, approved workload hashes, verifier sets, revocation status, attestation policies, and proof profiles. It is part of the Registry Layer, but may be operated in global, regional, national, community, or enterprise-scoped forms.

A global reference attestation registry may maintain public runtime profiles, schema definitions, conformance tests, and proof formats. A national attestation registry may maintain approved domestic nodes and SDZ execution rules. A regional attestation registry may maintain verifier sets for cross-border simulations. A community registry may approve community-controlled runtimes. An enterprise evidence room may maintain approved confidential compute nodes for Project SPV workflows.

Attestation registries should support resolution by node DID, runtime hash, measurement hash, proof profile, jurisdiction, clause family, data class, risk class, and status. They should support revocation, suspension, deprecation, vulnerability annotations, and replacement.

Attestation registries should also support historical resolution. A verifier may need to know whether a runtime was approved at the time of execution, even if it is now deprecated. Historical validity and current validity should be distinguished.

This is essential for long-term audit and institutional memory.

### Anchoring Attestation and CAC State Commitments

An attestation becomes stronger when bound to a state commitment. In NSF, an enclave’s execution state can be represented as a commitment over runtime state, inputs, clause hash, governance scope, jurisdiction, tenant, and execution policy.

A conceptual state commitment may be:

```
state_commitment = hash(runtime_state || input_commitments || clause_hash || governance_scope || jurisdiction || execution_id)
```

This commitment is signed by the attested runtime and included in the CAC. It prevents a valid attestation from being detached from the actual execution context. It links environment, clause, input, and scope into one proof object.

State commitments may be aggregated into CAC Rollups. Rollup roots may be anchored in the Audit Layer, sovereign archives, regional registries, enterprise evidence rooms, or optional public ledgers. Public anchoring should generally include only commitments, not sensitive payloads.

The seed says commitments may be published to treaty or UN governance channels. This must be framed carefully. NSF can publish to authorized treaty-specific logs, multilateral evidence channels, or UN-related channels only where competent bodies have adopted or accepted that process. Otherwise, the safe language is **treaty-aligned evidence logs** or **public-good audit channels**, not official treaty or UN channels.

Anchoring proves that a state commitment existed at a time and was included in a record. It does not prove legal adoption or official institutional recognition.

### Aggregated Attestations and Multisignature Validation

Some executions require more than one attestation. Mission-critical, cross-border, high-risk, or contested workloads may require multiple independent nodes to execute or verify the same clause. The system can compare outputs and require threshold agreement before accepting a CAC or rollup.

A multi-node attestation workflow may run the same clause across three or five enclave nodes, ideally with hardware diversity, operator diversity, jurisdictional diversity, and independent verifier credentials. The outputs are compared. If the threshold is met, a multisignature or aggregate signature is added to the CAC or rollup.

This can improve execution fidelity, reduce single-node dependence, support censorship resistance, detect compromised runtimes, and build cross-jurisdictional trust. It is especially valuable for shared hazards, regional simulations, public-safe outputs, disputed credentials, high-risk AI agent controls, and sensitive Project SPV evidence.

Aggregate signatures should identify which nodes signed, what each attested, what threshold applied, whether all outputs matched exactly, whether any dissent occurred, and what proof profile governed the set. If outputs differ, the system should enter safe mode or route to review.

Multisignature validation is not majority rule over truth. It is a redundancy and verification mechanism. Governance meaning still depends on authority scope.

### Jurisdictionally Constrained Attestation

Not all attestation is globally portable. Some workloads must execute and be attested inside specific jurisdictions, SDZs, community-controlled nodes, or enterprise evidence rooms. A valid TEE quote from an unauthorized jurisdiction may be technically valid but governance-invalid.

NSF attestation policies should therefore include jurisdictional constraints. These may specify in-country execution, SDZ-only execution, community-approved node execution, regional corridor node execution, controlled-room execution, or no public cloud execution. The attestation statement should include jurisdictional metadata and, where appropriate, location-class evidence. Location proof can be difficult and should be treated carefully. It may rely on registry-approved node location, hosting records, network controls, physical audits, or sovereign infrastructure records, not merely IP geolocation.

A CAC generated outside allowed jurisdiction should be rejected or marked invalid for that purpose. It may remain a technical execution record, but not an accepted governance execution.

Jurisdictional attestation preserves sovereignty at runtime.

### Attestation for Edge and Offline Environments

Remote Attestation must also support edge and offline contexts. Disaster zones, remote sensors, field devices, ships, aircraft, rural clinics, industrial gateways, and mobile teams may not have continuous connectivity. They may need to execute clauses locally and synchronize later.

Edge attestation may use secure elements, device-bound keys, signed firmware measurements, cached registry snapshots, local TEE evidence, and delayed audit submission. The attestation should include snapshot validity, cache age, offline policy, execution time, device credential, and synchronization status.

Offline attestations should have limited authority. They may support local advisory execution, preliminary evidence, or emergency fallback, but high-consequence credential actions, public-safe outputs, or enterprise triggers may require later verification. If the cached registry state was stale or node status revoked during the offline window, the CAC may require review.

Edge attestation enables resilience, but must preserve safe-mode and reconciliation logic.

### Attestation Slashing, Revocation, and Accountability

A node that produces invalid attestations, violates jurisdictional execution rules, runs compromised runtime environments, forges CACs, reuses stale quotes, signs unauthorized workloads, leaks tenant data, or repeatedly fails proof verification must be subject to accountability.

The seed uses “slashing.” This term can imply token economics or financial punishment. In mature NSF language, this should become **revocation, suspension, exclusion, reputation downgrade, validator-set removal, credential restriction, incident reporting, or contractual remedy**, depending on the governance and legal context. If a tokenized or staked environment exists, slashing may be one implementation, but it should not be the constitutional default.

A node may be revoked through a `TEERevocationVC`, `NodeSuspensionRecord`, `AttestationRevocationNotice`, or registry status update. The revocation should include reason, evidence, affected measurements, time window, signer, review path, and appeal or correction mechanism where appropriate.

A revoked node should be blocklisted or suspended in the Registry Layer. Schedulers should stop assigning workloads to it. CACs generated after revocation should be rejected. CACs generated before revocation may require review depending on compromise window.

Public reporting should be public-safe. Some node failures can be published. Security-sensitive details may need restricted disclosure. Project SPV or critical infrastructure details may require controlled reporting.

Attestation accountability is essential because trust-minimized infrastructure still requires consequences for misbehavior.

### Attestation and Audit Layer Integration

All material attestation statements and verification records should be logged in the Audit Layer. The audit record should link attestation to CAC, clause, node, runtime, tenant, jurisdiction, credential actions, rollups, disputes, and governance decisions.

Attestation records should be queryable by Clause ID, Node ID, runtime hash, measurement hash, time window, jurisdiction, risk classification, tenant, proof profile, verifier set, CAC ID, rollup ID, and status.

A query might ask:

`Find all attestations from nodes in jurisdiction = IDN for clauses matching WaterRef::Safety::WaterSafetyEvidenceClause@*`

Another might ask:

`Show all CACs produced by node did:nsf:tee-node:27 between 2025-04-01 and 2025-04-30.`

Another might ask:

`List all credentials issued based on CACs signed by a node later suspended for runtime mismatch.`

These queries are essential for dispute review, incident response, vulnerability management, credential correction, rollup validation, and public-safe reporting.

Audit integration turns attestation from a transient handshake into institutional memory.

### Attestation and CAC Rollups

CAC Rollups can aggregate attestations. A rollup may include attestation roots, node sets, verifier sets, runtime profiles, and aggregate signatures. This allows many CACs to share a rollup-level attestation summary while preserving individual inclusion proofs.

Rollup-level attestation is useful for high-volume execution. It reduces verification cost while maintaining proof traceability. However, rollup-level attestation should not hide individual node problems. If one node in a rollup is later compromised, the rollup should allow affected CACs to be identified.

A rollup may require all included CACs to have verified attestations. Or it may include mixed status CACs with a failure root. The rollup schema must state its policy.

Attestation rollups make execution provenance scalable.

### Attestation and Credential Evidence

CAC-linked credentials should include attestation references where runtime proof matters. A credential evidence field may include CAC hash, runtime hash, attestation statement hash, verifier status, node credential, and jurisdiction. This allows a verifier to determine whether the credential was supported by an attested execution.

If a node is later revoked, credentials linked to its attestations may be flagged for review. If a runtime is deprecated, credential issuers may require revalidation. If a proof profile is insufficient for a jurisdiction, recognition may be limited.

Attestation is therefore part of credential provenance. It gives credentials an execution trust chain.

### Attestation for AI Agents and Copilots

AI agents and copilots should verify attestation before relying on CACs for high-consequence actions. An agent should not accept a CAC merely because it appears in a message. It should verify CAC hash, attestation statement, node credential, runtime status, jurisdiction, and output boundary.

Agents that run policy gates inside TEEs should also produce attestations. If an AI agent is granted tool access, the system should be able to prove that the access decision was produced by an approved runtime and clause. If an agent is denied access, the denial should also be auditable where material.

Attestation helps prevent spoofed governance outputs from being consumed by agents. It is a core component of agentic trust safety.

### Attestation Boundary Statement

Remote Attestation supports runtime identity, measured execution, enclave verification, node credential validation, input commitment binding, CAC trust, rollup integrity, credential evidence, audit traceability, jurisdictional scope checking, AI agent verification, Project SPV evidence processing, finance-readiness evidence, and insurance-readiness evidence.

It does not by itself create legal authority, public authority status, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, legal liability, data truth, model correctness, or policy wisdom. Remote Attestation proves that a runtime or proof environment matched a declared measurement and scope under a defined attestation profile. The institutional meaning of the output depends on clause authority, source data, credential scope, simulation validity, governance review, jurisdiction, public-safe rules, and applicable law.

An attestation quote is not legal certification.

A measured runtime is not a verified policy.

A node credential is not public authority.

A state commitment is not proof of data truth.

A public chain anchor is not endorsement.

A treaty-aligned attestation is not treaty enforcement.

A finance-readiness attestation is not finance approval.

An insurance-readiness attestation is not underwriting.

This boundary must appear in attestation schemas, CAC records, verifier tools, registry pages, audit dashboards, credential evidence fields, and public documentation.

### Remote Attestation as the Gateway to Trust

In NSF, no high-consequence execution should be trusted unless it is attested, verified, and bound to governance scope. Remote Attestation is the gateway through which compute enters the trust fabric. It proves that the runtime is identifiable, the workload is measured, the node is credentialed, the input is committed, the jurisdiction is declared, the proof is verifiable, and the output can be tied to a specific execution state.

It enables zero-trust governance because the system does not trust infrastructure by default.

It enables execution provenance because every material output carries runtime evidence.

It enables jurisdictional control because workloads can be accepted or rejected based on execution scope.

It enables public observability where public-safe commitments can be published.

It enables interoperability across TEEs, ZK systems, validators, sovereign nodes, enterprise evidence rooms, and AI agents.

It enables correction because compromised nodes, invalid measurements, and disputed proofs can be traced.

Remote Attestation is not the whole trust architecture. It is the entry point. The Registry defines what is approved. The Credential Layer defines who is authorized. The Data Layer defines what inputs are valid. The Simulation Layer defines model status. The Audit Layer preserves memory. The Governance Layer defines scope. Safe-Mode Logic handles failure. CACs carry the receipt.

No clause runs with trust by assertion.

It must prove its runtime first.

That is the role of Remote Attestation in the Nexus Sovereignty Framework: to make distributed execution verifiable before outputs are relied upon, and to ensure that governance-critical compute begins with proof rather than assumption.


---

# 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/remote-attestation-and-state-commitments.md?ask=<question>&goal=<endgoal>
```

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