Coding Agents in KVM: Practical Containment and User Control with Limited Resources

Coding Agents in KVM: Practical Containment and User Control with Limited Resources

arXiv:2611.12823v1 [cs.SE] 9 Nov 2026

Yutaka Nagashima Institute of Computer Science, The Czech Academy of Sciences Abstract—Coding agents often need broad authority for productive development work, but granting that authority can expose users’ data and infrastructure. Off-the-shelf cloud workspaces can help contain agent activity, but reliance on provider-specific platforms can lead to vendor lock-in and reduced user control. Researchers and engineers must therefore balance agent autonomy, enforced containment, and user control within available financial, computational, and human resources. We analyze these trade-offs and present KVM-Agent, an open-source implementation that automates most setup and provisioning steps. It gives agents broad authority inside replaceable Ubuntu VMs while keeping host administration outside those VMs and supporting multiple coding-agent applications, model services, and remote job delegation. The approach retains familiar workflows and user choice at the cost of VM resources, maintenance, and residual risks from secrets accessible inside the VMs and permitted network access. Index Terms—AI engineering, coding agents, virtual machines, user control, deployment

I. I NTRODUCTION In an ideal world, everyone would have access to coding agents that are safe, affordable, open-source, easy to use, and efficient, without losing control over their data and computing infrastructure. In practice, these goals involve trade-offs. Broad permissions enable development work but increase the potential damage from mistakes or compromise. Cloud tools and model services can reduce local operational demands and offer scalability, but introduce external dependencies. Familiar development environments support existing tools and workflows, but deploying and maintaining them on user-controlled infrastructure requires computing resources and human effort. An agent may need to install a compiler, build an unfamiliar repository, or repair dependencies. Coding agents perform such actions through an agent–computer interface [1], exercising authority over the execution environment. Mistakes, malicious dependencies, and indirect prompt injection [2] can redirect that authority. Running these operations in an ordinary workstation account exposes the files and sessions accessible to that account; requiring human approval for every command makes progress depend on repeated user intervention. At the same time, a deployment that demands extensive security administration, a particular commercial service, or dedicated new hardware may be impractical for a small research group with tight resource constraints. In this paper, we introduce KVM-Agent to address the following question: How can researchers and engineers give coding agents the authority needed for development work

while preserving their choice of tools and infrastructure and keeping operational costs manageable? KVM-Agent is an operational wrapper around existing coding-agent applications. It provisions a graphical Ubuntu virtual machine (VM). We call the operating system (OS) inside the VM the guest and the OS running the VM the host. Agents use an account with passwordless sudo inside the guest. The user retains host virtualization controls and a dedicated recovery key. The design also supports a choice of coding-agent applications and large language model (LLM) service providers, remote operation, and optional job delegation to another machine. Our contributions are an analysis of these trade-offs in deploying coding agents under resource constraints (Section II) and an open-source reference implementation of the resulting design (Section III). The implementation automates most setup and provisioning steps, requiring manual input where user-specific choices, credentials, or trust decisions are needed. II. D ESIGN G OALS AND T RADE - OFFS We analyze three trade-offs that guide the design of KVMAgent: agent autonomy versus containment, provider reliance versus user sovereignty, and functionality versus operational cost. A. Autonomy versus containment We aim to grant broad authority within a replaceable project-specific environment while limiting access to host resources that may contain administrative credentials and other data unrelated to the project. Passwordless sudo inside the VM permits system-level installation and repair; we accept that guest compromise exposes the project’s code, data, sessions, and supplied credentials. To limit the blast radius, our intended deployment assigns one or more VMs exclusively to each project, although the implementation does not enforce this convention. This trade-off suits research projects where source-code confidentiality is not a primary requirement. Convenient interaction creates additional channels: host–guest clipboard sharing, exported files, remote-editor forwarding, and worker access all carry data or authority across a boundary. These channels can improve convenience while increasing exposure. The design therefore distinguishes restrictions enforced outside the guest from guest-local defaults and explicit user practices. These considerations include network reachability, the placement of credentials,

