Your AI agents act on your instructions. You are responsible for their actions and outputs and for complying with applicable law and third-party terms.
An AI agent sandbox for agents that write and run code
Isolate AI agents and the code they generate in a hardened runtime. Akamai Agent Sandbox extends Akamai Functions with WebAssembly isolation and deny-by-default outbound access, letting you instantly deploy agentic apps without building or maintaining custom infrastructure.
Why use Akamai Agent Sandbox?
Run agents that write their own code without handing them the keys to everything else. Akamai Agent Sandbox isolates what agents generate, wherever your users are.
How Akamai Agent Sandbox runs on Akamai Functions
Your agent runs on Akamai Functions, where Spin already puts it in a WebAssembly sandbox. Akamai Agent Sandbox adds a second, tighter boundary for the JavaScript or Python your agent writes.
Start with Spin, grow with Akamai Functions
Start today with Spin, the open source capability in the Spin SDK. Run your agents on Akamai Functions.
AI agent sandbox features for containing agent-generated code
- Stop agent-generated code from reaching remote sites, so it can’t send data out or pull malicious content in
- Keep one agent’s code from affecting other workloads running on Akamai Functions
- Store agent context and memories between steps with key value storage
- Enforce execution limits at runtime, so neither your agent nor its code can raise them
- Add agent capabilities to Spin applications you already build, without learning a separate toolkit
- Run intermittent agents that complete a step, stop, and resume on their next instruction
- Remove runtime APIs that could have unintended consequences, so agent code can’t call them
- Let your agent choose between JavaScript or Python runtime for the code it writes
- Swap between OpenAI-compatible models without rebuilding your agent
Akamai Agent Sandbox use cases
Give every agent that writes code a safe place to run it, whether the code powers an app, answers a question, or runs in the background.
Give your agent a safe place to run the code it writes to reach an answer.
Agents write and run code to analyze data, run calculations, and generate charts. Every question can produce new code that touches your data, so that code runs with no outbound network access by default. Your agent gets its answer back, connects to any OpenAI-compatible model you choose, and the code it wrote never leaves the sandbox.
Keep one customer’s agent-generated code away from another’s.
When you run agents for many customers, one customer’s agent-generated code can never touch another’s. Each agent runs in its own sandbox on Akamai Functions, with strict execution limits enforced by the runtime rather than by the agent. One tenant’s runaway code can’t consume the resources or reach the data of another.
Give agents the tools, skills, and MCP servers they need, and nothing else.
Grant your agent access to the external services and APIs you choose. By default, Akamai Agent Sandbox blocks the rest of the internet, so you hand your agent a full set of tools, skills, and MCP servers knowing it can only do what you permit. When the agent writes and executes its own code, that code runs in a restricted JavaScript or Python runtime nested inside the agent sandbox, under the same permissions you set.
Frequently Asked Questions (FAQ)
Frequently Asked Questions (FAQ)
Agents generate code and execute it seconds later, before anyone reads it. That code can delete files, call MCPs and APIs, or send data out, and instructions in a system prompt can’t stop it, because a model can ignore instructions or follow ones hidden in content it reads. A sandbox enforces limits the agent can’t override.
If your agent connects to tools, skills, or MCP servers, or reaches any external resource, it should run in a sandbox. Sandboxing matters most when the agent writes and runs its own code, because nobody reviews that code before it executes. An agent that only calls tools you wrote and reviewed yourself carries less risk, but it still acts on content you don’t control.
Akamai Agent Sandbox runs AI agents on Akamai Functions and gives the code those agents write an additional sandbox nested inside the sandbox Akamai Functions already provides. It works with any OpenAI-compatible model, blocks outbound access by default, restricts the JavaScript and Python code an agent can write, and enforces execution limits. It extends Akamai Functions rather than replacing it.
It uses two layers. Your agent runs in a WebAssembly sandbox because it is a Spin application on Akamai Functions, and the code it writes runs in a restricted JavaScript or Python runtime nested inside that sandbox. Isolation comes from the WebAssembly runtime itself, not from a layer wrapped around the agent.
Spin SDK, the capability that Akamai Agent Sandbox builds on, is open source and published by Akamai as an extension to Spin, a CNCF project. It includes the sandbox for JavaScript and Python plus an SDK for building agents. You can develop your agent locally in Spin and run it in production on Akamai Functions.
It runs across Akamai Cloud core regions worldwide. You deploy once, and Akamai routes each request to the closest available instance, so your agent runs near your users.
The tech preview supports intermittent agents. Each step completes in about a minute, then the agent stops until it receives its next instruction. Stateful components will add support for agents that stay alive and keep their state for days or weeks.
Unlike other developer-focused sandboxes, Akamai Agent Sandbox uses WebAssembly to isolate directly into the runtime, instead of wrapping it around traditional containers. This approach provides four distinct advantages:
- Native WebAssembly isolation: Because isolation is built into the Spin runtime, you avoid the heavy overhead and latency of spinning up custom microVMs or container wrappers.
- Global distribution: Instead of backhauling requests to a single centralized region, agents execute across Akamai Cloud core regions, automatically routing to the closest available instance.
- Same-platform inference: You can run both your agent execution and your OpenAI-compatible model inference natively on the same Akamai platform, reducing network hops and complexity.
- Open source foundation: The sandbox capability ships through the open source Spin SDK, ensuring you are not locked into a proprietary vendor runtime.
Akamai Agent Sandbox is built for developers whose AI agents generate or execute code they didn’t write and cannot review before it runs. Specifically, it serves four main developer profiles:
- Teams building AI app generators: If your product is an agent that outputs functioning applications, the sandbox provides a safe, isolated runtime to execute and validate that agent-generated code without risking your core infrastructure.
- Developers adding code-execution tools to agents: When you give an agent the ability to write and run its own Python or JavaScript to solve a problem, you need a secure boundary. The sandbox ensures this code runs with blocked outbound access and strict resource limits.
- Multi-tenant SaaS teams: If you are running agents on behalf of many different customers, you need guaranteed per-tenant isolation. The sandbox ensures one customer’s agent-generated code can never interact with another customer’s data or workloads.
- Existing Akamai developers: Developers already using Akamai EdgeWorkers or Akamai Functions can seamlessly add agentic behavior to their applications without leaving the platform or learning a separate toolkit.
Give your agents a safe place to run the code they write
Request access to the Akamai Agent Sandbox tech preview.
- See how agents build and run code inside a WebAssembly sandbox
- Learn how outbound access and resource limits contain agent-generated code
- Explore the open source Spin SDK
