# Security Layer -- Zero Trust Architecture for Distributed AI

**NOTE (2026-02-14 COURSE CORRECTION)**: This document references OpenZiti as the primary security overlay. The current architecture uses: Phase 1 HTTPS+mTLS (localhost), Phase 2 Tailscale/Cloudflare Tunnel (encrypted by default), Phase 3 Headscale/WireGuard for Hive Mode. OpenZiti deferred to Phase 4+ enterprise. See ADR-004 for current decision.

## META
- relevance: CRITICAL -- military-grade security requirement for LLMHosts
- sources: OpenZiti, WireGuard, IslandRun (arXiv:2512.00595), CSA Agentic Trust Framework (Feb 2026)
- last_verified: 2026-02-13

## SUMMARY

LLMHosts requires multi-layered security across heterogeneous compute (home devices, VPS, cloud APIs). This doc evaluates zero-trust approaches, encrypted overlay networks, privacy-aware routing, and tiered trust models. Recommendation: OpenZiti as primary overlay with IslandRun-inspired privacy routing.

## OPTION 1: OpenZiti (RECOMMENDED PRIMARY)

### Architecture
- Software-based zero trust networking platform
- Four components: Fabric (mesh network), Edge (security + SDK), SDKs, Clients
- Identity-based overlay -- eliminates IP-based networking
- Services invisible to the internet (dark services)

### Three Zero Trust Models
1. **ZTAA** (most comprehensive): SDK compiled into application, process-to-process E2E encryption
2. **ZTHA**: OpenZiti Tunneler secures host communications
3. **ZTNA**: Router-level for simpler deployments

### Security Layers
- Control + Link connections: mTLS 1.2+
- Edge connections: mTLS 1.2+ between SDKs and edge routers
- Service connections: E2E encryption via libsodium public-private key cryptography
- Cryptographically verifiable identities
- Fine-grained authorization with posture checking

### LLMHosts Integration
- Embed OpenZiti SDK into LLMHosts node agent
- All inter-node communication goes through OpenZiti overlay
- Compute nodes register as OpenZiti services
- Dark services: compute nodes invisible to internet
- Identity-based access: only authenticated LLMHosts nodes can communicate

### Deployment
- Docker-based controller and router
- SDKs: Go, C, Python, Node.js, Swift, Android
- Open source, Apache 2.0 license
- NetFoundry provides managed hosting option

## OPTION 2: WireGuard Mesh

### Architecture
- Kernel-level VPN with minimal attack surface
- Uses Noise protocol framework for cryptography
- ChaCha20 for symmetric encryption, Curve25519 for key exchange
- Minimal codebase (~4000 lines of code in kernel module)

### Advantages
- Very high performance (kernel-level)
- Simple configuration
- Proven in production at scale
- Built into Linux kernel since 5.6

### Limitations for LLMHosts
- IP-based networking (not identity-based)
- No native service discovery
- Requires key management infrastructure
- Less granular access control than OpenZiti
- Would need additional layers for service mesh features

### Tools for Mesh
- Tailscale: Managed WireGuard mesh (commercial)
- Headscale: Self-hosted Tailscale control server
- Netmaker: Self-hosted WireGuard mesh manager

## OPTION 3: mTLS (Complementary Layer)

### Use Case
- Application-level authentication between LLMHosts services
- Certificate-based mutual authentication
- Works alongside overlay network

### Implementation
- Internal CA (e.g., step-ca, Vault PKI)
- Auto-rotation of certificates
- Service mesh (Istio/Linkerd) for automatic mTLS

## ISLANDRUN PRIVACY-AWARE ROUTING (Key Design Pattern)

### Core Concept
Treats computational resources as autonomous "islands" with different trust levels. Routes requests based on data sensitivity, not just performance.

### Tiered Trust Model (Adapted for LLMHosts)
```
Tier 1: Personal Devices (Trust = 1.0)
  - User's own GPUs, laptops, desktops
  - Full trust, no sanitization needed
  - Intra-device data flows freely

Tier 2: Private Infrastructure (Trust = 0.6-0.8)
  - User's VPS instances, cloud GPUs
  - Moderate trust, light sanitization
  - Encrypted communication mandatory

Tier 3: External APIs (Trust = 0.3-0.5)
  - OpenAI, Anthropic, Google APIs
  - Low trust, full sanitization
  - PII detection and removal mandatory
```

### Six Design Principles (Mapped to LLMHosts)
1. **Constraint Preservation > Optimization**: Privacy constraints inviolable; reject rather than route to non-compliant node
2. **Fail-Closed Routing**: No island meets threshold → error, never silent degradation
3. **Context-Preserving Anonymization**: Typed placeholders maintain semantic context across trust boundaries
4. **Data-Locality-First**: Route compute to data, not data to compute
5. **Tiered Trust**: Three-tier hierarchy with clear mental model
6. **Agent-Level Modularity**: Each security concern is independent agent

### Privacy Constraint Compliance
- Island eligible for request only if: P_j >= s_r (privacy score >= sensitivity)
- PII detection agent (MIST analog) classifies request sensitivity
- Sensitive requests NEVER route to Tier 3 (external APIs)
- Reversible anonymization when crossing trust boundaries

### Data Locality Routing
- If request needs vector search → route to island with index
- If request needs fine-tuned model → route to island hosting model
- Invert "data to compute" into "compute to data"
- Critical for: privacy, bandwidth, latency

## CSA AGENTIC TRUST FRAMEWORK (Feb 2026)

### Overview
- Cloud Security Alliance's zero trust governance for AI agents
- Addresses autonomous agent security challenges
- Relevant for LLMHosts's self-evolving components

### Key Principles
- Agent identity verification (cryptographic)
- Least privilege for AI agent actions
- Continuous monitoring of agent behavior
- Audit trails for all agent decisions
- Human oversight gates for high-impact actions

## RECOMMENDED SECURITY ARCHITECTURE FOR LLMHOST

### Layer 1: Network (OpenZiti)
- Encrypted overlay mesh between all compute nodes
- Identity-based, not IP-based
- Dark services (invisible to internet)
- mTLS for all inter-node links

### Layer 2: Application (mTLS + Token Auth)
- Internal CA for certificate management
- API key/token authentication for user requests
- JWT tokens for session management
- RBAC for admin panel access

### Layer 3: Data (Privacy Routing)
- IslandRun-inspired sensitivity classification
- Tiered trust model (personal → private → external)
- PII detection before external API routing
- Reversible anonymization for cross-tier context
- Cache isolation (vLLM cache_salt per tenant)

### Layer 4: Audit
- Complete request trace: source → routing decision → destination → response
- Encrypted audit logs
- Admin-reviewable security events
- Compliance reporting (GDPR, HIPAA-ready)

### Layer 5: Evolution Security
- Code signing for platform updates
- Sandbox testing before deployment
- Human-in-the-loop approval for security-impacting changes
- Rollback capability for all updates
