Azure Sandboxes

​

What an Azure sandbox is

• Your cloud, your bill. The container runs in the subscription and resource group you choose. Azure bills you for it directly, per second, only while it runs.
• One container per sandbox. Each sandbox is one ACI container group with one Linux container. The agent starts it, runs commands, installs packages, moves files in and out, and deletes it when it is done.
• No inbound ports. The container gets no public IP address and no open ports. Genesis reaches it only through Azure’s own authenticated management and command services.
• Cleaned up automatically. Stopping a sandbox deletes its container group. If nobody stops it, Genesis stops it after it has been idle for its idle timeout, and the container exits on its own when it reaches its maximum lifetime, even if Genesis is down.
• A narrowly scoped identity. Genesis signs in to Azure as a service principal that you create and that can act only on the one resource group you give it.

​

When to use it

​

How it works

1. You ask. You ask a Genesis agent for something that needs code, for example “compute month-over-month growth by store and give me a CSV”. The agent decides to use an Azure sandbox, or you ask for one by name.
2. Genesis signs in to Azure. Genesis uses your saved Azure connection to get a short-lived access token from Microsoft Entra ID for the service principal.
3. Genesis creates the container. Genesis asks Azure Resource Manager to create a container group named genesis-sbx-<random> in your resource group and region, and waits until it is running. With the default image this takes about 25 to 30 seconds.
4. The agent works in it. Each command runs through Azure’s container exec service. Genesis connects out to an Azure exec endpoint for the region on port 19390, sends the command, and reads back the output. Each command adds about two seconds of overhead on top of its own run time. Files and installed packages stay in the container between commands.
5. The agent brings results back. Command output comes back to the chat, and the agent can download files the code wrote, such as a CSV or a chart.
6. The sandbox is deleted. When the work is done, the agent stops the sandbox and Genesis deletes the container group. Everything inside it is gone.

​

What runs where

​

Lifecycle and cost safety

az container list --resource-group genesis-sandboxes \
  --query "[?tags.\"genesis-sandbox\"=='true'].{name:name, provisioning:provisioningState}" -o table

​

Security model

• A scoped principal. Genesis acts in Azure as a service principal that you create. Grant it Contributor on the sandbox resource group only, or, for least privilege, a custom role with exactly the five permissions Genesis uses; see Least-privilege role. It cannot see or change anything outside that resource group.
• An encrypted secret that stays in Genesis. The client secret is stored as an encrypted Genesis secret. Genesis uses it only to request short-lived Azure access tokens. It is never passed into the sandbox container.
• Access follows the person asking. An agent can use an Azure connection only when the user it is working for, and the agent itself, are allowed to use that connection. Genesis checks this on every start, the same way it does for every other connection. Agents cannot supply their own Azure credentials when they start a sandbox: Genesis refuses a start that carries a tenant ID, client ID or client secret instead of a saved connection, so every sandbox can be found, reattached and deleted later as the same identity.
• Each sandbox stays where it was created. A sandbox is bound, when it starts, to the connection, subscription, resource group and region it was created in. Editing the connection later does not move or redirect sandboxes that already exist.
• No inbound network access. The container group has no public IP address and no exposed ports. Commands reach it only through Azure’s authenticated exec service, using a one-time session Genesis requests from Azure Resource Manager for each command.
• Outbound internet is on by default. Like any Container Instances container, the sandbox can reach the internet, which is what lets the agent pip install packages. To control where it can go, attach it to a subnet in your own virtual network and apply your network rules there; see Virtual network.
• Environment values stay hidden. Environment variables Genesis passes to the container are sent as Azure secure values, so they do not appear in the Azure portal or in Azure Resource Manager responses.
• Results are checked end to end. Each command and its output are carried with a checksum computed inside the container, so a command is never run, and output is never returned, if it was damaged on the way.

​

Limits

• Linux containers only. Windows containers are not supported.
• Any Azure region that offers Container Instances. Each connection uses one region. To run sandboxes in two regions, create two connections.
• Start time. About 25 to 30 seconds with the default image. Larger custom images take longer to pull. Genesis waits up to 10 minutes for a sandbox to start.
• Command overhead. About two seconds per command, on top of its own run time. Ask the agent to put related steps in one script rather than running many tiny commands.
• Size. 1 vCPU and 1.5 GB of memory by default. Larger sizes are available within the limits Container Instances allows in your region and your subscription’s quota.
• Not yet tested at launch. Attaching sandboxes to a virtual network subnet and pulling images from a private registry are supported, but were not tested end to end at launch. Try them in a non-production resource group first.

​

Next steps