Quarkus Insights #267: Sandboxing agents with Quarkus, for Quarkus

The promise of coding agents is that you hand over a task, walk away, and come back to finished work. In practice, many developers spend their day pressing "yes" on permission prompts. In episode 267, Sanne Grinovero, one of the earliest Quarkus contributors, joins hosts Eric Deandrea and Holly Cummins to present isx, a tool he built on Quarkus that gives each agent its own disposable machine so it can run with full autonomy while your keys, files, and production credentials stay out of reach.

Holly noted that Quarkus 4 Beta 3 is out and that CR1 is expected this week. She also reminded everyone that Quarkus:Dev is coming in early February, with the call for papers opening soon.

Holly explained that questions about Quarkus and AI tend to fall into three groups:

Sanne introduced himself as a contributor from the early days, when the group was prototyping ideas such as running Hibernate in native images. Today he splits his time between Quarkus and other projects, and acts as a link between Quarkus and the OpenJDK engineers so that each side benefits from what the other is building. He stressed that isx is a hobby project rather than an official direction of the Quarkus team, although several team members, including Holly, already use it daily.

Sanne described the typical first experience with an agent. You ask it to fix a failing test, and it asks whether it can run the test, then whether it can add a dependency, then whether it can run the test again, and then whether it can commit. Before long you are the approver of every step, and Eric and Holly agreed that for small tasks you often think you would have been quicker doing it yourself, even before considering token cost.

To make the point, Sanne ran a game, written by his agent, in which the hosts had to approve or reject a stream of commands as they flew by. A harmless Maven invocation, a pull from an unknown script, a force push, and a database deletion all arrive in the same format and with no context, so it is easy to approve the wrong one.

Two things make this worse:

Some tasks cannot be automated away anyway. Building the JDK needs system packages, which means root access, and each missing dependency stops the agent to wait for you. Sanne’s example took six approvals and 36 minutes. This is precisely the boring environment setup he most wants an agent to handle, especially when he moves between projects and has to rebuild his local setup after months away.

isx is built on Incus system containers. Unlike an application container from Podman or Docker, which is optimized to run a single process, a system container boots a whole operating system. That means the agent can install packages, run PostgreSQL as a separate process, and start its own services, all inside a boundary with its own file system, user identity, and network. Nothing in there can reach your home directory, your keys, or your documents.

The design follows a few principles:

A template has a name, a description, and a parent. Sanne prefers composition to inheritance, so templates also have a tools section that pulls in building blocks such as Podman, Maven, and Claude Code, optionally with parameters. A template can pre-install skills, add an agent note that works like an addendum to the project instructions, and list the Git repositories to clone. Most templates are very short.

Repositories are cloned from the remote at template creation time, but any object that already exists in your local clone is fetched from there instead, which saves time. This is done conservatively: nothing flows in or out of your local repository unless the same information is available on the remote.

Sanne also noted that a few JDK builds ship their own certificates, which requires deploying custom certificates into the machine. A helper handles this case, although it gets hairy for people building their own JDK.

Inside the machine you will not find your real tokens. You will find isx tokens that mean nothing outside it, because each is registered only against that local instance. A proxy runs on the host, and the machine’s traffic goes through it. For a given domain, the proxy terminates TLS, swaps in the real credential, and re-encrypts the request to the upstream API. From the agent’s point of view, it is talking to the Anthropic API or to GitHub over an ordinary encrypted connection. A custom DNS setup routes those domains to the proxy.

Sanne pointed to a recent report of around 2,500 secrets leaked in public repositories because tools did not redact them as users expected. Those were mistakes and misunderstandings, not malicious agents, but they illustrate why he prefers an environment with nothing to steal.

The proxy is configurable through plugins defined as YAML files that name the domains to intercept and the header to replace. Contributors have added support for Jira, for example, and Eric asked whether this works for tools such as Tableau. Sanne said it should be straightforward. You can also hold several subscriptions and swap which one a machine uses on the fly without the agent noticing, with one limitation: Claude uses a different protocol when going through Vertex than through the regular API, so switching between those two needs an agent restart.

