Microsoft announced general availability for Azure Container Apps Sandboxes on September 23, 2026. Each sandbox provides a hardware-isolated microVM with its own Linux kernel, aimed at workloads such as agent execution and multi-tenant code processing. Read Microsoft's GA announcement.
This follows the preview coverage already on the blog. The production discussion should now focus on the controls around execution: which services code can reach, which credentials it can use, what state survives, and whether an operator can reconstruct what happened.
My recommendation is to evaluate those controls together. An isolated machine is one part of the design, not a complete authorization or data-handling policy.
Egress Restrictions Are Not Enabled Automatically
The current egress guide is explicit: without an egress policy, a sandbox has unrestricted outbound access. Policies are opt-in. You can configure default-deny behavior and permit the destinations the workload needs; advanced rules can also match paths and methods or transform requests. Egress policy documentation.
That is the first setting I would review in an agent pilot. Start with a written list of required destinations and explain why each is necessary. Separate access needed to prepare an environment from access needed while executing a user task.
My acceptance test would exercise an approved destination and a deliberately prohibited one. Review the policy decision as well as the application's response. A connection failure alone does not prove that the intended security rule caused it.
The guide evaluates rules in order, with the first match winning, and provides a network audit view. Keep broad rules from accidentally taking precedence over narrower restrictions. Rule ordering and audit guidance.
Keeping a Secret Outside the Sandbox Is Useful, but Not Sufficient
Microsoft's announcement describes proxy-side header transforms that inject credentials from sandbox-group secrets outside the sandbox. It also describes egress webhooks for decisions that require an external authorization service. Credential injection and dynamic decisions.
My recommendation is to review what an allowed request can do, not only whether the caller can read the credential. Code permitted to call a powerful API may still perform an unwanted action through that API.
For a document-processing pilot, for example, distinguish permission to retrieve the assigned input from permission to enumerate every document in an account. Use a task-specific authorization design at the destination or proxy layer, and test an attempted request outside that task's scope.
Also check the return path. A downstream service that echoes sensitive headers or returns more data than intended can undermine an otherwise careful credential-injection design. Use controlled test data for that review.
Define Exactly What Should Survive a Session
The lifecycle documentation distinguishes running from stopped compute. Stopping preserves disk state, can optionally preserve memory, and stops compute billing. Policies can suspend idle sandboxes and later delete stopped ones. Sandbox lifecycle.
Microsoft also documents disk snapshots, combined disk-and-memory snapshots, and persistent volumes whose data can outlive the sandbox itself. State and storage capabilities.
I would define a retention rule for each kind of state before enabling automatic reuse. A clean reusable image, a customer's working session, and an audit record have different purposes and should not share an accidental retention policy.
Test a full sequence with non-sensitive fixtures: create, write state, suspend, resume, finish, and clean up. Verify what is restored and what remains after the sandbox is removed. Do not infer that deleting compute also deletes every associated artifact.
For multi-tenant workloads, include a test that a newly assigned task cannot observe another tenant's files or restored context. Give that test an explicit pass condition rather than relying on a successful happy-path demonstration.
Configure Telemetry Before the Work Starts
Sandbox telemetry is opt-in and configured at creation time. Omitting telemetryConfig means no telemetry is exported through that configuration, although Azure Monitor resource metrics remain separate. Available categories include console output, application OpenTelemetry signals, operational metrics, and network egress decisions. Telemetry configuration.
My recommendation is to treat the telemetry destination as part of the creation template. An operator should be able to trace a task to its sandbox, find the relevant policy decisions, and distinguish application failure from lifecycle or dependency failure.
Use an application task identifier that can be correlated with the sandbox identifier, while avoiding sensitive payloads in routine logs. Decide who can read the records and how long they are retained.
The documentation also separates exporting egress decisions from enforcing egress policy. Sending a decision record to a log destination does not itself establish that an unwanted request was blocked. Export versus enforcement.
Keep the GA Boundary Precise
The announcement lists Python and TypeScript SDKs, with .NET still forthcoming. It also labels the ACA Terraform provider and Connectors/Triggers integration as preview. General availability of Sandboxes does not make every adjacent integration generally available. Tooling and roadmap status.
For a production proposal, I would record the status of each component the application actually depends on. A core service and its integration path may have different adoption constraints.
Practical Cloud Engineer Takeaway
My proposed GA-readiness checklist is:
Choose the isolation unit: tenant, session, or task.
Configure and test egress restrictions explicitly.
Limit what permitted APIs can do on behalf of each task.
Define snapshot, volume, and session retention separately.
Configure telemetry during creation and verify records reach the destination.
Exercise suspend, resume, failure, and cleanup with controlled fixtures.
Confirm the support status of the SDKs and integrations in the proposed design.
These are recommended validation steps, not a claim of hands-on testing or a guarantee against malicious code.
Who Should Care?
AI platform engineers, multi-tenant SaaS teams, and developers building code-execution services or persistent agent workspaces.
Bottom Line
Sandboxes GA provides useful execution primitives. The production value comes from configuring and verifying the surrounding policies so that isolation, permitted actions, retained state, and audit evidence work together.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments