Threat model & trust boundaries
ClosedMesh is a peer-to-peer inference mesh, not a hosted API behind a privacy guarantee. This page states what that means in practice — including what we do not protect against today.
The honest trade-off: prompts and peers
When you chat through the mesh, a serving peer must read your prompt to run inference. That peer runs the open-source ClosedMesh LLM runtime on hardware the operator controls. Unlike a centralized API where one vendor contractually limits access, each mesh peer is a separate operator with physical access to the machine serving your session.
ClosedMesh does not today provide hardened enclaves, TEE attestation, or encrypted-inference guarantees that would prevent a malicious operator from inspecting traffic on their own box. If you need prompts to never be readable by third parties, run your own peer locally — or keep sensitive work entirely on hardware you control.
What we do enforce
- Model identity. Peers publish a deterministic fingerprint of the model they claim to serve. Entry nodes re-run unpredictable synthetic probes and compare — a peer cannot advertise a 70B model while quietly running an 8B or returning canned text. Verification uses only synthetic probes; real user prompts are never replayed for auditing.
- Open-source runtime. The inference stack is auditable at closedmesh/closedmesh-llm. Operators and users can inspect what runs on a peer before trusting it.
- No third-party AI provider in the default path. Mesh-routed requests stay on contributor hardware. A configured external fallback exists for daily-driver models when the mesh cannot meet latency targets — responses are labeled in routing headers so callers can see which supply path served them.
- Benchmark honesty. Peers gossip both through-mesh and native (local
llama-server) throughput figures. The public catalog at /status shows measured numbers, not marketing claims.
Today: verification runs in observe mode — verdicts are logged and displayed; routing is not yet demoted on mismatch. Enforcement ships only after false-positive rates on real peers are clean.
What we do not claim
- Prompt confidentiality from arbitrary mesh peers
- Hardware attestation or TEE-isolated inference
- SLA-grade uptime or latency on the free early-access mesh
- A crypto token, on-chain ledger, or guaranteed fiat payouts (contributors earn credits during early access — see /contribute)
How this compares
| Dimension | ClosedMesh | Centralized API | Attestation marketplace |
|---|---|---|---|
| Architecture | True P2P mesh; replication-first routing | Single vendor datacenter | Coordinator + attested workers |
| Prompt hiding | Honest peer read; run local for max privacy | Vendor policy + contract | Stronger hiding via TEE / hardened runtime |
| Hardware | Apple Silicon, CUDA, Vulkan, ROCm, CPU | Vendor-chosen GPUs | Often Apple Silicon + attestation |
| Supply model | Open contributors; credits → future payouts | Vendor capacity | Curated providers |
| Verification | Synthetic model-identity probes (open source) | Trust the brand | Hardware + runtime attestation |
ClosedMesh optimizes for open mesh supply on hardware people already own — speculative decoding, solo replication, and broad backend support. Attestation-first marketplaces optimize for stronger prompt hiding on curated hardware. Different trade-offs; we name ours explicitly rather than implying equivalence.
Operator responsibilities
If you run a peer, you are responsible for the machine, network exposure, model files, and power draw on your hardware. The runtime can autostart as a user service; it joins the mesh via an invite token embedded in the desktop app or supplied at install time. Do not run a peer on hardware or networks you do not control.
Reporting issues
Security vulnerabilities in the runtime or website: GitHub Security Advisories on closedmesh-llm. Mesh misbehavior (peers serving wrong models, suspicious routing): note the peer hostname and model on /status and open a discussion on the runtime repo.