VR-VM: An AI-Pluggable Appliance for Evidence-Graded Vulnerability Research

1Introduction

Determining what an unknown program actually does — vendor firmware, a third-party utility, an npm package that outweighs its documentation — remains slow specialist work. The realistic alternatives are worse: execute the artifact on a machine that must subsequently be treated as compromised, or forego dynamic analysis entirely. Meanwhile, language models have become credible operators of security tooling when the tooling is presented to them correctly, yet the environment in which such an agent could safely work on genuinely untrusted software has not been productized as open source.

VR-VM is that environment: a disposable, fully instrumented analysis machine. An AI client of the operator's choosing connects over a single Model Context Protocol (MCP) endpoint^[1] and immediately controls the standard toolkit of a reverse engineer and vulnerability researcher — disassembly, decompilation, debugging, memory forensics, dynamic instrumentation, network capture — while kernel-level sensors record everything the target does and a policy engine governs everything the target is permitted to reach. When a run concludes, the machine reverts to a clean snapshot.

The system's three load-bearing properties, stated plainly:

• Isolation. The analysis machine is separated from the host by construction. Its only network is a lab network whose default posture is deny-all, and the management plane is unreachable from it at every policy level.
• Total telemetry. auditd, an eBPF sensor, an IDS, and a TLS-intercepting proxy write one unified, queryable event timeline. The agent does not read logs after the fact; it interrogates the timeline as a first-class tool.
• Repeatability. Storage is a qcow2 backing chain. Snapshot and revert are exposed as tools, so every experiment begins from a known-clean state — a property usually asserted and rarely enforced.

The project began as the design of an agent and concluded as the design of an appliance. The deliverable is the VM, not the agent: the author maintains the lab, not a model, and any present or future client — Claude Code, Codex CLI, Cursor, or their successors — plugs in without modification.

This report makes three contributions:

1. A reference architecture for agent-operated vulnerability research VMs, in which telemetry, VM control, and network policy are separate MCP planes with distinct trust positions (§3).
2. A network trust ladder — a six-level egress policy engine the agent operates under constraint, in which every escalation must be justified from static evidence and every grant is journaled (§3.4).
3. An evidence-graded evaluation: a benchmark battery in which a solve counts only when corroborated by kernel-level records, with per-lane results for two contemporary models (§5).

2Related work and the integration gap

Every layer of the proposed stack exists today as mature open source; the integration layer does not. Table 1 positions the closest systems against the four properties this report considers essential: agent orchestration of the toolchain, a virtual-machine trust boundary, total telemetry, and network egress control.

Three observations sharpen the gap. First, the closest open system, agentic-malware-analysis, states its limitation in its own documentation: dynamic analysis tools are present but not orchestrated, and the boundary is a container rather than a VM. Second, the closest commercial system, Joe Sandbox AI, demonstrates that agentic reverse engineering works at production quality — closed-source, malware-focused, and resident on the vendor's cloud rather than the operator's lab. Third, the distribution layer has already moved: REMnux ships an official MCP server with OpenCode preconfigured^[6], radare2 ships an official C-native MCP server^[7], and Semgrep ships a first-party one^[8]. The toolchain's "buy, don't build" decision is therefore not aspirational; the remaining work is the three components enumerated in §1.

Two further precedents informed the design. Google's Project Zero lineage from Naptime to Big Sleep established the tool taxonomy — code browser, sandbox runner, debugger, reporter — that the gateway mirrors^[9]. On the evaluation side, verialabs' ctf-agent took first at BSidesSF 2026, solving 52 of 52 challenges with model swarms in isolated containers^[10], and the CyberGym benchmark evaluates agents on 1,507 real-vulnerability instances across 188 open-source projects^[11]; VR-VM's benchmark battery (§5.3) adopts the same graded-difficulty discipline.

3System design

3.1Overview

