A Wall Around Code-Writing Agents: Akamai's Sandbox and Inference Service Enter Beta Together

When an agent starts writing code and running it on its own, the question is no longer only "is the model strong enough" but "how far can the code it writes reach". Akamai's two products, introduced together on 27 October 2026, map exactly onto those two questions: Akamai Inference addresses how models are called, and Akamai Agent Sandbox addresses where agent-written code is allowed to run. Shipping both into beta at the same time is itself a judgement: offering models without a boundary is like offering an accelerator without a brake.

In Akamai's official release, the two products are foundational layers of its AI stack on Akamai Cloud: enterprises can build and tune their own or hosted open-weight models, ground them in their own data, run agents inside enforced boundaries, and protect applications, agents, and infrastructure. The release contains plenty of broad language, but only three things are worth pressing on: whether the inference interface really lowers migration costs, what actually enforces the sandbox boundary, and what the word "beta" still leaves out.

Inference: managed model access without operating the whole stack

Akamai Inference gives enterprises managed access to open-weight and custom models through OpenAI-compatible APIs, so existing applications move without rewrites. That is the most practical sentence in the release for smaller teams: interface compatibility means the way requests are constructed can be reused, and a team does not have to rewrite request construction, authentication, and error handling just to change inference providers. But "no rewrite" is not "no verification" — model behaviour, output-format details, rate limits, and latency characteristics still have to be tested case by case. Interface compatibility saves the integration layer's work; it does not save the validation layer's work.

For deployment, Akamai offers two options: serverless, pay-per-use inference, or dedicated deployments. Pay-per-use fits teams whose traffic fluctuates and whose usage curve is not yet clear; dedicated deployments fit teams with hard requirements on latency, version control, and isolation. The release also notes that Akamai Cloud provides managed databases and object storage and connects to private and public cloud platforms, so models can draw on enterprise data; the inference service itself handles orchestration, model execution, and authentication, and requests run on Akamai's global network to reduce latency and support availability and consistent service levels.

At launch, the catalogue includes 12 open-weight models ranging from 8 billion to 2.8 trillion parameters, including NVIDIA Nemotron 3 Ultra, OpenAI gpt-oss-120b, and Google Gemma 4, plus embedding models for retrieval-augmented generation. The significance of the catalogue is not its size but its cross-vendor character: a single managed entry point offers models from NVIDIA, OpenAI, and Google, so a team can compare results first and settle deployment second, rather than being locked into one vendor's stack first. Of course, whether the catalogue keeps being updated, and which exact versions and regions are available for each model, is not spelled out in the release; selection should be based on the catalogue actually available.

Agent Sandbox: code and the agent runtime run apart

If Inference answers "how do we call a model", Agent Sandbox answers "where does the code run, and what can it touch". Akamai's design separates two layers: the agent itself runs on Akamai Functions, while the code it writes runs in its own isolated environment, sequestered from the agent's runtime. The sandbox is delivered as an open source component of the Spin framework, and uses WebAssembly isolation to set limits on compute, memory, outbound connections, and system capabilities.

That separation deserves emphasis on its own. The root cause of many agent security incidents is not what the model said but what the code it generated could do when executed with the same privileges as the agent itself: read environment variables, reach internal services, send requests outward. Once the execution environment and the agent runtime are the same layer, any prompt injection or mistaken instruction can turn directly into a privilege escalation. Splitting "the agent that writes code" from "the environment that runs code", and constraining the latter with WebAssembly's capability model, amounts to an architectural admission: agent-generated code is untrusted by default, and must be caged first before discussing what it can do.

The release also notes that agent isolation is converging on several models: microVMs with snapshot and fork capability, policy-enforced containers, and WebAssembly-isolated functions. Akamai lets developers choose the architecture that fits the workload: NVIDIA-accelerated and dedicated CPU infrastructure, managed Kubernetes, and Akamai Functions for serverless execution across edge and core. The subtext is that no single isolation level fits every case — strong isolation for microVMs, elasticity for functions, custom environments for containers. Choosing the wrong isolation level is as dangerous as having none: too loose, and code escapes its bounds; too strict, and legitimate tasks cannot run at all.

GPUs and hardware: the third thread in the same release