TABLE I I SOLATION ALTERNATIVES ON L INUX ; THE SELECTED APPROACH IS MARKED . B OUNDARY AND AGENT AUTHORITY ARE SEPARATE DIMENSIONS , NOT SECURITY RANKINGS . D ESKTOP CONTAINER PRODUCTS MAY ADD A VM; D OCKER S ANDBOXES IS A SEPARATE MICROVM- BASED PRODUCT.

Choice

Isolation boundary

Agent authority

Practical advantages

Costs and limitations

Dedicated bare-metal machine

Separate machine; no trusted workload on the agent’s OS.

Entire Linux OS, including root and local devices.

Native performance/device access; no guest-to-host escape; hardware reuse.

Dedicated Linux account

UID/GID and permissions; shared kernel.

Account permissions; no host sudo.

Minimal setup; native tools/filesystem; no guest OS.

Docker containers

Namespaces, seccomp, resource controls; shared kernel.

Container tooling; lightweight process environments.

Podman containers

Similar kernel boundary to Docker.

KVM/QEMU VM (Our choice)

Separate kernel/virtual hardware; trusts host and hypervisor.

Configured user, capabilities, mounts; rootful or rootless. Container root runs with reduced capabilities by default. Configured user, capabilities, mounts; rootful or rootless. Guest root/sudo; host administration stays with the user.

Whole-machine allocation; external recovery. Supplied secrets and network access remain exposed. Shared kernel/resources; readable files exposed. System changes need trusted administration. Privileged daemon/socket access, mounts, and capabilities can expose the host. Rootless still shares its kernel.

output review, and user control over external actions, as well as the choice of isolation mechanism. B. Provider reliance versus user sovereignty We aim to help users retain sovereignty: their practical ability to choose and administer the execution infrastructure, coding-agent application, LLM service, and data destinations. The open-source virtualization stack can run on user-controlled hardware, and the guest accommodates both proprietary applications and open-source alternatives. Open-weight inference is an option, not a requirement or a guarantee of equivalent capability. Using a hosted LLM service can reduce local compute and maintenance requirements, but sends prompts and context to the provider and may incur service charges. Running a model locally places compute and maintenance demands on the user; limited hardware may constrain model choice and thereby affect task quality. Supporting several applications preserves choice but can increase maintenance effort, particularly when their software dependencies or configuration requirements differ. C. Functionality versus operational cost We aim to keep setup and daily operation manageable while supporting standard development tools, remote access, and worker delegation. These functions impose different costs: a full Ubuntu guest requires computing resources and software maintenance, while delegation adds machines and access permissions to manage. The design accepts these costs to accommodate project-specific software and use computing capacity available across existing machines.

Daemonless CLI; per-user operation; Open Container Initiative (OCI) compatibility. Full OS/desktop; existing tools/installers; disposable disk.

Rootless modes in both engines add networking, UID-mapping, and resource-control constraints. Boot, RAM, maintenance, and device/console attack surface; separate egress policy needed.

To limit administrative effort, repetitive setup and provisioning steps should be automated, and procedures for operation and recovery should be explicit. Manual input is needed for user-specific configuration, authentication, and trust decisions. D. Comparing deployment approaches Table I compares alternatives against the preceding goals. Dedicated bare metal removes the guest-to-host escape path and avoids virtualization overhead, but recovery must be performed outside the compromised OS. It remains a credible choice when spare hardware is available, although physical separation does not restrict network actions or protect supplied credentials. A dedicated Linux account runs agents under a separate user identity, with file access governed by Unix permissions [3]. It shares the host kernel; withholding sudo limits autonomous system-level installation and repair, while granting unrestricted sudo defeats account-based separation. Containers add namespaces and resource controls while sharing the host kernel [4], [5]. Docker and Podman both support rootless operation; Podman’s normal CLI is daemonless [6], [7]. We select KVM/QEMU primarily to address autonomy versus containment (Section II-A). KVM [8] provides hardwareassisted virtualization in the Linux kernel, QEMU [9] supplies the virtual hardware, and libvirt [10] manages VM configuration, lifecycle, storage, and networking. Agents can administer a full development OS inside the guest, while users retain host administration, recovery, and resource controls outside it. Compared with dedicating a physical machine to each project, separate VMs let users share hardware across projects

