> For the complete documentation index, see [llms.txt](https://docs.nerve-protocol.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerve-protocol.com/architecture/secure-computing-infrastructure-in-nerve-protocol.md). # Secure Computing Infrastructure in Nerve Protocol The **Secure Computing Infrastructure** is the execution backbone of Nerve Protocol. It transforms commodity hardware into a coordinated fleet of attested enclaves where AI missions run without producing accessible plaintext at any stage. Every request passes through cryptographically verifiable checkpoints from the client layer through to the Coordination Ledger. *** ## Core Layers **1. Operator Edge Capsules (Client Layer)** The client layer hosts the Nerve Console inside a local TEE or secure container provisioned on the operator's device. * Provides biometric or hardware-key attestation before any command is accepted. Commands that cannot be associated with a verified operator identity are rejected before they reach the network. * Renders interface elements inside enclave memory. UI state and decrypted output are never written to the host filesystem. Screen capture tools outside the TEE capture only static noise. * Holds the operator's private keys. Key material is generated inside the enclave on first use and never crosses the TEE boundary. **2. Policy and Identity Mesh (Governance Layer)** The governance layer anchors operator identity and policy definitions to the Coordination Ledger. * Issues zero-knowledge identity badges that prove authorization level without exposing role assignments or organizational structure. * Anchors agent manifests, policy capsule versions, and enclave attestation certificates to the ledger. Any modification to a running policy capsule produces a new ledger entry and is auditable. * Manages stake-and-slash mechanics for TEE Node operators. Stake is bonded before a node enters the active pool and is subject to slashing for verified policy violations. **3. Mission Scheduler** The Mission Scheduler converts compiled intent graphs into distributed execution plans and assigns work to TEE Nodes. * Evaluates candidate nodes by attestation freshness, current reputation score, latency profile, and available enclave capacity before assigning tasks. * Injects Enclave Integrity Monitor checkpoints at each stage boundary. Checkpoints can pause or terminate executors mid-mission if attestation failures or behavioral anomalies are detected. * Emits a deterministic assignment record to the Coordination Ledger before execution begins. The record is the canonical source of truth for what was scheduled — subsequent execution proofs are compared against it. **4. TEE Executor Layer** The execution layer runs all agent logic, data connector operations, and analytics pipelines inside hardware-isolated enclave memory. * Autonomous agents receive only the context slice their policy capsule permits. They cannot access data from integrations not declared in their capsule. * Streams runtime telemetry into zero-knowledge-friendly log structures so performance can be audited without revealing mission content. * Emits proof bundles at each mission stage: a remote attestation quote confirming enclave integrity, an execution hash committing to the exact computation performed, and a policy compliance receipt from the Enclave Integrity Monitor. **5. Signal Lattice Transport** The transport layer handles encrypted data movement between enclaves and to the operator's client. * Encrypts all intermediate data under operator-held keys before it leaves the source enclave. Even the orchestration infrastructure sees only ciphertext. * Applies noise-resistant batching to outbound traffic, preventing traffic analysis from inferring mission timing, volume, or intent from packet patterns. *** ## Security Properties **Checkpoint-based validation.** Requests propagate through multiple attestation checkpoints at stage boundaries. A failure at any checkpoint halts execution before the problematic step completes. **Payload secret sharing.** Sensitive payloads that span multiple enclaves are split using threshold secret sharing. No single node holds a complete plaintext payload — reconstruction requires a quorum of cooperating nodes, all of which must present valid attestation. **Anomaly quarantine.** Enclave Integrity Monitors run statistical analysis over agent behavior patterns and access timing. Enclaves that exhibit anomalous signatures are quarantined before the mission completes, without requiring the operator to intervene. **Operator identity obfuscation.** Operator metadata — IP addresses, device fingerprints, connection timing — is replaced with pseudonymous operator tokens at the network boundary. External observers cannot correlate network traffic to specific operators or missions. *** For details on individual node verification, supported TEE hardware platforms, and node operator incentives, see [TEE Nodes](/architecture/tee-nodes.md). --- # 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.nerve-protocol.com/architecture/secure-computing-infrastructure-in-nerve-protocol.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.