Sovereign AI Stack for Solo Founders: Levels 0-3 Explained
An archived explanation of the VaHive stack’s infrastructure, governance, staffing, and maintenance layers.
Originally published on the VaHive Systems Lab website. This archive preserves the original piece; its examples, figures, and product references reflect the original publication context and are not current Virasai AI commitments.
Self-hosting AI agents without data leakage is possible through a layered, sovereign architecture that eliminates upstream exposure to third-party providers. The core move is separating reasoning, where the LLM operates, from execution, where data and credentials live. That split means no sensitive information ever leaves your controlled environment.
At a high level, this stack consists of four levels:
- Level 0: a secure infrastructure foundation built on an isolated node, container jails, and database-level enforcement.
- Level 1: a governance operating system that keeps reasoning and execution strictly separated, with human oversight built in.
- Level 2: staff roles built as bounded agents, each given a narrow mandate.
- Level 3: a maintenance layer for observability, drift detection, and cost control.
Cloud AI is structurally unsafe because every prompt containing customer data, emails, or business context gets sent to a third-party provider. Once sent, that data is subject to the provider's retention policies, potential use in model training, and its own security perimeter. Even with "private" modes, leakage risk remains through breaches, subpoenas, or accidental logging. For solo founders handling real customer data, this isn't a theoretical concern. It's a permanent loss of control. A sovereign stack avoids all of this by keeping sensitive data on infrastructure you own.
What causes data leakage in cloud AI
Data leakage in cloud-hosted AI occurs primarily through prompt transmission. When an agent processes a customer email, support ticket, or lead record, it sends the full context, including PII like names, emails, phone numbers, or payment details, straight to the provider's servers. The vectors are usually the same:
- Prompt content. Raw data goes in directly for "helpful" reasoning.
- Conversation history. Accumulated threads grow to include sensitive information over time.
- RAG retrieval. Unsanitized database records get pulled straight into prompts.
- Provider logs. Provider-side logs capture full inputs for troubleshooting.
What a sovereign AI stack is
A sovereign AI stack is a self-hosted, compartmentalized system where all sensitive data and execution stay under your exclusive control. It treats AI as bounded infrastructure, not a black-box service.
| Level | Focus | Key Outcome |
|---|---|---|
| 0 | Infrastructure | Exclusive control, no upstream PII |
| 1 | Governance | Reasoning/execution separation |
| 2 | Staff | Narrow, role-based agents |
| 3 | Maintenance | Traceability, drift detection |
Level 0 architecture overview
Level 0 is the secure foundation: a dedicated VPS with container isolation and database enforcement. Setting it up means provisioning a VPS (Hetzner, DigitalOcean) with exclusive root access, installing Docker Compose, and deploying core services (PostgreSQL with RLS, n8n) on a private bridge network with no public exposure.
Visualizing Level 0: Imagine three locked containers on a VPS: the Airlock (n8n), the Sterile Zone (PostgreSQL), and Persistent Volumes. Private network lines connect them internally, but all external access is blocked by firewall shields.
PII airlocks and tokenization
The PII airlock prevents irreversible leakage: reasoning never sees a real identity. Before anything reaches the LLM, the system detects sensitive patterns (emails, phone numbers, names) via regex and replaces them with opaque tokens, such as {{customer_123}}. Reasoning then runs entirely over that sanitized context, and only at execution does the automation layer resolve the tokens back to real values, using trusted access it holds internally.
Docker jails and isolation
Containers are jails, not a convenience feature. Enforcement covers filesystem, process, and network isolation, plus resource limits that prevent denial-of-service. If one component fails, the blast radius stays contained within that one jail.
RLS and permission walls
Row-Level Security (RLS) in PostgreSQL makes the database the final authority. With RLS enabled on sensitive tables and distinct roles in place, such as human_admin and automation_worker, the database refuses unauthorized queries at the kernel level, even if the automation layer is misconfigured.
Red button kill switch
The red button is last-resort containment: a script that stops all containers or disables the n8n queue instantly. It prioritizes stopping damage over finishing the task at hand, and it should be triggered manually or on critical thresholds (e.g., spend > limit).
Cost comparison vs cloud AI
Self-hosting shifts costs from variable tokens to fixed infrastructure. For solo founders, a sovereign stack breaks even quickly and eliminates the margin erosion that comes from token spend.
| Scenario | Cloud AI (Variable) | Sovereign Stack (Fixed) |
|---|---|---|
| Low Vol (200/day) | $300 to $800/mo | $50 to $150/mo |
| Med Vol (1,000/day) | $1,500 to $4,000/mo | $100 to $300/mo |
| Control | Vendor retention | Full sovereignty |
Why doctrine matters
Most founders fail because they treat self-hosting as a tool swap instead of an architectural redesign. They bolt local LLMs onto cloud patterns, keeping prompts verbose and roles broad, and that produces drift and leakage. A doctrine approach enforces consistency through layers: a secure base (Level 0), governed operations (Level 1), bounded staff (Level 2), and sustained maintenance (Level 3). Without that structure, what's left is a pile of fragile hacks instead of a system.