and switch between project environments. The trusted host retains control over resource allocation and replacement of compromised VMs. Host-managed networking can keep physicalnetwork credentials, such as Wi-Fi passwords, outside the VMs. These benefits come at the cost of virtualization overhead and maintenance of the host software stack. The open-source virtualization stack also supports user sovereignty (Section II-B) by keeping the execution environment independent of a particular coding-agent application or model provider. For functionality versus operational cost (Section II-C), the full guest OS accommodates existing development tools, while our setup automation and recovery procedures aim to keep deployment and administration manageable on available hardware. III. A RCHITECTURE AND R EFERENCE I MPLEMENTATION Our ready-to-use reference implementation runs on x86-64 Ubuntu 24.04 or 26.04 hosts and provisions Ubuntu 26.04 guests. Fig. 1 illustrates the architecture, while Fig. 2 shows a scenario involving manager-worker deployment. Source code and setup instructions are available at https://github.com/yut akang/agent-vm [11]. A. Autonomy versus containment 1) Threat assumptions and risk coverage: For the autonomy goal (Section II-A), the VM boundary separates guest authority from host OS resources and unrelated files and credentials. We assume arbitrary guest commands, including as root; guest projects, sessions, and supplied credentials are exposed. The user, physical machine, firmware, host kernel, KVM, QEMU, libvirt, and administration tools form the trusted foundation. OpenAI and Anthropic provide OS-enforced sandboxes whose coverage depends on the application, configuration, and integration paths [12]–[14]. For host containment, we rely on KVM/QEMU rather than these application-specific sandboxes, keeping the isolation mechanism independent of the chosen coding-agent application (Section II-B). We retain Internet access by default so that agents can obtain software, dependencies, and data. By default, the guest firewall restricts access to local devices and services by blocking private and link-local IP address ranges. An agent with root access inside the guest can change or disable these rules. Safeguards supplied by model providers and developers of coding-agent applications can provide complementary checks on agent actions. Network restrictions intended to survive full guest compromise require enforcement outside the guest, with policies adapted to the deployment’s network topology and the services agents need to access. Users can configure hostenforced egress policies or disable guest networking from the host when the task permits. Table II summarizes threat scenarios, corresponding controls and user practices, and residual exposure. While virtualization exploits and side channels remain residual risks, we omit host-directory shares, host container sockets, and physical-device passthrough to limit paths to host authority [15].

