Skip to main content
This page is an RFC draft. Comments are welcome on PR #3023.
ASP is the harness-to-sandbox edge of the managed-agents architecture Initially proposed by and codesigned with @alexgshaw

​
TL;DR

  • ASP lets any agent harness execute its tools in a remote sandbox through .asp.json; SSH is the first transport because it already provides command execution, file transfer, and authentication that every sandbox can expose.
  • An agent implementing ASP does not realize it operates on a remote machine: all of its tools execute in the sandbox, so the sandbox is the only environment it can observe.
  • Agent tools have two layers, a model-facing policy layer (schemas, truncation, pagination) and a mechanism layer doing raw I/O; ASP swaps only the mechanism from local I/O to I/O over the network, and the policy layer remains unchanged.
  • To support ASP, an existing agent only needs two additions: detect .asp.json, and route its tools’ raw I/O (read, write, exec) through the configured transport instead of the local machine. alt text

​
Goal

Decouple the brain from the hands! Standardize the interface between an agent harness (the brain: agent loop, LLM calls, credentials) and the sandbox where its tools execute (the hands: filesystem, shell). Any harness should drive any sandbox through one declarative config file and a standard transport, with no provider SDK in the harness.

​
Background

Coding agents are ubiquitous, and non-coding agents increasingly rely on execution environments too. Yet most agents run in the same environment they execute code in. In low-trust or cloud settings the two are better separated, as argued in Vercel’s post on security boundaries in agentic architectures: credentials and host information stay out of the agent’s reach, the agent cannot OOM or kill its own runtime, and infrastructure can be tuned per side, for example disabling internet in the sandbox while the runtime keeps connectivity. current Today only an agent’s own developers can make that split, by rewriting its execution tools to route into a sandbox. Everyone building on top of an existing agent (Claude Code, Codex, pi) inherits its tools and cannot decouple. Shared environments hurt reproducibility, and sandbox internet access is a major reward-hacking channel, yet cutting it is impossible while the agent runs inside the sandbox, so developers fall back to brittle allowlists of model endpoints. Anthropic’s managed agents decomposes an agent system into session, orchestration, harness, sandbox, resources, and tools, and achieves the split by installing an environment worker inside the sandbox, which couples the sandbox to that harness. Provider SDK integrations do the reverse and couple the harness to one provider. On the other hand, SSH already implements the primitives the missing interface needs. It can run commands, transfer files through SFTP, and handle authentication and host verification. Many sandbox providers are already reachable over SSH or can be configured that way. What’s missing is a shared convention for telling a harness to run its tools remotely and describing how to connect. ASP provides that convention.

​
Scope

Measured against the managed-agents component table, ASP is deliberately niche. It standardizes only the harness-to-sandbox edge, and within that component’s interface only execute(name, input) -> String. The provision({resources}) half is explicitly out of scope, provisioning is the orchestrator’s job (e.g. harbor), done before the agent starts by tooling such as daytona_setup.py and docker_setup.py, and the agent must not have the freedom to provision at runtime. Sessions, orchestration, resources, and tool definitions remain whatever the harness already does. Of the sandbox interface, ASP takes execute and rejects provision ASP adopts execute and deliberately excludes provision.

​
The contract: .asp.json

Check full definition at asp.schema.json. Examples: daytona and docker. A harness that finds .asp.json (working directory, then parents) binds its tool I/O to the sandbox. Tool calls are stateless, fresh shell per command, persistent filesystem. The agent is unaware of any of this. It is not told about the transport, and it could not act on the knowledge anyway: all of its tools execute remotely, so it has no verb that reaches the harness machine and no way to inspect the environment the harness runs in. The only environment it can observe is the sandbox itself. The boundary is enforced by capability, not by policy or prompt.

​
Architecture

An agent’s tools split into two layers. The policy layer is model-facing: the tool schema (path, offset, limit), truncation limits, pagination. The mechanism layer is a small seam of raw I/O functions underneath (read, write, exec). ASP swaps only the mechanism, local I/O becomes the same I/O over the transport; the policy layer runs unchanged in the harness, so the model sees identical tool behavior and existing prompts and evals carry over. ASP Diagram

​
Two Agent ASP examples

Minimal Python agent running a task in a Daytona sandbox over ASP The vanilla agent running in Daytona with ASP

​
Internet configurability

ASP composes cleanly with sandboxes whose internet is turned off. SSH is ingress: a stateful firewall admits replies on connections the harness initiated while dropping every connection the sandbox starts, so tools keep working with all egress dead (verified on Daytona and Docker).

​
Future steps

Soon, we are planning to add terminus-slim, an ASP-based version of Terminus. ASP v0 begins with SSH, but the format can later support transports such as stdio and HTTP. In the future, a more opinionated version could define transport-independent operations and types for generating SDKs. This is a v0 draft so everything here, including the schema, is subject to change in v0.1 or v1. Comments are welcome!.

​
Appendix for support matrix

SSH SDKs Sandbox providers

​
References