Edera at OSS Summit Europe

A Tavern In The Middle Of The Expo Hall

If you walked past the Edera booth at Open Source Summit Europe in Prague, you probably noticed it didn't look like a typical vendor booth. We design it to look like a medieval tavern, an inspired Czech beer hall, around one of Czechia's best-loved traditions - tank beer.

Tankové pivo is served from dedicated sealed tanks, unpasteurised, with one tank feeding one line. It isn't a tourist gimmick; it's how a lot of Czechs actually drink their beer. It also happens to be a literal isolation architecture, and one our Prague audience already understood (and liked).

One Tank. One Line. Nothing Shared. That's how the Czechs do beer. It's how we do kernels.

Most container platforms run every workload through a shared kernel: one keg, many taps, everything mixing downstream. Edera gives every workload its own tank and its own line, straight to the glass. There are no shared taps, just as there are no shared kernels, so contamination in one line never touches another.

But enough about the booth. We spent the week talking to anyone and everyone who stopped by. We went on stage to talk about the hard parts of running microVMs at scale, we ran a Capture The Flag (CTF) challenge all week, and we sat in on some excellent talks. Here's what we brought home.

On Stage: Kata at Scale and the Hidden Cost of a VM Behind Every Container

On Wednesday, October 7th, Kavitha Daula and Nigel Douglas took to the Small Hall stage to give Kata at Scale: The Hidden Cost of Running VMs Behind Every Container. The core message: getting Kata Containers working in a PoC environment is one thing. Operating a large, multi-tenant Kata environment for years afterwards is something else entirely.

Once every pod carries a lightweight VM lifecycle behind it, platform teams aren't only running Kubernetes anymore. They're also running guest kernels, guest images, VMMs, hypervisor behaviour, virtio devices, runtime and agent version skews, and a second debugging surface sitting underneath the container platform.

The talk walked through the issues that tend to surface at scale, from the kernel lifecycle of dealing with guest kernel CVEs and regressions, plus drift between host and guest kernels, networking and storage management of the CNI and tap-device networking, and virtio-fs durability semantics, as well as capacity and performance, dealing with boot storms, vCPU oversubscription, memory accounting drift and NUMA behaviour, as well as VFIO/IOMMU lifecycle management. Couple all this with operational complexity of fragmented observability, upgrade matrices and unclear incident ownership within your platform and security teams, the talk really tries to address how when you adopt MicroVMs in production, you are oftentimes taking on an entire new platform of responsibilities.

To be clear, this was at no point a critique of the Kata project. The team at Kata are solving a genuine, real open source isolation problem, and the talk was deliberately vendor-neutral. The goal was to help operators see the full operational picture before they commit, so they can understand how best to run VM-isolated containers safely and sustainably in production.

Off Stage: Sandboxing AI Agents, One MicroVM at a Time

Sandboxing was everywhere at this year's summit, both for AI agents and for containerised AI workloads. It sat alongside another big theme and that’s how the EU’s CRA has shifted liability for open source dependencies, and how that will intensify software supply chain pressure that's already at a fever pitch for enterprises. Bruce Gain was covering the event for TechTarget, and he caught up with Kavi after the talk. 

Kavi was eager to chat about how Edera is helping to prevent software supply chain incidents further down in the stack. They discussed how Edera provides the isolation mechanisms to wrap AI agents and containerised workloads into zones, and chatted about how our hardware-isolated microVMs run securely inside of Kubernetes. These agent sandboxing capabilities were announced recently as part of Edera's Project Lunchbox.

"Every single agent – and we really mean every one – has its own microVM and private Linux kernel," Daula said. "They also run on the Kubernetes clusters you already own."

In other words: one tank, one line, even for agents.

Our First Kubernetes Isolation CTF: Still Open on GitHub

To make workload isolation something people could poke at rather than just hear about, we ran an interactive, on-demand Capture The Flag challenge for the whole week. Players used kubectl and the Edera Protect CLI to explore how zone-based isolation works in Kubernetes with Edera.

To everyone who captured the 6 flags: congratulations!!! If you didn't get the chance, don't worry. The CTF will stay up on GitHub indefinitely, so you can work through it at your own pace.

Talks We Loved on Isolation, eBPF, and Agent Security

A few sessions stood out, and each left us with something practical for the community.

Runtime-generated code is debuggable, if you manage to build the toolkit.
When the Kernel Writes Its Own Code (Alexis Lothoré, Bootlin) tackled the instructions the kernel creates at runtime through ftrace, kprobes and eBPF's JIT compiler, where symbols and debug info don't exist. The takeaway here is that a custom kernel under QEMU, GDB across user and kernel space, TUI and GDB scripts, and stepping through raw machine instructions gets you real visibility into eBPF programs, trampolines and verifier patches. As more security tooling runs as eBPF probes, that skill matters for everyone operating it.

Isolation isn't a one-size-fits-all, so you’re better off matching the boundary to the threat.
Sandlock: Rootless and Containerless Confinement for AI Agents (Cong Wang, Multikernel Technologies) showed how to confine an agent's individual commands in about 5 ms, with no root or containers, by composing Landlock, seccomp-bpf and seccomp user notification. It's a useful reminder that defence comes in layers with lightweight per-command confinement (egress allowlists, copy-on-write working directories, previewing file changes) and per-workload kernel isolation solve different problems and can work together.

Mixed-criticality systems need clear roles and shared safety work.
In Zephyr and Xen in Automotive Mixed-OS Systems, Harunobu Kurokawa (Renesas) laid out a clean division of labour using Xen for domain isolation and resource partitioning, Linux for higher-level services, and Zephyr for focused RTOS functions. The bigger lesson was cultural. The Zephyr Safety Working Group treats safety readiness as shared groundwork, with requirements, tests, and documentation all built upstream, and are very much inviting automotive stakeholders to contribute.

Agents will find a way out, so make every isolation decision observable.
The final session we attended, Life Finds a Way by Henrik Rexed of Dynatrace, used a Jurassic Park framing to make the point that in 2025's high-profile agent escapes, the sandbox was either missing or in the wrong place. His demo ran an agent gateway inside Kubernetes agent-sandbox, swapped gVisor for Kata under the same CRD, and emitted policy verdicts as OpenTelemetry spans. Two actions for the community is that (1) you need to put a real isolation boundary under your agents, and (2) you need to help shape existing OpenTelemetry semantic conventions so those verdicts become standard, queryable telemetry.

Na zdraví, Prague

The thread running through the whole week was the same one behind our booth: shared infrastructure is convenient until something leaks between lines. Whether it's containers, AI workloads or autonomous agents, the community is converging on stronger, more observable isolation, and on being honest about what it takes to run it in production.

Thank you to everyone who stopped by our tavern, attended our talk, or took on the challenge of our first ever CTF. We'll see you all again very soon at Kubecon, Salt Lake City.
Until then: one tank, one line, nothing shared.

‍