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 approach is to separate reasoning (where the LLM operates) from execution (where data and credentials live), ensuring no sensitive information ever leaves your controlled environment.
At a high level, this stack consists of four levels:
- Level 0: Secure infrastructure foundation — isolated node, container jails, and database enforcement.
- Level 1: Governance and operating system — strict reasoning/execution separation and human oversight.
- Level 2: Staff roles — bounded agents with narrow mandates.
- Level 3: Maintenance — observability, drift detection, and cost controls.
Cloud AI is structurally unsafe because every prompt containing customer data, emails, or business context is transmitted to a third-party provider. Once sent, that data is subject to the provider's retention policies, potential use in model training, and their security perimeter. Even with "private" modes, leakage risks remain through breaches, subpoenas, or accidental logging. For solo founders handling real customer data, this is not a theoretical concern — it's a permanent loss of control. A sovereign stack avoids this entirely 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, the full context — including PII like names, emails, phone numbers, or payment details — is sent to the provider's servers.
Common vectors:
- Prompt content: Direct inclusion of raw data for "helpful" reasoning.
- Conversation history: Accumulated threads that grow to include sensitive information.
- RAG (Retrieval): Pulling un-sanitized database records into prompts.
- Provider Logs: Provider-side logs capturing 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 remain 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. The implementation involves 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 & Tokenization
The PII airlock prevents irreversible leakage by ensuring reasoning never sees real identities.
- Before sending to LLM: Detect sensitive patterns (emails, phones, names) via regex and replace with opaque tokens (e.g.,
{{customer_123}}). - Reasoning: Occurs over sanitized context.
- At execution: The automation layer resolves tokens internally using trusted access.
Docker Jails & Isolation
Containers serve as jails, not convenience. Key enforcements include filesystem/process/network isolation and resource limits to prevent DoS. If one component fails, the blast radius is strictly contained within that jail.
RLS and Permission Walls
Row-Level Security (RLS) in PostgreSQL makes the database the final authority. By enabling RLS on sensitive tables and creating distinct roles (human_admin, 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. It is a script designed to stop all containers or disable the n8n queue instantly. It prioritizes stopping damage over task completion and 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, sovereign breaks even quickly and eliminates margin erosion from token spend.
| Scenario | Cloud AI (Variable) | Sovereign Stack (Fixed) |
|---|---|---|
| Low Vol (200/day) | $300–800/mo | $50–150/mo |
| Med Vol (1000/day) | $1500–4000/mo | $100–300/mo |
| Control | Vendor retention | Full sovereignty |
Why Doctrine Matters
Most founders fail because they treat self-hosting as a tool swap rather than an architectural redesign. They bolt local LLMs onto cloud patterns — keeping prompts verbose and roles broad — leading to drift and leakage. A doctrine approach enforces consistency through layers: secure base (Level 0), governed operations (Level 1), bounded staff (Level 2), and sustained maintenance (Level 3). Without this structure, attempts fragment into fragile hacks.