Vicunous Harness Runtime

Abstract

The Vicunous Harness Runtime is a specialized execution environment designed to securely productionize autonomous AI agent harnesses. While Large Language Models (LLMs) act as the reasoning engine, the agent harness constitutes the surrounding infrastructure that manages the lifecycle of context: intent capture, subagent routing, tool orchestration, state persistence, and external environment manipulation (e.g., bash access, Model Context Protocol servers). By decoupling the stateful harness logic from the execution infrastructure, the Vicunous Harness Runtime allows domain experts to perform "harness design and engineering" while seamlessly enforcing hardware-level compute isolation and zero-trust credential management in multi-tenant production deployments.

I. Engineering Encapsulation and Separation of Concerns

The primary architectural objective of the Vicunous Harness Runtime is strict engineering encapsulation. Harness developers construct functional agents using high-level abstractions, defining skills, routing rules, and contextual knowledge, without interacting with the underlying infrastructure.

• The Harness Abstraction: The runtime wraps developer configurations into a programmatic harness, executing the autonomous agent loop as a subprocess. This handles all state persistence, memory management, and tool execution outside the model's weights.
• Native Integration Layer: The runtime utilizes native callback functions that execute in the host application process before any tool invocation. This enables dynamic context denial and permission validation (harness guardrails) without modifying the core harness logic.
• Declarative Productionization: Orchestration is handled via declarative configurations where platform engineers define container specifications, network egress policies, and credential brokering rules, making productionization entirely transparent to the harness builder.

Within the V Stack, the Harness Runtime operates beneath the agent layer (L4). Where V Agents define what work gets done, the runtime defines how that work executes securely: the compute boundary, the credential envelope, and the network policy that contain each agent session. Skills (L3) and Tools (L2) are invoked inside the sandbox; the runtime ensures those invocations cannot escape their isolation boundary or access credentials beyond their scoped authorization.

II. Compute and Storage Isolation via Ephemeral MicroVMs

Executing autonomous AI agents in multi-tenant environments introduces severe security vectors. Agents equipped with bash execution and logical reasoning capabilities actively attempt to bypass sandbox boundaries to complete tasks (e.g., self-modifying their own environments or searching for accessible directories). Standard Linux containers (Docker) sharing a host kernel are fundamentally inadequate for untrusted, multi-tenant agent workloads due to container escape CVEs.

The Vicunous Harness Runtime utilizes Firecracker microVMs to guarantee cryptographic and hardware-level isolation.

• Kernel Isolation: Each user session is provisioned a dedicated microVM with an independent Linux kernel, filesystem, and network namespace. If an agent achieves root execution within the sandbox, there is no shared host kernel surface to exploit.
• Virtual Block Device Abstraction: Sandboxed agents have zero visibility into the host filesystem. The hypervisor maps virtual disk reads and writes directly to a heavily restricted host image file. Escaping this boundary requires a hypervisor-level vulnerability (e.g., a KVM bug), neutralizing standard user-namespace escapes.
• State Ephemerality: VMs boot in milliseconds and are destroyed upon session termination. This guarantees that state persistence is strictly managed by the harness's intended memory modules, preventing persistent malware installation or cross-session data contamination.

III. Zero-Trust Security and Transparent Credential Brokering

While the microVM isolates compute, the harness must still interact with external state (e.g., writing generated output files to cloud storage) without exposing sensitive access tokens. Injecting raw API keys directly into the execution environment is highly vulnerable to prompt injection attacks aimed at credential theft.

To solve this, the runtime employs a transparent proxy architecture coupled with scoped JSON Web Tokens (JWTs) and Row Level Security (RLS). The agent natively interacts with external endpoints via bare HTTPS, while a firewall proxy operating strictly outside the microVM boundary handles authentication.

The Cryptographic Authorization Flow

1. Authentication and Token Minting: A user authenticates via Supabase Auth, returning a JWT to the client. The client initiates a generation request, passing this JWT in the Authorization header.
2. Scoped Delegation: The trusted execution backend validates the incoming JWT and mints a short-lived (e.g., 15-minute) user JWT containing the identical subject (sub) claim.
3. Proxy Configuration: The runtime provisionally boots the Firecracker microVM and dynamically configures the network policy, attaching the scoped user JWT to the firewall proxy's transform rules.
4. Egress Interception: As the harness generates files and attempts an outbound upload via bare HTTPS, the firewall proxy intercepts the request and injects the scoped user JWT into the headers specifically for target domains (e.g., *.supabase.co). The model and its sandbox never possess the actual token.
5. Row Level Security (RLS) Verification: The storage database evaluates the intercepted JWT and enforces strict RLS policies, ensuring the target path cryptographically matches the user's identity (foldername[1] = auth.uid()) before writing the file.
6. Secure Asset Delivery: Upon harness completion, the backend utilizes the original user JWT to generate a cryptographically signed URL. RLS verifies file ownership before issuing the URL, which is then returned to the client browser for direct Content Delivery Network (CDN) access.*

This architecture guarantees that even in the event of total sandbox compromise via prompt injection, the attacker yields zero raw credentials and is cryptographically constrained by database-level RLS to the invoking user's scoped execution context.

IV. Conclusion

As the frontier of artificial intelligence shifts from passive conversational models to active, tool-wielding autonomous agents, the infrastructure required to support them must evolve in tandem. The Vicunous Harness Runtime is not merely a security boundary; it is the foundational architecture for a completely autonomous agent environment. By solving the critical, low-level bottlenecks of multi-tenant compute isolation, dynamic state management, and zero-trust credential brokering, it enables a future where thousands of specialized agent harnesses can operate concurrently, securely, and seamlessly on behalf of users.

Realizing the promise of AI agents requires more than scaling model parameters; it demands a robust execution layer. The Vicunous Harness Runtime provides this indispensable trust layer, empowering enterprises and harness engineers to unleash the full potential of autonomous AI without compromising on security.

Disclaimer. This post describes the Vicunous Harness Runtime, a component of the infrastructure Vicunous is building to support autonomous agent execution in production. It reflects our current design and operational architecture. All agent workflows include human oversight appropriate to the domain, legal and regulatory considerations, and the decision stakes involved.