Beyond the two software products, the release announces an expansion of the GPU fleet: new NVIDIA Blackwell Ultra GPU clusters, with preparation to support the NVIDIA Vera Rubin platform next year. The fleet includes NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs for low-latency inference, as well as Blackwell Ultra clusters for building, tuning, and self-hosting models. Each eight-GPU Blackwell Ultra node carries 288 GB of HBM3e memory per GPU, 2.3 TB in total, targeting test-time scaling, chain-of-thought reasoning, and long-context agentic work.

For an ordinary vibe coding team, this hardware thread is not required reading, but it explains Akamai's commercial logic: managed inference and the sandbox do not float in mid-air; they run on the same infrastructure from core to edge. The release notes that GPU clusters let enterprises control model versions and deprecation timelines, and run without rate limits or shared-tenancy queueing. For teams troubled by model retirement schedules, that matters in practice — in October alone, GitHub and OpenAI each published model retirement timelines, reminding many teams that whether a model version can be decided by the team itself is a form of production stability.

Adam Karon, Akamai's Chief Operating Officer and General Manager of Akamai Cloud, frames the same logic in the release: customers want to build, run, and protect AI on the same platform, and the inference and execution layers turn Akamai's AI infrastructure into a full AI stack. Jon Alexander, Senior Vice President of Cloud Technology, puts it even more directly, and the sentence is worth quoting verbatim: "Every team running agents needs a boundary around the code those agents write." That is not a marketing slogan; it is the one sentence in the release that can be used directly as an acceptance criterion.

What beta means, and what is still missing

The release's availability section is short: Akamai Agent Sandbox (via the Spin SDK) and Akamai Inference are available in beta, and the inference beta includes serverless deployment options; availability of NVIDIA B300 GPU clusters is via Akamai Sales. The brevity has an upside — beta is not dressed up as a general release. But readers should read the full meaning of beta: features, limits, pricing, and service levels can all change before general availability, and the release publishes no price list, so cost modelling must not assume general-availability pricing.

Two distinctions between "delivered" and "planned" also need care. First, the release says Akamai "also plans to add" capabilities governing what agents can reach and what can reach them — that is a future plan, not a control available today, and it must not be counted as part of the current boundary when evaluating. Second, WebAssembly isolation in the sandbox is a boundary mechanism, not a security guarantee: it limits the compute, memory, outbound connections, and system capabilities available to code, but it cannot guarantee that every program is safe under all circumstances. The boundary must be used together with code review, dependency checks, secret management, and audit logging; the sandbox alone does not replace those.

In addition, secondary reporting has described the inference documentation as a closed beta and the sandbox page as a request-access tech preview. This article follows Akamai's official release wording of "beta", but readers should note that actual access may require an application or a queue, and "beta" should not be assumed to mean "sign up and use immediately". That matters most for project scheduling: if a plan rests on the assumption that the service can be used next week, confirm the access route before committing to the schedule.

How this differs from Vercel's durable-harness

This site covered Vercel's durable-harness on 21 October, which also concerns the agent execution stage and is easy to confuse with this release. The division of labour is in fact clear: durable-harness addresses resilience — an agent that crashes resumes without breaking the thread or burning tokens twice — while Akamai Agent Sandbox addresses the boundary — how wide a cage the agent-written code runs in. One governs "keeps running", the other governs "cannot run away". Both are needed, but neither replaces the other: however well resumption works, escaped code can still exceed its authority; however strict the isolation, the cost of restarting after a crash remains.

For vibe coding teams, that distinction turns directly into a checklist. First, where does your agent-generated code run today — on the same layer as your development machine, your server, or your production database, or already isolated? Second, which secrets, internal services, and outbound addresses can it reach — open by default, or closed by default and opened on demand? Third, who bears the cost of a crash or a timeout — a full rerun, or a resumable run? If any of the three cannot be answered, the execution stage is missing a piece, and Akamai's release supplies precisely the "boundary" piece.

Judgement: fix the boundary first, then talk about scale

Seen in the October 2026 agent-security context, the timing of Akamai's release is no accident. In the same month came a self-disclosure of agents weakening monitoring, reports of agent-driven attacks, and a succession of model retirement timelines. All of those stories point to the same conclusion: agents have moved from "tools that help you write code" to "executors that act on their own, spend money on their own, and run code on their own", and the governance of executors is only now catching up.

In that context, Akamai's product combination has a clear judgement worth endorsing: the inference service answers "which model, and how is it called", while the sandbox answers "where does the code run, and what can it touch", and neither is complete without the other. Talking only about models leaves execution risk with the user; talking only about boundaries leaves calling costs with the user. Launching two betas together at least shows that the vendor understands these two problems must be solved together.

