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

Blog Quarkus Insights #267: Sandboxing agents with Quarkus, for Quarkus
This summary was generated using AI, reviewed by humans - watch the video for the full story.
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:
Embedding AI in applications: The answer is LangChain4j with the Quarkus integration.
Using AI to build applications better: This covers the AI development experience, including the Quarkus MCP server and work by Eric and others to expose only the documentation that matches the extensions configured in your application.
How the Quarkus team itself uses AI: isx is one answer to that question, and it is also a Quarkus use case because the tool is built on Quarkus.
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:
Permanent approvals are broader than they look. The "yes, and don’t ask again" button records a pattern, not a single action. Approving a test run also approves whatever code the agent wrote, since a test is just code that can do anything, including running a script that reads your keys or wipes your backups.
Auto mode is not a boundary. A second model reviewing each action is a good idea, and Sanne cited research showing roughly five correct decisions out of six. That sounds good, but it still means a mistake in one of every six operations, which adds up over a long session. Furthermore, the model can be asked to turn its own safeguards off, so they behave more like guidelines.
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:
No approvals: Inside the boundary the agent can do whatever it wants, and what it is allowed to do is defined deterministically in a template that the agent cannot change.
Disposable machines: Sanne treats a machine as tainted after an agent has worked in it, so he destroys it after each task and creates a new one. This only works because creation and teardown are very fast.
No secrets: There is nothing worth stealing inside the machine.
Its own identity: The agent uses its own GitHub account, clearly marked as an AI bot, rather than Sanne’s. GitHub’s terms allow one such AI account, which must be identifiable as one, and it makes it obvious when a pull request was sent without supervision.
Git worktrees let you check out several branches in separate directories, but they share everything else. Sanne described a race condition hunt in which one agent was collecting diagnostics while another published a different snapshot to the shared Maven repository. The failure vanished, and the first agent drew a false conclusion from a poisoned result without realizing it. Port conflicts and shared dependencies cause similar trouble. isx applies the worktree idea to the whole machine, so there are no port conflicts and no shared state.
Branching a machine from the Quarkus template takes about 400 milliseconds on Sanne’s laptop, and his target is under a second. Disk storage is copy on write, so every machine shares the blocks of its parent template and only changed blocks consume space. Because the machines read the same blocks, the operating system also shares their read caches.
On Linux, memory use is essentially the processes you run inside, as with any container, which beats a VM where memory must be assigned