Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions
open-standards/sandbox/spec/mcp.md
Transaction Science ba1212361f Add aac, map, sandbox standards; catalog the standards family 
Commit the previously-untracked standard directories and catalog them in the
root README alongside proof:

- aac/    — communication cargo class: portable boards + a ten-level
            offline-first cascade (Apache-2.0 code / CC-BY-4.0 spec).
- map/    — geospatial cargo class: range-requestable signed tilesets +
            an F0–F4 fidelity cascade (Apache-2.0 code / CC-BY-4.0 spec).
- sandbox/— isolated, metered, attested execution across the heterogeneous
            compute fabric (Apache-2.0 code / CC-BY-4.0 spec).
- jouleclaw-otel-authz, jouleclaw-trust — new jouleclaw reference crates.

Root README now lists aac, map, sandbox, and proof in the catalog, the tree,
and the contribution guide.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-07 17:04:36 -04:00

2.1 KiB
Raw Permalink Blame History

MCP server (agent integration)

A Sandbox host MAY expose itself as a Model Context Protocol server so that agents (Claude Code, Cursor, Codex, and any MCP client) can run untrusted code in the sandbox as a tool call. An MCP server is table stakes for an agent sandbox; the distinguishing feature here is the tool result.

The differentiator: an attested result

Every other agent sandbox returns the program's output. A Sandbox MCP server returns the output and a signed, energy-metered receipt of the run: the per-device joule receipt (JCR-1), the Ed25519 attestation, and a RATS EAT (spec/eat.md). The agent — or whoever audits it later — gets a verifiable record of what ran, at what isolation tier, and what it cost in joules, signed by the host. That binding (attested joules per run, delivered through the agent tool surface) is what no other sandbox tool emits.

Tools (reference)

sandbox-mcp (newline-delimited JSON-RPC 2.0 over stdio) exposes:

  • run_wasm — run a WebAssembly unit (run: () -> i32) at tier S2 under explicit capability grants (cpu_time_ms, memory_bytes, energy_budget_uj, kv, clock, storage_read/storage_write globs, max_iops). Agent-supplied code is untrusted, so it minimizes to S2. The result is the attested receipt: tier, outcome, per-device energy with provenance, receipt_id, attestation_id, the EAT (hex + profile + tier), the metered storage line, and the host's verifying keys. The server verifies the receipt, attestation, and EAT before returning — it hands back nothing it has not checked.
  • verify_eat — verify a Sandbox EAT against a public key and return the recovered claims.

The result carries both a human-readable text block and MCP structuredContent, so a client can render the receipt or consume it programmatically.

Capability mapping

The MCP tool input is the capability grant: a field that is not set is not granted (deny-by-default, SPEC §5). There is no ambient authority — an agent cannot reach the network, the filesystem, or a subprocess unless the tool call named it, and whatever it does name is metered and attested.