Arcstone Sidecar MCP server

Arcstone Execution Boundary

Repository identity: arcstone-mcp-sidecar Implementation package: arcstone-execution-boundary Status: Experimental / Downstream / Non-Canonical / Bounded Evidence Version: 0.1.0 implementation starter

This repository is the initial native implementation of the frozen Arcstone Execution Boundary v0.1 experimental specification.

It tests one bounded question:

Can a deterministic downstream execution boundary prevent an untrusted or nondeterministic producer from causing a protected side effect unless an explicit, boundary-controlled authorization condition has been satisfied?

Frozen upstream relationship

Arcstone Continuity Core
                        FROZEN
                       /      \
                      /        \
                     ▼          ▼
       Path A Ingress Lab    Execution Boundary
          COMPLETE/FROZEN       THIS REPO

The Path A Ingress Lab and Execution Boundary are sibling downstream investigations.

This repository does not modify or reinterpret either frozen upstream repository.

v0.1 invariants

I1 — NO VALID AUTHORIZATION
     ⇒ ZERO PROTECTED ACTUATION

I2 — ONE VALID SINGLE-USE AUTHORIZATION
     ⇒ AT MOST ONE PROTECTED ACTUATION

I3 — UNTRUSTED PRODUCER
     ⇏ PROTECTED RESOURCE

The implementation explicitly keeps separate:

authorization lifecycle
≠ gate decision
≠ actuation result
≠ observed protected effect

What is intentionally not here

v0.1 does not require or claim:

• MCP
• WASM
• HMAC / signatures / PKI / KMS
• network APIs
• generalized policy engines
• agent frameworks
• package-manager publication
• public production distribution guarantees
• exactly-once real-world execution
• production authorization security
• AI alignment or general agent safety

Local data model

The experimental root has this shape:

runtime/
├── auth/
│   ├── issued/
│   └── consumed/
├── protected/
│   └── effect.bin
└── evidence/
    └── <run-id>/

An authorization record is trusted because the untrusted producer is not permitted to create or modify the auth tree under the tested authority configuration. The authorization identifier itself carries no authority.

The consumed/.claim file is created with create_new(true). That atomic local reservation is the v0.1 single-use claim primitive.

Build

Windows CMD:

cargo build
cargo test

or:

scripts\windows\verify.cmd

Example

Create the runtime directories:

arcstone-exec init --root runtime

Issue one authorization:

arcstone-exec issue --root runtime --auth-id AUTH-001 --action WRITE_PROTECTED_FILE --resource-id EFFECT_LOG --payload-hex 48454c4c4f

Create request.json:

{
  "authorization_id": "AUTH-001",
  "action": "WRITE_PROTECTED_FILE",
  "resource_id": "EFFECT_LOG",
  "payload_hex": "48454c4c4f"
}

Execute it:

arcstone-exec execute --root runtime --request request.json --run-id manual-001

Inspect authorization state:

arcstone-exec inspect --root runtime --auth-id AUTH-001

A replay of the same request should return a denied result because the claim already exists.

Windows authority-boundary evidence

The Rust tests verify deterministic authorization, binding, consumption, replay, failure separation, and concurrent claiming.

They cannot by themselves prove producer-to-resource authority separation when producer and boundary run under the same Windows principal.

A separate bounded Windows authority experiment was therefore completed using distinct non-administrator producer and authority principals and a dedicated disposable runtime with explicit ACL separation.

Observed results:

Shortened. The full README is on GitHub.