2) Interaction and external authority: As discussed, we assume that guest VMs may be fully compromised; however, agents still need access to online services, including paid services. We therefore separate guest service access from account administration and recovery. GitHub, OpenAI, and Anthropic account passwords, passkeys, recovery secrets, and administrative browser sessions stay on the trusted host or remote controller (Fig. 2). Where supported, cross-device authorization grants guest service access while users sign in on a trusted device; Codex requires enabling device-code authentication [16]–[18]. The guest nevertheless receives access/session tokens, possibly refresh tokens, or task API keys; an attacker with root access inside the guest can steal and use them. Where supported, guests should receive narrowly scoped, revocable task credentials with short lifetimes. For OpenAI and Anthropic services, financial exposure can be reduced through subscription-based access without paid overages, or API access subject to provider-enforced spending caps where available. Budget alerts alone do not stop usage, and cap enforcement varies by product and plan [19]– [21]. Users administer billing, permissions, and usage limits from the trusted device; guest credentials must not authorize changes to these settings. Under the one-project-per-VM convention, a GitHub finegrained token can be scoped to the project’s repositories and required permissions, with an expiry [22]. Branch protection and human review provide additional controls. Clipboard sharing supports a common workflow for transferring provider login URLs to the trusted browser, but can also expose host clipboard contents to the guest. In our experience, this convenience justifies retaining clipboard sharing. B. Provider reliance versus user sovereignty For the sovereignty goal (Section II-B), provisioning the execution environment independently of the coding-agent application preserves application and provider choice. By default, setup installs Codex, Claude Code, OpenCode, Aider, GitHub CLI, and Ollama. Some services reserve particular features for paid plans, but preinstalled alternatives make it easier to switch applications or providers and reduce dependence on any single vendor. For users with sufficient computing resources, Ollama enables model inference inside the guest, keeping inference inputs local and avoiding reliance on external LLM services. The reference implementation supports CPU inference without GPU passthrough. Using a hosted model instead shifts computation elsewhere and sends the configured project context to that service. C. Functionality versus operational cost To address the operational goal (Section II-C), KVMAgent automates most setup and provisioning steps and provides tools for recovery, remote access, and running jobs on worker VMs. Manual input remains necessary for user-specific choices, credentials, and trust decisions.

Trusted Ubuntu host Trusted browser / account control GitHub, OpenAI, Anthropic Long-term critical credentials and administrative sessions stay here User: host sudo / libvirt authority Setup / recovery script virt-manager

Per-VM recovery private key

Login URL

Disposable Ubuntu guest: assume full compromise Graphical desktop, terminal, editors Account with passwordless sudo

KVM / QEMU

Codex Claude Code OpenCode Aider Application installers, builds, and project commands

Project data; task tokens Readable by guest root

Host files: no guest shares

Provider-enforced controls Scopes and hard limits where supported Configured through trusted browser

Ollama on guest loopback No model weights by default

Official software sources and project repositories

Selected remote model provider

Guest Internet egress through NAT; guest firewall removable by root Fig. 1. Architecture and credential placement. Recovery access is separate from provider-account control. Guest applications receive usable tokens; provider limits require separate configuration and credentials unable to change them. The login-URL arrow shows guest-to-host transfer through the shared clipboard. The dashed guest boundary denotes assumed compromise; dashed model access is optional. TABLE II R ISK COVERAGE UNDER KVM-AGENT ’ S STATED TRUST ASSUMPTIONS .

Scenario

Controls and user practices

Residual exposure

Destroy or corrupt important data Steal data or credentials

No host-home/project mount; normally one project per disposable guest. Primary account credentials, admin sessions, and recovery/controller keys stay outside the guest; SSH-agent forwarding is disabled. Optional, user-configured directional Tailscale access rules; guest firewall defaults restrict private ranges.

All co-located projects remain exposed. Backups and version control are separate requirements. Guest tokens can be stolen and used within their granted scope. Internet access permits exfiltration; shared clipboard contents can cross the boundary. Guest root can remove its firewall. NAT is not an egress allowlist; Internet and permitted peers remain reachable. Virtualization defects and compromised host administration can invalidate separation. Guest credentials must lack limit-changing authority. Alerts are not caps; no comprehensive I/O/bandwidth limits; thin disks can exhaust host storage. Initial recovery trusts the first SSH host key. Clipboard, terminal output, and exported code still need scrutiny. Guest-root-writable records are not a tamper-evident audit trail.

Attack other machines

Gain host authority Exhaust resources or incur costs

KVM/QEMU boundary; no host socket or device passthrough. VM RAM, vCPU, and disk capacity; separately configured provider hard limits where supported.

Spoof a peer or export malicious content

SSH key pinning; console fingerprint check for remote access; host-side quarantine of retrieved files.

Erase or falsify activity records

Provisioning and job logs aid diagnosis.

