Akamai Inference and Agent Sandbox: Open-Weight APIs Meet WebAssembly Isolation (November 2026)

Updated November 3, 2026 · News and developer analysis

AI agents are moving from answering questions to executing code, calling tools, and touching real customer data. That creates two separate infrastructure problems: developers need a dependable way to serve models, and they need a boundary around the code an agent writes before it runs. On October 27, 2026, Akamai announced two beta products aimed at those layers: Akamai Inference for managed open-weight model serving and Akamai Agent Sandbox for isolated agent execution.

The interesting part is not simply that another cloud provider has added an LLM endpoint. Akamai is trying to place model inference and agent-generated code execution on the same cloud platform. For teams already building OpenAI-compatible applications, the inference service may be straightforward to evaluate. The sandbox is more consequential for teams whose agents generate Python or JavaScript, but it is still in preview and its current execution model has meaningful limits.

This article separates what Akamai has confirmed from what developers should independently test, explains the architecture, and gives a practical evaluation path. It is based on public information available on November 3, 2026; it is not a report of hands-on testing.

What Akamai announced on October 27, 2026

Akamai introduced two related but distinct services:

• Akamai Inference: a managed service for serving open-weight and custom models through an OpenAI-compatible API. Akamai manages GPU infrastructure, model serving, autoscaling, and model lifecycle operations.
• Akamai Agent Sandbox: an execution environment for AI agents and the code they generate. It builds on Spin and WebAssembly, and adds a more restricted JavaScript or Python runtime inside the agent's own sandbox.

Akamai's October 27 announcement says the initial Inference catalogue contains 12 open-weight models, ranging from 8 billion to 2.8 trillion parameters. The release names NVIDIA Nemotron 3 Ultra, OpenAI gpt-oss-120b, and Google Gemma 4 as examples, and also mentions embedding models for retrieval-augmented generation. The announcement does not provide a complete, versioned model catalogue in the press release, so check the live beta console before designing around a specific model.

Independent coverage from SiliconANGLE and Data Center Dynamics also describes the two launches as additions to Akamai's AI infrastructure offering. These reports corroborate the announcement, but they do not constitute independent performance or security testing.

1. Akamai Inference: a managed endpoint for open-weight models

The service is designed for teams that want to use open-weight models without operating GPU nodes, inference servers, autoscaling, and model lifecycle management themselves. Akamai describes an OpenAI-compatible API, which means an existing application can often be adapted by changing its API base URL, API key, and model identifier rather than rewriting its entire model-client layer.

Serverless versus dedicated inference

Akamai's current product FAQ says there is no charge during the beta. It says Serverless Inference is expected to be priced per million input and output tokens when billing begins at limited availability. Dedicated Inference is described as GPU-hour pricing, billed by the minute for as long as the endpoint is provisioned. Dedicated availability is limited. Treat these as the vendor's published beta terms, not a final price sheet.

What OpenAI-compatible means—and what it does not

Compatibility reduces migration work, but it does not guarantee that every OpenAI API feature behaves identically. Akamai's own FAQ warns that support for features such as tool calling and structured outputs can vary by model. Streaming, image inputs, embeddings, JSON modes, token limits, and error formats should all be checked against the specific model and endpoint you receive.

2. Akamai Agent Sandbox: two boundaries, not just a prompt rule

The Agent Sandbox addresses a different problem. A system prompt that says “do not access the filesystem” is not an operating-system security boundary. If an agent generates code and executes it, that code can attempt to read files, make network requests, consume resources, or interact with tools. A model can also be influenced by hostile instructions inside retrieved documents or web pages.

Akamai describes a two-layer design:

1. The agent application runs as a Spin application. On Akamai Functions, Spin places the application inside a WebAssembly sandbox.
2. Agent-generated code runs inside a second, tighter runtime. The product page describes restricted JavaScript and Python execution nested inside the first boundary.
3. Outbound access is blocked by default. Developers can grant the agent access to selected tools, skills, APIs, or MCP servers rather than allowing unrestricted internet access.
4. Runtime limits are enforced outside the model's control. Akamai says the sandbox can apply resource limits and remove runtime APIs that generated code should not be able to call.

This distinction matters. The model decides what code to propose; the runtime decides what that code is allowed to do. Those responsibilities should not be confused. A sandbox does not make the model trustworthy, but it can reduce the damage caused by an unsafe or manipulated action.

Akamai also describes per-agent isolation, key-value storage for context between steps, and the ability to connect agents to MCP servers under controlled permissions. The product page says the current tech preview is aimed at intermittent agents: a step completes in about a minute, then the agent stops until it receives another instruction. Longer-lived stateful components are described as planned, not as an already available capability.

3. How to evaluate Akamai Inference with an existing Python app