Endorsement, however, must not lower the acceptance bar. For any team considering evaluating these two betas, run three tests first: use agent-generated code that deliberately tries to exceed its authority or reach an external address, and verify that the sandbox really blocks it; use your own real call volumes and models to verify that the OpenAI-compatible interface meets expectations on output format and latency; and confirm the beta's limits, pricing direction, and exit path — if migration to the general release later proves expensive, that cost belongs in the decision now. Only when all three tests pass should scaling be discussed; if any one is unclear, keep the scope inside experimental projects.

Three acceptance tests, spelled out

The first test is a privilege-escalation test. Prepare agent-generated code that tries to read an environment variable it should not read, reach an internal address it should not reach, and send a request to an unauthorised external address, then watch whether the sandbox blocks each attempt item by item. Record three things for each test: which item was blocked, whether the block was a silent failure or an explicit error, and whether the error message leaks internal information it should not. Silent failure and explicit errors each have trade-offs, but testers must know which one actually happens, or troubleshooting after launch will have nowhere to start. More importantly, do not prepare only one kind of escalation code: environment variables, the file system, outbound networking, and system calls each need at least one case, because missing any category leaves a back door in that category.

The second test is an interface-compatibility test. Run the OpenAI-compatible interface with your own real request volumes, real prompts, and real output lengths, and check three things: whether the output format matches the parsing logic in existing code, whether streaming chunking and end markers behave as expected, and whether error codes and retry behaviour match the existing provider. Interface compatibility fails most easily at the edges: ordinary requests all pass, but over-long contexts, empty outputs, and rate-limit behaviour differ. Deliberately cover those edges in testing rather than declaring success after a few happy-path requests. Latency should also be recorded by percentile, not by average — agent tasks are most sensitive to tail latency, and a good average with a poor ninety-ninth percentile still feels terrible in practice.

The third test is an exit and cost test. Confirm the migration path after beta ends: can data, configuration, model versions, and sandbox policies be carried over intact; if not, what does migration cost; and if beta limits tighten suddenly, does the team have a fallback plan. With pricing unpublished, do not budget on "beta is free" or "beta is cheap" — model the worst case using general-release market prices, and only proceed if the result still makes sense; if it only makes sense at a beta discount, keep the scope inside experimental projects until official pricing appears. What these three tests share is that they measure not the vendor's advertised strengths but the risks the team will actually bear.

A low-cost approach for indie developers

Akamai's product combination is aimed first at enterprises, but indie developers can borrow the principle without buying anything immediately. The principle is a single sentence: agent-generated code must never run directly in the same layer as your secrets and your production database. Low-cost ways to honour it are plentiful: run code locally inside a container, with networking closed by default and opened on demand; inject secrets into a controlled process through environment variables rather than writing them into files the agent can read; pass every outbound request through an allow list, refusing any address outside the list. None of these requires a new purchase; they simply implement the principle behind Akamai's sandbox with tools that already exist.

The inference side works the same way: the value of an OpenAI-compatible interface is replaceability. When writing a calling layer, indie developers should wrap model calls in a thin adapter — request construction, retries, error handling, and usage statistics all live in the adapter, and business code depends only on the adapter. Then, whether the team later moves to Akamai Inference or to another compatible provider, the change touches a single file. Replaceability is not about switching providers frequently; it is about retaining a choice when a provider raises prices, retires a model, or tightens limits. October's model retirement news has already shown that choice itself is a form of production stability.

Do not schedule against a beta as if it were a release

One last reminder concerns scheduling. The correct use of a beta product is experimentation and validation, not serving as the anchor for a core business schedule. If a team's release plan says "switch to production once the Akamai sandbox launches", the first question should be: does that "launch" mean beta availability or general availability? Between the two may lie feature changes, limit adjustments, a pricing announcement, or even a change of product direction. Anchoring a core business to a beta timetable hands your own release rhythm to someone else's experimental rhythm. The steadier approach is to run only experimental projects and shadow traffic during beta, and discuss production migration only after the general release, pricing, and service levels are all clear. The conclusions from the experimental period — what the sandbox actually blocked, how far interface compatibility actually went, what the cost model actually looks like — are the assets that genuinely inform a later decision. Rushing to announce "shipped" during beta, beyond one more internal memo, gains nothing in practice.