The Hypervisor for Agentic Workflows

Give agents tool access. Without the blast radius.

VIVARY is the open-source runtime that wraps tool-using LLMs in a hard-isolation boundary. Move from "prompts and prayers" to governed, auditable, and production-ready agent execution.

Get Started Architecture
Isolation
systemd-nspawn
Policy
KDL ACLs
Audit
MUS over SQLite

What you get

Agents you can actually govern.

I

Hard isolation by default

Each agent runs in its own systemd-nspawn container with its own Btrfs subvolume, a firewalled veth, and a single MUS pipe to keeperd. No ambient access to the host.

II

Credentials never leave the host

Agents reference a credential_id. keeperd holds the vault and resolves secrets at dispatch time. No token, key, or password ever enters the container.

III

Capabilities are contracts, not strings

Each capability is a self-documenting Unix CLI tool: run it with --help and it returns its full JSON schema. Scope, rate limits, and approval requirements are declared in agent.kdl, not buried in prompts.

IV

Every action is auditable

MUS-framed traffic and structured events are recorded to SQLite. vivlog gives operators a plain CLI to decode frames, trace denials, and reconstruct what the runtime actually did.

Why not just use X?

The alternatives leave gaps you can't close later.

OpenAI Assistants & hosted platforms

Your agents run in their infrastructure. Credentials, tool results, and audit data never leave their cloud. Vendor lock-in is structural, not incidental. You cannot inspect what the runtime actually did.

Open-source frameworks (LangChain, CrewAI, AutoGen)

Agents get process-level access to the host environment. Tool calls are untyped function calls. Policy is prompt text. There is no audit trail, no approval flow, and no credential separation — by design.

MCP (Model Context Protocol)

No isolation. No credential separation. Tool definitions live in prompts. Any server an agent can reach can be called. No structured audit. MCP is a tool-discovery protocol, not a governance layer.

Raw containers or VMs

You get OS-level isolation but nothing above it. No capability schema. No policy enforcement. No audit protocol. No orchestration. Every project ends up rebuilding the same ad-hoc governance layer from scratch.

Forensic Visibility

Agents shouldn't be a black box.

VIVARY provides a forensically-sound SQLite trail of every byte that passed between your LLM and your infrastructure. MUS-framed, timestamped, and immutable.

Full Byte-Stream Audit

Every capability request and response is captured in its raw binary form. Decouple your audit trail from the model's own (often unreliable) internal logs.

Security Event Logging

Denials are not just errors; they are security events. Every blocked URL, path traversal attempt, or rate-limit trigger is recorded with agent-level identity stamping.

How it works

One control plane. Any number of agents. One audit trail.

VIVARY architecture diagram A host OS containing a NixOS LXD layer with keeperd and multiple nspawn agent containers, plus host-side Chrome and MUS audit logs decoded by vivlog. Host OS Chrome and audit inspection stay outside the container boundary NixOS LXD Layer Minimal, reproducible base system keeperd policy, routing, audit identity and dispatch viv TUI / CLI over keeper.sock nspawn Agent ×N ward syntax + protocol adapter LLM subprocess no raw credentials no unrestricted network egress Chrome host-side browser isolated profile per agent keeperd speaks CDP MUS Audit Log SQLite decoded by vivlog frames, events, denials MUS over Unix socket MUS over stdio CDP proxy prompt dispatch MUS frames and event records

Compiled Go, few dependencies

keeperd, ward, viv, and vivlog are statically-linked Go binaries. The full runtime ships in a minimal NixOS LXD image. No Python. No npm. No runtime interpreter.

MUS binary framing

All agent-to-keeper traffic uses compact MUS frames with typed headers. Every frame is logged. vivlog decodes them without bespoke tooling — grep-friendly, CLI-first.

KDL capability schema

Capabilities are declared in agent.kdl with named scopes, rate limits, and optional approval gates. The schema is machine-generated from Go types; there is no drift between policy and implementation.

Capabilities

What are "Capabilities"?

Every action an agent can take is a named, scoped, typed capability — declared in capabilities.kdl and enforced by keeperd. Capabilities are self-documenting Unix CLI tools: run any with --help to get its full JSON schema. No capability, no access.

Web_Page_Read Browser risk: low

Fetch the readable text content of a web page, stripped of markup, scripts, and boilerplate.

  • urlstringrequired
  • timeoutintdefault 30s
  • wait_forstringdefault "networkidle"
→ string — readable page text in markdown
Calendar_Event_Create Calendar risk: high

Create a new calendar event. Writes to the CalendarEvent entity; requires explicit grant in agent.kdl.

  • titlestringrequired
  • startstringrequired — ISO8601
  • endstringrequired — ISO8601
  • attendeeslist<string>optional
→ object — event_id, html_link
Fs_File_Write Filesystem risk: medium

Write or overwrite a file in the agent's scoped workspace. Path prefix is enforced by keeperd; symlink escapes are rejected.

  • pathstringrequired
  • contentstringrequired
  • encodingstringdefault "utf-8"
→ object — path, bytes_written
Commerce_Order_Create Commerce risk: critical

Place an order with a configured commerce provider. Requires a confirm: true field and operator approval gate by default.

  • skustringrequired
  • quantityintrequired
  • shipping_address_idstringrequired
  • confirmboolmust be true
→ object — order_id, total_amount, estimated_delivery
Home_Device_Invoke SmartHome risk: medium

Invoke an action on a smart home device via the configured hub (Home Assistant, Google Home, etc.).

  • device_idstringrequired
  • actionstringon · off · toggle · set
  • valuestringoptional
→ object — device_id, new_state, acknowledged_at
Messaging_Message_Send Messaging risk: high

Send a message to a contact via WhatsApp, SMS, or Signal. Recipient must be a pre-approved contact in agent.kdl.

  • tostringrequired — E.164
  • bodystringrequired
  • providerstringdefault "whatsapp"
→ object — message_id, status, sent_at

Capabilities are granted per-agent in agent.kdl. Each grant specifies scope, rate limits, and whether operator approval is required before execution. All calls — allowed and denied — are written to the audit log.