Skip to main content
Brooks Townsend
Brooks Townsend
Brooks Townsend
||6 min read

Sandboxing agentic developers with WebAssembly

If you want to use AI agents for enterprise development, you’ve got some big security questions to answer. For example: How do you limit the capabilities that agentic developers can access in your environments? You don’t want to give them access to your whole platform, and you probably shouldn’t just YOLO AI-generated code into a container and deploy.

But what if you could give AI agents a custom sandbox with a limited number of capabilities? WebAssembly makes it possible, and wasmCloud gives you a way to deploy agents’ code with custom capabilities injected at runtime—all executing safely within the sandbox.

In this blog, we’ll walk through how it all works as part of a hands-on demo that you can try for yourself at KubeCon EU 2025 in London.

Build sandboxes for AI agents with WebAssembly

WebAssembly binaries are designed from the ground up to run sandboxed code anywhere, from the browser to smart TVs to the cloud. The only way code can reach outside the sandbox is through strictly defined contracts that we call capabilities.

Some capabilities exist as community standards. If you’ve worked with WebAssembly before, you’ve probably heard of the WebAssembly System Interface (WASI), which provides standard specifications for common capabilities like HTTP and key-value storage.

But what if you want to create custom capabilities for your agents’ code to utilize? The WebAssembly orchestrator CNCF wasmCloud is a platform for platform engineers that makes it simple to inject a custom capability at runtime—and it also happens to be the open source foundation of our own WebAssembly control plane called Cosmonic Control.

As I was writing our booth demo for Cosmonic Control, I decided to put the combined power of WebAssembly, wasmCloud, and AI-generated code into practice.

From Claude to prod

My booth demo is a cross-border, cross-language payments application called “wasmpay” that can send transactions between banks regardless of currency or language. Part of the architecture for the application is a validator for each bank. The validators can include custom logic to approve or deny a transaction based on a bank’s specific rules.

With custom capabilities and tightly defined interfaces, wasmpay is both an application and an extensible platform for their customers. In the same way that Shopify functions or SingleStore UDFs allow extending their platform, wasmpay validators (human or agentic) can write code in a language of their choice to further enforce their business needs.

All of that means that it’s pretty easy to spin up a validator with AI. In this case, we’ll use Anthropic’s Claude. I used a simple prompt to ask Claude to write a validator for wasmpay. The prompt was:

You are a code generator for TinyGo. I'm going to give you a sample of code and a Transaction structure and I want you to prepare for user requests to write a transaction validator.

From there, I provided the generated code from the following WebAssembly interface, wasmpay:platform. This was enough context for Claude to be able to write a transaction validator in TinyGo.

package wasmpay:platform@0.1.0;

// Types involved in the wasmpay platform
interface types {
   record bank {
      id: string,
      name: string,
      country: string,
      currency: string,
   }
   record currency {
      name: string,
      symbol: string,
      amount: s64,
   }
   record transaction {
      id: string,
      origin: bank,
      destination: bank,
      amount: currency,
      status: string,
   }
}

// Function to validate a transaction
interface validation {
   use types.{transaction};
   validate: func(transaction: transaction) -> bool;
}

// Wrapper component to handle messaging logic for validator components
world validator-messenger {
   import validation;
   export validation;
   export wasmcloud:messaging/handler@0.2.0;
}

// Implemented by banks to validate transactions using their own rules
world validator {
   export validation;
}

When taking AI-generated code and compiling it to WebAssembly, it must conform to the interface wasmpay:platform/validator. It is only allowed to export the validation interface, which means that it can only validate transactions. It cannot access any other capabilities or interfaces like file servers or HTTP. The wasmpay platform provides a component that handles the messaging logic for the validator components, and the final deployed component is composed of the validator and the messaging component.

From the Claude interface, we can publish the AI-generated code to a public URL.

claude generated code

Since the code is public, we can lean on the sandbox of WebAssembly to pull, build and deploy this code as-is. If the AI spits out invalid code, it fails to compile and won’t get deployed. If the AI attempts to invoke additional capabilities that it shouldn’t have access to, it will panic at runtime without affecting other workloads.

We can programmatically verify that the compiled component conforms to the wasmpay:platform/validator interface, and inspect all of its capabilities:

 wash inspect --wit ./ai_generated_validator.wasm
package root:component;

world root {
  import wasi:io/error@0.2.0;
  import wasi:io/streams@0.2.0;
  import wasi:cli/stdout@0.2.0;
  import wasi:random/random@0.2.0;
  import wasmpay:platform/types@0.1.0;

  export wasmpay:platform/validation@0.1.0;
}

As you can see, this component exports the function we expect. The only other capabilities it has access to are the standard WASI capabilities for I/O and random number generation. It would be significantly harder to have this level of confidence in running code with anything other than WebAssembly. But now? We can use our existing cloud-native tools to the fullest—for example, using Argo CD to build and deploy straight to Cosmonic Control.

artifact deployment

Amidst the absolutely insane process of downloading AI generated code from the internet and running it, there’s of course a broader implication. When you build a platform with wasmCloud, you’re building a secure, extensible sandbox that runs polyglot code. Whether you’re using AI agents or not, that gives your platform enormous flexibility.

Check it out at KubeCon EU 2025 in London

If you’re going to KubeCon EU 2025 in London, visit us at Cosmonic booth S680 to check out the full demo running with Cosmonic Control, our new enterprise control plane for WebAssembly workloads. You can even create your own validator live.

(While you’re there, make sure to catch the Cosmonic team’s talks.)

Hope to catch you in London!

Keep up to date

Subscribe to Cosmonic for occasional communication straight to your inbox.