MCP安全审计与运行时证据CCS

问题：MCP 工具调用链里的「事后无证据」困境

MCP 服务器暴露的 tools/call、资源读取和提示词模板，在执行路径上往往横跨多个外部依赖。当一次推理尝试了多个外部调用时，传统静态扫描很难回答：

• 哪个工具在哪个时间点被触发，参数是否被中间层改写？
• 执行期间读取的资源是否超出声明范围，是否访问了未在 manifest 中登记的端点？
• 如果回放审计日志，能否证明「这次行为」与「当时的运行时状态」一致？

更多团队把日志堆在对象存储里，用正则做匹配。结果是日志能证明「曾经发生」，无法证明「运行时没有越界」——这也是安全审计里最棘手的「证据链缺口」。

技能如何工作：把证据拉回运行时

MCP Security Audit & Runtime Evidence Layer CCS（ccs-runtime-verifier）试图在 Agent 与 MCP 服务器之间插入一层轻量采集器，直接在进程边界收集运行时状态。核心路径包括：

• 事件捕获：拦截 tools/call 的入参、返回值和元数据（如 requestId），记录到结构化证据条目。
• 行为对齐：将每次工具调用与 MCP manifest 中的 description 和 inputSchema 做差异比对，识别参数注入或未声明字段。
• 证据签名：对采集到的关键证据（如工具调用哈希、响应摘要）进行本地签名，保证事后审计时可验证证据未被篡改。

最终输出不是一份报告，而是一组可独立验证的「证据包」，包含事件时间线、签名摘要和校验值，便于回放和自动化判定。

适用边界与注意点

• 本技能假设你的 Agent 运行环境允许注入 hook 或 wrapper，若使用纯黑盒 SDK，事件捕获可能不全。
• 对 JSON-RPC 之外的传输层（如 stdio、WebSocket）需要额外适配，默认不覆盖。
• 签名密钥需本地管理，建议配合 age 或 KMS 方案，避免硬编码。