Akamai Agent Sandbox is out in preview - locked-down by default for the code your AI agents write

Akamai launched two AI products on 27 October: Agent Sandbox, an isolated place for AI agents to run the code they write, and Akamai Inference, a managed service for open-weight models. Both are in beta. The sandbox is the more interesting of the two, because it goes after a problem most businesses deploying agents have not thought about yet.

What happened

According to Akamai's announcement, Agent Sandbox ships as an open-source part of Spin, a WebAssembly framework that is a CNCF project. Agents run on Akamai Functions. When an agent writes code, that code runs in a restricted JavaScript or Python runtime nested inside a WebAssembly sandbox. That makes two layers between the generated code and anything it could damage.

The product page lists the defaults. Outbound network access is blocked, including requests to outside websites. You open access to specific APIs, tools or MCP servers one at a time. Runtime APIs "that could have unintended consequences" are removed. The limits on compute, memory and system access are enforced by the runtime, and neither the agent nor its code can raise them.

Akamai Inference is the other half. It gives you 12 open-weight models at launch, from 8 billion to 2.8 trillion parameters, behind an OpenAI-compatible API. The named models include Nvidia's Nemotron 3 Ultra, OpenAI's gpt-oss-120b and Google's Gemma 4, plus embedding models for retrieval, SiliconANGLE reported. You can pay per use on serverless or rent dedicated capacity.

What is genuinely new

Sandboxes for agent code are not new. What is new is a large network company shipping one where denying outbound access is the default, with limits the agent itself cannot change.

That default matters more than the WebAssembly detail. Most agent setups do the opposite. They start with broad access because it is faster to build, and tighten things later. Teams rarely get to the "later" part. A sandbox that ships locked and makes you list every allowed destination turns that order around.

The inference service is less new. Several providers already serve open-weight models behind OpenAI-compatible endpoints. Akamai's pitch is that the model and the agent run on the same network, near your users. That helps if latency is your problem. For most back-office automation it is not.

What it means for a business owner

The useful question is whether your agents write and run code at all.

Many do not. An agent that reads an inbound email, pulls the customer record and drafts a reply is calling fixed tools. It does not write a script and execute it. For that kind of workflow, a code sandbox solves a problem you do not have. The risk there sits in which tools the agent can call and with what permissions.

Some workflows do generate code, and they are becoming common. Think of an agent that writes a Python script to clean a spreadsheet, build a report or reshape data between two systems. If that script runs on a server with your database credentials and open internet access, one bad prompt or one poisoned input file can send your data somewhere it should not go. Agent Sandbox puts a wall around that step.

The deny-by-default rule is worth copying even if you never touch Akamai. Whatever you run agents on, ask your builder for a written list of every outside system the agent can reach. If the honest answer is "anything", that is the first thing to fix.

The honest caveat

This is a tech preview, by request only. Akamai has not published pricing for the sandbox. The inference service lists pay-per-use as an option but gives no rates in the announcement. You cannot budget for either yet.

The limits are real, too. In the preview, each agent step finishes in about a minute and then the agent stops until it gets its next instruction. Long-running agents that hold state for days are "planned", not shipped. Generated code is limited to JavaScript and Python.

It also means building on Spin and Akamai Functions. That is a new runtime for most teams, with its own SDK. If your agents already run somewhere stable, rebuilding them around a beta product to get a sandbox is a poor trade. Container sandboxes with network rules can get you most of the same protection on infrastructure you already have.

And a sandbox does not make a bad agent good. It limits the damage. It does nothing about an agent that sends the wrong invoice through an API you allowed.

What to do about it

List every workflow where an agent writes and runs its own code. For each one, write down where that code executes, what credentials that environment holds and whether it can reach the open internet. If any line reads "production server, full credentials, open internet", fix that this month. Use Akamai's sandbox, a locked-down container or plain human review before the code runs. Which tool you pick matters less than closing the gap.