Three things Azure Container Apps Sandboxes still won’t do for you

What actually gets isolated — process, container, or VM?

The boundary is the interesting part. Standard Container Apps run your containers on a shared, multi-tenant Kubernetes-based environment where the isolation between workloads is fundamentally a container boundary — namespaces, cgroups, a shared host kernel. That’s fine for your code. It is not fine for code you didn’t write and can’t trust, because a single kernel exploit is a single kernel exploit.

Sandboxes move the boundary down. Each sandboxed workload gets hardware-level isolation with its own kernel, so an escape from the container no longer lands you on a host shared with other tenants. Treat it as VM-grade isolation delivered as a managed service, not a hardened container. If you’ve built anything with gVisor or Kata Containers, that’s the mental model — Microsoft is running that layer so you don’t have to.

How is this different from a normal Container App?

Three things change, and they’re the three that matter for untrusted code:

• Kernel sharing. Standard: shared host kernel. Sandbox: isolated kernel per workload.
• Egress. A sandbox assumes the code inside is hostile, so network reachability is locked down by default rather than open-by-default. You explicitly allow what it can talk to.
• Filesystem and privilege. Ephemeral, scoped filesystem; no persistence assumptions; reduced ability to poke at anything outside its own boundary.

Everything else — the deployment model, revisions, scaling to zero — stays familiar. That’s the selling point: same operational surface, harder wall.

What is this actually for?

Agentic AI is the honest answer. The moment your LLM app executes model-generated code — the “run this Python and tell me the result” pattern — you are running untrusted code by design, on every request. Same shape for multi-tenant SaaS that runs customer scripts, ephemeral dev environments, and CI jobs from forked pull requests. If the code originates from someone who isn’t you, this is the fit.

If the code is yours, you don’t need this. Don’t sandbox your own API and call it security theatre.

Does it stop container escape? Spectre-class attacks?

Container escape: yes, that’s the whole point — an escape stays inside a per-workload boundary instead of reaching a shared host. Microarchitectural side channels (Spectre, and the steady drip of successors): partially, and don’t bet your compliance story on it. Hardware isolation raises the cost of cross-tenant leakage but no cloud vendor is claiming immunity to the next speculative-execution disclosure, and you shouldn’t infer it from a GA blog post. If your threat model includes a determined adversary mining CPU timing leaks, that risk is shared with the platform, not eliminated by it.

What’s still my job?

More than the marketing implies. The isolation boundary does not manage:

• Secrets. Don’t mount Key Vault references or long-lived tokens into a sandbox running hostile code. Assume anything reachable from inside is compromised.
• Egress filtering. Default-deny is a starting point, not a policy. Data exfiltration and SSRF to the metadata endpoint or your internal network are yours to design against.
• Identity. If you attach a managed identity, its permissions are the blast radius. Scope it to nothing, or near it.
• Resource abuse. Set CPU/memory limits and timeouts, or your isolated workload becomes an isolated cryptominer that you’re paying for.

How do I turn it on?

It’s a property on the container app / job, not a separate resource type. Confirm the exact field names against the GA docs before you commit IaC — the surface is fresh. The pattern in Bicep:

1
2
3
4
5
6
7
8
9
10
11

// Illustrative pattern — verify resource type, API version, and all properties against GA docs
resource sandboxJob 'Microsoft.App/jobs@2024-03-01' = {
  name: 'untrusted-exec'
  location: location
  properties: {
    environmentId: managedEnvironmentId
    configuration: {
      replicaTimeout: 300
    }
  }
}

And validate before deploy — always:

1
2
3

az deployment group what-if \
  --resource-group rg-sandbox \
  --template-file sandbox.bicep

What does it cost, and where can I run it?

Consumption-based, in line with the rest of Container Apps — you pay for what the sandbox consumes while it runs, which suits bursty agent and CI workloads. Exact rates and the GA region list are on the update page (azure.microsoft.com/updates?id=561262); I’m not going to invent numbers or regions here. Check availability in your region before you architect around it, because GA rarely means everywhere on day one.

Should I rip out my gVisor/Kata setup?

If you built it purely to isolate untrusted code and hate maintaining it, probably yes — this offloads the boundary you were babysitting. If you need node-level control, custom kernels, or GPU sandboxing that isn’t offered here, keep it. This is the easy 80%, not a replacement for every isolation design you have.

The wall is real. The gaps around it — secrets, egress, identity scope — are still exactly where someone finds you in six months.