The inference service is the simpler component to trial. The following example uses the official OpenAI Python client against an endpoint and model identifier supplied to your account. It deliberately uses environment variables: do not guess the beta endpoint, copy a URL from an unrelated example, or commit credentials to source control.

Prerequisites

• Access to the Akamai Inference beta and an API key.
• The exact API base URL and model identifier shown in your account.
• Python 3 and the OpenAI Python SDK.
• A test prompt that contains no customer secrets or regulated data.

Step 1: Request access and record the endpoint details

Start from the official Akamai Inference page. Request beta access. Once your account is provisioned, copy the documented API base URL, create an API key, and select a model that is actually listed for your account. Record the model's context limit and supported API features as well.

Step 2: Install the client and configure environment variables

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip openai

export AKAMAI_INFERENCE_API_KEY="replace-with-your-key"
export AKAMAI_INFERENCE_BASE_URL="copy-the-base-url-from-your-akamai-account"
export AKAMAI_INFERENCE_MODEL="copy-an-available-model-id"

On Windows PowerShell, use $env:AKAMAI_INFERENCE_API_KEY, $env:AKAMAI_INFERENCE_BASE_URL, and $env:AKAMAI_INFERENCE_MODEL instead of the Unix export syntax.

Step 3: Send a small test request

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AKAMAI_INFERENCE_API_KEY"],
    base_url=os.environ["AKAMAI_INFERENCE_BASE_URL"],
)

response = client.chat.completions.create(
    model=os.environ["AKAMAI_INFERENCE_MODEL"],
    messages=[
        {
            "role": "system",
            "content": "Answer concisely. If you are unsure, say so."
        },
        {
            "role": "user",
            "content": "Explain the difference between model inference and model fine-tuning."
        },
    ],
)

print(response.choices[0].message.content)

This is a compatibility smoke test, not proof that every Chat Completions option is supported. Use the exact base URL and model ID supplied by Akamai. If your beta account documents a different request route or SDK configuration, follow that documentation. Then test streaming, usage fields, tool calls, structured output, embeddings, timeouts, and error handling separately before migrating production traffic.

Step 4: Compare the service against your current route

Run the same fixed workload against your current provider and the beta endpoint. Record time to first token, total latency, tokens per second, error rate, rate-limit behavior, and cost under your expected traffic shape. Keep prompts, model versions, output limits, and concurrency constant. Do not compare a small model on one provider with a larger model on another and call the result a platform benchmark.

4. How to approach Agent Sandbox without assuming preview APIs

Akamai's public product page explains the architecture and access path, but it does not publish a complete, stable set of sandbox SDK calls or a self-serve deployment recipe. Do not invent method names or copy commands from unrelated sandbox projects. Use the Spin documentation for the general development environment, then use the Agent Sandbox beta documentation supplied with access for the product-specific integration.

Step 1: Install Spin for local development

Spin is an open-source framework for event-driven applications built from WebAssembly components and is a CNCF sandbox project. Its official installation guide currently documents Homebrew for macOS:

brew tap spinframework/tap
brew install spinframework/tap/spin
spin --version

On Linux and Windows, use the platform-specific instructions in the Spin installation guide. Verify the installed version before following any SDK-specific tutorial. Installing the general Spin CLI does not by itself grant access to Akamai's beta sandbox features.

Step 2: Request the Agent Sandbox preview

Use the official Agent Sandbox page to request access. Confirm which Spin SDK package, templates, runtime version, supported language versions, and deployment regions are available to your account. Akamai describes JavaScript and Python as the restricted runtimes for generated code; that does not mean every Python or JavaScript package can run inside the sandbox.

Step 3: Separate the agent from the code it generates

Keep the model client, policy checks, tenant identity, and approved tool orchestration in the agent application. Treat generated code as untrusted input. Pass only the data required for one task into the restricted execution boundary, and return a bounded result to the agent. Never give generated code a raw database connection, unrestricted filesystem access, or a long-lived production credential.

Step 4: Start with deny-by-default permissions

• Leave outbound network access disabled unless a specific destination is required.
• Expose narrow, reviewed tools instead of passing broad API credentials to generated code.
• Set CPU, memory, execution-time, and output-size limits using the supported controls in the beta SDK.
• Keep each customer's state and tool credentials separate; derive tenant identity from your authenticated application context, not from model-generated text.
• Store only the minimum state needed between steps.

Step 5: Test the boundary deliberately

Before connecting real customer data, create a controlled test suite. Ask generated code to read an environment variable, access a path outside its workspace, make an outbound request to a destination that is not allow-listed, exceed a time or memory limit, and request another tenant's record. The expected result is denial or a controlled failure—not a successful action. These are recommended security tests, not claims that Akamai has published independent results for them.

5. Where Akamai's approach fits compared with a self-managed stack

Akamai's value proposition is reduced operational burden and a shared platform for inference and execution. The trade-off is a beta product with gated access, a vendor-specific deployment environment, and preview constraints. A local model server gives more direct control over model files and hardware, but it does not automatically provide a secure execution sandbox for agent-generated code.

