# Security Principles **Page:** vision/security [Download Raw Markdown](./vision/security.md) --- # Security Principles **Traditional security is a house of cards.** A thousand entry points. A million configurations. Endless patches, endless vulnerabilities, endless complexity. **Hoody's approach:** Everything flows through HTTP. Everything lives in containers. Everything starts isolated. Security is built-in by default—reducing friction while enabling the [100x future](/vision/100x-foundation/) where humans orchestrate AI at scale. The result? Your attack surface collapses from thousands of vectors to one: your browser. --- ## One Protocol, Focused Security **Traditional Computing:** SSH, RDP, VNC, FTP, custom protocols, binary APIs. Every protocol is an attack vector requiring separate security models. **Hoody:** HTTP for everything. One protocol to secure, monitor, and control. When everything speaks HTTP, your entire security model simplifies to securing web traffic—something we've been perfecting for 30 years. ## Why HTTP Works for Hoody **We chose HTTP not because it's universally superior, but because it fits our specific architecture perfectly.** Hoody is built around containers that need to be accessible from anywhere—phones, tablets, browsers, AI agents, IoT devices. HTTP is the one protocol that works everywhere without special clients or configuration. **The practical benefits for our use case:** - **Universal compatibility**: Every device speaks HTTP—no client installation needed - **Single protocol to secure**: Instead of securing SSH + RDP + VNC + FTP + custom protocols, we focus on one - **Browser sandboxing**: When accessed via browser, you inherit decades of sandboxing improvements - **Observable by default**: HTTP traffic is easier to log, monitor, and audit than binary protocols - **Works through firewalls**: Corporate networks that block everything still allow HTTPS - **Native embeddability**: Containers become iframe-able without special wrappers **The tradeoffs we accept:** This approach isn't perfect. Binary protocols can be more efficient. Native applications can access hardware directly. Custom protocols can implement specialized security models. But for Hoody's goal—making containers accessible from any device, by humans and AI alike—HTTP provides the right balance of security, compatibility, and simplicity. --- ## Cryptographic URL Security Every container gets a URL like this:
https://projectId-890abcdef12345678901cdef-display-1.node-us.containers.hoody.icu
**The Math:** Container ID = 24 hex characters = 2^96 possible combinations Even if an attacker discovers your projectId: - At 1 billion attempts/second: **2.5 × 10^12 years** to guess - Using all global computing power: **Still billions of years** This enables "open by default"—the URL itself is the secret. When you need more, layer on additional auth. --- ## Security Components Hoody's security isn't layered sequentially—it's a combination of complementary mechanisms working together: ### Unguessable URLs - **24 hex character container IDs** = 2^96 keyspace - **No enumeration possible**—can't scan for containers - **Instant revocation**—delete container, URL dies ### Permissions **Multi-layered access control from API to service level:** **Hoody API Access:** - **Auth tokens** with IP whitelisting, expiration, enable/disable - Scope tokens to specific realms **Container Proxy Permissions:** - **Project-level** (applies to all containers in project) - **Container-level** (overrides project settings for specific containers) - **Authentication groups**: JWT, password, IP-based, bearer tokens - **Program-specific permissions** per group (terminal, files, display, etc.) - **Default policy**: Allow or deny **Service-Level Granularity:** - Terminal: Execute vs read-only - Files: Read vs write vs delete - Database: Query vs modify - Display: View vs control See [Proxy Permissions](/foundation/proxy/permissions/), [Container Proxy Permissions](/api/proxy-permissions/), and [Auth Tokens](/api/auth-tokens/) for complete configuration. ### TLS Everywhere - **Every connection HTTPS**—no exceptions - **Wildcard certificates** (`*.containers.hoody.icu`)—your URLs never appear in Certificate Transparency logs - **Modern protocols**—HTTP/1.1, HTTP/2 and HTTP/3 ### Container Isolation **All services run inside containers, never on the host.** The entire **Hoody Kit** (terminal, files, display, exec, database, browser, agent, etc.) runs exclusively inside containers—never on the bare metal host. This architectural decision prevents compromised services from affecting the host system. **Why this matters:** - **Host stays pristine**: Only minimal system services run on bare metal - **Blast radius contained**: Compromised container can't escape to host - **Easy recovery**: Delete container, spawn fresh replacement - **No host contamination**: Malware stays isolated to the container **Isolation Technologies:** - **Hardened LXC**—lightweight virtualization on the Hoody kernel (with optional full VM instances) - **Linux namespaces**—kernel-enforced boundaries - **Hardened kernel**—custom-built (currently `7.0.0-rc5-hoody`) - **Seccomp filters**—syscall restrictions - **No shared kernel memory**—containers can't read each other's RAM **Efficient Scaling (On Your Own Hardware):** Beyond the core isolation technologies, Hoody employs advanced optimizations to enable massive scale: - **KSM (Kernel Samepage Merging)**—shares identical memory pages across containers to optimize RAM usage - **BTRFS deduplication**—eliminates duplicate data blocks for storage efficiency This allows spawning hundreds of containers without proportional resource consumption. ### Dedicated Infrastructure **You run your own container engine on dedicated servers you control.** Unlike traditional cloud providers where multiple customers share physical infrastructure, Hoody containers run on **your bare metal**—no hypervisor sharing, no neighbor containers from other customers. **Security benefits:** - Side-channel attacks (Spectre, Meltdown) eliminated - No hypervisor escape vulnerabilities - No shared kernel risks between customers - Container breaches stay within your isolated infrastructure **Performance benefits:** - No "noisy neighbor" problems—your containers never compete with strangers' workloads - Predictable performance—no random slowdowns from other tenants - 100% resource utilization—every CPU cycle and memory byte is yours ### Disk Encryption (LUKS) - **AES-256 encryption** at rest - **Encrypted swap** and temporary files - **Sub-partition remote unlock**—requires authorized remote mechanism ### Snapshots: Time-Travel Security **Instant recovery and forensics:** Restore pre-compromise snapshot (30 seconds), preserve compromised state for analysis, compare snapshots to find breach moment. Zero downtime—production runs from clean snapshot while you investigate. ### Realms: API-Level Isolation Realms segregate the Hoody API, not container networks: ``` https://{realmId}.api.hoody.icu ``` **Purpose:** - AI agents in one realm can't discover containers in another - Auth tokens scope to specific realms - Production/staging/development completely separated at API level - Multi-tenant isolation for teams/clients ### Container Firewalls **Host-level network control (not tamperable by containers):** - Ingress/egress rules per container - Port-level granularity - Protocol filtering: TCP/UDP/ICMP controls - Default-deny stance **Additional layers:** Users can add iptables, nftables, or ufw inside containers for defense-in-depth. See [Container Firewalls](/api/container-firewall/) for complete configuration. ### Controlled IPv4 Routing **No direct IPv4 by default:** - Containers have no IPv4 address by default - All external traffic routes through Hoody Proxy - Forces observable, controllable network access **Host-Level Exit Options (not tamperable by containers):** - **SOCKS5/HTTP/HTTPS proxies** as exit nodes - **WireGuard VPN** integration - **Commercial VPN providers** (Mullvad, iVPN, AirVPN, etc.) - zero in-container configuration - **Block mode** to prevent all outgoing traffic - **Custom DNS servers** (up to 4) Ideal for location rerouting with zero container management overhead. See [Container Network Configuration](/api/container-network/) for setup. ### Observability **When everything is HTTP, everything becomes observable.** Using hoody-exec, you can intercept and analyze all traffic: - Scan inputs for malicious payloads - Create complete audit trails - Rate limit to prevent abuse - Validate against policies - Real-time threat detection Use [hoody-exec](/kit/exec/) to build observability pipelines that intercept and analyze traffic across services. ### Gateway Containers (Jumphost) **Think of it as a poor man's VPN—but more appropriate for HTTP-native infrastructure.** Traditional VPN solutions are complex to configure, require specific clients on every device, and create a single point of failure. Gateway containers give you the same network access model but through pure HTTP—no special software, no configuration files, just a URL. ``` Your Device (Browser Only) → Gateway Container → Working Containers ``` **How it works:** A gateway container is just another Hoody container, but you use it exclusively as your entry point. It runs with elevated permissions and MITM capabilities, acting as your secure proxy into the rest of your infrastructure. From this gateway, you can: - Access all other containers via their internal network - Route requests through different exit nodes - Apply organization-wide security policies - Log and audit every action across your fleet - Give temporary access to outsiders without exposing your real infrastructure **Why this beats traditional VPNs:** - **Zero client installation**: Works from any browser on any device—phone, tablet, borrowed laptop, internet café - **Instant provisioning**: Spin up a gateway container in 30 seconds, not hours of VPN configuration - **Per-user isolation**: Each contractor/team gets their own gateway container with specific permissions - **Disposable security**: Suspect compromise? Delete gateway, spawn new one, update URL—60 seconds total - **Better auditability**: Every action is an HTTP request with complete logging, not opaque VPN tunnel traffic - **Works everywhere**: Corporate firewalls that block VPN protocols allow HTTPS - **Multiplayer by default**: Share gateway URL with team, everyone sees same environment - **MITM superpowers**: Inspect, modify, or block any request flowing through your infrastructure It's the network isolation model of VPNs, but HTTP-native, browser-accessible, and infinitely more flexible. No OpenVPN configs. No WireGuard keys. No "it works on my machine but not yours." Just a URL that grants secure network access through pure HTTP. --- ## What Hoody Knows (And Doesn't Know) **Technical transparency about data visibility:** **What Hoody IS Aware Of:** Through the **Hoody API** (`api.hoody.icu` or `{realmId}.api.hoody.icu`), we can see: - Container lifecycle events (creation, deletion, snapshots) - Project and realm configurations - Storage share mounts and network setup - Billing and authentication activity - API request metadata (timestamps, IP addresses, endpoints called) See our Privacy Policy for complete details on data handling. **What Hoody is NOT Aware Of:** Because the **Hoody Proxy runs on YOUR server** (in a container on your bare metal): - ❌ What you host on containers (websites, tools, applications) - ❌ Container traffic content - ❌ Container activity and operations - ❌ Terminal commands executed - ❌ Files accessed or modified - ❌ Database queries and data - ❌ AI agent prompts or responses - ❌ HTTP logs from your services - ❌ Internal container communications While we cannot see your container activity, you remain responsible for complying with our Acceptable Use Policy. **The Architecture:** ``` Hoody API (api.hoody.icu) ├─ Sees: Container management, billing, configuration └─ Cannot see: Container traffic, content, activity Your Bare Metal Server(s) └─ Hoody Proxy Container (Your Infrastructure) ├─ Routes: All container traffic ├─ Enforces: Network policies, firewalls └─ Zero-knowledge: Traffic never reaches Hoody infrastructure Your Containers └─ Complete privacy for all operations ``` --- ## AI Privacy & Control **You're free to use any AI setup you want.** Install your own agents, use any provider (OpenAI, Anthropic, local models), or connect directly to AI services—it's your infrastructure. **Why we recommend Hoody AI:** When using our AI gateway: - **Proxy on YOUR server**—self-hosted in a container - **Your choice of [models](/foundation/hoody-ai/models/)**—Claude Opus 4.1, Sonnet 4.5, GPT-5, Gemini 2.5 Pro, Llama, Qwen, or any provider - **Requests route through your hardware**—before reaching external providers - **Complete MITM capability**—any container can intercept/inspect prompts or responses - **Local audit trails**—all AI interactions logged on your server This gives you complete control and observability while maintaining compatibility with any AI service. --- ## Realistic Security Posture **Security is never perfect.** Hoody reduces attack surface and simplifies security management, but no system is invulnerable. What we provide is a more manageable, auditable, and recoverable security model. ### The Dependency Problem **Compromised dependencies remain an industry-wide challenge.** NPM packages, system libraries, Docker images—the software supply chain has countless potential points of failure. This affects every platform, not just Hoody. **Our position:** Hoody's focus is on infrastructure isolation and rapid recovery, not solving supply chain security. When a dependency is compromised: - **Container isolation** limits the blast radius—one compromised container doesn't spread - **Snapshots** enable instant rollback to known-good states - **Realms** prevent cross-contamination between projects - **HTTP observability** helps detect unusual behavior faster But we don't claim to prevent supply chain attacks. That's a broader ecosystem problem requiring solutions at the package manager, build tool, and distribution levels—beyond any single platform's scope. **The 100x future** discussed in [The 100x Foundation](/vision/100x-foundation/) depends on trusting AI-generated code and third-party packages. Hoody provides the isolation and recovery mechanisms to make that trust viable through containment, not prevention. ### What Hoody Improves - **Attack Surface**: Thousands of protocols → Single HTTP entry point - **Recovery**: Hours/days to patch → Seconds to restore from snapshot - **Auditing**: Scattered logs → Unified HTTP logging - **Forensics**: Lost evidence → Perfect state preservation ### What Remains Complex - **Application security** still requires careful coding - **Authentication** still needs proper implementation - **Network policies** still need configuration - **Security patches** / **Updates** still need to be applied - **Human factors** remain the weakest link --- ## Key Principles **Hoody's security model provides:** - **Simpler security** through protocol unification - **Faster recovery** through snapshot restoration - **Better visibility** through HTTP observability - **Reduced surface** through browser-only access - **Complete forensics** through state preservation - **AI privacy** through self-hosted infrastructure and MITM capability When everything is containerized, HTTP-native, and snapshot-able, security becomes more manageable—not magical. --- > **Traditional security:** Thousands of doors, each with different locks > **Hoody security:** One door, cryptographically sealed, fully observable > **The difference:** Not perfection, but radical simplification. **Next:** [Getting Started →](/getting-started/quickstart/)