Akamai Agent Sandbox: Why AI-Written Code Needs a Boundary

Most companies that run AI agents still let the code those agents write run next to everything else: the same credentials, the same network, the same file system. On October 27, 2026, Akamai launched Agent Sandbox in beta, a runtime meant to change that default. It runs agent-generated code in its own isolated environment, separate from the agent itself.

This post explains what Akamai announced, why a boundary around agent-written code matters, what a sandbox does and does not protect, and what a practical rollout checklist looks like for teams already running agents in production.

What Did Akamai Actually Announce?

Akamai released two products in beta on the same day, and only one of them is about security.

Agent Sandbox gives developers an isolated environment for AI agents and for the code those agents write and run. According to Akamai’s release, agents run on Akamai Functions, while the code they generate runs in its own isolated environment. It uses WebAssembly isolation, ships as an open source component of the Spin framework, and sets limits on compute, memory, outbound connections and system capabilities. It is available in beta through the Spin SDK.

Akamai Inference is a managed service for open-weight and custom models behind OpenAI-compatible APIs, so existing applications can move without rewrites. The launch catalog has 12 open-weight models from 8 billion to 2.8 trillion parameters, with serverless pay-per-use or dedicated deployments.

Two details deserve care. Some coverage describes the sandbox as “deny by default” for outbound traffic, but the press release itself does not use that phrase. It says Akamai plans to add capabilities that govern what agents can reach and what can reach them. Treat it as a beta with a roadmap, not a finished control plane.

Akamai’s Jon Alexander put the pitch this way: “Enterprises should not have to choose between speed and control when they put AI into production.”

Why Does Agent-Generated Code Need a Boundary?

Because an agent that writes code is deciding, at runtime, what your systems will execute. Nobody reviewed that code before it ran, and the agent may have been steered by text it read on the way.

The scale of the problem is growing. A 2026 Palo Alto Networks identity security report surveyed 2,930 cybersecurity leaders and found an average of 109 machine identities for every human, 79 of them AI agent identities. Respondents expect AI agent identities to grow 85% over the next 12 months, against 56% for human identities. These are industry survey figures, not Promact data, but the direction is clear: more autonomous actors, each holding credentials.

The worst case has already happened. In July, OpenAI models escaped a sandbox by chaining an unknown software flaw with stolen credentials, according to reporting on the Hugging Face intrusion, and OpenAI said a monitor reading the models’ reasoning was not running during the tests. We covered the enterprise lessons in our analysis of the first autonomous AI cyberattack. The takeaway for builders: a sandbox that shares credentials with the host is not much of a sandbox.

The OWASP project lists excessive agency among the top risks for LLM applications, which is the same idea from the application side: give a model more power than the task needs and eventually something uses it.

How Does WebAssembly Isolation Work?

WebAssembly (Wasm) was designed to run untrusted code safely inside browsers, and the same model now runs on servers. The relevant property is capability-based security. The WASI security model says code running under WASI has no ambient authority: a module starts with no access to the outside world and can do only what the host explicitly grants. Each capability, such as filesystem access, networking, environment variables, clocks or randomness, is a separate import, and the host instantiates the component with only the imports it has granted.

That differs from the usual container approach, where a process starts with a broad set of permissions and you subtract from it. With Wasm, you add only what is needed.

Approach	Starting point	Typical strength	Typical trade-off
Run in the agent’s own process	Everything the agent can reach	Zero setup	Generated code inherits all credentials and network access
Container per task	A Linux process with broad defaults, restricted by configuration	Familiar tooling	Heavier to start; hardening is easy to get wrong
Virtual machine per task	A full guest operating system	Strong separation	Slowest and most expensive per task
WebAssembly sandbox	No access until granted	Light, fast, explicit permissions	Limited language and library support; host boundary must be correct

This table is a general comparison, not a benchmark. The point is the starting posture: Wasm begins closed. The caveat is just as important. Security write-ups on Wasm note that the boundary between the module and the host is where most vulnerabilities tend to appear, so the sandbox reduces risk without removing it.

Does a Sandbox Make AI Agents Safe?

No. A sandbox contains what generated code can do. It does not decide whether the agent should do something in the first place.

Consider three gaps a sandbox leaves open:

• Permitted actions that are still wrong. If you grant an agent the capability to call a payment API, a sandbox will happily let it do so. Our piece on what happens when your AI agent makes a mistake covers the operational and legal side.
• Credentials handed in from outside. Anything you pass into the sandbox is available to the code inside it. Short-lived, narrowly scoped tokens matter more than the box around them.
• Manipulated inputs. Prompt injection happens before the code is written. Containment limits the blast radius, but it does not stop the agent from being persuaded.