1) Provisioning and recovery: Setup verifies the Ubuntu image against Ubuntu’s signed checksums, creates the VM with a temporary disk containing its initial configuration [23], and installs the desktop and development tools. The host checks that provisioning and the required reboot have completed, removes cached setup data, and confirms that the configuration disk is disconnected before deleting it. Version records aid diagnosis, but updates to upstream installers prevent byte-for-byte reproducibility. Recovery access uses a dedicated SSH key for each VM,

with the private key kept on the host. Users should review and export needed results before replacing a VM. After suspected compromise, users should use the trusted host or controller to revoke or rotate service credentials used inside the guest; deleting a VM does not revoke stolen tokens. 2) Remote access and persistent sessions: The basic setup runs on a single computer; remote access is optional. For users with multiple computers, a laptop can serve as the controller for a VM running on a more powerful desktop (Fig. 2). The guest includes tmux to keep terminal sessions running when a

remote connection is interrupted, allowing users to reconnect to ongoing work [24]. These sessions end if the guest reboots. OpenSSH provides authenticated remote terminal access, while Tailscale connects the controller and guests through an encrypted private network [25]. The physical VM hosts remain outside this private network. As with the online services discussed above, users authorize a guest by opening its Tailscale sign-in URL in a browser on the trusted host or controller, keeping account credentials and administrative browser sessions outside the guest. Tailscale simplifies connection setup but introduces reliance on its managed coordination service. Self-managed WireGuard is an alternative requiring more setup effort [26]. Users authorize devices and configure access rules that allow the controller to connect to guests while blocking guest-initiated connections to the controller and unrelated devices [27]. Users must replace the default allow-all policy with rules enforced by receiving devices independently of guest settings; setup does not configure this policy. The rules govern the private network; access through other networks requires separate controls. KVM-Agent includes a setup script for using a macOS computer as a trusted remote controller. We have tested this configuration. 3) Manager–worker execution: Users with spare computers may want to offload long-running builds or tests while continuing development in their main VM. In this optional arrangement, the main VM acts as the manager and submits jobs over OpenSSH to worker VMs on other machines (Fig. 2). In our deployment, we configure the manager to access accounts inside worker VMs with passwordless sudo for software installation, dependency repair, and job execution as guest root. Users retain administration of the physical hosts and keep recovery keys on those hosts. For build and test jobs, model-service tokens can remain on the manager, while primary account credentials stay on the trusted host or controller. Access rules for the private network should allow the manager to connect to workers and receive replies, while blocking workers from initiating connections to the manager, controller, or unrelated devices. Because a compromised manager can also control its authorized workers, users should dedicate the manager and its workers to the same project. To accelerate development of the next version of KVMAgent, we use this manager–worker setup to run independent development and testing tasks in parallel across three VMs hosted on older laboratory computers. IV. R ELATED W ORK SWE-agent studies agent–computer interfaces [1]; OpenHands integrates agent development and sandboxed execution [28]. Firecracker targets serverless workloads [29], while Docker Sandboxes provides coding agents with sudo inside microVMs and host-side network and credential controls [30]. Anthropic also describes VM-based code execution for Cowork [31]. KVM-Agent builds on existing virtualization

Tailscale private network

OpenSSH over Tailscale WireGuard transport VM hosts outside the private network

Trusted remote controller Browser sign-in; SSH key macOS

Manager VM Agent + worker SSH key Account with passwordless sudo

Jobs / queries

Status / logs and results

Worker VM Remote work Builds and tests Account with passwordless sudo

Host A Host B KVM/libvirt control KVM/libvirt control Recovery key stays on host Recovery key stays on host User-configured policy blocks reverse connection initiation. Each physical host retains independent recovery access.

Fig. 2. Remote control and delegation. Solid arrows show SSH initiation; dashed arrows show replies. The controller and guests join the private network established using Tailscale; physical VM hosts do not. Provider-account administration and controller keys stay on the controller; recovery keys stay on hosts. The manager holds worker-access keys.