The appliance is a QEMU/KVM virtual machine derived from REMnux^[12], which already curates roughly two hundred analysis tools as reproducible salt states. A Rust MCP gateway terminates the individual tool servers inside the guest and exposes one streamable-HTTP endpoint^[13], collapsing roughly sixteen tools across three planes — an arrangement that also keeps the client's context window free of hundreds of tool definitions.

  your AI client  (Claude Code · Codex · Cursor · any MCP client)
          │  one streamable-HTTP MCP endpoint
  ┌───────▼─────────────────────────────────────────┐
  │  MCP GATEWAY  — many servers, ~16 tools         │
  └───────┬──────────────┬───────────────┬──────────┘
          │              │               │
    vmctl plane   telemetry plane   policy plane
    (host :8805)  (guest :8802)     (guest :8803)
    exec into guest  query the        AI-controlled
    as analyst       unified          nftables trust
                     timeline         ladder (§3.4)
  ┌───────┴──────────────┴───────────────┴──────────┐
  │  VR-VM  — disposable REMnux analysis machine (QEMU/KVM)  │
  │  tools:   Ghidra · radare2 · Volatility · Frida · …      │
  │  sensors: auditd · Tracee (eBPF) · Suricata · mitmproxy  │
  │  storage: qcow2 snapshot → revert = clean-room repeat    │
  └──────────────────────────────────────────────────────────┘

3.2The three planes

vmctl (host, :8805). The control plane: execute inside the guest as the unprivileged analyst user, upload targets, and drive snapshot/revert. It lives on the host precisely so that nothing inside the guest — including a compromised analysis — can command its own containment.

telemetry (guest, :8802). Read and search over the unified JSONL timeline produced by auditd, the eBPF sensor, the IDS, and the TLS proxy: time-range, process, event-type, and free-text queries, plus packet-capture search. To the author's knowledge this is the novel component; capture-only pipelines exist in several sandboxes, an agent-queryable timeline exists in none of the open systems surveyed.

policy (guest, :8803, root). The dynamic firewall described in §3.4. Runs as root because it programs nftables; accepts pins only through the MCP API, never by hand-editing the ruleset.

3.3Telemetry as evidence, not exhaust

The design treats the deny log and the syscall trace as the primary artifacts of an analysis, on par with decompilation output. Every denied connection, granted pin, and revocation is written to the timeline with the agent's stated justification, so the audit trail is not reconstructed after the fact — it is produced by the experiment itself. This is the substrate that makes the evaluation standard of §5.1 possible.

3.4The network trust ladder

Real targets are not uniformly malware: benign software phones home for updates and license checks, and an analysis that cannot distinguish infrastructure from command-and-control will either stall or leak. The policy engine therefore implements a graduated ladder rather than a binary switch. The target always begins at level 0; the agent escalates by issuing per-process, per-domain, TTL'd pins, each accompanied by a justification that cites the deny-log entry and the decompiled code path that produced the connection attempt.

The safety floor is non-negotiable and kernel-enforced: the management plane and the host are unreachable from the lab network at every level, and the agent's own processes are never gated — the agent is not the subject of the experiment.

3.5Repeatability

Storage is a qcow2 backing chain (base ← clean snapshot ← session). Snapshot and revert are MCP tools rather than operator chores, which makes clean-room repeatability part of the agent's ordinary workflow: an analysis can be restarted from an identical state as many times as the evidence requires.

4Implementation

The build reduces to four pieces; everything else is off-the-shelf open source, inventoried and license-checked in August 2026.

• telemetry-mcp — the query interface over the unified timeline (§3.3). The novel core; approximately 300 lines of FastMCP.
• vmctl-mcp — snapshot, revert, target upload, and target execution over the host-side control plane.
• policy-mcp — the deny-log feed plus AI-issued, TTL'd, per-process and per-domain network pins across the levels of Figure 2.
• provisioning — a reproducible script/salt layer that turns a stock REMnux image into the hardened lab: sensors, MCP servers, the guest CA, nftables, and systemd units.

The operating deployment additionally runs an operator console (WebUI, loopback-only, single-operator by design) and a branching subsystem that dispatches queued investigations onto pooled slot VMs created as overlays of a re-frozen golden image.

5Evaluation

5.1The evidence standard

5.2Verified-solve scoreboard

Ten solves outside the benchmark battery have met the standard to date (Table 2). The set spans classic binary exploitation classes, the two DVWA web lanes, and two integration proofs in which the solve was driven through the operator console rather than a terminal session.

5.3The extended benchmark battery (XB)

The battery grades capability across seven lanes — binary exploitation at three difficulty tiers, cryptography, web, forensics, and reverse engineering — with per-repetition flags and deterministic judges implementing §5.1. Headline results, taken from the durable record (bench/results/xb-history.jsonl):

