Code isolation

Submitted code runs in a fresh QuickJS WebAssembly environment inside a worker thread. The guest has no general network client. Only allowlisted calls to documented Tamperbox API routes cross the host boundary.

Data path

Code and embedded inputs are visible to the MCP client and model provider. When execute calls an operation, its request input is sent to the configured Tamperbox API. A remotely hosted MCP service also receives the submitted code and embedded values.

Use synthetic examples for evaluation. Prefer browser-local tools for sensitive material that should not leave the device.

Evidence boundaries

• JWT decoding does not verify signature authenticity or issuer trust.
• DNS evidence does not prove email delivery or mailbox existence. A published DKIM key, for example, does not prove any message is signed with it (why).
• HTTP headers do not establish the complete security of a site, and one TLS handshake from one location does not establish what every client negotiates (why).
• A redirect trace or a CORS preflight sent from the service is one observation from one place: cookies, client addresses and firewalls can make a visitor’s browser see something else (why).
• A decoded JWT is readable, not trusted; a signature match proves only that the supplied key verifies those bytes (why).
• A failed probe is not the same as a negative result.
• Caller-context checks can observe a proxy, shared gateway, or MCP host.

Unsupported authority

Tamperbox does not authenticate to DNS accounts, send mail, publish records, or mutate third-party services. It inspects and transforms within the documented API contract.

Report security issues through the process in the Tamperbox MCP security policy.