Platform and runtime reference
The exact values behind the platform's connected tools and execution surface. MCP transports and auth modes, sandbox host kinds and resource classes, and the secret policy matrix.
This page is the value reference for the platform layer: the connected tools the agent can call, the hosts and resource classes a sandbox runs under, and the policy that governs where a secret may travel. The concepts behind these live in their own guides, MCP tools, sandbox hosts, and credentials and the secret policy. This page is the flat catalog those guides point back to, where you confirm a transport, a host kind, a resource class, or a delivery mode by its exact name.
This page is the value catalog. The reasoning behind the secret policy, and the security guarantees it makes, live on credentials and the secret policy. Come here for the exact names; go there for the why.
MCP transports and auth modes
A connected MCP server is reached over one of three transports and authenticates in one of a few ways.
Transports
| Transport | What it is |
|---|---|
http | A server reached over HTTP. |
sse | A server reached over server-sent events. |
stdio | A local server the platform runs as a process and talks to over standard input and output. |
One-click installation from the catalog is available for an http server that signs in with browser OAuth. An sse server, a stdio server, or an http server that uses any other sign-in is added by hand in the connection editor, where you set the transport and the auth yourself.
Auth modes
The connection editor offers five ways to authenticate a server.
| Auth mode | What it does |
|---|---|
none | No authentication. |
browser-oauth | Sign in through a browser OAuth flow. |
cli-session | Reuse a signed-in CLI session. |
env-bearer | Send a bearer token from an environment value. |
custom-header | Send a credential in a header you define. |
Two auth shapes sit outside the five-option menu and are worth naming. A GitHub token auth shape exists and is used by connected GitHub servers, but it is not one of the five options in the editor; it is set up through the GitHub connection rather than chosen from the auth menu. And device code is not a separate mode but a variant of browser OAuth, used where a provider signs in that way, such as Azure DevOps through Microsoft. For those, the sign-in completes with a device code and the credential is stored per person.
A few rules govern how MCP connections behave. A server's configuration is workspace-scoped, while its credential can be per workspace or per person, depending on how it signs in. Custom MCP servers are turned on by the custom MCP entitlement, on the Business plan and up. A connection takes effect on the next session, not the one already running, since the tools are loaded when a sandbox starts. And which of a server's tools are available is set on the connection, so a workspace can narrow a server to the exact tools it wants the agent to have.
Sandbox hosts and runtime
A sandbox runs either on the platform's managed compute or on a host you bring.
Host kinds
| Host kind | What it is |
|---|---|
kubernetes-operator | Your own Kubernetes cluster, driven by an operator you install. |
local-docker-operator | Your own Docker engine, driven by a local operator. |
Those are the two host kinds you register. Managed compute is the default and needs no registration: when a sandbox profile names no host, the platform runs it on its own managed hosts, so a workspace works out of the box without bringing anything. Registering a host of your own is the bring-your-own-host capability, on the Business plan and up. Two further host kinds, an Azure Container Apps operator host kind and a custom HTTP host, are reserved in the model and not yet usable.
Of all the places a sandbox can run, only managed compute on Azure Container Apps is metered against your compute quota. A sandbox on a host you brought runs on your own compute and is not metered.
Resource classes
A sandbox profile picks a resource class, which sets the CPU and memory a sandbox gets. A profile can also override either value.
| Resource class | CPU | Memory |
|---|---|---|
planning | 1 | 2 GiB |
development | 2 | 4 GiB |
development-large | 4 | 8 GiB |
Managed command enforcement
A profile sets how strictly it governs the commands a sandbox can run.
| Mode | What it does |
|---|---|
advisory | The default. The agent is told the policy and is expected to follow it. |
redirect-known | Known commands are redirected to their managed equivalents. |
strict-command | Known commands must run through their managed form, and the profile can drop the agent's shell from its tools. |
The secret policy matrix
Where a credential may travel inside a sandbox is governed by a policy with two axes: the phase of the sandbox's life, and the delivery mode by which a secret could reach it. The two axes meet in a grid, and each cell carries one answer: for this phase, by this delivery mode, is a secret allowed to travel or not. Reading the policy is reading one cell. The deep treatment of this, and the security model behind it, is on credentials and the secret policy. This page is the catalog of the two axes and the one guarantee that is enforced today.
The five phases
A sandbox moves through five phases, and the policy can answer differently for each.
| Phase | When it is |
|---|---|
template-seed | The container is seeded from its template. |
package-install | Dependencies are installed. |
mcp-cold-start | Connected tools are brought up. |
agent-turn | The agent is doing the work. |
sidecar-internal | The sidecar's own internal operations. |
The eight delivery modes
A secret could in principle reach a process eight ways, and the policy names each so it can allow or forbid it per phase. These are the same delivery modes an environment uses to describe how a capability's credential is provided.
The grid below is the target matrix, the map of where each kind of secret should and should not travel. Of its cells, one is enforced today; the rest describe where the model is headed. The live guarantee is in "What the policy guarantees today" just below.
| Delivery mode | What it is |
|---|---|
forbidden | Not delivered at all. |
process-env | An environment value on a single spawned process. |
temp-file | A short-lived file. |
stdin | Piped to a process on standard input. |
git-askpass | Provided to git through its askpass mechanism. |
package-config | Written into a package manager's config. |
proxy | Supplied by a proxy that holds the credential. |
host-exec | Resolved on the host at the moment of use. |
What the policy guarantees today
One guarantee here is enforced now, and it is the one that matters most: a managed secret can never be a standing environment value on a sandbox. A model-provider key, a git token, or another managed credential is refused at the moment a sandbox launches if it appears in the launch or profile environment, so a secret cannot be quietly baked into a container and left there. The full per-phase matrix around it is the target the platform is building toward, a map of where each kind of secret should and should not travel as the model is enforced phase by phase. The deep version of how a credential reaches a run when it genuinely needs one, leased for a single operation and cleaned up after, is on credential leases.
Why the platform layer is shaped this way
Every value on this page is a configuration choice with a consequence you will live with on a real run. A transport decides whether a tool installs in one click or by hand. A host kind decides whose compute the work runs on and whether it is metered. A resource class decides how much a sandbox gets. A delivery mode decides whether a credential is allowed near a process at all. None of these is an implementation detail you can ignore once real work is running. Each one is a choice you make at setup and live with at run time, which is why this page names them in full.
The secret policy is the clearest case of the design the whole platform follows. The matrix is honest about being a target, and the one cell that is live is stated plainly, because a security claim is only worth making if it draws the line between what is enforced and what is intended. A reader can take the live guarantee to a review and read the rest as the direction of travel.
For a platform engineer, this is the page behind configuring a workspace: the transports and auth modes when you connect a tool, the host kinds when you bring your own compute, the resource classes when you size a profile.
For an administrator, the host and metering facts are the ones to keep. Managed compute is the default and the only metered option; a host you bring runs on your compute and is not counted.
For an enterprise reviewer, the secret policy section is the one to read closely. The two axes are named in full, the live guarantee is stated without overreach, and the security framing it belongs to is one click away.
For a prospect, the takeaway is that the platform is configurable at the edges without being a maze: a handful of transports, two host kinds plus a managed default, three resource classes, and a credential policy with a guarantee you can check.