Arcstone Mcp Sidecar

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/<authorization-id>.claim file is created with create_new(true). That atomic local reservation is the v0.1 single-use claim primitive.

Build

Windows CMD:

cargo buildcargo 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:

• T7 direct protected-resource bypass: PASS under the tested ACL configuration
• T8 direct actuator bypass: PASS — bounded public-API/structural result
• T9 forged authorization issuance: PASS under the tested ACL configuration
• I2 single-use / at-most-once authority: supported for the tested authorization
• I3 producer-to-protected-resource separation: supported for the tested Windows configuration

The successful authorized execution transitioned the tested authorization from Issued to Consumed, created the expected protected effect, and a replay was denied before a second actuation attempt.

This evidence does not establish general Windows sandbox security, arbitrary hostile-code containment, production authorization security, or universal bypass resistance.

See docs/WINDOWS-AUTHORITY-BOUNDARY.md for the complete bounded evidence record and freeze limitations.

Machine / AI / autonomous-agent navigation

This repository is intentionally machine-operable and machine-readable.

Start here:

AGENTS.mdmachine/system-manifest.jsonmachine/repo-policy.jsonmachine/protocol.jsonmachine/test-matrix.jsonSTATUS.mdBUILD-REPORT.mdEXPERIMENT.md

Recommended automated traversal:

1. Read machine/system-manifest.json2. Read machine/repo-policy.json3. Read AGENTS.md4. Read STATUS.md5. Read EXPERIMENT.md6. Run cargo test7. Read docs/WINDOWS-AUTHORITY-BOUNDARY.md before making OS-authority claims

Humans are not required in the deterministic request/decision path. Human-facing prose exists primarily for governance, scientific interpretation, and review.

Working principle

Evidence before expansion. Preserve the core. Test the boundary. Freeze completed evidence.