Three of the seven lanes sit at 3/3 for the stronger model (a fourth, X6, is 2/2), which compresses the battery's ability to track improvement — a calibration flaw the design calls for correcting. The battery is expanding to nine lanes / 24 repetitions (adding a network authentication lane and a cloud metadata-service chain); those lanes have no published results and are excluded here.

5.4Tool-use efficiency

Solve counts alone cannot distinguish an agent that uses the toolchain from one that shells out to everything. Tool-mix telemetry from the traced campaigns: on 2026-08-27 the agent solved the setuid target in 11 steps of a 15-step budget — the identical configuration had exhausted the same budget the previous day — with radare2 carrying 55% of tool calls and raw shell 9%, against a baseline of 0.6% and 57% respectively one week earlier. Dispatch to the kernel-verified open of /flag took under 100 seconds of wall clock (campaign-id and auditd timestamps). The preceding measurement campaign (2026-08-26) recorded a 53% MCP-tool share and opened with the one-call reconnaissance tool. The intended posture — RE tooling first, shell as fallback — is now the measured one.

6Limitations and threat model

The honest list, each with its current resolution: TLS-pinned targets resist the interception proxy (accepted and flagged; optional unpinning via Frida); Windows and macOS targets are out of scope for the present build (the same harness admits a Windows guest in phase 2); the agent operates with effective control of the guest (accepted — the VM itself is the security boundary, and snapshot revert kills persistence); distribution will ship build scripts rather than a disk image, both for licensing and for trust; the eBPF sensor layer requires a KVM host on kernel ≥ 5.10, and nested virtualization is unsupported. The evaluation's own limits are declared in §5.3: three lanes at ceiling, one confounded lane excluded, and one provider-quota gap in the second model's grid.

7Availability and intended use

The lab is operational; the source is being prepared for a public GitHub release. The intended quickstart, so the shape of adoption is on record:

# intended use
1. provision a VM from the build scripts                  (scripts, not images — §6)
2. boot it — the MCP gateway comes up inside the guest
3. point your AI client at one endpoint                   ← the only step that is yours
4. hand it a target; receive an evidence-linked report

The repository link and full operator documentation will appear here on release. The narrative account of the gap analysis in §2 exists as a companion essay, "The AI-Pluggable Vulnerability Research VM Nobody Built" (currently in draft).

§References

1. Model Context Protocol — specification. modelcontextprotocol.io
2. Blazytko, T. — agentic-malware-analysis. github.com/mrphrazer/agentic-malware-analysis
3. Dreadnode — dyana. github.com/dreadnode/dyana
4. CAPEv2 sandbox. github.com/kevoreilly/CAPEv2
5. Joe Security — Joe Sandbox AI. joesecurity.org
6. REMnux project — remnux-mcp-server; see also Zeltser, "AI Malware Analysis with REMnux." github.com/REMnux/remnux-mcp-server · zeltser.com
7. radare2 — official radare2-mcp. github.com/radareorg/radare2-mcp
8. Semgrep — first-party MCP server. github.com/semgrep/mcp
9. Google Project Zero — "From Naptime to Big Sleep" (2024). projectzero.google
10. verialabs — ctf-agent (first place, BSidesSF 2026: 52/52). github.com/verialabs/ctf-agent
11. Wang, Z. et al. (UC Berkeley) — CyberGym: Evaluating AI Agents' Real-World Cybersecurity Capabilities at Scale (2025). arXiv:2506.02548
12. REMnux — a Linux toolkit for malware analysis. remnux.org
13. Parkkola, M. — mcp-gateway (Rust). github.com/MikkoParkkola/mcp-gateway
14. Component inventory (verified August 2026): GhidraMCP, gdb-mcp, ya-frida-mcp, pd-tools-mcp, Volatility-MCP-Server, inetsim. Links collected in the project architecture document.

Internal records: ARCHITECTURE.md (design, barriers, phases) · AGENTS.md (operational contract, scoreboard) · docs/DECISIONS.md (#26–#40) · bench/results/xb-history.jsonl (battery record) · campaign traces 20260826_183436-e0108d and 20260827_194930-ecd236. All benchmark figures in §5 were re-read from these records at publication time, not recalled.