MCP Sandbox Authority Boundary Profile

Abstract

A profile for making an authority boundary observable.

The MCP Sandbox Authority Boundary Profile is a vendor-neutral, synthetic-only evaluation artifact for characterizing whether an MCP-connected execution sandbox preserves its declared authority boundary. It covers repository and storage scope, workload credentials, revocation timing, network and DNS egress, session isolation, cross-interface consistency, independently reviewable evidence, and cross-module composition. Its purpose is to produce bounded, reviewable observations of a named target in one authorized configuration, not to certify a platform or make a provider finding.

Control question

What authority does the environment actually exercise?

A sandbox can appear contained while its effective authority extends beyond the boundary an operator intended. The profile requires an evaluator to state the declared boundary, run both positive and negative synthetic controls, record the observed effective authority, and bind the result to an evidence record. It treats a result as a characterization only: a pass means the observed behavior matched declared policy under that configuration and observation window.

A sandbox may correctly restrict access to one attached repository while still possessing a broadly scoped credential and unrestricted network egress. Each local control can behave as configured while the composed environment exercises authority beyond the operator’s declared boundary.

Profile coverage

Nine questions that a sandbox boundary must answer.

Each observation records the profile and case versions, target-configuration digest, declared and observed authority, action, expected and actual outcomes, timestamps, evidence digest and producer, control outcomes, redactions, reviewer, limitations, and untested dimensions.

How to use it

Run only against an authorized, isolated target.

1. Declare the boundary. Name the permitted repositories, storage, credentials, egress, interfaces, and observation window.
2. Use disposable identities and synthetic data. Do not introduce production credentials, customer data, or unrestricted egress.
3. Exercise positive and negative controls. Demonstrate an authorized path and a deliberately out-of-policy synthetic path before interpreting a denial.
4. Publish a bounded observation. Record what the named configuration demonstrated, the evidence supporting it, and what remains untested.

Evidence and limitations

An experimental profile with a self-contained synthetic example.

• The public release contains a machine-readable profile, a self-contained observation schema, a synthetic characterization example, coverage matrix, changelog, and dependency-free validator.
• The current corrective release is pinned by Git tag v0.1.1 and Hugging Face dataset revision d6046c561ba25ef29e1b7c410fb88531a4d061f4.
• Its synthetic example demonstrates profile structure and evidence requirements. It is not an audit of a named provider or a production environment.
• Consumers should pin profile and schema versions. Future minor releases may add optional fields; breaking semantic changes require a new major version.

Related research

Authority needs architecture, evidence, and adversarial evaluation.