6. Security and privacy: questions to answer before production

Akamai's product pages state that Inference uses zero data retention for prompts and responses. That is a useful published commitment, but teams should still review the beta agreement, account telemetry, support workflows, audit-log scope, region selection, subprocessors, and applicable data-processing terms. “Zero retention” should not be interpreted as a substitute for a vendor security review.

For Agent Sandbox, a WebAssembly boundary and default-deny egress are valuable controls, but no sandbox should be treated as a complete security program. Confirm how secrets are injected, how allowed network destinations are configured, whether DNS and metadata endpoints are blocked, how tenant identity is propagated, what gets logged, and how the service handles abuse and resource exhaustion. Keep authorization in the host application and require explicit approval for high-impact actions such as payments, account changes, destructive database writes, and external messages.

Also remember that sandboxing generated code does not automatically sandbox every tool the agent can call. A carefully isolated Python runtime can still ask a privileged host-side tool to perform a dangerous action if that tool exposes excessive authority. Apply least privilege at both layers.

7. Who should pay attention—and who should wait?

• Worth evaluating now: SaaS teams building code-writing agents, companies already using Akamai Cloud, and developers who want to route open-weight model traffic through an OpenAI-compatible interface.
• Potentially useful later: teams needing long-running, stateful agents. The current preview is described as intermittent, with roughly one-minute steps.
• Probably not urgent: hobbyists running a single local model, teams with low-volume workloads already served economically by Ollama or LM Studio, and developers who need a fully self-hosted execution environment.
• Wait for more evidence: organizations that require public security certifications, published independent isolation tests, firm production SLAs, a full price schedule, or a guaranteed list of supported API features before adoption.

8. What developers should watch next

The next useful evidence will not be another model-count announcement. Watch for a public API reference, a versioned model catalogue, region and GPU availability, final pricing, documented SDK interfaces, clear runtime limits, audit-log details, and independent testing of the isolation boundary. For Agent Sandbox, the key question is how developers express capabilities and how those permissions are enforced across host tools, MCP connections, and generated code.

For Inference, evaluate the model and the serving product separately. A compatible endpoint is convenient, but latency, throughput, queueing, context limits, tool-call behavior, embedding quality, and total cost depend on the selected model and workload. Benchmark with your own representative prompts before switching traffic.

Frequently asked questions

Is Akamai Inference generally available?

No. As of November 3, 2026, Akamai's announcement and product page describe beta access. Request access and confirm the terms for your account.

Is Akamai Agent Sandbox open source?

Akamai says the sandbox capability is delivered through its open-source Spin SDK extension to the Spin project. The managed Akamai Functions service and its beta access are separate from the open-source Spin framework. Review the exact SDK repository and licence supplied by Akamai before depending on a particular component.

Can I use my existing OpenAI SDK code?

Often, yes. Akamai says most OpenAI API applications can switch by changing the base URL, API key, and model identifier. However, tool calling, structured outputs, and other features can vary by model.

Does Agent Sandbox block all network access?

Akamai describes outbound access as blocked by default. Developers can grant selected access to tools, APIs, and MCP servers. Verify the exact allow-list and policy behavior in the beta documentation.

Can an agent run continuously for days?

The current tech-preview page describes intermittent execution, with each step completing in about a minute. Longer-lived stateful components are described as planned, so do not assume continuous multi-day execution is available today.

Does WebAssembly isolation eliminate prompt injection?

No. Prompt injection can still influence an agent's decisions. A sandbox can constrain what generated code can do, but the host application must still enforce authorization, validate tool arguments, isolate tenant data, and require approval for sensitive actions.

Official sources and further reading

• Akamai announcement — October 27, 2026
• Akamai Inference product page and FAQ
• Akamai Agent Sandbox product page and FAQ
• Spin framework documentation
• Spin v4 installation guide
• SiliconANGLE coverage — October 27, 2026
• Data Center Dynamics coverage — October 29, 2026

Related GyanAangan guides

• Build a Local LLM Gateway with LiteLLM: Route Ollama and LM Studio Through One API — useful background for OpenAI-compatible model routing.
• Build a Multi-Tenant LLM Quota Layer with FastAPI and Redis — complements the discussion of tenant-level limits and API governance.
• MCP Python SDK v2.3.0 Upgrade Guide — useful when exposing carefully scoped tools to agents through MCP.

Bottom line: Akamai's October 27 launch is worth watching because it pairs managed open-weight inference with a runtime boundary for agent-generated code. The strongest near-term use case is not “replace every LLM endpoint”; it is evaluating whether one managed platform can reduce the operational gap between model serving and safe agent execution. Both products are still in beta or tech preview, so verify access, APIs, pricing, and security controls before committing production workloads.