A few years ago, WebAssembly was the format that let a game engine or a design tool like Figma run in your browser at near-native speed. It was designed around one very specific problem: Run code that you didn't review, from a source you don't fully trust — safely, instantly, and anywhere.
Now, think about what an AI agent does all day:
It writes a Python script to clean up a CSV.
It generates a function to call an API it found in the docs five seconds ago.
It tries something, fails, rewrites it, and tries again.
That’s code nobody reviewed, from a source nobody fully trusts, that needs to start instantly and run anywhere.
Sound familiar? The problem WebAssembly was built to solve is exactly the problem that agents just created.
Today, we're making two things official.
Akamai Functions is generally available (GA), with an SLA and the production readiness enterprises expect from Akamai.
We’re contributing the building blocks for an open source WebAssembly sandbox to Spin, the WebAssembly framework that Akamai Functions is built on.
From enterprise-grade general availability to native Property Manager workflows, here is everything new hitting the platform today.
Self-service provisioning through your existing Akamai Delivery contract, no manual approval step
Property Manager integration, so you can bind a function to a property from a drop-down
WASI P3 and target world support, so your code stays on open standards
Intelligent resource scheduling for predictable performance when you deploy
Per-application limits enforcement to keep one runaway app from affecting anyone else
Akamai Agent Sandbox building blocks headed to Spin, the open source framework under Akamai Functions
Where should agent-generated code run? It needs to be isolated, it needs to start fast, and it shouldn’t cost much to keep ready. Containers and VMs handle isolation well, but speed and cost are where they struggle.
WebAssembly flips that trade-off. Four properties matter most for AI and agent workloads:
Deny-by-default isolation. A Wasm component can’t touch the file system, the network, or environment variables unless you explicitly grant it. Agent-generated code starts with no permissions and gains permissions one at a time.
Sub-millisecond start-up. There’s nothing to boot and nothing to keep warm. Each request, or each tool call, can get a fresh sandbox, and you throw it away when it’s done.
Portable by design. The same component runs on a laptop, in a Kubernetes cluster with SpinKube, or across Akamai’s global network. No rewrite when you move it.
Small and dense. Components are measured in kilobytes or a few megabytes, not gigabytes. That means more isolated workloads per server and less infrastructure sitting idle.
Put those four properties together and you get a runtime that allows you to “spin up a sandbox for every single thing an agent wants to try” inexpensively and by default.
We’ve been busy building Akamai Agent Sandbox, a developer sandbox for running agents and the code they generate. Under the hood, it's Spin: Every piece of agent-generated code runs in its own WebAssembly sandbox with only the capabilities you hand it.
We think the core of that belongs in the open. So, we’re contributing the Akamai Agent Sandbox building blocks to the Spin project, where anyone can use them, whether they run on Akamai or not. That contribution is going through the Spin improvement proposal process now, and we expect it in the project soon.
As a developer, you can:
Use the Spin SDK you already know. Sandboxing for agent tools and generated code ships as part of the Spin developer experience, not a separate product to learn.
Run it anywhere Spin runs. It will run on your laptop, your own cluster with SpinKube, or Akamai Functions.
Help shape it. Proposals, issues, and pull requests are open to everyone in the Spin community.
A sandbox is only as useful as the place you run it. That’s where Akamai Functions comes in. Akamai Functions is an edge native serverless platform for engineering teams that are building latency-sensitive apps and AI services. You get sub-millisecond start-up, secure sandboxed isolation, and global distribution by default — all on open WebAssembly standards.
At Akamai, we've written previous blog posts about what that unlocks: redirects that resolve in about 10 milliseconds, personalization that drops from 200 ms to 40 ms, and token validation that stays consistent across every CDN. Those same properties make Akamai Functions the natural home for agent tools and AI-generated code. A function can call inference, check an Akamai Bot Manager classification, or read from a KV store without ever leaving Akamai’s network.
GA means that Akamai Functions now comes with an SLA that’s backed by the same operational rigor that keeps Akamai in front of a large share of the world's applications. If you’ve been waiting to move a workload off a proof of concept, this is the green light.
Akamai Functions now also meets the same criteria that Akamai sets for everything you run in production, including the ability to:
Turn it on with the contract you already have
Bind functions to your properties in Akamai Property Manager
Build on the latest WebAssembly standards
Get predictable performance at deployment time
Define guardrails for runaway applications
If you’re an Akamai Delivery customer, Akamai Functions is now unlocked automatically through your standard Delivery contract entitlement. No ticket, no manual approval, no waiting on someone to flip a switch. You can go from “I wonder if this would work at the edge” to a running function the same afternoon.
Akamai Functions now show up where you already configure delivery. In Property Manager, pick your function from a dedicated origin drop-down and bind it to a property. Your edge logic and your delivery configuration live in one place, instead of needing two tools and a wiki page explaining how they connect.
Akamai Functions supports the latest WASI P3 updates and target worlds from the WebAssembly Component Model. In plain terms: You write in JavaScript, Python, Rust, Go, or whatever your team already uses, compile to a standard component, and that component isn’t tied to us. If you ever need to move it, you can.
New Intelligent Resource Scheduling fairness logic keeps resource availability stable when you deploy, even when lots of teams are deploying at once. One command still ships your function to every region, and now you can count on how it behaves when it lands.
You can now define per-application resource limits, and Akamai Functions enforces them at runtime. If a function, or an agent-generated piece of code, goes into a loop it shouldn’t, it hits its ceiling instead of hitting its neighbors. That’s good for your bill and good for everyone sharing the platform.
Everything in Akamai Functions starts with Spin, a CNCF project, along with SpinKube for running Spin apps on Kubernetes. Most of the new functionality was added directly to Spin.
Production-grade WASI Preview 3 (WASI P3) and async runtime: Full stabilization and long-term support for WASI P3, featuring fully async host APIs (key-value, SQLite, Postgres, Redis, MySQL, HTTP) and concurrent request processing per instance
Component middleware pipeline: Support for plugging WebAssembly components directly into the HTTP pipeline as middleware (such as CORS or auth) to process requests before reaching application handlers
Fine-grained capability inheritance: Ability to configure and isolate security permissions (such as allowed outbound network hosts or environment variables) specifically for individual Wasm component dependencies
Interactive dependency management (spin deps): A dedicated CLI workflow to interactively discover, configure, order middleware, and attach component libraries and permissions to your application manifest (spin.toml)
My favorite part of open source is that people build things they never planned for. A recent one: A community member built a SpinKube execution back end that runs each Spin app replica inside its own microVM, putting a hardware virtualization boundary behind the WebAssembly sandbox. That member has been posting new start-up timings every few days, each one faster than the last.
I also keep hearing various versions of this story: A platform team goes to set up Akamai Functions for an internal app and discovers another team has been running SpinKube in their cluster for months. Then, they ask whether those apps can run on Akamai Functions too. The answer: They can. Same component, no rewrite.
At Akamai, we want more of that. Over the coming months, you'll see us show up more in the Spin and CNCF communities: more maintainer time, more workshops, and more work to move Spin forward in the CNCF. Be a part of the communities by:
Joining the conversation in the #spin channel on the CNCF Slack
Starring and contributing to Spin on GitHub
Finding us at KubeCon + CloudNativeCon North America in the Project Pavilion on Thursday, November 12 from 10:15 AM to 2:00 PM, kiosk number P-15B, or at the Akamai booth (Booth 132)
WebAssembly spent years waiting for a workload that requires exactly what it does best. AI agents are that workload. And now there's a production-ready, SLA-backed place to run it, close to every user, on open standards you can take with you.
If you're an Akamai Delivery customer, Akamai Functions is already in your contract. Start with the Akamai Functions Quick Start Guide and you can have something deployed worldwide with a single command. Then come tell us what you built in the Spin community.
Akamai Delivery customers get Akamai Functions automatically through their existing Delivery contract, with no approval step. If you’re interested in Akamai Functions, get in touch.
In Property Manager, select your function from the origin drop-down and bind it to the property.
Yes. Each function runs in an isolated WebAssembly sandbox with no access to files, network, or environment unless you grant it.
It stops at the per-application limit you set, so it can't take resources other workloads need.
WASI P3 is the latest version of the WebAssembly System Interface standard. Supporting WASI P3 keeps your code current and portable across compatible runtimes.
Yes. Akamai Functions is built on Spin, so Spin and SpinKube apps deploy without a rewrite.
Akamai Agent Sandbox runs AI agents and the code they generate on Spin. Akamai Functions is where those sandboxed workloads run globally in production.
© 2026 Akamai Technologies