to automate a user-managed graphical Linux workflow with a choice of coding-agent applications, model services, and optional remote execution. The Nitro Isolation Engine provides formal assurance for specified VM-management mechanisms [32]; seL4 has machine-checked kernel proofs under explicit assumptions [33], [34]. Agentic-seL4 proposes an agent sandbox with dynamic permission and information-flow controls [35]; its planned guarantees differ from established kernel results. This work on stronger isolation assurance complements our focus on deployment, provider choice, and operational cost. A potential concern is the performance overhead introduced by KVM/QEMU in KVM-Agent. Independent studies report KVM performance at 95.9% of bare metal for Linux kernel compilation [36] and 6% overhead for SPEC ACCEL 1.2 OpenMP workloads [37]. Although these studies do not evaluate KVM-Agent itself, their results suggest that VM isolation can impose modest execution overhead for such workloads. V. D ISCUSSION AND C ONCLUSION This paper examined three trade-offs in deploying coding agents: agent autonomy versus containment, provider reliance versus user sovereignty, and functionality versus operational cost. We presented KVM-Agent as an open-source reference implementation of the resulting design. Agents administer replaceable project VMs, while users retain host administration, recovery, and account control. The implementation preserves choices among coding-agent applications and model services, supports familiar development tools and optional remote execution, and automates most setup and provisioning steps. This balance still requires VM resources, software maintenance, and user decisions about credentials and network access. In practice, however, we have found these demands

manageable for our small research team. We have used KVMAgent in four projects: ProofStudio [38], the neural adaptation of AbductionProver [39], a cross-prover proof-automation tool, and the next version of KVM-Agent itself. In these projects, we use commercial LLM services while restricting agents’ authority over our machines to project-specific VMs. We retain the option to switch to models hosted on Czech academic infrastructure (e-INFRA CZ [40]), reducing our dependence on commercial providers. Future work will evaluate setup and recovery effort, execution performance, and the effort required to switch codingagent applications or model providers. It will also assess host and network controls under full guest compromise. These evaluations will help refine the choices embodied in KVMAgent, which provides a largely automated way to deploy autonomous coding agents while retaining user control under resource constraints. ACKNOWLEDGMENT ChatGPT, Codex, Claude Code, OpenCode, and Kimi-K3 assisted with brainstorming, manuscript drafting and revision, literature survey, and software implementation. R EFERENCES [1] J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “SWE-agent: Agent-computer interfaces enable automated software engineering,” in Advances in Neural Information Processing Systems, vol. 37, 2024. [Online]. Available: https://proceedings.neurip s.cc/paper_files/paper/2024/hash/5a7c947568c1b1328ccc5230172e1e7 c-Abstract-Conference.html [2] K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, “Not what you’ve signed up for: Compromising real-world LLMintegrated applications with indirect prompt injection,” in Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security. ACM, 2023, pp. 79–90. [3] Linux man-pages project, “credentials(7),” Linux manual pages, accessed October 26, 2026. [Online]. Available: https://man7.org/linux /man-pages/man7/credentials.7.html [4] M. Souppaya, J. Morello, and K. Scarfone, “Application container security guide,” National Institute of Standards and Technology, Tech. Rep. SP 800-190, 2017. [Online]. Available: https://doi.org/10.6028/NI ST.SP.800-190 [5] Docker, “Docker Engine security,” Online documentation, accessed October 26, 2026. [Online]. Available: https://docs.docker.com/engine/s ecurity/ [6] ——, “Rootless mode,” Online documentation, accessed October 26, 2026. [Online]. Available: https://docs.docker.com/engine/security/root less/ [7] Podman project, “podman(1),” Podman documentation, accessed October 26, 2026. [Online]. Available: https://docs.podman.io/en/latest /markdown/podman.1.html [8] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori, “kvm: The Linux virtual machine monitor,” in Proceedings of the Linux Symposium, vol. 1, 2007, pp. 225–230. [Online]. Available: https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf [9] F. Bellard, “QEMU, a fast and portable dynamic translator,” in USENIX Annual Technical Conference, FREENIX Track. USENIX Association, 2005, pp. 41–46. [10] libvirt project, “The virtualization API,” Online documentation, accessed October 31, 2026. [Online]. Available: https://libvirt.org/ [11] Y. Nagashima, “KVM-Agent: A graphical Ubuntu VM for coding agents,” GitHub repository, 2026, accessed: 2026-11-09. [Online]. Available: https://github.com/yutakang/agent-vm [12] OpenAI, “Agent approvals & security,” Codex documentation, accessed October 27, 2026. [Online]. Available: https://developers.openai.com/ codex/agent-approvals-security

