Source-linked AI summary
Tracekit Box: Running AI Agents in Micro-VMs Where Every Way Out Is Decided and Signed
Bravish Ghosh
TL;DR
Coding agents need network access, credentials, and write access to do their jobs, but those same resources can expose data, credentials, or systems to harm. Tracekit Box puts agents in a no-network-card Firecracker micro-VM and routes exits through host doors where a signer decides and records actions. All 13 checks of TestBox passed in 28.47 s for the test function.
Problem
Coding agents need network access, credentials, and write access to do their jobs, but those same resources can expose data, credentials, or systems to harm.
Source: §1 · p. 2Method
Tracekit Box puts agents in a no-network-card Firecracker micro-VM and routes exits through host doors where a signer decides and records actions.
Source: §1 · p. 2, §4.2 · p. 4Results
All 13 checks of TestBox passed in 28.47 s for the test function.
Source: §7.1 · p. 12Takeaways & Limitations
With no other exit from the VM, a host door cannot be bypassed from inside by the agent.
Source: §8.2 · p. 17Box decides which hosts the agent may reach, not what it sends to them.
Source: §8.1 · p. 16
Abstract
from arXiv · showhide
AI agents now install packages, call model APIs with their operators' keys and change code in repositories that deploy to production. The network, credentials and write access they need are also how they can leak data, steal a key or change a system nobody approved. Sandboxes contain an agent but leave little evidence of what crossed their boundary; tracing records what happened but contains nothing. We present Tracekit Box, an open-source system (MIT, v0) that does both. Each job runs in its own Firecracker micro-VM with no network card. The only ways out are doors on the host, served over vsock: commands, outbound connections, secrets, model calls and the workspace patch. At every door a Tracekit signer the agent cannot reach decides what passes and signs it into one run per box. Names are resolved on the host; private and cloud-metadata addresses are always refused; secrets never enter the VM, which sees placeholders the host proxy swaps for real values only in one header for bound hosts; and changes come back as a patch applied file by file after the signer decides each file. Box fails closed, and each job ends as a .tkb bundle anyone can verify offline. All 13 end-to-end checks pass on a real KVM runner (the test that runs them takes 28.5 s, including image pull and boot); 15 fuzz targets on the trust boundary produced nine findings, all fixed; and the demo run's 102 signed records verify. Box does not yet run Firecracker's jailer, needs a co-located signer, and records processes inside the VM only where they cross a door.
1 Introduction
Coding agents need network access, credentials, and write access that can also enable data leaks, credential theft, and unreviewed changes. Tracekit Box combines containment with signed decisions by placing host-controlled doors at every exit.
1 Introduction
- For each boxed job, commands, outbound connections, and checkout writes are decided before they happen and recorded for offline verification.The stated guarantee applies to commands started from the host and files written to the checkout by tkbox apply.Source: §1 · p. 2
- Tracekit Box places agents in a micro-VM whose only exits are host-served doors, with a signer deciding what passes.The mediated doors cover commands, network, secrets, model calls, the workspace patch, and stop.Source: §1 · p. 2
- Outbound names are resolved on the host, and private, link-local, metadata, and host addresses are refused.SNI is bound to the requested host, and off-allowlist hosts require human approval.Source: §1 · p. 2
- The VM holds secret placeholders; the host proxy swaps in real values only in one header for exact bound hosts.The proxy also blocks leaks and redacts responses on connections it reads.Source: §1 · p. 2
- Every file is decided before writing; sensitive files require explicit consent, and git apply never runs on the checkout.Git must read the patch exactly as Box does.Source: §1 · p. 2
- Tracekit Box extends Tracekit’s signer and evidence format with an environment where the agent has no other way out.Tracekit’s signer, evidence format, and verifier are described in [5].Source: §1 · p. 2
2 Background and related work
Prior tools separately provide isolation, network control, credential brokering, or tamper-evident records. Box’s contribution is combining these capabilities so decisions are recorded for the doors that form the only exits.
Isolation
- Firecracker provides a hardware-virtualisation boundary with a small device model, and its vsock lets the host choose the guest’s channels.Box uses it to give each job its own VM while starting fast enough for per-job isolation.Source: §2 · p. 3
Agent sandboxes
- Existing agent sandboxes control what agents may reach, but, as far as the authors know, do not combine verifiable decisions, host-held credentials, and per-file decided writes.Examples include E2B, microsandbox, sandbox-runtime, and NVIDIA OpenShell.Source: §2 · p. 3
Egress control
- Domain allowlists face DNS-channel, private-address, rebinding, and domain-fronting weaknesses; Box addresses them at the host door.The authors treat the guest as the attacker.Source: §2 · p. 3
Credential brokering
- Box keeps credentials out of the VM by using placeholders, adding real values in one header for exact hosts, and blocking or redacting them on inspected traffic.Credential helpers, workload identity, and authentication-header proxies are established approaches that Box applies to agents.Source: §2 · p. 3
Tamper-evident records of agent actions
- Tracekit records signed tool calls in offline-verifiable bundles, but cannot record actions that bypass its signer [5]; Box routes exits through doors that ask the signer.Table 1 frames the novelty as the combination: the record is complete for the doors, and the doors are the only ways out.Source: §2 · p. 3
3 Threat model
Box assumes the agent controls everything inside the VM while the host, signer, and connection approver remain trusted. Within stated limits, its guarantees require signer decisions at controlled doors and preserve those decisions in a verifiable run record.
3.1 Trust domains
- The attacker controls the agent, its processes, the guest kernel’s view, and guest-sent bytes; the host, signer, and connection approver are trusted.The agent is assumed hostile, including when prompt-injected or following instructions from a file it read.Source: §3.1 · p. 3
3.2 What the attacker wants, and what stops it
- Table 3 maps the attacker’s goals to the mechanisms intended to stand against them.The passage points to section 4 for the mechanism details.Source: §3.2 · p. 3
3.3 What Box guarantees
- Commands started through tkbox exec are decided before launch and recorded; outbound connections are decided before dialing and allowed, host-approved, or refused.Outcomes that cannot be recorded are counted in a tkbox.gap record; refusals beyond 20 per second per box are summarized.Source: §3.3 · p. 3
- A bound secret is sent only to its bound hosts and header, with each use recorded by name and host rather than value.Source: §3.3 · p. 3
- tkbox apply writes only signer-allowed files, file by file; the bundle is the signer’s run record, and verification detects changes to it.Source: §3.3 · p. 3
- The record does not cover processes inside the VM individually, and Box decides which hosts may be contacted—not what an allowed host receives.A host that fetches on the agent’s behalf can relay workspace data further.Source: §3.3 · p. 4
- Assurance is bounded: uninspected HTTPS exposes only connection metadata, a same-user dev signer can be reached by another same-user process, and v0 runs without Firecracker’s jailer.Root and the operator are trusted; stronger assurance needs a signer under its own user and a witness on another host.Source: §3.3 · p. 4
4 Design
A job moves from box creation and command execution through mediated network, secret, model-call, and patch doors to export. The design uses a networkless Firecracker VM and host-side decisions to control what crosses those doors.
4.1 A job’s life
- The workflow builds the box and registers a Tracekit run, executes commands, routes connections and secret or model use through the proxy, then saves, applies, and exports the patch.The exported bundle and trust file are written when the run closes.Source: §4.1 · p. 4
4.2 The box
- The Firecracker VM has no network interface; vsock is its only host channel, while workspace changes are isolated in a writable upper layer.Writes outside the workspace live in a temporary overlay and vanish with the box; the guest is treated as untrusted.Source: §4.2 · p. 4
4.3 Commands
- Host-started commands require signer approval, and the recorded command is shaped to match execution while restricting environment changes and deciding known stdin.Known stdin up to 1 MiB is decided with the command; streamed stdin is recorded by digest at completion.Source: §4.3 · pp. 4–5
4.4 Network
- The host proxy resolves names once and dials the checked address, refuses private and metadata ranges, and requires signer approval plus human approval for off-list hosts.TLS ClientHello names must match the requested host; non-TLS traffic is allowed only to a port-specific entry.Source: §4.4 · p. 6, Figure 4 · p. 6
4.5 Secrets
- The VM sees a placeholder for each secret; the proxy substitutes its value only in the bound header to the exact bound host and blocks or redacts exposed forms elsewhere.Before startup, Box also refuses workspace files, environment values, or command lines containing a secret value.Source: §4.5 · pp. 6–7, Figure 5 · p. 7
4.6 Model calls
- Model API access uses the ordinary SDK with a placeholder key, while the proxy makes a WebFetch decision and records each inspected model request.A secret’s host alone does not designate it as a model host.Source: §4.6 · p. 7
4.7 Changes
- Changes leave as a git-format workspace patch, and apply writes files only after signer approval through checks that align the patch read by Box with the bytes written.The pipeline rechecks files after decisions and writes each file atomically without following symlinked parents.Source: §4.7 · p. 7, Figure 6 · p. 8
4.8 Stop and containment
- A box stops on timeout, operator request, signer containment, or fail-closed error; egress closes as stopping begins, and a hold pauses the VM while quarantine kills it.The daemon polls containment state while boxes run.Source: §4.8 · pp. 7–8
5 Recording the doors
Box records each controlled door through an unmodified Tracekit signer, keeping one run per box and exporting an offline-verifiable bundle. Its guarantees depend on what the signer can be trusted to attest.
5 Recording the doors
- Box uses Tracekit’s public RPC, evidence format, and verifier rather than its own signer or log format, mapping controlled doors to signed decisions and observations.Commands, connections, approvals, and writes use Tracekit tool names so standard policy packs apply.Source: §5 · p. 8, §5.2 · p. 8, Table 7 · p. 9
5.1 One run per box
- Each box has one run that stays open through stop so later per-file Write decisions join the commands and connections that produced the patch.The run token is held only in daemon memory; after a daemon crash, the box cannot be applied or exported.Source: §5.1 · p. 8
5.2 From doors to records
- Decisions precede actions and receive completions, while observations are signed without being decided; bundles identify observations as trusted or guest-derived and preserve their integrity and run position.Known command stdin is decided with the command; non-TLS connections are recorded as tcp://host:port because Box cannot know their protocol.Source: §5.2 · p. 8
5.3 Failing closed
- Box makes losses of records impossible or visible, preserving must-keep observations such as secret uses, model calls, approval outcomes, and containment.Rate-limited connection refusals still leave a count.Source: §5.3 · pp. 8–9, Table 8 · p. 10
5.4 Export and verification
- Export closes the run and produces a bundle that offline verification checks for signatures, the hash chain, and inclusion of the first and last records in the checkpointed Merkle tree.The demo run’s verifier report is shown in Figure 8.Source: §5.4 · pp. 9–10, Figure 7 · p. 9
5.5 Assurance
- A verified bundle shows that records were not changed after signing, but all bundles reported here use dev signers and do not establish whose machine produced them.The assurance of a bundle depends on who could reach the signer’s key.Source: §5.5 · p. 10
6 Implementation
The implementation centers on a Go daemon and an egress proxy, with interfaces that support both isolated package tests and real KVM end-to-end runs. CLI, MCP, GitHub Action, and Python SDK access all use the same daemon doors.
6 Implementation
- The Go repository includes the daemon, egress proxy, guest agent, SDK, and GitHub Action, with code and tests concentrated at the daemon and egress boundaries.The egress package has about as many test lines as code lines; test fakes allow package tests without a VM, registry, or signer.Source: §6 · p. 10, §6.1 · p. 10
6.1 Structure
- The daemon pins and verifies Firecracker and kernel assets, while the guest runs as PID 1 with a read-only root overlay and bounded, strictly parsed host messages.The daemon keeps per-box state and secrets and run tokens are not stored in files.Source: §6.1 · p. 10
6.2 Interfaces
- CLI, MCP, GitHub Action, and Python SDK interfaces share the daemon’s doors; MCP calls can narrow operator configuration, while people retain apply and export control.The GitHub Action uploads the bundle, trust file, and patch; Verified Runs are listed only after bundle verification.Source: §6.2 · pp. 10–12
7 Evaluation
The evaluation tests Box’s doors on real KVM hardware, examines a signed demo run, fuzzes trust-boundary parsers, and reports independent review. The checks and fuzzing support the implementation’s stated behavior, with bounded coverage and deployment scope.
7 Evaluation
- The evaluation does not benchmark boot latency, exec overhead, proxy throughput, or per-connection signer cost, and it uses scripted attacks rather than a capable agent searching for escape paths.The reported deployments use dev signers, and the scale is one host, one daemon, and a handful of boxes.Source: §7 · p. 12
7.1 End to end on KVM
- 13 end-to-end checks passed in 28.47 s, including a fail-closed test that refuses to start without a signer; the test function’s time includes deliberate waits and package installation.The checks exercise representative cases of the guarantees, not every address, secret encoding, or hostile patch form.Source: §7.1 · pp. 12–13, Table 12 · p. 13, Figure 11 · p. 14
7.2 A real box and its record
- The demo bundle contains 102 signed records and verifies with Tracekit 1.4.2; its record includes a metadata-address refusal, an unapproved held host, and one secret use without the token value.The metadata address was refused before reaching the signer; the held host also appears as refused after approval timed out.Source: §7.2 · pp. 13–14, Table 13 · p. 14
7.3 Fuzzing the trust boundary
- Fuzzing 15 trust-boundary targets produced nine findings, all fixed, including six in the egress proxy.The findings included paths that could have exposed a swapped secret through request routing or response redaction.Source: §7.3 · p. 14
7.4 Review
- Independent review rounds and verification passes found issues where hostile guests, upstream hosts, or patches could make a door act differently from its record.The README counts three independent review rounds plus the fuzzing campaign.Source: §7.4 · p. 14
8 Discussion
Box’s limits include incomplete visibility into guest processes and what allowed hosts receive, plus evaluation gaps; its host-side doors trade that scope for records the guest cannot bypass. Future work targets stronger host isolation, remote assurance, performance measurement, guest sensing, and broader deployment.
8.1 Limits
- Box records door crossings, not guest processes: a script running many commands may leave only one Bash decision and the resulting door activity.Box v0 has no process sensor in the guest.Source: §8.1 · pp. 14, 16
- An allowed host can relay workspace data onward, so Box decides which hosts the agent reaches, not what those hosts do with its traffic.The stated practical mitigation is a smaller allowlist.Source: §8.1 · p. 16
- With default inspect: bound, the proxy reads only connections to bound-secret hosts and plain HTTP; other HTTPS traffic exposes host, port, and server name.inspect: all reads every allowed HTTPS host but breaks clients that pin certificates.Source: §8.1 · pp. 16–17
- Other v0 boundaries include no rollback after a partial patch write, possible cloud-host public-address access, same-user daemon access, and delayed containment.The delay is within 2 s in a box’s first minute and about 15 s afterward; inspected connections also reject encrypted ClientHello and support HTTP/1.1 only, while changes outside /workspace are lost at stop.Source: §8.1 · p. 17
- The evaluation does not establish performance beyond suite wall-clock times, resistance to a capable agent trying to escape, or deployment above dev assurance.Source: §8.1 · p. 17
8.2 Why doors, and not a smarter guest
- Host-side doors cannot be bypassed from inside a VM with no network card, and the host—not the guest—records what crossed them.The trade-off is that Box sees only door-crossing activity; the authors argue this covers actions that cause harm outside the box.Source: §8.2 · pp. 17–18
8.3 Future work
- The most important missing defence-in-depth measure is running Firecracker under its jailer.Source: §8.3 · p. 18
- The stated future work includes remote signing and witnesses, adversarial-agent and performance studies, guest-process reconciliation, deployment options, and more verified runs.Source: §8.3 · p. 18
9 Conclusion
Tracekit Box puts an agent in a Firecracker micro-VM whose exits are host-mediated doors, with a signer deciding and recording actions at each door. Its checks and fuzzing passed as reported, while the paper states limits on process visibility, host content, jailer use, and assurance.
- Box joins containment and signed recording: commands, connections, and file writes are decided before they happen, with each box’s run verifiable offline.Source: §9 · p. 18
- Secrets stay on the host and are used only in a bound header for exact hosts; workspace changes return as a patch applied file by file.Source: §9 · p. 18
- The v0 implementation passes its end-to-end checks on real KVM hardware, and fuzzing and review findings are fixed.Source: §9 · p. 18
- The stated limits include no guest-process recording, no judgment of what an allowed host receives, no jailer, and dev-assurance bundles.Source: §9 · p. 18
A Quick look
The quick-look sequence installs and starts a dev signer, launches a box, exercises package access, egress approval, and secret handling, then reviews, applies, exports, and verifies the run.
- On a Linux host with KVM and Tracekit 1.4.2, install the signer, initialize and start it, then launch the box with an image, allowlist, and workspace.Source: A Quick look · p. 19
- The example installs requests through the pypi preset, holds an example.com request for approval, and exposes a GH secret placeholder rather than its token.Source: A Quick look · p. 19
- After stopping the job, review its diff, apply the patch file by file, export the bundle, and verify its integrity.Source: A Quick look · p. 19
B Example configuration
The example configuration sets an image, name, workspace, and host allowlist, binds API secrets to exact hosts and headers, and configures resource, time, and inspection limits.
- The configuration names a Python image and service-agent job, copies the workspace into /workspace, and allows pypi, GitHub, and Anthropic hosts.Source: B Example configuration · p. 19
- Anthropic and GitHub credentials come from host environment variables and are bound to named hosts and request headers; ordinary environment settings remain visible in the box and are recorded.Source: B Example configuration · p. 19
- The example sets 2 CPUs, 4 GiB memory, an 8 GiB workspace disk, one-hour box lifetime, 30-minute command timeout, and bound inspection.The comment says inspect: all reads every allowed HTTPS host and refuses unlisted hosts at once.Source: B Example configuration · p. 19
C Default limits
The selected-defaults table points to the full list of defaults in the documentation; the glossary defines Box’s doors, decisions, secrets, approvals, records and assurance.
C Default limits
- Table 19 lists selected defaults; the full list and printed messages are in docs/limits.md.Source: Table 19 · p. 20
D Glossary
- A Box is one Firecracker micro-VM per agent job; a door is a host-served channel whose passage the signer decides.Source: D Glossary · p. 20
- A decision evaluates a tool call as allow, flag, ask or deny, while an observation is a signed record the signer does not decide.Source: D Glossary · p. 20
- The VM sees a placeholder instead of a secret; the proxy swaps in the real value only in one header for its bound hosts.Source: D Glossary · p. 20
- Approval is a host user's allow or rejection of an off-allowlist connection; a gap observation counts records Box could not keep.Source: D Glossary · p. 20
- A bundle contains a box's run, checkpoint and keys for offline verification; assurance identifies who could have signed records, such as a same-user dev signer.Source: D Glossary · p. 20