Blog

If WebAssembly gives you portable, sandboxed access to the CPU, what's the equivalent for the GPU? That's the question at the heart of wasi:webgpu, and the subject of the latest episode of WebAssembly Unleashed, where Cosmonic engineer and wasi:webgpu champion Mendy Berger joins hosts Joel Moses and Matthew Yacobucci to dig into portable GPU access for Wasm components.

The Bytecode Alliance recently welcomed Endive, a JVM-native WebAssembly runtime forked from Chicory. Endive carries Chicory's pure-Java approach forward under vendor-neutral stewardship, with a roadmap that includes the Cranelift-based Redline compiler, WasmGC, and the WebAssembly Component Model.

To celebrate, we did the natural thing: we ran wasmCloud on it.

Today, AI agents execute code, call APIs, read files, manipulate databases, and orchestrate multi-step workflows across production infrastructure. They can be tremendously accelerative tools for enterprises, but each of those actions comes with a blast radius, and the sheer speed at which they occur means that organizations need an AI sandbox to contain it.

Without proper sandboxing of AI agents, teams face an overwhelming risk surface:

• A single hallucinated tool call can exfiltrate a database.
• A prompt injection can escalate to credential theft.
• A poisoned Model Context Protocol (MCP) tool can pivot from an AI agent into production systems.

This guide covers what an AI sandbox is, why AI agents need one, the four dominant approaches to isolation, and how to choose among them. In doing so, we'll explore the under-discussed questions of agent tooling and AI-generated code, where a great deal of risk resides, and the blast radius is considerable.

Last month the Bytecode Alliance published security advisories for Wasmtime: the largest set of advisories the project has ever published at once, triple the total number issued in all of 2025. The accompanying patch releases (Wasmtime versions 43.0.1, 42.0.2, 36.0.7, and 24.0.7) address 12 vulnerabilities surfaced with the help of a frontier AI model.

Wasmtime is one of the most rigorously engineered runtimes in open source: written in Rust, continuously fuzz-tested, backed by multiple organizations who treat it as security-critical infrastructure. What this release demonstrates is that surfacing vulnerabilities in even the most hardened codebases is no longer the hard part. Finding them quickly and at scale is now within reach of any well-resourced team with access to a capable model.

The hard part is what happens next. Teams have to review each finding, triage severity and blast radius, and patch across active versions, while coordinating disclosure with production embedders before vulnerabilities become public. That work still requires deep expertise, sustained investment, and the kind of trust that only comes from years of doing it right. It shouldn't come as a surprise that, according to a technical blog from Anthropic Red Team, over 99% of vulnerabilities uncovered through similar research have not yet been patched.

At Cosmonic, we're privileged to be part of the Bytecode Alliance, and proud to be part of a community with the commitment to swift releases and advisories like the ones we saw in April.

When people talk about AI sandboxes today, they usually mean:

• seccomp, seatbelt, or bubblewrap
• containers built from namespace mappings, cgroups, and allowlists
• hand-tuned profiles bolted onto the existing OS
• some assemblage of the above

These are all useful tools. But none of them were built for agentic AI security, and every single one of them inherits the same original sin: ambient authority.

We're heading to Amsterdam for KubeCon + CloudNativeCon EU 2026, and we'd love to see you there!

From March 24-26, you can find us on the KubeCon floor demoing Cosmonic Control, our Kubernetes-native control plane for running WebAssembly workloads in secure, sandboxed environments. Whether you're exploring Wasm for the first time or looking for a production-grade platform for microservices, AI agents, and other sensitive workloads, stop by and see what Control can do.

Over on the VMware Cloud Foundation blog, Ka-Kit Wong has published an excellent guide to running Cosmonic Control on vSphere Kubernetes Service (VKS).

We're heading to Atlanta for KubeCon + CloudNativeCon NA 2025, and we'd love to see you there!

On November 10-13, you can find us sponsoring Cloud Native AI Day and talking SandboxMCP, exploring new developments in Wasm at WasmCon, and sharing the latest from Cosmonic Control and wasmCloud on the KubeCon floor.

Plus, the Cosmonic crew will be presenting throughout the show, talking service meshes, Wasm instrumentation, WASI WebGPU, GitOps with Wasm workloads, and more.

Servers using the Model Context Protocol (MCP) from Anthropic have become the industry standard approach for extending the capabilities of Large Language Models (LLMs) and creating agentic workflows. WebAssembly (Wasm) components are quickly emerging as the ideal unit of deployment, providing a secure-by-default sandbox for MCP servers.

In this blog, we'll explain how you can use the open source Wasm Shell (wash) CLI and OpenAPI2MCP to quickly and easily develop MCP servers that enable models to use APIs defined in the OpenAPI specification—and then compile those MCP servers to Wasm component binaries that can be deployed to Kubernetes with Cosmonic Control.