Protocol Specification · v0.1.0-draft

The Ethical Hardware Enclave

Software protocols are not enough. The kernel must be sovereign too.

The Hardware Enclave Isolation Protocol (HEIP) v0.1.0 defines the physical compute boundary for the tfb: runtime — the Algorithmic Infrastructure Agency. True cognitive sovereignty requires physical custody of the underlying silicon. The Enclave is a localized, hardened development node running on dual NVIDIA RTX 3060 hardware inside the Engine Room, enforcing absolute data containment through three mutually reinforcing security pillars. No cloud dependency. No data harvesting. No remote kill switch. Every constraint is enforced at the kernel level — not in a terms of service agreement that can change overnight.

Three Pillars

What makes hardware ethical?

An "ethical" hardware deployment is not about the brand of the silicon. It is about who controls the kernel, where packets can route, and whether residual state survives a session boundary. These three pillars are enforced by concrete system configurations — not promises.

Pillar I

Hardened Kernel Isolation · The Compute Pillar

The multi-agent tfb: runtime executes inside a strict Docker sandbox with explicit kernel-level restrictions. Compute workloads are hard-pinned to dual NVIDIA RTX 3060 GPUs via NVIDIA_VISIBLE_DEVICES=0,1, preventing cross-GPU data contamination. Every container drops all Linux capabilities (cap_drop: ALL) and enforces no-new-privileges: true — even a compromised process inside the sandbox cannot escalate to root. System resource consumption is hard-bounded using cgroups, mitigating side-channel memory leaks and noisy-neighbor vulnerabilities during intensive local model inference cycles. No telemetry. No phone-home. No training on user data.

Enforced by: docker-compose.sandbox.yml § services.tfb-orchestration

Pillar II

Zero-Egress Network Topology · The Network Pillar

To prevent corporate data harvesting and eliminate cloud failover risks, network isolation is enforced directly at the host kernel layer. The Docker bridge network is declared internal: true — no container on the enclave bridge can reach the public internet. The host nftables ruleset enforces a second, independent barrier: any outbound packet from the enclave subnet (172.30.0.0/24) addressed to a non-RFC1918 IP is silently dropped at the kernel level. Cloud metadata endpoints (169.254.169.254) are explicitly blocked. The only traffic permitted through the host boundary is on port 8443 — the designated libp2p transport port for the Lattice mesh. Inference requests cannot fail over to a remote API. If local resources are saturated, the system returns a graceful local timeout, not a data leak.

Enforced by: nftables.conf § chain output, chain forward; docker-compose.sandbox.yml § networks.enclave_isolated

Pillar III

Tiered Cryptographic Storage · The Memory Pillar

The host maps data persistence across two distinctly isolated cryptographic lifecycles depending on volatility.

Volatile Memory Tier (RAM Sandbox): A 16 GB RAM-backed tmpfs filesystem handles all active conversation context windows, transient multi-agent message strings, and raw intermediate execution logs. Mounted with strict kernel flags (noexec, nosuid, nodev) and restricted to mode=0700 — only the enclave user can access it. Every byte residing in this tier is completely purged from physical memory upon session termination via setup-enclave-storage.sh. No residual state survives a container restart. No context window leaks between sessions.

Persistent Storage Tier (At-Rest Encryption): Deep storage elements — base model weights, localized vector database embeddings, and historical telemetry — reside exclusively on an encrypted physical storage partition. Protected via Linux Unified Key Setup (LUKS/dm-crypt) with kernel-level block device encryption. Data at rest remains cryptographically unreadable without local token unlocking. The enclave validates the LUKS device is active before allowing any container to start.

Enforced by: setup-enclave-storage.sh § Steps 1–3; docker-compose.sandbox.yml § volumes (tmpfs mounts)

Hardware Tiers

From Raspberry Pi to multi-GPU workstation

The Enclave scales across three tiers. Every tier meets the three-pillar standard — kernel isolation, zero-egress networking, and cryptographic storage — scaled to the hardware's capacity. The current Engine Room deployment is a Tier 3 Synthesis Node running dual RTX 3060 GPUs on Ubuntu with full HEIP enforcement.

Tier 1

Edge Node

Raspberry Pi 5 · 8 GB RAM

