Sandbox

Sandbox Playground

Onboard an MCP server and run it as a sandbox run - our own copy of the published package, inside a sandbox this host must first prove can block network egress and confine the host filesystem, both observed before anything is spawned. Because the artifact is our own fetched copy running in our own container with no third party reachable, every tool may be exercised and the server is judged by witnessed behavior, not just what it declares. That is the contrast with a static scan, which reads source and metadata without executing anything, and with a live URL, which only ever gets a read-only enumeration. The scan form runs a published package the same way by default where a runner exists, and statically where it does not.

Sandbox runs happen only where this deployment can actually build a confining sandbox. Where it cannot, the run is refused honestly (a service-unavailable response), never reported as a clean pass - refused is not clean.

Sandbox run - the fetched artifact runs in a sandbox this host has proved can block network egress and confine the host filesystem.

or drag a .json file here, or paste above

Must parse as JSON with an mcpServers object. Multi-server configs are accepted as-is (cross-server observation is a later phase). env values are your responsibility - do not paste live secrets into a public playground.

Rule scope

Full registry scan - all 184 active rules in scope

Sandbox run - the fetched artifact runs in a sandbox this host has proved can block network egress and confine the filesystem, then the result view opens. A public sandbox run is not listed in the public registry.

What a sandbox run produces

On a host that can build a confining sandbox, the run executes and the result view shows:

  • Severity-ranked findings from the deterministic engine - each named, with any OWASP MCP / MITRE ATLAS mapping it carries, plus a per-server coverage note showing what did and did not run (out-of-scope is never dressed up as a clean pass).
  • Watch it run - a per-tool step-through of the witnessed behavior of the highest-risk tools (a risk-ordered sample, not the whole surface): declared annotation hints vs what running each did - filesystem writes observed host-side, and outbound attempts the tool’s own output evidenced (sandbox-blocked at the routing layer) - plus the redacted input/output and the tool→tool feeding chain. A tool that declared readOnlyHint: true but was caught writing or reaching off-box is flagged as a divergence.
  • Cross-server intelligence (multi-server config): the deterministic risk matrix (P01–P12) and kill-chain patterns (KC01–KC07, always hypothetical) over the observed servers, plus any observed cross-server flow - a real read on one server composed into a real egress attempt on another, both inside the sandbox.

The intelligence layer is deterministic - risk patterns and kill chains, no LLM guessing in the analysis path. A live adversarial-LLM narrative is a future authenticated-workspace capability; it is deliberately not run on this public page, because an anonymous live-LLM pass is an unbounded cost surface. Everything above degrades honestly: where the host cannot build a confining sandbox, the sandbox observation is reported as a coverage gap (the console simply does not appear, and the scan continues source-only) - never a clean pass.