Inside a Real AI Company in a Box: The Sovereign Stack Model
An archived overview of a four-level model for infrastructure, governance, bounded agent roles, and operational maintenance.
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 comes down to a layered architecture that keeps reasoning separate from execution and keeps all sensitive data on infrastructure you control. The stack runs on four levels, forming a "Company in a Box":
- Level 0: a secure infrastructure foundation, isolated and contained.
- Level 1: a governance operating system that enforces separation and oversight.
- Level 2: bounded staff roles, each with a narrow mandate.
- Level 3: a maintenance layer for observability and cost control.
In this model, reasoning runs on sanitized inputs (PII tokenized), and execution only rehydrates real data at validated steps, on your own node. No raw customer information ever reaches an external provider.
What causes data leakage in cloud AI
Leakage happens through prompt transmission, the basic mechanism every cloud LLM runs on. The main causes:
- Direct context inclusion. Agents need full conversation history for coherence, so PII goes out unmasked.
- RAG retrieval. Database pulls inject unfiltered records straight into the prompt.
- Accumulated threads. Long-running interactions build up sensitive history over time.
- Provider logging. Inputs get captured for debugging or product improvement.
This isn't a hypothetical risk. Once data is transmitted, it's subject to the provider's own policies, breaches, and subpoenas. For a technical founder building on customer data, depending on a cloud provider means handing over sovereignty over that data along with it.
What a sovereign AI stack is
A sovereign AI stack keeps every sensitive operation on infrastructure you own, and only hands external LLMs sanitized input. The four levels form a closed loop:
DIAGRAM: The Closed Loop System
[ LEVEL 3: MAINTENANCE (Mechanic) ]
^ |
Observability Fixes
| v
[ LEVEL 2: STAFF (Specialists) ]
^
|
[ LEVEL 1: GOVERNANCE OS ]
|
Reasoning <--> Execution
|
[ LEVEL 0: INFRASTRUCTURE (The Node) ]
Level 0 architecture overview
Level 0 establishes exclusive control through a dedicated node: a VPS with root access, Docker Compose installed, and PostgreSQL and n8n deployed on a private network.
Checklist:
- Exclusive tenant, no shared memory inspection
- Private bridge network
- Environment variables for secrets
- Encrypted volumes
- Tested backups
DIAGRAM: Level 0 Isolation
[ INTERNET ] --x-- [ SHIELD ] --x-- [ DB ]
|
[ LLM API ] <--> [ Airlock (n8n) ] <--> [ Internal API ]
|
[ Vector Store ]
PII airlocks and tokenization
The airlock means reasoning never sees a real identity. Patterns are detected (regex for emails, phone numbers) and replaced with tokens before the data reaches the reasoning layer. Real data is only rehydrated in the automation layer, after validation, which keeps the original intent intact without ever exposing it.
Docker jails and isolation
Containers enforce containment sideways as well as down: separate containers per service, strict resource limits, and non-root users, so a compromise in one container stays contained to that one container.
RLS and permission walls
Row-Level Security makes the database defend itself. With RLS enabled and policies defined on session context, the database enforces its own rules even if the application layer tries to get around them.
Red button kill switch
Immediate containment for a runaway process: a script that stops containers or disables the queue, triggered manually or automatically past a threshold. It freezes state changes first, so damage stops before anything else happens.
Cost comparison vs cloud AI
| Volume | Cloud AI | Sovereign stack |
|---|---|---|
| Low (200/day) | $300 to $800/mo | $50 to $150/mo |
| Medium (1,000/day) | $1,500 to $4,000/mo | $150 to $400/mo |
| Long term | Price hikes | Predictable |
Why doctrine matters
Most founders fail not because self-hosting is hard, but because they port cloud-native patterns straight into it: agents kept too broad, execution left mixed in with reasoning, prompts left verbose. That produces a system that's complex, leaky, and collapses under real load. A doctrine approach avoids that by building the levels in order: a secure base (Level 0), governed operations (Level 1), bounded staff (Level 2), and sustained maintenance (Level 3). Skip that structure and what you get instead is a pile of fragile hacks that happen to work today.