Verifies trilateral receipts, relays mesh traffic, and participates in lightweight consensus. Holds a TPM-anchored Ed25519 identity. Cannot run large models, but can cryptographically verify that others did. Runs a minimal HEIP profile: cap_drop: ALL, internal bridge networking, and tmpfs-backed volatile storage. The smallest sovereign unit in the Lattice.

Tier 2

Standard Node

Homelab server · 32+ GB RAM · Consumer GPU

Runs mid-size open-weight models locally (7B–13B parameters). Handles routine synthesis work, Georgist ledger computation, and community data processing. Full HEIP enforcement: NVIDIA device pinning, nftables zero-egress rules, LUKS-encrypted model storage. The backbone of the mesh.

Tier 3

Synthesis Node · Engine Room

Multi-GPU · 64+ GB RAM · Dual RTX 3060 · Ubuntu

Runs large models (70B+) entirely on local hardware. Handles complex adversarial simulation rounds, multi-agent orchestration, and high-stakes governance proposals requiring deep reasoning. The current reference implementation. Full HEIP profile with all three pillars enforced at the kernel level. This is the physical instantiation of the tfb: branch in the TCP v0.1.0 pipeline.

Defense in Depth

From silicon to mesh: the full security stack

The Enclave's security model is not a single gate. It is a layered defense where each layer independently enforces the same constraint — no data leaves sovereign custody. A failure at one layer is contained by the next.

Layer 1: GPU Pinning

Workloads are bound to specific physical GPUs via NVIDIA_VISIBLE_DEVICES. No other GPU is visible to the container. Cross-device data contamination is impossible at the driver level.

Config: docker-compose.sandbox.yml § environment

Layer 2: Capability Drop

All Linux capabilities are stripped from the container (cap_drop: ALL). The runtime cannot load kernel modules, access raw sockets, or escalate privileges — even if the process is compromised.

Config: docker-compose.sandbox.yml § security_opt

Layer 3: cgroups Bounding

CPU, memory, and I/O resources are hard-bounded at the kernel level via cgroups. A runaway inference process cannot starve the host or leak data through memory pressure side channels.

Config: docker-compose.sandbox.yml § deploy.resources

Layer 4: Internal Bridge

The Docker network is declared internal: true. No container on the enclave bridge can initiate a connection to the public internet. The bridge itself has no gateway to the WAN.

Config: docker-compose.sandbox.yml § networks

Layer 5: nftables Kernel Firewall

The host nftables ruleset provides a second, independent barrier. Outbound packets from the enclave subnet to non-RFC1918 addresses are dropped at the kernel level. Cloud metadata endpoints are explicitly blocked. This layer catches any escape from the Docker bridge.

Config: nftables.conf § chain output

Layer 6: tmpfs Volatility

All runtime state — context windows, message queues, intermediate logs — resides in RAM-backed tmpfs with noexec, nosuid, nodev. Destroyed on session teardown. No residual state survives a restart.

Config: setup-enclave-storage.sh § Step 2

Layer 7: LUKS At-Rest Encryption

Model weights, vector embeddings, and persistent data reside on a LUKS/dm-crypt encrypted partition. Without the local cryptographic token, the data is unreadable at the block device level.

Config: setup-enclave-storage.sh § Step 1

Layer 8: Mesh Verification

Even if all seven local layers are compromised, the Lattice mesh provides the final backstop. Trilateral receipts require three independent signatures (lvn: + tfb: + lat:). The mesh detects anomalous behavior and refuses to commit state transitions without full cryptographic coordination.

Protocol: TCP v0.1.0 § Verification Procedure

The Intersection

Governance meets hardware

The Tripartite Consensus Protocol (lvn:tfb:lat:) provides the cryptographic governance framework. The Ethical Hardware Enclave provides the physical, sovereign soil upon which that framework runs — specifically the tfb: simulation layer where the internal adversarial loop executes and Impact Certificates are signed. One without the other is incomplete. Governance without sovereign hardware is a terms-of-service agreement. Hardware without governance is just a computer. Together, they ensure the Emergence Collective remains self-sovereign, secure, and structurally aligned with its foundational principles — from the kernel up.

The Emergence Institute: Collective Charter Community Gallery Engine Room Applied Verification Updates