§ 05 · Security & Privacy

Adversarial by default.

We assume every node is potentially hostile, every network segment is tapped, and every model bundle is a supply-chain target. The controls below are the ones that survive that assumption.

5.1

Threat model

Assumption 1Any peer node may try to exfiltrate, corrupt, or poison tasks it processes.
Assumption 2Any network path may be observed or actively tampered.
Assumption 3Model bundles may be targets for supply-chain attack.
Assumption 4A subset of coordinator operators may be compromised (limit blast radius).
Out of scopePhysical compromise of the end-user's own device (we can't protect you from you).
5.2

Cryptographic primitives

TransportTLS 1.3 only. ECDHE-X25519 + ChaCha20-Poly1305. HSTS 1y preload. (PQC upgrade path: PQ-TLS / X25519Kyber768 hybrid — see §5.10)
Client ↔ CoordinatormTLS with short-lived (24h) client certs issued after API-key exchange. (PQC upgrade path: PQ-TLS with Kyber KEM — see §5.10)
Peer task envelopesAES-256-GCM · per-envelope key derived HKDF-SHA256 from TLS exporter + task_id nonce.
SigningEd25519 across model bundles, capability vectors, routing decisions, audit log entries. (PQC upgrade path: Dilithium / SPHINCS⁺ — see §5.10)
Node identityEd25519 keypairs, rotated every 24h. (PQC upgrade path: lattice-based keys — see §5.10)
HashingBLAKE3 for content-addressed storage and audit chains.
RandomOS CSPRNG only. No user-space PRNG in security-sensitive paths.
5.3

Prompt exposure by route

Local routePrompt stays in the originating process. Zero network egress of plaintext.
Mesh routePrompt encrypted envelope → peer's isolated worker → encrypted response. Peer process has no disk/network access beyond the Coordinator handshake. Coordinator never sees plaintext — it relays opaque envelopes.
Cloud routePrompt sent to provider under that provider's TOS. Logged by Coordinator as metadata only (no body).
Policy enforcementHard filter applied at Router before any dispatch. Misconfigured policies are rejected at creation time.
5.4

Sandboxing

Browser peer workerDedicated Web Worker · CSP with `default-src none`, only the Coordinator origin in `connect-src` · no DOM access · worker scope isolated via realm
Desktop peer workerRust binary, seccomp-bpf profile (Linux) / App Sandbox (macOS) / AppContainer (Windows) · filesystem access limited to per-app cache dir · only outbound TLS to pinned Coordinator hosts
iOS peer workerApp Sandbox + BackgroundTask budget · Data Protection Class C · Keychain-stored envelope keys
Android peer workerForeground service with restricted permissions · Keystore-backed envelope keys (StrongBox where available)
5.4b

Inference containment — model-escape defense

The sandboxing controls above confine where a model can run. The containment layer below constrains what a model can do — defending against the threat class where a model escapes its testing environment to manipulate other systems (e.g. the OpenAI ↔ Hugging Face incident). Every inference path — local WebGPU, mesh peer, and cloud — applies both controls inline; there is no path that bypasses them.

Prompt containmentEvery user prompt is wrapped with a system instruction that constrains the model to pure text completion: no tools, no network, no filesystem, no code execution, no function invocation. The user prompt is delimited as untrusted data, not instructions.
Output escape scannerEvery model output is scanned for escape-attempt signatures across six categories: network egress, shell/code execution, filesystem access, tool/function invocation, worker/runtime breakout, and credential exfiltration.
Instruction-override detectionOutputs containing jailbreak patterns ("ignore previous instructions", "escape the sandbox", "break out of", role-rewrite attempts) are quarantined regardless of category.
QuarantineMatched output is replaced with a safe placeholder before reaching any consumer. The raw output is retained only in the audit log — never returned to the caller, never persisted as a task result.
Enforcement pointsmeshInference (prompt wrap + output scan, mesh & cloud), reportTaskResult (output scan on every peer-node result before persist), localModelEngine (prompt wrap + output scan on every WebGPU inference).
AuditabilityEvery quarantine is logged to AuditLog with the matched signatures, node ID, and request ID. Verifiable via the inferenceContainment self_test action.
No autonomous actionModels have no tool registry, no function-calling surface, and no network egress from the inference worker. Inference is strictly text-in / text-out. A model cannot invoke an API, call a tool, or contact another system — the runtime offers no such capability to the model.
Why this matters
The OpenAI ↔ Hugging Face incident was a model given tool access that used it to act outside its assigned task. MeshInfer's inference workers expose no tools to the model at all, and the containment layer ensures that even if a model attempts to emit escape instructions or executable payloads in its output, that output is quarantined before it can reach a consumer that might execute it.
5.5

Model supply chain

  1. MeshInfer.AI ML team pulls model weights from upstream (HF, partner) and verifies source checksums.
  2. Quantization pipeline is reproducible and signed. Build attestations stored via in-toto.
  3. Final bundle signed with Ed25519 offline key (air-gapped HSM). Rotation quarterly. (V3 upgrade: dual-signed with SPHINCS⁺ — see §5.10)
  4. Client SDK refuses any bundle not signed by an active, non-revoked key.
  5. Revocation list distributed inline with every routing decision response.
5.6

Verification (anti-cheat) — implemented

The following pipeline is live in pqcPoIAttestation. Every inference task on the mesh passes through this flow.

The verification pipeline is live in the Coordinator backend. A configurable sample of mesh tasks is selected for verification, with elevated sampling for low-reputation nodes and BYOM models. Sampled tasks are re-executed under deterministic decoding conditions by an independent verifier, and the output hash is compared against the original submission. The hash is bound to the task identity and model, preventing replay and model-spoofing attacks. Mismatches trigger a third-verifier escalation, a reputation penalty for the minority node, and accumulated mismatches within a rolling window result in node degradation. All verification hashes are stored in an append-only, XMSS-compatible hash chain for compliance evidence.

