The AWS keynote on trusted agentic workloads at Open Source Summit Europe 2026 described what every agent needs around it: identity, policy, limits and an audit log. On the show floor I went looking for the projects that implement those pieces. Three conversations stood out: Edera on isolation, Coder on where agents run, and OpenBao on secrets.
Edera: containers are not a security boundary
With Kavitha Daula, VP of Engineering at Edera.
Edera builds hypervisor-based isolation for containers and AI workloads. Their booth slogan was a local joke that landed well in Prague: “How the Czechs do it. We do kernels.” Edera’s founder, Alex Zenla, was not at the event, so the team suggested Kavitha Daula, their VP of Engineering, as the technical guest. We met at the Edera booth for our Udienza slot on Wednesday afternoon.
The angle I brought:
- What is the architecture for isolating untrusted cloud-native and AI workloads?
- What do developers get wrong about containers as a security boundary?
- Where does hypervisor-based isolation fit, and how does Edera approach it?
The core issue is simple. Containers share the host kernel. One kernel bug, and a process in one container can reach every other container on the node. That has always been a risk for multi-tenant platforms. With AI agents that run code they generated themselves, it becomes a daily one: you are executing untrusted code by design.
Kavitha also co-presented a vendor-neutral session with Nigel Douglas: “Kata at Scale: The Hidden Cost of Running VMs Behind Every Container”. It covered what it really costs to run Kata Containers at scale: guest kernels, VMM drift, virtio quirks and the extra debugging surface. That honesty is rare in a vendor talk. VM-level isolation is the right answer for many agent workloads, but it is not free, and you need to know where the operational cost goes. My piece on Kata Containers 4.0 for AI agent sandboxing covers the runtime side.
Coder: when development leaves the laptop
On Thursday morning I recorded a Udienza conversation with Ben Potter, Head of Developer Relations at Coder and formerly its VP of Product. Ben has been at Coder for six years. Coder was a Gold sponsor in Prague.
Coder runs development environments as cloud workspaces. That used to be a developer productivity story. With coding agents it becomes a security architecture story: if an agent works autonomously for hours, where should it run, and with which permissions? The questions I took into the recording:
- What genuinely improves when development environments move off local machines?
- What new security boundary appears when coding agents run autonomously in cloud workspaces?
- Should agent permissions be defined as infrastructure code?
- What does reproducibility mean when the “developer” may be an agent running asynchronously?
- Which AI coding workflow is still mostly hype in enterprise teams?
My own view, after a year of helping teams with this: never run an autonomous agent on a developer’s laptop with the developer’s credentials. Give it a disposable workspace, its own identity, scoped tokens and a network policy. Cloud development environments are the easiest way to get there. Ben’s episode will be on Udienza soon.
OpenBao: secrets when the client is an agent
With Marcin Czupryniak (Udienza), Andrii Fedorchuk, and Toni Tauro (Adfinis, OpenBao) near the OpenSSF booth, next to the GUAC demo screen.
OpenBao is the open source secrets and encryption management platform that originated from the Vault codebase after the licence change. It is now an OpenSSF project. Toni Tauro, a systems engineer at Adfinis, is a repository-level committer working on the Helm chart, the CSI provider, Kubernetes integration, the Secrets Operator and the Consul secrets plugin. He has also presented on sovereign workload identities with OpenBao and SPIFFE/SPIRE.
I found the OpenBao crew in their green hoodies around the OpenSSF area on Wednesday and again on Thursday.
With Alex Scheel (Control Plane) and Toni Tauro (OpenBao) on Thursday.
The questions I wanted to cover with Toni:
- What changes in secrets management when the client is an autonomous AI agent rather than a human-operated service?
- Where should short-lived identity replace long-lived secrets today?
- What did OpenBao learn from the Vault licence change about governance for security-critical infrastructure?
- How do SPIFFE/SPIRE and OpenBao fit together for workload identity?
- What should teams migrate first if they want to reduce dependency on static credentials?
OpenBao 2.6 added per-namespace sealing, so each tenant namespace can have its own cryptographic key material and can be sealed without affecting other tenants. For multi-tenant agent platforms that is a significant step: a compromise in one tenant does not unseal the others. If you are new to OpenBao, I interviewed Christian Gafner of Adfinis at the OpenBao Summit earlier this year.
Putting the three together
The three conversations map neatly onto the agent controls from the keynote:
| Control | What it means for agents | Where I saw it in Prague |
|---|---|---|
| Isolation | Untrusted, self-generated code runs behind a VM boundary, not just a namespace | Edera, Kata Containers |
| Environment | Agents work in disposable, reproducible workspaces, not on laptops | Coder |
| Identity and secrets | Short-lived, workload-specific credentials with per-tenant keys | OpenBao, SPIFFE/SPIRE |
| Policy and audit | Rules outside the prompt, with a record of every decision | Cedar, Dogwood |
If your agent platform is missing one of these rows, that is your next project. The broader security picture from Prague is in AI-speed exploits: the Open Secure AI Alliance and OSERA, and the full week is in my Open Source Summit Europe 2026 recap.