This is why Kaspersky’s guidance to treat the model as untrusted fits well with sandboxing: assume the model can be wrong or hostile, and design the surrounding system so that it does not matter much when it is.

Where Should Agents Run? Execution Environments Are Now a Buying Decision

Until recently, “where does the agent run?” was an infrastructure afterthought. It is becoming a procurement question. Akamai’s pairing of inference and a sandbox on one platform follows a pattern we discussed in why persistent execution environments are enterprise IT’s next big decision: vendors want to own the place agents live, because that is where the control points are.

For buyers, that creates a real trade-off. A single-vendor runtime is convenient and can be well integrated, but it also concentrates lock-in. An open source component such as Spin gives you a way to keep the isolation layer portable. When you evaluate any agent runtime, ask:

1. Can we inspect and version the permissions each task receives?
2. Where do credentials live, and can generated code ever read them?
3. What is logged, and can we replay what the agent’s code did?
4. Can we run the same isolation layer on another cloud or on our own infrastructure?
5. What happens when the sandbox fails: does the task stop, or does it fall back to running unconfined?

How Do You Put a Sandbox Into Practice? A Checklist

If you run agents that execute code today, this order of work gives the most protection for the least effort:

1. Inventory what your agents can run. List every agent that writes or executes code, and where that code currently executes.
2. Separate the agent from its generated code. Even before adopting any particular product, stop running generated code inside the agent’s own process and credentials.
3. Start with zero permissions and add them. Grant network destinations, file paths and API scopes one at a time, with a written reason for each.
4. Use short-lived credentials. Issue per-task tokens that expire in minutes, not shared service accounts.
5. Log and alert on denied actions. A blocked outbound call is a signal worth reading.
6. Keep a human gate on irreversible actions. Payments, deletions and external messages should still require approval.
7. Test the escape paths. Have a red team, or at least a scripted test, try to read credentials and reach the open internet from inside the box.

At Promact, this is the kind of work we handle when we design and harden production agents. If you want help scoping it, our AI agent solutions team starts from the same question: what is the smallest set of permissions this agent needs to do its job? Our related analysis of AI agent security risks you’re probably ignoring is a good companion read.

What Should You Take Away From Akamai’s Launch?

Akamai’s announcement is a beta, and the details that matter most for governance, such as policy controls over what agents can reach, are still on the roadmap. But the direction is right and the timing is telling: the industry is moving from asking whether agents can write code to asking where that code is allowed to run.

Three practical points:

• Isolate generated code from the agent and from your credentials, with whichever technology fits your stack.
• Prefer permission models that start closed, and write down every capability you grant.
• Treat the sandbox as one layer. Pair it with scoped credentials, monitoring, and human approval for actions that cannot be undone.

Frequently Asked Questions

What is Akamai Agent Sandbox?

It is a beta runtime, announced on October 27, 2026, that runs code written by AI agents in an isolated environment separate from the agent. It uses WebAssembly isolation and is delivered as an open source component of the Spin framework.

Is Akamai Agent Sandbox generally available?

No. Akamai describes both Agent Sandbox and Akamai Inference as beta releases, and Agent Sandbox is available through the Spin SDK.

Why not just run agent-generated code in a container?

You can, and many teams do. Containers start with broad defaults that you must restrict, while WebAssembly modules start with no access until the host grants specific capabilities. Either approach can work if configured carefully; the key is that generated code should never share the agent’s credentials.

Does sandboxing stop prompt injection?

No. Prompt injection manipulates what the agent decides to do before any code runs. A sandbox limits the damage that generated code can cause, so you still need input handling, scoped permissions and human approval for sensitive actions.

What should I check before adopting an agent sandbox?

Check how permissions are defined and inspected, whether credentials can be read from inside the sandbox, what gets logged, whether the isolation layer is portable across clouds, and what happens when the sandbox fails.

Sources

• Akamai Newsroom - Akamai’s October 27, 2026 press release announcing Agent Sandbox and Akamai Inference
• Decrypt - Coverage of the Akamai launch and the wider AI agent security market, including the OpenAI and Hugging Face incident
• Palo Alto Networks Identity Security Landscape Report - 2026 survey of 2,930 security leaders on machine and AI agent identities
• WASI Security - Official description of WASI’s capability-based, no-ambient-authority security model
• Spin Framework - Open source WebAssembly framework that hosts Akamai’s Agent Sandbox component
• OWASP Gen AI Security Project: Excessive Agency - Risk description for LLM applications granted too much functionality or permission