[13] Anthropic, “Choose a permission mode,” Claude Code documentation, accessed October 27, 2026. [Online]. Available: https://code.claude.co m/docs/en/permission-modes [14] ——, “Configure the sandboxed Bash tool,” Claude Code documentation, accessed October 27, 2026. [Online]. Available: https://code.claude.com/docs/en/sandboxing [15] K. Scarfone, M. Souppaya, and P. Hoffman, “Guide to security for full virtualization technologies,” National Institute of Standards and Technology, Tech. Rep. SP 800-125, 2011. [16] GitHub, “gh auth login,” GitHub CLI manual, accessed October 29, 2026. [Online]. Available: https://cli.github.com/manual/gh_auth_login [17] OpenAI, “Authentication,” Codex documentation, accessed October 29, 2026. [Online]. Available: https://developers.openai.com/codex/auth [18] Anthropic, “Authentication,” Claude Code documentation, accessed October 29, 2026. [Online]. Available: https://code.claude.com/docs/en/ authentication [19] OpenAI, “Spend limits,” API documentation, accessed October 29, 2026. [Online]. Available: https://developers.openai.com/api/docs/guide s/spend-limits [20] Anthropic, “Rate limits,” Claude Platform documentation, accessed October 29, 2026. [Online]. Available: https://platform.claude.com/do cs/en/api/rate-limits [21] GitHub, “Budgets and alerts,” Billing documentation, accessed October 29, 2026. [Online]. Available: https://docs.github.com/en/billing/conce pts/budgets-and-alerts [22] ——, “Managing your personal access tokens,” GitHub documentation, accessed October 29, 2026. [Online]. Available: https://docs.github.co m/en/authentication/keeping-your-account-and-data-secure/managing-y our-personal-access-tokens [23] Canonical, “NoCloud datasource,” cloud-init documentation, accessed October 26, 2026. [Online]. Available: https://docs.cloud-init.io/en/late st/reference/datasources/nocloud.html [24] tmux contributors, “tmux: Getting started,” Project documentation, accessed October 27, 2026. [Online]. Available: https://github.com/tmu x/tmux/wiki/Getting-Started [25] Tailscale, “Connection types,” Online documentation, accessed October 26, 2026. [Online]. Available: https://tailscale.com/docs/reference/con nection-types [26] J. A. Donenfeld, “WireGuard: Next generation kernel network tunnel,” Technical whitepaper, draft revision e2da747, June 1, 2020, accessed October 26, 2026. [Online]. Available: https: //www.wireguard.com/papers/wireguard.pdf [27] Tailscale, “Manage permissions using ACLs,” Online documentation, accessed October 26, 2026. [Online]. Available: https://tailscale.com/do cs/features/access-control/acls [28] X. Wang, S. Rosenberg, J. Michelini, C. Smith, H. H. Tran, E. Nyst, R. Malhotra, X. Zhou, V. Chen, R. Brennan, and G. Neubig, “The OpenHands software agent SDK: A composable and extensible foundation for production agents,” in Proceedings of Machine Learning and Systems, vol. 8, 2026. [Online]. Available: https://proceedings.mlsys.org/paper_files/paper/2026/hash/8ae9cf363ea 625161f885b798c1f1f78-Abstract-Conference.html [29] A. Agache, M. Brooker, A. Florescu, A. Iordache, A. Liguori, R. Neugebauer, P. Piwonka, and D.-M. Popa, “Firecracker: Lightweight virtualization for serverless applications,” in 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI). USENIX Association, 2020, pp. 419–434. [Online]. Available: https://www.usen ix.org/conference/nsdi20/presentation/agache [30] Docker, “Docker Sandboxes: Isolation layers,” Online documentation, accessed October 26, 2026. [Online]. Available: https://docs.docker.co m/ai/sandboxes/security/isolation/ [31] Anthropic, “How we contain Claude across products,” Engineering report, May 2026, accessed October 27, 2026. [Online]. Available: https://www.anthropic.com/research/how-we-contain-claude [32] Amazon Web Services, “Nitro Isolation Engine whitepaper,” Amazon Web Services, Tech. Rep., Jun. 2026. [Online]. Available: https: //d1.awsstatic.com/onedam/marketing-channels/website/aws/en_US/wh itepapers/compliance/nitro-isolation-engine-whitepaper.pdf [33] G. Klein, J. Andronick, K. Elphinstone, T. Murray, T. Sewell, R. Kolanski, and G. Heiser, “Comprehensive formal verification of an OS microkernel,” ACM Transactions on Computer Systems, vol. 32, no. 1, pp. 2:1–2:70, 2014. [34] seL4 project, “What the proofs assume,” accessed October 26, 2026. [Online]. Available: https://sel4.systems/Verification/assumptions.html

