IAP：智能接入协议的证据格式设计与考虑

版本说明：IAP（智能接入协议）是本项目保留的专名。本文为当前设计讨论，重点仍是内部证据与测试证明格式 0.1；不是对外正式规范。早期 1.7-draft 另文保留，两者不合并成同一份已生效标准。

前面的文章介绍了智能世界、智能接入（Intelligent Access，简称 IA）和 IAP 早期草案。这一篇讲证据：当人或 AI 准备接入一个工具时，"这条智能接入现在是什么样、依据在哪"应该用什么格式来表达。下文沿用 IAP 专名，讨论其中内部证据格式的设计。

先说清楚一件事：IAP 起初的构想是一个"智能接入协议标准"，范围很大。经过几轮评审，我们把它收窄为"关于一条接入的证据与测试证明格式"，并计划先在 CapaLens 内部积累记录，累计 100 条以上真实测试记录之后再考虑对外。这篇文章讲的是设计思路和为什么这样取舍，不是一份对外规范。

一、空在哪里：安全链的四环

要理解 IAP 的位置，先看一条接入从发布到被调用，安全上要过哪几关：

• 身份：谁发布的。注册中心管这一环——但只验命名空间归属，不验内容。
• 定义：工具到底做什么、要什么权限、这个版本和上个版本有什么不同。
• 运行：调用时的权限与隔离。网关、客户端、安全厂商管这一环。
• 审计：事后追责。企业日志管这一环。

定义、权限与版本变化是团队希望补充记录的部分。工具定义哈希、发布者身份和最小权限等机制都需要明确对象与证据；具体协议和注册中心支持什么，应按其当前版本核对，不能据本文断言已有机制完全空白。

IAP 就是为这一环准备的。它不是另一个调用协议，不替代 MCP，不替代注册中心；它是"关于一条接入的证据"的统一格式：版本、条件、权限、测试结果、检查日期、证据来源。注册中心帮助发现"有哪些"，IAP 拟关联接入判断所需的证据，不代替使用方裁定安全或可用。它是补充记录的设计，不是新的调用竞争层。

二、一条证据记录长什么样

设计原则是：拟议检测报告本身应成为证据记录，减少转换层与字段漂移。以下文字介绍内部格式 0.1 的关键设计；它们尚不是完整可执行的 Schema，也不表示检测引擎已在当前平台上线。

几个关键设计：

适用版本 + 检查日期。 证据只对这个版本、这个日期成立。设计目标是：接入升级版本或扩大权限时，将旧证据标为"待复测"并显示新鲜度；也可为证据设置有效期（比如 90 天）并提示过期。自动化规则须以实际实现为准。

证据等级分开标，绝不混在一起。 机器检测、人工确认与 AI 自报是不同来源和范围的记录，不能仅凭类型推导统一高低。一张卡片上可以同时出现三种，但必须分别标注，不能揉成一个"综合分"。

条件三态：已满足 / 未满足 / 未知。 未知就写未知，不猜测、不默认。字段缺失一律判"未知"。每一条条件附一个证据 id，指向原始报文。

定义与归属字段。 动作等级（读取 / 写入 / 执行 / 调度）、发布者身份（官方 / 厂商托管 / 社区 / 批量发布者）、工具定义哈希。其中定义哈希把名称、描述、输入输出 schema、注解一起算——因为"偷换"（rug pull）的典型手法是改描述、改注解，schema 不动。计划在定义哈希变化时触发复核或告警；哈希本身不判断变化是否恶意。

原始报文可复跑。 在取得授权且不泄露受限数据的前提下，计划随报告公开可公开的脱敏请求与响应；以让外部人员能够复跑并核对结论为目标，30 分钟是设计目标而非已验证承诺。这是"说法 = 实测"的技术实现。

三、证据是怎么产生的：四级阶梯

项目用四种展示类型组织证据：自我声明（厂商或发布者声明，AI 自报也在此范围）→ 文档核查（对照指定资料并记录来源）→ 机器检测（在指定条件下的自动检查）→ 人工校验（人工检查列明事项）。这是展示模型，不是天然单一可信度排名；每项都须记录范围，人工看过身份不等于完成业务实测。

每项只显示实际已有的记录。"官方写过"不等于"我们测过"，业务调用测试单列。Registry 来源登记及本地补充信息仍为未核验、未实测；正式目录的文档标签也只说明其记录范围。本文不声称多数全部条目已经核查，不将其他开发线的框架测试或试点计划当作 0.4.8 上线验收。机器与人工覆盖按后续实际交付和逐条证据扩大。

机器检测拟分层设计。较轻的活性检查可考察可达性、协议应答、能力发现、定义与鉴权条件；请求和时间上限应按授权与具体用例制定，本文不宣称已经执行某个固定预算。不可达须区分权限、环境和暂时故障，不能直接判为长期失效。深度检查与官方一致性测试拟分别记录，矛盾结果需复核；这不代表自动队列已经上线。

大模型只发现疑点，不下结论。 若后续引入规则或模型辅助检查，其输出只应作为投毒嫌疑或文档差异的候选，仍需人工和可复现证据确认。本篇导入不启用模型调用、扫描或测试引擎。

四、把校验固化到每一次调用

证据有了，怎么让它真正起作用？我们的长期目标是：让"查一次证据"成为每次 AI 调用智能接入的内置步骤。

关键原则：不是让每次调用"经过"CapaLens，而是让每次调用"带着"CapaLens 的检查结果。 我们不做网关代理——那样慢、贵、有单点故障，也与"不在调用路径上"的定位冲突。

以下四条均为长期设计路径，不代表当前客户端插件、签发服务、治理规则或标准已经交付：

1. 可离线校验的签名凭证：按接入、按版本签发，绑定被测版本和定义哈希，客户端可在本地验证签名；撤销状态是否最新仍取决于状态列表的更新时间、缓存有效期与必要的在线刷新。
2. 嵌进工具链：Agent 框架、SDK、MCP 客户端插件默认"接入前先校验"；未校验或版本不符时提醒用户，决定权仍在用户手里。
3. 写进规范：推动注册中心等标准加入"信任与证据"字段。
4. 进企业制度：帮企业把"未经校验的接入不得使用"写入 AI 治理策略。

密码学细节上，评审意见是不自己发明：拟参考 RFC 8785（JCS）处理 JSON 规范化，并参考 W3C Verifiable Credentials 2.0 与状态列表设计凭证和撤销机制。JCS 不是签名算法；具体证明格式、密钥分发、状态刷新与互操作测试仍需单独定义。

五、我们放弃了什么，为什么

一份诚实的设计说明应该讲清楚取舍。IAP 早期草案被我们自己的评审否掉了不少东西：

漏洞信息发布须遵守《网络产品安全漏洞管理规定》等适用规定。公开状态、受影响版本及细节均应逐项审查，不能仅因删去技术细节就认定合规；是否发布、披露时点与接收方需结合厂商响应和适用要求确定。

六、路线

当前设计目标：以检测引擎输出的 evidence.json 作为 IAP 内部格式 0.1，并与 v0.5.0 字段标准对齐；是否完成及覆盖范围以实现和实测记录为准。接下来：累计 100 条以上机器检测加人工确认的真实记录。之后才谈公开草案，并对齐官方注册中心、GB/Z 185 等现有体系——不另立山头。

我们知道，一个标准的价值不在于谁先写出来，而在于有多少真实记录按它产出、有多少平台愿意引用。所以 IAP 的路线是先做记录，再谈格式；先补空白，再谈标准。

---

本文基于团队内部评审与备忘录（2026 年 10 月），所述格式为内部草案，字段名可能变化，不构成对外规范或承诺。