Technical overview

PV3: a runtime isolation layer for untrusted code on developer machines.

PV3 runs untrusted repositories in a disposable microVM. Host credential paths — SSH keys, environment files, cloud configuration, and wallet signing keys — are not mounted into the guest. Filesystem access, process spawning, and outbound network calls are mediated by policy. After each run, PV3 returns a structured threat report.

This document describes the threat model PV3 addresses, its architecture, its observable capabilities, and how it differs from existing tooling.

§ 1 — Threat model

Recent breaches originated on developer hardware.

Each of the following incidents began with a developer machine — a cloned repository, an installed dependency, or a malicious update — and propagated to production infrastructure or custodied funds. None originated from a server-side exploit or a smart-contract bug.

Incident	Loss	Initial vector
Bybit	$1.5B	Developer machine compromised
Ronin Bridge	$625M	Developer social engineering
3CX	Undisclosed	Supply chain → credential theft
Harmony Bridge	$100M	Compromised developer keys
Atomic Wallet	$100M	Supply chain attack
Ledger Connect	$600K	npm package hijack

1.1 Attack surface

The standard developer workflow assumes the cloned repository, the package manager, and the developer's host filesystem share a single trust boundary. They do not. A package's postinstall hook executes with the same privileges as the developer's shell.

Figure 1. Any installed package can read host credentials and exfiltrate them. No isolation exists between the cloned repo and the developer's keys, environment files, or browser data.

Any read of the paths shown is sufficient to grant an attacker a foothold in production infrastructure or to drain custodied funds. Exfiltration over outbound HTTPS is uncontested by default.

§ 2 — Architecture

PV3 mediates the boundary between host and guest.

Figure 2. PV3 clones the target repo into a disposable microVM. Host credential paths are never mounted into the guest. Filesystem, process-spawn, and network syscalls are mediated by policy. A telemetry stream returns to the host as a structured threat report. The microVM is destroyed at the end of the run.

When a developer invokes pv3 run <repo>:

PV3 provisions a disposable microVM with a minimal guest image.
The target repository is cloned into the guest. Host credential paths are not mounted.
A guest agent records every filesystem, process-spawn, and network syscall.
Outbound network calls are subject to a default-deny policy with optional allowlists.
At exit, the guest emits a structured event stream. The host renders this as a threat report.
The microVM and its filesystem are destroyed.

The guest cannot observe the host filesystem. It cannot inspect host environment variables. It cannot reach host-bound network sockets.

§ 3 — Capabilities

What is blocked, what is monitored, what is logged.

The following matrix describes how PV3 treats each class of guest behavior. deny indicates the syscall is rejected at the mediation layer; policy indicates configurable rule evaluation. Every classified event is captured in the threat report.

Behavior	Blocked	Monitored	Logged
Read host filesystem outside repo	deny	●	●
Read ~/.ssh, keychains, .env	deny	●	●
Read ~/.aws, ~/.gcp, ~/.azure	deny	●	●
Outbound network (default)	deny	●	●
Outbound to allowlist	—	●	●
Process spawn inside guest	—	●	●
open / exec / connect syscalls	policy	●	●

Figure 3. Capability matrix. deny means the syscall is rejected at the mediation layer. policy means subject to configurable rules. ● means the event is captured in the threat report.

§ 4 — Reporting

Each run emits a structured threat report.

PV3 classifies each run into one of three categories. The full event stream is also available as JSON for ingestion by SIEM systems and team-level dashboards.

SAFE

0 sensitive paths accessed
0 unexpected outbound connections
duration: 4.2s

WARNING

attempted to read ~/.ssh/id_rsa, ~/.aws/credentials → denied
1 outbound connection to registry.npmjs.org (allowlisted)
duration: 8.1s

MALICIOUS

14 sensitive read attempts → denied
hidden child process: /tmp/.cache/.x → terminated
egress to 185.xx.xx.xx:443 → denied
execution terminated

§ 5 — Comparison

Adjacent tools occupy different points in the trust model.

Tool	Isolated execution	Egress control	Syscall monitor	Threat report
Docker / containers	●	○	○	○
Antivirus	○	○	◐	◐
GitHub Dependabot	○	○	○	◐
Socket.dev / Snyk	○	○	○	◐
Firejail / Bubblewrap	●	◐	◐	○
PV3	●	●	●	●

Figure 4. Comparison across four capability axes. ● full, ◐ partial, ○ absent. Static scanners (Dependabot, Socket.dev) classify packages before execution. PV3 observes packages during execution.

Container runtimes isolate processes but do not constrain network egress or generate behavioral reports. Static analyzers (Dependabot, Socket.dev) inspect packages before execution; they cannot detect novel malicious behavior that activates only at runtime. Sandboxes such as Firejail and Bubblewrap require manual configuration per project and do not produce structured threat reports.

PV3 occupies the runtime-observation slot none of these tools fill. Static scanners and PV3 are complementary: a static scanner classifies packages by reputation, while PV3 observes packages by behavior.

§ 6 — Deployment modes

Local today. Cloud and API forthcoming.

6.1 Local

The microVM runs on the developer's machine. The full event stream stays on the host. Operates offline. Available today.

6.2 Cloud & API

Forthcoming

Ephemeral microVMs provisioned via API. Suited for CI/CD pipelines, agent platforms, and organization-wide policy enforcement. Provides a shared dashboard and a complete audit trail.

§ 7 — Install

One command. Every repo. Isolated.

PV3 installs in under a minute. The CLI shim runs on macOS and Linux and provisions a microVM on first invocation.

Get PV3curl -L pv3.dev/install.sh | bash

Book a demo