arcstone-mcp-sidecar

Arcstone 実行境界

リポジトリの識別情報： arcstone-mcp-sidecar 実装パッケージ： arcstone-execution-boundary ステータス： 実験的／下流／非正規／限定的なエビデンス バージョン： 0.1.0 実装スターター

このリポジトリは、凍結されたArcstone Execution Boundary v0.1 実験仕様の初期ネイティブ実装です。

検証するのは、次の限定的な問いです。

明示的で境界が制御する認可条件が満たされない限り、信頼されていない、または非決定的な生成元が保護対象の副作用を引き起こすのを、決定論的な下流実行境界によって防止できるでしょうか？

凍結された上流との関係

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

Path A Ingress Lab と Execution Boundary は、互いに兄弟関係にある下流の調査です。

このリポジトリは、凍結された上流リポジトリのいずれも変更または再解釈しません。

v0.1 の不変条件

I1 — NO VALID AUTHORIZATION
     ⇒ ZERO PROTECTED ACTUATION

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

I3 — UNTRUSTED PRODUCER
     ⇏ PROTECTED RESOURCE

実装では、次の項目を明確に分離しています。

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

意図的に含めていないもの

v0.1 では、次のものを要件とせず、実現できるとも主張しません。

• MCP
• WASM
• HMAC／署名／PKI／KMS
• ネットワーク API
• 汎用ポリシーエンジン
• エージェントフレームワーク
• パッケージマネージャーによる公開
• 本番環境向けの一般公開に関する保証
• 現実世界での厳密に 1 回の実行
• 本番環境向けの認可セキュリティ
• AI アラインメントや一般的なエージェントの安全性

ローカルデータモデル

実験用ルートは次の構造です。

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

信頼されていない生成元には、テスト対象の権限設定のもとで auth ツリーの作成や変更が許可されていないため、認可レコードは信頼できます。認可 ID 自体には権限がありません。

consumed/<authorization-id>.claim ファイルは create_new(true) で作成されます。このアトミックなローカル予約が、v0.1 の単回使用クレームプリミティブです。

ビルド

Windows CMD：

cargo build
cargo test

または：

scripts\windows\verify.cmd

例

ランタイムディレクトリを作成します。

arcstone-exec init --root runtime

認可を 1 件発行します。

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

request.json を作成します。

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

実行します。

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

認可の状態を確認します。

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

同じリクエストを再実行すると、クレームがすでに存在するため、拒否結果が返されます。

Windows の権限境界に関するエビデンス

Rust テストでは、決定論的な認可、バインディング、消費、リプレイ、障害の分離、並行クレームを検証します。

ただし、生成元と境界が同じ Windows プリンシパルで動作する場合、これらのテストだけでは、生成元とリソースの権限分離を証明できません。

そのため、個別の非管理者生成元プリンシパルと権限プリンシパル、および ACL を明示的に分離した専用の破棄可能なランタイムを使用して、別途、限定的な Windows 権限実験を完了しました。

観測された結果：

• T7 保護対象リソースへの直接バイパス：テスト対象の ACL 設定で PASS
• T8 アクチュエーターへの直接バイパス：PASS — 公開 API／構造上の限定的な結果
• T9 偽造された認可の発行：テスト対象の ACL 設定で PASS
• I2 単回使用／最大 1 回の権限行使：テスト対象の認可について裏付けあり
• I3 生成元から保護対象リソースへの分離：テスト対象の Windows 構成について裏付けあり

認可された実行が成功すると、テスト対象の認可は Issued から Consumed に遷移し、想定された保護対象の効果が作成されました。また、リプレイは 2 回目の作動を試みる前に拒否されました。

このエビデンスは、一般的な Windows サンドボックスのセキュリティ、任意の悪意あるコードの封じ込め、本番環境向けの認可セキュリティ、またはあらゆるバイパスへの耐性を立証するものではありません。

限定的なエビデンスの記録と凍結に関する制約については、docs/WINDOWS-AUTHORITY-BOUNDARY.md を参照してください。

マシン／AI／自律型エージェントによるナビゲーション

このリポジトリは、意図的にマシンで操作可能かつマシン可読な構成になっています。

まずはこちらを確認してください。

AGENTS.md
machine/system-manifest.json
machine/repo-policy.json
machine/protocol.json
machine/test-matrix.json
STATUS.md
BUILD-REPORT.md
EXPERIMENT.md

推奨される自動トラバーサル：

1. Read machine/system-manifest.json
2. Read machine/repo-policy.json
3. Read AGENTS.md
4. Read STATUS.md
5. Read EXPERIMENT.md
6. Run cargo test
7. Read docs/WINDOWS-AUTHORITY-BOUNDARY.md before making OS-authority claims

決定論的なリクエスト／判定経路に人間が関与する必要はありません。人間向けの説明文は、主にガバナンス、科学的な解釈、レビューを目的としています。

Working principle

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