arcstone-mcp-sidecar

Arcstone 执行边界

仓库标识： arcstone-mcp-sidecar 实现包： arcstone-execution-boundary 状态： 实验性 / 下游 / 非规范 / 有界证据 版本： 0.1.0 实现起始版本

此仓库是已冻结的Arcstone 执行边界 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
• 通用策略引擎
• Agent 框架
• 软件包管理器发布
• 公开生产分发保证
• 真实世界中的恰好一次执行
• 生产级授权安全
• AI 对齐或通用 Agent 安全

本地数据模型

实验根目录的结构如下：

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

授权记录之所以可信，是因为在测试的权限配置下，不受信任的生产者无权在 auth 树下创建或修改内容。授权标识符本身不具备任何权限。

consumed/<authorization-id>.claim 文件通过 create_new(true) 创建。这个原子本地预留操作是 v0.1 的单次使用声明原语。

构建

Windows CMD：

cargo build
cargo test

或：

scripts\windows\verify.cmd

示例

创建运行时目录：

arcstone-exec init --root runtime

签发一项授权：

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 主体运行时，生产者与资源之间存在权限隔离。

因此，另行完成了一项有界 Windows 权限实验，使用了不同的非管理员生产者和授权主体，并为专用的一次性运行时明确配置了 ACL 隔离。

观察结果：

• T7 直接绕过受保护资源：PASS（在已测试的 ACL 配置下）
• T8 直接绕过执行器：PASS — 有界公共 API / 结构性结果
• T9 伪造授权签发：PASS（在已测试的 ACL 配置下）
• I2 单次使用 / 至多一次授权：对已测试的授权提供支持
• I3 生产者与受保护资源隔离：对已测试的 Windows 配置提供支持

成功的授权执行将已测试授权的状态从 Issued 转换为 Consumed，创建了预期的受保护效果；重放请求则在第二次执行器操作前被拒绝。

这些证据并不能证明通用 Windows 沙箱安全、对任意恶意代码的遏制能力、生产级授权安全或对所有绕过方式的抵御能力。

完整的有界证据记录和冻结限制请参阅 docs/WINDOWS-AUTHORITY-BOUNDARY.md。

机器 / AI / 自主 Agent 导航

此仓库专为机器操作和机器读取而设计。

从这里开始：

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.