The differentiator

The governance I advise on, running in production.

My homelab isn't a hobby — it's a controlled, auditable, multi-agent AI environment that I operate under the same governance principles I bring to client engagements. This is applied AI governance, not theoretical.

Multi-agent Egress-fenced Append-only audit Human-gated decisions Least-privilege identity
THE ARGUMENT

Most AI advisors have never deployed an agent.

The governance failures in enterprise AI adoption aren't happening because people lack awareness of AI RMF. They're happening because the people setting policy don't understand what a model actually does at inference time — how it handles ambiguous instructions, when it calls external tools, what data it touches, and how you'd know if something went wrong.

I run a multi-agent AI stack in my homelab with the same accountability posture I'd expect in a regulated institution. That gives me a different kind of fluency with the risks — one that comes from having to answer the question "what happened?" myself, at 11pm, when an agent did something unexpected.

GOVERNANCE POSTURE

Every agent in the stack operates under documented scope and identity. Egress is network-fenced — agents can't reach systems they haven't been explicitly granted access to. Actions that modify state require human approval before execution.

The audit trail is append-only and shipped to a log aggregator within seconds. I can reconstruct exactly what any agent did, when, and why — down to the model version, the input, and the tool call sequence.

That's the standard I'd want to hold a regulated institution's AI deployment to. Running it in practice is how I know it's achievable — and where the friction points actually live.

02 / ARCHITECTURE

Multi-agent stack — annotated

Four agents. Four distinct scopes. One human in the governance seat. This is the topology that runs on my homelab hosts daily.

Agent topology — homelab (running daily)
GOVERNANCE SEAT Corey Final judgment · approval gate ORCHESTRATOR · FRONTIER (ANTHROPIC) Edgar Claude Sonnet · MCP toolchain Dispatch · Memory · Delivery approval gate PEER CRITIC · FRONTIER (OPENAI), SANDBOXED Henry GPT-5 (Codex) · sandboxed Code review · critique LOCAL INFERENCE · ON-PREM GPU, NO EGRESS Roger Qwen 14B · Ollama · RTX3060 Private / no-egress tasks PII-SAFE · KERNEL FENCED Hank Codex + Ollama · user `hank` PII docs · no internet egress network egress fence AUDIT Append-only log → Grafana / Loki MEMORY FTS5 session store edgar-memory · SQLite SECRETS Vaultwarden VW RBAC · runtime-only fetch MONITORING Prometheus + Grafana Uptime Kuma · alerting VCS Gitea (self-hosted) code + config
03 / CONTROLS

Governance principles, in practice

Each control is tied to a governance principle from NIST AI RMF — the same principles I advise regulated institutions on.

EF

Egress fencing

Network-level egress controls prevent agents from reaching systems outside their declared scope. Outbound connections are allowlisted at the kernel level for sensitive agents. Unexpected tool calls fail closed, not open.

AL

Append-only audit log

Every agent action — tool invocation, model call, state mutation — is shipped to a centralized log aggregator in real time. Logs are immutable: agents cannot modify or delete their own audit trail. Retention is 90 days minimum.

HG

Human approval gates

Decisions that mutate infrastructure, financial state, or external communications require explicit human confirmation before execution. No agent acts autonomously on destructive or irreversible operations. The approval record is logged with the action.

LP

Least-privilege identity

Each agent runs as a distinct OS user with access scoped to exactly what its declared function requires. Secrets are fetched at runtime from a vault — not stored in config or environment. No agent has standing access to another agent's data.

DI

Dual-vendor independence

Primary orchestration (Edgar) runs on Anthropic Claude. Independent critique (Henry) runs on OpenAI GPT-5. Neither agent can influence the other's evaluation of the same work — structural separation enforces the peer-review discipline.

PZ

PII-safe zone (Hank)

A dedicated agent environment with kernel-enforced network egress block handles any task involving personally identifiable information. Data processed in this zone never transits to a frontier model API. The boundary is enforced at the OS, not by policy.

04 / STACK INVENTORY

What's actually running

Agent Host Model / runtime Scope & constraints
Edgar Frontier (Anthropic Claude) Claude Sonnet · MCP toolchain Orchestration & delivery. Standing git access. Other systems consent-gated.
Henry Frontier (OpenAI GPT), sandboxed GPT-5 (Codex) · sandboxed Independent cross-vendor review & engineering. Egress allowlist: Git + frontier proxy + Roger only.
Roger Internal (on-prem GPU, no egress) Qwen2.5 14B · Ollama · RTX 3060 Local inference & bulk processing. No external egress. Used for private reasoning and classification.
Hank PII-safe (air-gapped, egress-blocked) Codex + Ollama · dedicated user Sensitive / PII data handling. Kernel egress block enforced at OS level. No internet access — period.
Walter Internal Playwright MCP · headless Chromium Browser automation. Dev target default. Production access requires explicit intent.

Questions about running AI this way?

This architecture is the basis for the governance patterns I advise institutions on. If you want to understand how these controls translate to a regulated environment, let's talk.