isx installs a custom Git protocol as an extension of your local Git. When you create a machine, a remote with that machine’s name is registered in your repository, and when you destroy the machine, the remote is removed. From your host you can fetch and pull from the agent’s repository like any other remote, then review the result in your IDE.

Many projects do not accept agent-authored pull requests, and Sanne does not send them directly from the sandbox either. He fetches the branch, inspects it, signs the commit himself, and then opens the pull request, which is his way of saying he actually looked at it.

The same mechanism helps with untrusted contributions. To test a pull request from a stranger, Sanne branches a machine from his template, checks out the PR inside, runs the tests, and destroys the machine. Anything malicious has zero blast radius.

On Linux, graphical applications running in the machine can display on the host. Sanne’s presentation was running in a Firefox instance inside an isx machine, and his agent edited the slides while he watched. macOS does not offer the same remote windowing, so front-end work there still needs to run on the host.

A newer feature lets one isx instance control others through MCP. A coordinator can create sub-machines, delegate tasks to Claude Code, Codex, or other agents, check whether they are finished, collect results, and destroy them when they are no longer useful. Sanne introduced this because he found himself with around 100 agents running in parallel and could no longer tell which were still needed.

Security is layered in two places:

Sanne maintains isx itself this way. A coordinator spins up a machine to take a first look at each incoming pull request, validates assumptions, resolves conflicts, and loops until the build is green. It then tells him which pull requests are waiting for his approval, so he no longer watches GitHub directly. He describes this as a large reduction in cognitive overload, and encouraged others to try the mode on larger tasks that need many pull requests coordinated.

isx ships as two binaries tuned for different jobs:

Building it exposed problems that more conventional applications do not. Early on, Sanne found nasty bugs in the Quarkus CLI, including one where it picked up configuration files from the current directory, which was a particularly circular problem when using the Quarkus CLI to work on Quarkus. The proxy also took real effort to migrate from Vert.x 4 to 5 because of its low-level code, and it now runs on Quarkus 4. Sanne’s hope is that side projects that push the boundaries find improvements the framework can use. Given the complexity of the effort, Eric suggested swapping in Sanne to the saying that the Quarkus team does the hard work so users do not have to.

Two further changes stood out:

On Linux, the CLI talks to the Incus daemon, which controls the storage pool, instances, and network. A Git helper also talks to the daemon so that fetches reach the right container. A switch lets you use VMs instead of containers when you want a stronger boundary, though Sanne was candid that no sandbox will contain a determined, malicious AI. isx is meant to prevent well-intentioned mistakes, not to replace air gapping.

On macOS the same stack runs inside a single VM using Apple’s virtualization framework, with the memory you assign shared across all agents inside it. Nested VMs are not possible there, but the VM already provides the isolation. Getting there involved a custom Linux kernel, a custom Fedora distribution, a custom Alpine appliance, and WebSocket forwarders, and working around a connection leak that sometimes hangs and needs a recovery process. Sanne said none of this would have been feasible without an agent.

Because every download passes through the proxy, caching is an obvious optimization, but Sanne dislikes caches that can serve stale or corrupted artifacts without any way to evict them. His approach is to look carefully at each protocol:

In a short terminal UI demo, Sanne created a new machine from the Quarkus template by pressing a single key. It was ready in about 400 milliseconds, with Claude Code running in around two more seconds. He opened a second one, jumped between them, and showed both appearing as remotes in his local Quarkus checkout. Templates can copy or overlay files into the machine, and the UI integrates with the Herder tool for switching between agent sessions. The agents run with permission bypass on by default, because the sandbox is the safety boundary.

isx shows that the way to make agents useful is not to supervise them more closely but to make it safe to stop supervising them. Putting the boundary around the whole machine, keeping real secrets on the host, and reviewing results through Git lets you hand off a task and return to a tested result. Next week, Quarkus Insights returns with a look at secure agents with LangChain4j.