[35] University of Surrey, “Surrey leads £3.2m project in collaboration with Sheffield and Melbourne to develop provably secure sandbox for AI agents,” Project announcement, Oct. 2026. [Online]. Available: https://www.surrey.ac.uk/news/surrey-leads-ps32m-project-collaborati on-sheffield-and-melbourne-develop-provably-secure-sandbox-ai [36] S. Giallorenzo, J. Mauro, M. G. Poulsen, and F. Siroky, “Virtualization costs: Benchmarking containers and virtual machines against baremetal,” SN Computer Science, vol. 2, no. 5, 2021, art. no. 404. [37] J. Tharwani, S. Aggarwal, and A. A. Purkayastha, “Quantifying virtualization overhead for CPU-intensive HPC workloads in hypervisors: A comparative study of KVM, Proxmox VE, Xen, and Hyper-V,” in IEEE SoutheastCon, 2026, pp. 1–6. [38] Y. Nagashima, “ProofStudio: Five proof assistants in the browser,” arXiv preprint arXiv:2611.05540, Nov. 2026. [Online]. Available: https://arxiv.org/abs/2611.05540 [39] Y. Nagashima and D. S. Goc, “Abduction prover in Isabelle/HOL,” CoRR, vol. abs/2606.04877, 2026. [Online]. Available: https://doi.org/ 10.48550/arXiv.2606.04877 [40] CERIT-SC, “AIaaS introduction,” e-INFRA CZ documentation, accessed: 2026-11-09. [Online]. Available: https://docs.cerit.io/en /docs/ai-as-a-service/introduction

Related documents

• VeriHarm-Bench: Measuring Harmful Success in LLM Coding Agents Verifiably#1528038
• Local-Splitter: A Measurement Study of Seven Tactics for Reducing Cloud LLM Token Usage on Coding-Agent Workloads#13060
• LLM-Based Agents for Software and Systems Security: Approaches, Applications, and Assessment#618499
• Enhancing Virtual Agents through SLMs and Edge-Computing: An Exploratory Evaluation of Think and Memory Processes#451336
• The Dark Side of LLMs: Agent-based Attack Vectors for System-level Compromise#617839