Sandbox and Sidecar

Every run executes in a short-lived sandbox next to a sidecar. The sandbox holds the agent. The sidecar is the only way out: it injects credentials, enforces the network rules, serves the platform tools and relays model calls. The model never sees a raw token.

Execution backends

The RUN_ADAPTER setting chooses how the sandbox is built. The default is process.

Isolation guarantees below (network separation, no direct egress) describe docker and firecracker. Credential hiding applies in every mode. Use docker or firecracker for anything beyond local development. See Progressive Infrastructure and Isolation and Security for the operator side.

Shape of a Docker run

┌───────────────────────────────────────────────────────┐
│  Per-run network appstrate-exec-<runId>  (internal)   │
│                                                       │
│  ┌────────────────┐     ┌──────────────────────────┐  │
│  │ Agent container│────►│ Sidecar                  │  │
│  │ Pi agent, no   │     │ :8080  /mcp  /llm        │  │
│  │ credentials    │     │ :8081  forward proxy     │  │
│  └────────────────┘     └───────────┬──────────────┘  │
└─────────────────────────────────────┼─────────────────┘
                                      ▼
                        shared egress network ──► internet

For each run, the platform:

1. Creates an internal-only Docker network (no direct route out) and a workspace volume. The workspace is a RAM-backed tmpfs capped at WORKSPACE_TMPFS_SIZE_MB (512 MiB by default).
2. Starts the sidecar, attached to the run network and to a shared egress network, and the agent container, in parallel.
3. Gives the agent the address of its sidecar, its prompt and its model endpoint. The agent's HTTP traffic is pointed at the sidecar's forward proxy.
4. Runs the agent until it finishes, fails, is cancelled or times out, then removes both containers, the network and the workspace.

Memory and CPU of the agent default to 1536 MiB and 2 vCPU and can be requested per agent within operator ceilings. See Configuring agent resources. The runtime and sidecar images are pulled at boot and kept warm so a run does not pay a cold pull.

What the agent can and cannot do

The secrets of a run (the sidecar address and token, the keys that sign its events) are passed to the agent runtime over stdin and are never in its environment. The runtime process is made non-dumpable, so nothing the agent spawns can read them from /proc. The platform's own run token never enters the agent container.

What the sidecar does

The sidecar is a small server in front of everything the agent reaches.

• A single MCP endpoint. Everything beyond the sandbox is an MCP tool served at /mcp: the {namespace}__api_call and MCP tools of each integration, run_history, recall_memory, and the runtime tools the agent selected. Every request must carry the run's sidecar token.
• Credential injection. For an integration call the sidecar fetches the connection's credentials from the platform at request time, substitutes them into the request, checks the target against the integration's authorized_uris, and sends it. The response comes back without any credential. A call that would carry a credential to a host the integration did not name is refused.
• Model relay. Inference goes through /llm. The sidecar holds, or fetches, the provider credential. API-key models are served through the platform's LLM proxy, which meters usage (see Run cost).
• Network policy. All outbound traffic leaves through its forward proxy, through the proxy that resolved for the run, if any.
• Integration runners. An integration backed by a local MCP server is spawned by the sidecar in its own container on the same run network. It gets its credentials from the sidecar but can reach only the hosts of its connection's allowlist.

SSRF protection

Every target, and every redirect hop, is checked three ways: a literal check against private, loopback, link-local and metadata ranges (including IPv4-mapped IPv6) and against the names localhost and every *.localhost; a DNS check that refuses the call if any resolved address is blocked; and resolve-and-pin, so the connection goes to the address that was validated. A host that must be reached on an internal address is listed by the operator in EGRESS_ALLOW_INTERNAL_HOSTS. A refused call returns an error that says which guard tripped.

Large results

Tool output above an inline cap is not pushed into the model's context. It is stored for the run and the model receives a link to read it. The caps (per call and per run) are operator settings, see Environment Variables.

Observability

The sidecar does not keep a separate audit log. What happened is visible in the run's logs, the denormalized columns of the run (model, proxy, connections used, trigger), the live cost stream and, when the observability module is enabled, OpenTelemetry traces and metrics. See Runs, Run cost and the observability notes.

Going deeper

The full protocol (tools, authentication, retries, the egress allowlist, the transparent plane for MCP servers that ignore proxy settings) is in SIDECAR.md and INTEGRATIONS_RUNTIME.md.