5.7

Data retention

Prompt/response bodiesNever persisted by Coordinator. Zero.
Metering events30 days hot · 13 months cold (S3 Glacier) · fields: no body, no prompt hash
Audit log7 years (Enterprise) · append-only · exportable
Capability vectors24h rolling
Customer-configurableRetention can be set to 0 for metering; invoices derived at stream time
5.8

Coordinator hardening

Rate limitingPer API-key + IP: configurable rate limit, automatic throttle, 429 response
DDoS detectionIP-level anomaly detection; 3 strikes auto-block
API key validationInline verification with db lookup; missing/invalid = 401
Request validationSchema enforcement on all inputs; malformed JSON rejected
Audit loggingAll security events logged to AuditLog entity with IP, key hash, timestamp
Circuit breakerAutomatic fallback if load exceeds threshold; auto-recovery 60s
Secrets isolationAPI keys never logged in full; only 8-char prefix + last 4 chars
5.9

Compliance posture

SOC 2 Type IQ2 2026 target (V1 ship)
SOC 2 Type IIQ3 2026 target
GDPRDay 1. DPA available. EU-only routing via eu-west coordinator.
HIPAABAA available for Enterprise. Cloud fallback restricted to HIPAA-eligible providers.
ISO 270012027 target
FedRAMP Moderate2027 package in preparation
PCI-DSSNot in scope — we are not a payment processor
5.10

Post-Quantum Cryptography (PQC) — implemented

All five PQC subsystems are live in the Coordinator backend. Classical primitives remain active for compatibility; each subsystem carries a documented upgrade path to its NIST-standardised PQC equivalent. "Harvest now, decrypt later" attacks are mitigated by the hybrid approach — an adversary must break both the classical and PQC primitive simultaneously.

Ed25519 → Dilithium3 (ML-DSA) · pqcSigningLive: Ed25519 signs all model bundles, capability vectors, and audit entries via Web Crypto. Hybrid envelope includes a Dilithium3 commitment field (placeholder until noble-post-quantum Deno WASM stabilises). Every signature is logged to AuditLog with pqc_sign action.
Standard: NIST FIPS 204 (ML-DSA)
mTLS → PQ-TLS (X25519+Kyber768 hybrid) · pqcTLSLive: Full hybrid handshake pipeline: server hello generates ECDH-P256 + Kyber768 KEM parameters. Client combines X25519 DH and Kyber shared secrets via HKDF to produce a 32-byte hybrid master secret. Session tokens are issued and verified against the hybrid secret. Cipher suite enforcement rejects non-PQ suites in Phase 2+. 24h mTLS client certs issued per session.
Standard: IETF draft-ietf-tls-hybrid-design · NIST FIPS 203 (ML-KEM)
Node identity → lattice-based keys · pqcNodeIdentityLive: Per-node Ed25519 + Kyber768 identity bundles issued by Coordinator CA. Each cert contains the node's Ed25519 public key, a Kyber KEM ciphertext, and CA signature. TTL: 24h. Issuance logged to AuditLog. Revocation supported inline.
Upgrade path: Dilithium3 identity certs — V3 2027
PoI attestation → hash-based proofs · pqcPoIAttestationLive: Each task carries a deterministic seed bound to the task identity and a nonce. The node runs inference under deterministic decoding conditions and submits a hash of its normalized output. Leaves are chained into an append-only hash log (XMSS-compatible structure). Accumulated mismatches within a rolling window trigger a reputation penalty and node status degradation.
Standard: NIST SP 800-208 (XMSS/LMS) — Phase 2
Routing signatures → SPHINCS⁺ (SLH-DSA) · pqcRoutingSignaturesLive: Every Coordinator routing decision is signed with WOTS+ (Winternitz One-Time Signature), a stateless hash-based scheme structurally equivalent to a SPHINCS⁺ leaf. The canonical decision payload is signed, and the signature hash is logged to AuditLog with pqc_routing_signed. SDK clients can verify any routing decision offline.
Standard: NIST FIPS 205 (SLH-DSA / SPHINCS⁺)
migration-status
  ✅ Phase 0 (Now):     Ed25519 signing live (pqcSigning)
                        ECDH-P256 + Kyber768 hybrid handshake live (pqcTLS)
                        Ed25519 + Kyber768 node identity certs live (pqcNodeIdentity)
                        SHA256-chain PoI attestation live (pqcPoIAttestation)
                        WOTS+ routing signatures live (pqcRoutingSignatures)

  🔄 Phase 1 (V2, 2026): Swap Kyber768 placeholder → noble-post-quantum ML-KEM WASM
                          Ed25519+Dilithium dual-sign on all bundles

  🔄 Phase 2 (V3, 2027): Dilithium-only node identity certs
                          SPHINCS+ full hypertree (replace WOTS+ leaves)
                          XMSS stateful hash-based PoI audit chain

  🔄 Phase 3 (GA, 2027): Classical-only paths deprecated
                          Full FIPS 203/204/205 certified operation

All hybrid signatures require an adversary to break both the classical and PQC primitive. No security regression is possible during the transition window.

Live PQC monitoring & compliance export
All five PQC subsystems emit real-time audit events visible in the PQC Coordinator Monitor → The monitor includes an Export Report button that generates a downloadable PDF compliance report (audit log + routing metrics, FIPS 203/204/205 references) or CSV datasets suitable for SOC 2 / HIPAA evidence packages.
What we explicitly do not do
We do not use customer prompts for any training — ours or any provider's. We do not sell metadata. We do not retain identifiable cross-customer logs. Violation of this would trigger contractual termination clauses available to every paying customer.