snapsynapse/guidecheck

# GuideCheck GuideCheck 是一个用于代理指令表面的信任边界协议。它确保人类批准的指令与代理执行的指令是相同的。 AI 安装指南可能隐藏模型读取但人类从未看到的指令。随后，使用工具的助手可能会以人类认为指南已审核的授权去执行这些隐藏指令：暴露凭证、运行破坏性命令、安装恶意依赖、或禁用安全防护。 GuideCheck 是"人类可验证的助手指南"（Human-Verifiable Assistant Guide）配置文件的标准化项目：这是一个受限的纯文本配置文件，用于 `assistant-guide.txt`，涵盖面向助手的安装、实施、修复、迁移和操作说明，人类可以在助手执行之前完整审查这些说明。核心主张是审查完整性：经过审查的指令表面与执行的指令表面应该是同一个有界制品。 规范网站：https://guidecheck.org/ 验证器：https://guidecheck.org/verify 新读者：`ADOPTION.md` 是实用的入门指南。它解释了合规阶梯，提供了逐级路径，并附有指南作者检查清单。 ## 规范 URL https://guidecheck.org/ ## 命名模型 - 标准化项目、公共检查器、生态系统和网站均称为 GuideCheck。 - 制品是 `assistant-guide.txt`。 - 配置文件是"人类可验证的助手指南"配置文件。 - 合规文件是指满足特定配置文件版本的 `assistant-guide.txt` 制品。 - GuideCheck 合规主张仅在得到验证器输出、指南哈希、达到的级别和发现项支撑时才有效。 ## 合规不等于安全 无论处于哪个级别，符合此配置文件并不意味着指南可以安全遵循，也不意味着发布者可信，更不意味着助手可以在没有合格操作员本应应用的安全实践的情况下继续操作。验证器确认形式。人类确认含义。在采纳之前，请阅读 `spec.md` 第 1 节和 `operator-guide.md`。 ## 它解决了什么问题 AI 辅助的安装指南通过 HTML、渲染的 Markdown、PDF、文档网站、复制的工单评论、终端输出和截图进行分发。这些表面可能承载模型摄取但人类看不到的内容：隐藏的 HTML 注释、离屏 CSS、白底白字文本、脚本插入内容、不可见 Unicode 控制字符、终端转义序列、长而埋藏的指令块。 对于高后果任务，项目需要一个受限的指令表面，人类可以在授权助手遵循之前完整审查。问题在于信任边界失效：人类批准一个表面，而代理可能执行另一个表面。 ## 适用人群 - AI 治理实践者，他们需要证据来证明指导在助手执行之前是可审查的。 - 安全工程师，关注提示注入和隐藏指令通道。 - AI 平台和 MLOps 工程师，负责操作化助手工作流。 - MCP 服务器作者和主机实现者，需要可审查的安装、配置、工具、资源和批准边界。 - A2A 实现者，评估委托任务、返回制品和远程代理指令应如何跨越信任边界。 - 技术政策与合规专业人员，从事证据、可审查性和控制设计。 - 任何希望在使用 AI 代理安装软件或执行其他自主操作时采取基本预防措施以防范提示注入和其他已知安全问题的人。 ## 此配置文件定义了哪些内容 - 一个名为 `assistant-guide.txt` 的 `.txt` 制品，提供于 `/.well-known/assistant-guide.txt` - 严格的 ASCII 字节配置文件和 8 KiB 大小上限，使得整个指令表面可以在一次会议中审查完毕 - 结构化的 `[action]` 块，带有显式分类、批准门和命令限制 - 从纯文本可用性到可验证来源再到运行时强制执行的五级合规阶梯 - 用于来源验证的 sidecar 清单加跨渠道哈希发布 - 配套的验证器合规配置文件，使独立验证器在结果上达成一致 - 本仓库自身的 `assistant-guide.txt`，用于起草或审查目标仓库的指南 ## 文档 - `ADOPTION.md` - 实用入门：合规阶梯、逐级路径、指南作者检查清单 - `spec.md` - 规范性的"人类可验证的助手指南"配置文件 - `verifier-conformance.md` - 用于验证指南的工具的规范性配置文件 - `design-rationale.md` - 为何做出这些设计选择 - `operator-guide.md` - 面向操作员的非规范性深度防御实践 - `threat-register.md` - 面向 fixture、验证器和运行时作者的已知风险分类 - `docs/acs-integration.md` - 非规范性 ACS 运行时控制模式 - `docs/mcp-integration.md` - 非规范性 MCP 集成模式 - `docs/a2a-integration.md` - 非规范性 A2A 集成模式 - `schemas/` -用于清单、验证器输出和 fixture 期望的 JSON Schema - `finding-ids.md` - fixture 必需和发出的验证器发现项 ID 注册表 - `assistant-guide.txt` - GuideCheck 采用指南的仓库副本 - `.well-known/assistant-guide.txt` - 采用指南的规范公共副本 - `evals/` - 针对 fixture 和生成检查的本地评估文档 - `scripts/eval_guidecheck.py` - 对主要引擎（静态 fixtures 加生成的边界情况）的评估运行器；不是独立的验证器 - `roadmap.md` - 未来行动和未决问题 - `CHANGELOG.md` - 配置文件和配套文档的变更历史 - `CONTRIBUTING.md` - 如何提议配置文件变更 - `SECURITY.md` - 如何私下报告安全漏洞 - `examples/` - 示例合规指南和示例清单 - `fixtures/` - 验证器合规测试语料库 - `INTENT.md` - 标准级策略、不变条件和重新校准门 - `archive/` - 起源文档，非规范性 ## 合规级别 - 级别 0：指令仅通过可能隐藏或转换文本的表面获得 - 级别 1：存在纯文本指南，可访问，并包含紧凑的验证指令 - 级别 2：严格的 ASCII 字节配置文件、大小限制、无禁止结构 - 级别 3：助手安全契约、所有必需部分、显式批准门 - 级别 4：可验证的来源、sidecar 清单、独立控制平面上的跨渠道哈希 - 级别 5：指南加上符合要求的助手运行时，机械地强制执行执行契约 级别 4 是指南文件本身的最高得分。级别 5 不是更高的指南文件得分；它是一个独立的运行时强制执行主张，适用于执行级别 4 指南的部署。 ## 本地评估 使用以下命令运行本地回归套件： ``` make eval ``` 使用以下命令运行完整的本地验证套件： ``` make test ``` 评估运行器检查静态 fixture 语料库以及生成的边界情况，涉及字节配置文件、元数据、操作块、命令限制、禁止模式、级别 4 清单和锚点证据以及公共获取安全性。它是仓库回归工具，不是规范性验证器。参见 `evals/README.md`。 CI 在推送到 `main` 和拉取请求时运行相同的 `make test` 目标。 ## 验证器范围 验证器工作按评估模式划分。存在两个验证器： - 本地文件参考 CLI，`scripts/guidecheck_verify.py`，评估级别 1 到 3。它还检查任何提供的 sidecar 清单和独立锚点证据是否内部一致，但将达到的级别上限设为 3，并报告 `level4.requires-fetch`：级别 4 断言独立来源，只能通过从其实际位置获取证据来建立。 - 托管公共Web验证器，位于 https://guidecheck.org/verify，通过 URL 获取指南，并在支持公共Web来源证据可用时应用级别 1-4 检查。托管验证器还接受可选的代理类别和期望级别输入，以便产品遥测显示特定代理系列在何处经常错过期望的合规级别。 两个验证器： - 评估 `assistant-guide.txt` 字节，而不执行指南内容 - 计算并报告指南 SHA-256 - 检查级别 1 紧凑验证指令和基本来源元数据 - 检查级别 2 字节配置文件和禁止结构 - 检查级别 3 元数据、必需部分、操作块、批准门、命令限制、禁止模式、状态和过期情况 - 输出机器可读的验证器输出以及紧凑的人类可读报告 两个验证器都检查级别 4 sidecar 清单以及指南哈希和字节计数匹配。本地参考 CLI 接受本地独立锚点证据（使用 `--anchor`）并确认其一致性，但不断言本地字节的级别 4（上限为级别 3）；只有托管验证器（获取支持的公共Web锚点，如包注册表元数据和透明度日志条目）才断言级别 4。 托管验证器可能为同时通过运行时强制执行（级别 5 就绪）的指南端准备检查的级别 4 指南报告 `level5_ready: true`（级别 5 就绪仅在达到级别 4 后评估，因此在本地文件模式下不适用）。这不是达到的级别 5 主张；级别 5 仍然需要符合要求的助手运行时。 面向用户的评分语言应将其视为 `指南得分：4 级（共 4 级）` 加上 `运行时就绪：5 级就绪`。避免使用 `4 级（共 5 级）`、`几乎达到 5 级` 或类似暗示指南文件缺少最终得分的措辞。 使用以下命令运行本地参考验证器： ``` python3 scripts/guidecheck_verify.py assistant-guide.txt --pretty ``` 检查级别 4 sidecar 证据的一致性（本地仍上限为级别 3，报告 `level4.requires-fetch`；使用托管验证器断言级别 4）： ``` python3 scripts/guidecheck_verify.py assistant-guide.txt --manifest manifest.txt --anchor dns-txt=anchor.txt --pretty ``` 使用以下命令对参考验证器运行静态 fixture 检查： ``` make verify-fixtures ``` 托管验证器是一个预览版。它已上线且可用，但并未声称完全合规：验证器合规 fixture 套件尚未完成，并且托管实现尚未证明能通过该套件。 临时限制： - 尚不支持 DNS TXT、仓库文件或签名的 `security.txt` 作为级别 4 锚点 - 托管验证器是级别 1-4 预览版；其 SSRF 和滥用控制由单元测试 `scripts/test_fetch_safety.py` 覆盖；重放测试涵盖重定向、响应大小限制、标头捕获和内容变化；每个托管请求都有五次获取的出站预算上限 - 无级别 5 运行时合规声明；级别 5 仍不在参考验证器范围内 托管验证器产品遥测故意受限。它记录目标主机、路径是标准 well-known 路径还是自定义路径、选定的代理类别、期望级别、达到的级别、结果、失败类别和大致持续时间。它不存储完整的提交 URL、查询字符串、提示、模型响应、IP 地址或稳定的访问者标识符作为产品遥测。Vercel 可能保留标准的短期请求日志用于滥用防御；这些请求日志不包括提交的指南 URL。 当前的 `scripts/eval_guidecheck.py` 仍然是回归工具和参考映射，而不是验证器本身。参考验证器位于 `scripts/guidecheck_verify.py`，并通过 `scripts/check_reference_verifier.py` 根据相同的静态 fixture 期望契约进行检查。 ## 状态 审查草案，配置文件版本 0.4.0。参见 `CHANGELOG.md`。 这是一个早期阶段开放标准。目前最有用的反馈是：隐藏指令问题是否映射到您环境中的实际运营风险；`assistant-guide.txt` 和合规阶梯是否是合适的抽象；以及在您能够在内部政策或架构中引用这样的标准之前缺少什么。请提出问题或发起讨论。 如果该方向对您的 AI 治理、安全或平台工作有用，GitHub 星标有助于该项目接触到正在解决相同问题的其他实践者。 ## 许可 规范文本和文档：Creative Commons Attribution 4.0 International（`LICENSE`）。 参考代码和模式：MIT（`LICENSE-MIT`）。 版权所有 2026 PAICE.work PBC。 ## 项目 一个 PAICE Foundation 标准。请参见 https://paice.foundation/ 了解项目组合。

标签：AI安全, Chat Copilot, CSP, Git 安全, 人工智能安全, 人类监督, 代理安全, 信任边界, 可审查性, 可验证性, 合规性, 子域名枚举, 安全标准, 安全规范, 完整性校验, 指令劫持, 指令安全, 指南标准, 攻击面, 系统安全, 纯文本协议, 逆向工具, 透明性, 防御加固, 隐藏指令