SWT3 AI Witness

@tenova/swt3-mcp

已在 MCP Registry 中列出，名称为 io.tenova/swt3-witness

SWT3™ AI Witness 协议的 MCP 服务。为任何兼容 MCP 的 AI Agent 添加加密合规证明。

SWT3（主权见证可追溯性）通过在本地对 AI 的输入和输出进行哈希处理，提取数值因子（延迟、令牌数量、护栏状态），并将这些因子锚定到可供任何人独立验证的加密指纹中。你的提示词和回复绝不会离开你的设备。审计人员可获得防篡改证据，而你的数据仍由你掌控。

协议规范： swt3.ai/spec | 注册表： swt3.ai/registry | 验证： swt3.ai/verify

v0.7.9 新特性

v0.7.9 是一次生态适配器版本更新。开发者日常实际部署的四个平台——追求速度的 Groq、提供开放权重托管的 Together AI、主打高性价比推理的 DeepSeek，以及面向企业云的 Azure OpenAI——现在均支持原生见证适配器，并可在 Python 和 TypeScript 中全面自动检测。六篇新的提供商专属见证指南，将带你从首次安装一路完成生产部署。适配器生态现在覆盖 10 种 SDK 语言中的 47 个提供商。

这对 MCP 的意义： MCP 服务是所有这些能力汇聚的集成点。当 Claude Desktop 用户调用一个 MCP 工具，该工具使用 Groq 进行快速推理，并使用 Azure OpenAI 进行二次检查时，两次调用都会生成格式相同的见证锚点。MCP 服务的 swt3_query_anchors 工具允许用户检查、筛选和导出这些锚点，而无需了解每次调用由哪个提供商处理。借助 v0.7.9，所有主要商业推理提供商——OpenAI、Anthropic、Google Vertex、AWS Bedrock、IBM Granite、Mistral、Groq、Together AI、DeepSeek、Azure OpenAI、Cohere 和 NVIDIA——生成的锚点都能通过 MCP 服务的 75 个工具传递。无需针对提供商单独配置，也无需单独的审计仪表板。一个 MCP 服务，一条证据流。

六篇新指南涵盖最常见的 MCP 部署模式：

指南	内容
OpenAI GPT 见证	GPT-4o、o1、o3 的流式处理和系统指纹捕获
Anthropic Claude 见证	Claude 的流式处理、工具调用链和扩展思考
Google Vertex/Gemini 见证	通过兼容 OpenAI 的端点使用 Vertex AI，以及 Google ADK Agent 见证
DeepSeek GPAI 见证	R1 推理链捕获、GPAI 行为准则映射
Groq 见证	LPU 推理及延迟证明
LangChain/LangGraph 见证	用于链和图编排的回调处理器与代理适配器

v0.7.9 中的新增适配器

适配器	提供商标签	说明
wrap_groq / wrapGroq	groq	LPU 推理及延迟捕获
wrap_together / wrapTogether	together	开放权重模型托管
wrap_deepseek / wrapDeepSeek	deepseek	R1 推理链见证
wrap_azure_openai / wrapAzureOpenAI	azure-openai	保留部署名称，检测内容过滤器

发现文件同步

v0.7.9 还统一了所有 MCP 发现元数据。mcp.json、agent-card.json、llms.txt 和 server.json 文件现在报告的版本号、框架数量和指南数量完全一致。MCP 爬虫和 Agent 发现机器人在每个端点上看到的元数据都保持一致。

更新后的覆盖范围

• 10 个命名空间中的 293 个过程
• 75 个 MCP 工具、340 份合规指南、78 个监管框架、47 个适配器、10 种 SDK 语言

v0.7.8 新增内容

六个新适配器统一了 IBM watsonx、AWS Bedrock、AWS Strands 和 Mistral AI 的证据收集。在多个云服务提供商上运行模型的组织不再需要协调各自独立的审计记录——无论服务提供商是谁，每次推理和策略决策都会以相同格式生成见证锚点。

服务提供商	适配器	见证内容	重要性
IBM watsonx.ai	wrap_granite	generate()、generate_text()、流式传输	在 IBM 受监管云上运行的企业级 AI——银行和保险公司使用 Granite 进行文档处理
AWS Bedrock Guardrails	wrap_bedrock_guardrails	apply_guardrail() 策略决策（AI-GRD.1）	内容过滤审计记录——证明护栏已启用，而不仅仅是完成配置
AWS Strands	wrap_strands	Agent 可调用对象的调用（AI-INF.1）	AWS Agent 编排框架——拥有 120 多家企业客户，但没有内置审计功能
Mistral AI	wrap_mistral	chat.complete()、chat.stream()、异步	欧洲主权 AI——Mistral 在欧盟基础设施上运行，自 8 月 2 日起必须符合 GPAI 要求
NVIDIA NemoClaw	NemoClawWitness	策略引擎决策（AI-GRD.1）	硬件级 AI 治理——独立见证 NeMo Guardrails 的策略决策
NVIDIA ROSClaw	ROSClawWitness	ROS 2 机器人审计日志事件	机器人合规——《欧盟机械法规》（2027 年 1 月）要求安全关键型机器人提供 AI 决策证据

指南：IBM Granite 适配器 | AWS Bedrock Guardrails | Mistral AI 适配器 | NVIDIA NemoClaw

**这对 MCP 的重要性：**MCP 服务会跨服务提供商编排工具调用。当 Granite 模型触发 Bedrock Guardrail 来限制 Strands Agent 时，MCP 服务现在可以通过单一见证流查看完整的决策链。新增的 6 个适配器意味着，在任何主流云 AI 平台上运行并连接 MCP 的工具都会生成锚点，MCP 服务无需针对特定服务提供商进行集成，即可汇总、查询和导出这些锚点。

v0.7.6 新增内容

2026 年第三至第四季度，五个标准组织对 Agent 治理要求达成共识：NIST、FIDO Alliance、G7、新加坡 IMDA 和欧盟（DORA）。v0.7.6 新增了三个过程，弥补委派链可追溯性、范围边界监控和 Agent 可中断性方面的最后证据缺口。

**这对 MCP 的重要性：**NIST AI Agent 互操作性配置文件明确将 MCP 协议列为“在分化出现之前需要纳入治理意见的结构性发展”。Agent 中断见证（AI-SAFE.2）和范围边界证明（AI-SAND.2）与 MCP 工具服务直接相关——当 MCP 客户端的工具调用被策略阻止时，这就是审计人员需要证据的治理事件。NIST Agent 配置文件框架模板已完成预先映射，可在规范于 2026 年第四季度发布当天立即填充。

3 个新程序

• AI-DEL.3（委派链完整性）：记录多 Agent 交接中的委派链完整性。当 MCP 客户端将任务委派给子 Agent 时，现在可以为委派链的完整性提供见证。
• AI-SAND.2（范围边界证明）：记录边界执行报告。当工具服务将操作限制在声明的范围内时，此程序会为遵守这些边界提供见证。
• AI-SAFE.2（Agent 中断见证）：记录终止开关事件，包括触发来源、暂停的操作和状态保留情况。直接对应《欧盟 AI 法案》第 14(4)(e) 条中的可中断性要求。

新增交叉映射

• G7 AI-SBOM ——将 50 项最低要求映射到 18 个 SWT3 程序
• DORA ——面向欧盟金融实体的 20 项程序映射
• 新加坡 IMDA Agentic MGF ——涵盖 4 个治理维度的 24 项程序映射
• NIST Agent Profile ——预先映射到 3 大支柱（身份、日志记录、遏制）的框架模板

更新后的覆盖范围

• 涵盖 10 个命名空间的 293 个程序
• 75 个 MCP 工具、340 份合规指南、78 个监管框架
• G7 AI-SBOM 交叉映射 | DORA + ECB 交叉映射

v0.7.4 新增内容

NVIDIA 已向 120 多家合作伙伴推出 OpenShell。Agent 遏制现已成为基础设施的一部分。但此前没有 MCP 工具可以证明沙箱策略已得到执行。v0.7.4 新增了 witness_runtime_containment，以及蒸馏来源记录和诱导检测功能。新增 3 个工具，填补 3 个治理缺口。

这对 MCP Server 的意义：witness_runtime_containment 可让任何 MCP 客户端从 OpenShell、gVisor、Kata、Firecracker 或 WASM 沙箱生成加密遏制证据，无需导入任何 SDK。witness_distillation 记录教师模型到学生模型的血缘关系。witness_elicitation 记录提示词边界违规情况。所有工具均采用鸭子类型，且均能感知清算等级。

新增 3 个 MCP 工具（共 75 个）

工具	程序	记录内容
witness_runtime_containment	AI-SHELL.1	运行时沙箱策略执行情况、违规次数、OCSF 事件数、观测窗口
witness_distillation	AI-DIST.1	教师模型到学生模型的血缘关系、蒸馏类型（logit/feature/attention/data/hybrid）、服务条款合规情况
witness_elicitation	AI-MCP.6	通过工具响应检测提示词边界违规情况、同意状态、范围违规类型、检测方法

更新后的覆盖范围

• 涵盖 10 个命名空间的 278 个程序（原为 277 个）
• 75 个 MCP 工具（原为 74 个）
• 277 份合规指南
• NVIDIA OpenShell 交叉映射 ——为 OpenShell、gVisor、Kata、Firecracker 提供运行时遏制证据
• 面向承保沟通的 AI 保险证据指南
• 提供 Streamable HTTP 传输（swt3-mcp-http），支持 Meta Muse 等原生 HTTP MCP 客户端

v0.7.3 新增内容

A2A（Google 的 Agent-to-Agent 协议）已有 150 多家支持组织，涵盖全部三家超大规模云服务商，并在 Linux Foundation 治理下发布了稳定的 v1.0 规范，但没有内置审计记录。MCP OAuth 的采用率为 8.5%，且 60 天内已提交 30 多个 CVE。v0.7.3 通过专用程序、支持生命周期感知的适配器和新增的交叉映射 CLI 命令，让 SWT3 成为这两种 Agent 通信协议的证据层。

**这对 MCP Server 的意义：**新增 4 个工具，总数达到 72 个。witness_task_lifecycle、witness_agent_card_discovery 和 witness_context_chain 让任何 MCP 客户端无需集成 SDK，即可为 A2A 委派流程提供见证。witness_oauth_token_binding 记录 OWASP MCP-07 指出见证不足的 8 个 OAuth 生命周期事件。

4 个新增 MCP 工具（共 72 个）

工具	流程	记录内容
witness_task_lifecycle	AI-A2A.1	任务状态转换（submitted/working/input_required/completed/failed/canceled/rejected），包括委派深度和延迟
witness_agent_card_discovery	AI-A2A.2	通过知名 URL、注册表或推荐进行 Agent 发现，并记录已验证凭证数量
witness_context_chain	AI-A2A.3	记录多 Agent 委派链中的 contextId 链接，用于取证重建
witness_oauth_token_binding	AI-MCP.5	记录 8 种 OAuth 生命周期事件（从发现到撤销），包括绑定强度和范围治理

覆盖范围更新

• 覆盖 10 个命名空间中的 284 个流程（之前为 280/9）
• 72 个 MCP 工具（之前为 68 个）
• 新增 A2A 命名空间（第 10 个命名空间）
• 新增 swt3 crosswalk <procedure> CLI 命令，可离线查询框架映射
• 269 份合规指南

v0.7.2 新增内容

如今，每个投入生产的 MCP 服务都缺少合规证据。工具调用在没有证明、审计跟踪或事件证据的情况下直接流转。v0.7.2 通过一个函数调用改变了这一点：withSWT3(transport)。Witness Middleware 可包装任何 MCP 传输——Stdio、SSE、HTTP、自定义传输——并为每次工具调用自动生成 AI-TOOL.1 锚点。无需修改工具处理程序。响应已先于 Witness 写入传输线路，因此它不会阻塞、不会导致工具失败，也不会增加关键路径上的延迟。对于运行大量 MCP 服务的平台团队而言，这就是“我们应该增加合规功能”和“合规功能已经就位”之间的区别。

Witness Middleware

import { withSWT3 } from "@tenova/swt3-mcp/middleware";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
  batchSize: 10,
  flushIntervalMs: 5000,
});
await server.connect(transport);

只需一行。每次工具调用都有见证。适用于任何 MCP 服务，而不仅仅是我们的服务。

这为何重要： MCP 的采用正在加速，但合规证据却常被忽视。要为现有 MCP 服务补上见证功能，就意味着要修改每个工具处理程序——对于拥有数十种工具的服务或并非由你拥有的服务而言，这并不现实。Middleware 模式消除了这一障碍。它会观察 JSON-RPC 层，提取工具名称和时间信息，生成锚点，并在后台刷新。现有服务无需重构即可获得密码学证明。Middleware 还支持：

• 批处理——缓冲数据负载，并在达到大小阈值、时间间隔或传输关闭时刷新
• 采样——针对高调用量服务，按工具采用基于确定性哈希的采样率。跳过的调用会计数，并汇总到 AI-SAMPLE.1 锚点中
• 多租户解析——通过回调解析每次工具调用所属的租户。一个 Middleware 实例即可覆盖整个服务集群
• 重试——使用带指数退避的有界内存队列重试失败的批次
• 演示模式——未配置 API 密钥时记录到 stderr，让你无需后端即可查看锚点

5 个新增 Harness 治理流程

AI Harness 层——编排、委派、上下文管理、沙箱化、评估门——是 AI 领域最热门的基础设施类别。到 2026 年底，40% 的企业应用将包含 AI Agent，但目前没有人在 Harness 层进行密码学证明。v0.7.2 新增五个流程，让 Harness 层的治理决策可审计。

工具	流程	记录内容
witness_orchestration_topology	AI-ORCH.1	路由模式（并行/顺序/分层）、Agent 数量、依赖深度
witness_agent_handoff	AI-ORCH.2	委派者与受委派者之间的身份关联、权限差异方向
witness_context_window	AI-CTX.1	淘汰前后的 Token 数量、淘汰方式
witness_sandbox_enforcement	AI-SAND.1	声明的工具与实际调用的工具、违规次数
witness_eval_gate	AI-GATE.1	评估通过/失败次数、自动计算的门控分数

数据一览

• 68 个 MCP 工具（之前为 63 个）
• 覆盖 77 个命名空间中的 280 个流程（之前为 275 个）
• 约 3,000 项测试通过
• 265 份合规指南（之前为 250 份）

v0.7.1 版本更新内容

MCP 是 AI 领域增长最快的集成层，同时也是治理最薄弱的领域。OWASP 于 2026 年发布了 MCP Top 10——30% 至 82% 的 MCP 服务容易受到工具投毒、身份验证不足和影子服务泛滥等问题的影响。v0.7.1 新增 3 个工具，弥补剩余的 OWASP 风险。SWT3 现已成为首个通过加密证据覆盖全部 10 项 OWASP MCP 风险的 MCP 服务。

新增 3 个 MCP 工具（共 68 个）

工具	流程	记录内容	OWASP MCP 风险
witness_mcp_tool_integrity	AI-MCP.2	连接时与调用时的架构哈希。若出现偏差则失败。	MCP-03 工具投毒
witness_mcp_server_auth	AI-MCP.3	身份验证方法、验证状态。若未进行身份验证则失败，并生成 IA-9 调查结果。	MCP-07 身份验证不足
witness_mcp_server_discovery	AI-MCP.4	发现方法、允许列表检查。发现影子服务时失败。	MCP-09 影子服务

OWASP MCP Top 10：全面覆盖

OWASP MCP 风险	SWT3 工具
MCP-01 令牌管理不当	witness_nhi_rotation、witness_nhi_expiration
MCP-02 权限提升	witness_nhi_scope、witness_nhi_privilege_change、witness_access
MCP-03 工具投毒	witness_mcp_tool_integrity（新增）
MCP-04 供应链篡改	witness_sbom、witness_model_provenance
MCP-05 命令注入	witness_guardrail、witness_output_filter
MCP-06 意图流劫持	witness_chain_handoff、witness_trajectory
MCP-07 身份验证不足	witness_mcp_server_auth（新增）
MCP-08 缺少审计/遥测	SWT3 协议（全部 68 个工具）
MCP-09 影子 MCP 服务	witness_mcp_server_discovery（新增）
MCP-10 上下文注入	witness_guardrail、清除级别

v0.7.0 版本更新内容

AI 并非孤立运行。它使用服务帐户进行身份验证，在具有供应链的硬件上运行，并消耗足以重塑电网的大量电力。v0.7.0 新增 22 个 MCP 工具，将见证能力扩展到完整的 AI 基础设施技术栈。工具总数达到 59 个。

22 个新增 MCP 工具（共 59 个）

三个全新的工具系列覆盖了 AI 所依赖的基础设施：

凭证治理（NHI）——6 个工具。 AI Agent 使用服务账户、OAuth 令牌和 API 密钥向 API 进行身份验证。在典型企业中，这些非人类身份的数量是人类用户的 45 倍。审计员询问“你的 AI 使用了多少个服务账户？”时，大多数组织都答不上来。这些工具会针对凭证范围、生命周期、权限变更、轮换、委托和撤销创建独立的审计跟踪记录，而无需替换你的身份提供商。

工具	流程	记录内容
witness_nhi_scope	NHI-SCOPE.1	服务账户获准访问的内容
witness_nhi_lifecycle	NHI-LIFE.1	凭证的配置、激活、暂停和停用
witness_nhi_privilege_change	NHI-PRIV.1	凭证的范围变更
witness_nhi_rotation	NHI-ROT.1	凭证轮换事件（证明轮换已发生）
witness_nhi_delegation	NHI-DEL.1	Agent 间凭证委托，并跟踪委托深度
witness_nhi_revocation	NHI-REV.1	支持级联操作的凭证撤销

硬件与电池护照（HBOM/DPP）——10 个工具。 欧盟《电池法规》要求为每块容量超过 2 kWh 的电池提供数字护照。《网络弹性法案》要求提供硬件物料清单。《能源效率指令》要求报告 PUE。单个超大规模数据中心就有 50,000 多块 UPS 电池——到 2027 年 2 月，每一块都需要数字护照。

工具	流程	记录内容
witness_hardware_inventory	HBOM-INV.1	组件数量、清单哈希、基线差异
witness_component_lifecycle	HBOM-LIFE.1	组件的配置、维护和退役
witness_thermal_profile	HBOM-THERM.1	环境温度和组件温度、阈值警报
witness_water_consumption	HBOM-WATER.1	用水量和 WUE 比率
witness_power_usage	HBOM-PUE.1	设施功耗、IT 负载、PUE
witness_supply_chain_provenance	HBOM-SUPPLY.1	供应商验证和原产国
witness_battery_soh	DPP-SOH.1	电池健康状态、循环次数、容量
witness_charge_cycle	DPP-CHRG.1	充放电事件及峰值温度
witness_degradation_event	DPP-DEGRAD.1	电池退化事件
witness_end_of_life	DPP-EOL.1	生命周期终止处置和移交回收商

能源与需求响应（ADR）——6 个工具。 AI 训练的耗电量相当于小型城市。由于缺少对实际情况的独立证明，需求响应事件引发的结算争议金额可达六位数。这些工具覆盖完整生命周期：电网信号、基线、削减、结算、碳信用和电网关联。

工具	流程	记录内容
witness_demand_response	ADR-EVENT.1	需求响应事件阶段和承诺负载
witness_baseline_consumption	ADR-BASE.1	采用测量方法记录的事件前基线
witness_curtailment	ADR-CURT.1	实际削减量与承诺削减量的对比
witness_settlement	ADR-SETTLE.1	财务结算数据
witness_carbon_credit	ADR-CARBON.1	碳信用和 REC 证明
witness_grid_signal	ADR-GRID.1	电网信号关联和响应延迟

这些工具为何需要协同使用

原有的 37 个工具覆盖 AI 生命周期：推理、治理、授权和信任。这 22 个新增工具覆盖基础设施生命周期：Agent 以何种身份进行身份验证、运行于何种硬件上，以及消耗了多少能源。通过 MCP 使用 SWT3 的 AI Agent，如今可获得从用于身份验证的凭证，到生成的推理结果，再到生成这些结果所消耗的电力的全流程覆盖。共 59 个工具。

数据一览

• 59 个 MCP 工具（原为 37 个）
• 75 个命名空间中的 266 个过程（原为 118 个／64 个命名空间）
• 约 2,950 项测试通过
• 237 份合规指南（原为 222 份）

v0.6.6 新增内容

供应链问责：新增 4 个工具（总计 37 个）、TypeScript SDK 治理能力对齐、OTel GenAI 约定，以及 CI/CD 门禁操作。主题是：证明你的 AI 供应链来源明确、边界清晰且受到监控，而不只是证明单次推理行为符合预期。

新增 4 个 MCP 工具（总计 37 个）

工具	过程	功能	重要性
witness_model_provenance	AI-PROV.1	记录模型谱系：基础模型、训练流水线、微调祖先，以及父模型指纹	G7 广岛 AI SBOM 和《欧盟 AI 法案》第 53 条要求提供来源文档。通过加密指纹将衍生模型关联至其祖先。
witness_delegation_boundary	AI-DEL.2	记录 Agent 不允许执行的操作：被阻止的工具、受限范围和升级触发条件	《欧盟 AI 法案》第 14 条要求记录 AI 的限制。证明这些约束是在 Agent 行动前声明的。
witness_anchor_density	AI-DENSITY.1	记录某个时间窗口内已见证事件与事件总数的比例	在评估人员发现之前，及时发现覆盖率从 100% 降至 2% 的情况。证明监控始终一致，而不只是完成了配置。
witness_mcp_security	AI-MCP.1	评估 MCP 服务连接的 8 项安全属性。记录已通过检查项与总检查项的数量，而绝不记录具体哪些检查未通过	NSA/CISA 已指出 20 多万个存在漏洞的 MCP 部署。生成安全评估证据，同时避免形成攻击地图。

这 4 个工具为何要配合使用

原有的 33 个工具涵盖了见证生命周期（签发、验证、签名）和治理生命周期（授权、过滤、审查、同意）。这 4 个新工具覆盖了供应链生命周期：模型来源、Agent 不能执行的操作、监控是否始终一致，以及 MCP 连接是否安全。现在，通过 MCP 使用 SWT3 的 Agent 可以实现端到端覆盖——从模型来源到运行时行为，再到监控保真度。每项合规义务只需调用一个工具。工具总数达到 37 个。

TypeScript SDK 治理能力对齐

TypeScript SDK 现已在治理见证方面与 Python 完全对齐，新增 10 个方法，包括 witnessGovernanceReview()、witnessGovernanceConfig()、witnessGovernanceException() 和 witnessPolicyEnforcement()。构建启用 MCP 的 Agent 的 TypeScript 团队不再是治理证据方面的二等公民。

OTel GenAI 语义约定

Python 和 TypeScript 的 OTel 导出器现已按照 OpenTelemetry GenAI 语义约定，生成 gen_ai.system、gen_ai.request.model 和令牌用量属性。通过 OTel 导出的见证锚点现已与使用 GenAI span 的 AI 可观测性平台原生兼容。

GitHub Action

tenova-labs/swt3-gate-action@v1 可在 CI/CD 流水线中评估 .swt3-gate.yml 策略。提供 7 个输入和 3 个输出。当合规覆盖率低于声明的阈值时，构建会失败。MCP 服务可在 CI 中设置门禁——如果服务不符合声明的合规策略，流水线会在部署前失败。

- uses: tenova-labs/swt3-gate-action@v1
  with:
    api-key: ${{ secrets.SWT3_API_KEY }}
    tenant-id: MY_TENANT
    framework: EU-AI-ACT

v0.6.5 新增内容

面向 MCP 生态系统扩展治理能力。中间件层、概率见证支持和 4 项加固功能，让 SWT3 可用于生产环境中的 GPAI 规模 Agent 部署。

见证中间件

功能： withSWT3(transport) 会包装任意 MCP 传输层，将每次工具调用自动见证为一个 AI-TOOL.1 锚点。无需更改任何工具处理程序代码。见证触发前，响应已经发送——既不会阻塞，也不会导致工具调用失败。适用于任何 MCP 服务，不仅限于我们的服务。支持批处理、采样、多租户解析，以及使用有界队列的重试。请参阅下文的见证中间件。

重要性： MCP 的普及正在加速，但大多数 MCP 服务部署时都没有任何合规证据。采用中间件模式，只需添加一行代码，现有服务便可获得密码学证明。无需重构、无需更改工具处理程序，也不会影响性能。见证触发前，响应已经发送。对于运营多个 MCP 服务的平台团队，多租户回调可解析每次工具调用所属的租户——一个中间件实例即可覆盖整个服务群。

概率见证兼容性

Python 和 TypeScript SDK 现已支持 sampling_rate，适用于每秒处理数十亿次推理的 GPAI 部署。AI-SAMPLE.1 摘要锚点会准确记录跳过了多少次推理。MCP 服务的 list_procedures 和 resolve_crosswalk 工具现已在注册表中包含 AI-SAMPLE.1。经过采样的推理所生成的锚点，也可通过 MCP verify_anchor 工具以相同方式验证。

Go SDK（v0.1.0）

SWT3 生态中的第 10 种语言。Go 覆盖基础设施层——Kubernetes 运算符、API 网关、推理编排器。Go 服务生成的指纹可通过 MCP 的 verify_anchor 工具以相同方式验证。公式相同、输出相同、审计轨迹相同。

v0.6.4

新增 10 个合规工具、1 个提示词模板和推理前门禁。MCP 服务现已提供 37 个工具，覆盖完整的 AI 治理生命周期：从推理前的授权，到推理后的事件报告。

新增 10 个合规工具

工具	程序	功能	重要性
swt3_gate	AI-ACC.1	推理前授权检查点	证明 AI 行动前已获得运行批准。欧盟《人工智能法案》第 9 条要求在部署前进行风险管理。
swt3_guardrail	AI-GRD.1	记录护栏激活状态	证明推理时安全过滤器处于启用状态，而不仅仅是已配置。
swt3_hitl	AI-HITL.1	记录人工审核完成情况	证明有资质的人员审核了 AI 决策。欧盟《人工智能法案》第 14 条对此有要求。
swt3_consent	AI-CONSENT.1	记录同意收集情况	证明在处理数据前已获得用户同意。GDPR 第 6/7 条。
swt3_data_provenance	AI-DATA.1	记录训练数据治理审核	证明已执行数据治理，但不披露数据本身。
swt3_rag	AI-RAG.1	记录 RAG 检索溯源信息	证明检索了哪些来源及其相关性评分。
swt3_output_filter	AI-GRD.2	记录输出安全分类结果	证明输出通过了内容安全过滤器。与输入侧护栏不同。
swt3_incident	AI-INCIDENT.1	记录事件文档	证明已按政策报告并记录事件。
swt3_reconstruct	AI-CHAIN.1	根据锚点重建取证链	为事件响应或审计生成可验证的时间线。
swt3_trajectory	AI-MOB.6	记录自主轨迹决策	证明 VLA/路径规划模型已记录其决策。ISO/PAS 8800。

合规检查提示词

新增的提示词模板 compliance-check 可引导大模型执行结构化合规评估。该提示词接收一个框架 ID，并使用可用的 SWT3 工具返回分步评估计划。评估人员可以直接在 Claude Desktop、Cursor 或任何 MCP 客户端中运行该提示词。

为什么 33 个工具很重要

原有的 23 个工具覆盖了见证生命周期：铸造、验证、签名、查询。新增的 10 个工具覆盖了治理生命周期：授权、筛选、审查、同意、重建。通过 MCP 使用 SWT3 的 AI Agent 现在可以在 MCP 协议内完成完整的合规工作流，无需离开 MCP。无需单独集成 SDK。无需单独调用 API。每项合规义务只需调用一个工具。

v0.6.3

新增 6 个工具和 1 个提示词模板。最新功能填补了自动驾驶汽车合规方面的空白：NVIDIA 开源了一个用于 Robotaxi 的 34B VLA 模型，EU AI Act 将自动驾驶汽车归类为高风险（Annex III, 3a），而每家对开源 VLA 模型进行微调的公司都需要目前尚不存在的问责基础设施。

• 轨迹决策证明（AI-MOB.6）——witness_trajectory 工具。每项自动驾驶决策都会生成规划轨迹和因果推理追踪。此工具记录 VLA 或路径规划模型是否生成了轨迹、该轨迹是否通过安全验证，以及其分类级别（正常、谨慎、降级、紧急、中止）。上下文只存储哈希和计数——绝不存储原始坐标、航点或专有的 CoC 追踪。与模型无关——适用于任何 VLA、路径规划器或运动模型。ISO/PAS 8800、EU AI Act Annex III(3a)、UNECE WP.29 R157。

• RAG 上下文见证（AI-RAG.1/RAG.2）——witness_rag_context 工具。每个 RAG 流水线都会检索内容块，但没有一个能证明使用了哪些内容块、它们来自哪个语料库，以及相关性得分是多少。此工具为每次检索铸造来源锚点：内容块数量、语料库身份、嵌入模型。内容块文本会在本地哈希，绝不会发送到服务端。如果提供了相似度得分和阈值，第二个 AI-RAG.2 锚点会记录上下文相关性，证明检索达到了质量阈值，而不只是证明检索发生过。EU AI Act Art. 12（记录保存）和 NIST AI RMF MEASURE 2.6 要求提供此类证据。没有这些证据，RAG 系统就没有来源链。

• 护栏见证（AI-GRD.1）——witness_guardrail 工具。护栏会运行，但没有证据证明它们确实运行过。当内容过滤器拦截响应、PII 脱敏器删除敏感数据，或毒性分类器标记输出时，此工具会创建加密记录：使用了哪个护栏、是否触发，以及采取了什么操作（拦截、脱敏、标记、允许）。这是 EU AI Act Art. 9（风险管理措施）和 NIST AI RMF GOVERN 1.7 要求填补的证据缺口。仅提供证据——绝不会阻止执行。

• 人工审查见证（AI-HITL.1）——witness_human_review 工具。监管机构要求证明人类在作出重大决策前审查过 AI 输出。此工具记录审查结果（批准、拒绝、修改、升级），将其绑定到经过哈希处理的审查者身份，并记录审查延迟。EU AI Act Art. 14（人工监督）、GDPR Art. 22（自动化决策）和 SR 11-7 Section III.A（有效质询）都要求证明人工审查确实发生过，而不只是证明审查流程存在。两者的区别在于，“我们有审查流程”和“这是锚点，证明审查者 #a8f3 在审查 45 秒后批准了输出 #7c91”。

• 治理门控评估——gate_evaluate 工具。团队会在 .swt3-gate.yml 文件中定义合规策略，但在此之前，这些策略只能通过命令行检查。此工具可通过任何 MCP 客户端直接解析和验证门控配置：门控数量、框架覆盖范围、模型风险分配和警告。将 evaluate_live: true 设为启用，即可根据服务端上的实际见证锚点检查策略，从而回答“我当前运行的系统是否符合我声明的策略？”。离线验证无需网络调用。

• 取证时间线重建 —— reconstruct_timeline 工具。发生事件时，审计人员需要按顺序了解事情发生的完整过程，不能选择性取证。此工具会向服务查询符合某个周期、Agent、指纹、链或时间窗口的所有见证锚点，并按时间顺序呈现。返回流程标签、判定结果、成本数据，以及漂移／覆盖／违规标记。为事件响应团队提供所需证据，帮助回答“AI 做了什么，何时做的”，而不必依赖可能不完整或遭篡改的应用日志。

• 合规检查提示词 —— compliance-check 提示词模板。为 34 种受支持的监管框架生成自适应会话提示词。列出适用于该框架的流程、覆盖这些流程的 MCP 工具，并引导会话从开始审计直至生成覆盖报告。帮助不熟悉合规见证的开发者减少“不知道从何开始”的阻力。

• 同意见证（AI-CONSENT.1）—— witness_consent 工具。GDPR 第 6／7 条规定的同意，是欧洲最常引发诉讼的 AI 合规议题。此工具记录处理前是否已记录同意或合法依据：法律依据类型（同意、合同、合法利益等）、主体数量、是否提供撤回机制，以及司法管辖区。CJT 字段（司法管辖区、法律依据、目的类别）在所有清除级别下都会保留——即使在第 3 级（机密）下，监管元数据也会保留。这是审计人员首先会索取的证据。

• 输出安全见证（AI-GRD.2）—— witness_output_filter 工具。此工具不同于 witness_guardrail（AI-GRD.1，用于见证护栏的激活）。它记录输出侧的分类结果：模型输出是否通过内容安全过滤器？运行了哪种过滤器？采取了什么措施？当监管机构因输出违规而关闭 AI 系统时，问题不在于是否存在护栏，而在于是否有证据证明每项输出都经过了分类。欧盟《AI 法案》第 15(3) 条。

• 事件见证（AI-INCIDENT.1）—— witness_incident 工具。NIS-2 要求在 24 小时内报告事件。欧盟《AI 法案》第 62 条要求报告严重事件。此工具会创建防篡改记录，记载事件的发现时间、严重程度、类型，以及是否已通知主管部门。锚点时间戳是发现时间的证明——当监管时限为 24 小时，且问题是“你们什么时候知道的？”时，这一点至关重要。

• 数据溯源见证（AI-DATA.1）—— witness_data_provenance 工具。证明已完成训练数据治理审查，但不会披露训练数据内容。不含数据集名称，也不含许可文本——只记录是否已审查治理情况（布尔值）、文档哈希（数据卡的哈希，而非数据本身）、许可证是否已验证，以及是否确认不存在人口统计特征。此工具旨在应对欧盟《AI 法案》第 10 条（训练数据文档要求）与商业秘密保护之间的矛盾。证据表明“我们已履行尽职审查”，而不是“这是我们的数据”。

• 司法管辖区解析器 —— resolve_jurisdiction 工具。传入 ISO 3166-1 国家代码（例如，“JP”“DE”）或 ISO 3166-2 细分区域代码（例如，“US-CA”），即可获取所有适用的监管框架，并按约束力状态分组：强制性（有执法机制的法律）、指导性（政府指南）和自愿性（行业标准）。对于细分区域，会同时返回当地和国家层面的框架。已为 50 多个司法管辖区代码映射 34 种框架。无需阅读 34 张对照表，即可回答“我在德国部署——适用哪些框架？”。

• 33 个工具、1 个提示词、36 种框架、114 个流程、2 个资源。

v0.6.1

• 委派树见证（AI-DEL.1）—— witness_delegation_tree 工具。
• 资源消耗见证（AI-COST.1）—— witness_resource_consumption 工具。

v0.6.0

• 生命周期链——多锚点治理序列。包括紧急覆盖、映射后果的漂移，以及冠军-挑战者评估见证。新增 3 个流程（AI-EMRG.1、AI-DRIFT.2、AI-ASSESS.1）。

v0.5.9

• 合规智能——resolve_crosswalk 可将任意流程映射到其满足的所有框架控制项（36 个框架、118 个流程，支持离线使用）。coverage_report 可显示你的审计会话已覆盖指定框架中的哪些流程，并提供得分和剩余差距。
• 与核心 SDK v0.5.9 保持一致（resolve()、coverage()、本地见证模式）。

见证中间件

适用于任何 MCP 服务的零集成合规见证。包装传输层后，每次工具调用都会自动生成一个 AI-TOOL.1 见证锚点。无需更改工具处理程序代码。无需集成 SDK。只需一行代码。

import { withSWT3 } from "@tenova/swt3-mcp/middleware";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const transport = withSWT3(new StdioServerTransport(), {
  apiKey: process.env.SWT3_API_KEY,
});
await server.connect(transport);
// Every tool call now auto-witnesses AI-TOOL.1 anchors

**工作原理：**中间件会包装传输层的 send() 和 onmessage，以观察 tools/call 请求/响应对。在响应已发送到线路后，它会发送见证 POST。工具处理程序完全不需要知道 SWT3 的存在。失败不会向上传播。工具调用不会受到阻止、延迟或任何其他影响。

**适用于任何传输方式：**Stdio、SSE、HTTP、WebSocket、自定义传输。中间件通过鸭子类型识别 MCP Transport 接口——无需依赖 @modelcontextprotocol/sdk。

**演示模式：**省略 apiKey 后，锚点会记录到 stderr，而不是通过 POST 发送。适用于本地开发。

配置

选项	默认值	描述
endpoint	https://sovereign.tenova.io	Axiom API 端点
apiKey	演示模式	API 密钥（axm_...）
tenantId	自动解析	租户 ID
clearingLevel	1	数据清除级别（0-3）
agentId		Agent 身份（AI-ID.1）
signingKey		HMAC 签名密钥
maxBuffer	100	丢弃最旧条目前允许跟踪的待处理调用数上限
onWitness		每次见证尝试后触发的回调

回调

withSWT3(transport, {
  apiKey: process.env.SWT3_API_KEY,
  onWitness: (receipt) => {
    console.log(`${receipt.toolName} -> ${receipt.fingerprint} (${receipt.latencyMs}ms)`);
    if (receipt.error) console.warn(`Witness failed: ${receipt.error}`);
  },
});

无论见证成功还是失败，每次工具调用都会触发回调。只有见证 POST 失败时才会设置 error 字段——工具调用本身从未受到影响。

为何存在此项目

2026 年，Flowise 中的 MCP 配置注入导致数千个 AI 工作流实例遭到任意代码执行。遭入侵的第三方 AI 工具（Context.ai）进一步渗透到 Vercel 的内部系统。Microsoft 披露了 Semantic Kernel 中的 RCE 漏洞。65% 的公司报告发生过 AI Agent 事件。只有 14.4% 的 Agent 在获得完整合规批准后上线。

Agent 发起的每次工具调用都应留下见证记录。本服务会记录这些调用，根据声明的策略进行评估，并生成可证明事件经过的加密证据链。审计轨迹不可更改。如果工具调用不符合策略，见证记录会记录违规行为，从而形成证据，证明尝试执行了什么操作以及适用的规则。

Trust Mesh——安全的 Agent 间通信

见证自己的 Agent 是第一步。接下来的问题是：你能信任另一端的 Agent 吗？在两个 Agent 交换数据、调用彼此的工具或共享上下文之前，双方都会验证对方的合规状况。没有锚点，就没有握手。

你运行 Agent A。你的合作伙伴运行 Agent B。事情会这样进行：

Your Agent (A)                    Partner's Agent (B)
     |                                  |
     |--- presentCredential() --------->|
     |                                  |-- verifyTrust(credential)
     |                                  |-- signed? yes
     |                                  |-- procedures witnessed? 12 of 12
     |                                  |-- trust level? 2 (verified)
     |<---------- GRANTED --------------|
     |                                  |
     |    (data exchange begins)        |
     |                                  |
     |<-- presentCredential() ----------|
     |-- verifyTrust(credential)        |
     |-- signed? yes                    |
     |-- trusted tenant? yes            |
     |------------ GRANTED ------------>|
     |                                  |
     |    (bidirectional trust)         |

双方各自需要：

1. 双方都安装 SDK（pip install swt3-ai 或 npm install @tenova/swt3-ai）
2. 双方都使用签名密钥和信任边界配置 .swt3.yaml
3. 双方都将对方的租户添加到 trusted_tenants
4. 通过带外方式（环境变量、密钥管理器、KMS）交换签名密钥
5. 在交换任何数据之前调用 presentCredential() / verifyTrust()

就是这样。采用 SWT3 见证层后，你的合作伙伴和供应商也必须采用它，才能与你的 Agent 交互。合规性成为连接协议。网格中的每个 Agent 都会增强整个网络。

# Your .swt3.yaml
trust_mesh:
  mode: strict
  min_trust_level: 2
  require_signature: true
  trusted_tenants: ["PARTNER_B_TENANT"]

# Partner's .swt3.yaml
trust_mesh:
  mode: strict
  min_trust_level: 2
  require_signature: true
  trusted_tenants: ["YOUR_TENANT"]

信任级别：

级别	名称	含义
1	基础	凭证有效，但未验证签名
2	已验证	凭证 + HMAC 签名已确认
3	已证明	已验证 + 硬件证明 + 护栏
4	主权级	已证明 + 清算级别为 2+

未签名的 Agent 最高只能达到级别 1。你可以决定 Agent 接受的最低级别。所有验证都在本地进行。云端开销为零。在双方通过关卡之前，不会有任何数据离开。

策略即代码（swt3.yaml）

在 YAML 文件中定义完整的见证策略。无需构造函数参数，也无需管理杂乱的环境变量：

# Generate a config from a built-in profile
npx @tenova/swt3-mcp  # reads .swt3.yaml automatically

# .swt3.yaml
endpoint: https://sovereign.tenova.io
tenant_id: YOUR_TENANT
api_key_env: SWT3_API_KEY
clearing_level: 2
signing_key_env: SWT3_SIGNING_KEY
agent_id: my-agent

trust_mesh:
  mode: strict
  min_trust_level: 2
  require_signature: true

mcp_policy:
  require_witness: true
  blocked_tools: ["shell_exec", "rm_rf"]

使用 extends: 叠加配置，以覆盖特定环境的设置。SDK 内置了三个配置档：eu-ai-act-high-risk、nist-ai-rmf 和 minimal。

验证配置：

npx swt3 doctor       # 8 checks: YAML, env vars, profile, trust mesh

零配置启动

npx @tenova/swt3-mcp

就是这样。无需账户、API 密钥或配置。服务会以演示模式启动，并立即生成本地见证锚点。

让你的 Agent 见证一次推理，你就会看到：

Verdict: PASS
Anchor: SWT3-DEMO-LOCAL-AI-AIINF1-PASS-1779146826-ed28dc4c2698
Procedure: AI-INF.1
Model: gpt-4o
Clearing Level: 1
Fingerprint: ed28dc4c2698

该指纹是租户、过程、因素和时间戳的 SHA-256 哈希。任何人都可以独立重新计算。如果匹配，锚点就是真的。如果有一个位发生变化，哈希就会失效。

准备好将锚点持久化到 SWT3 账本时，可在 Agent 对话中使用 signup 工具，无需离开编辑器。

设置

Streamable HTTP 传输（Meta Muse、远程 Agent）

适用于通过 HTTP 而非 stdio 连接的 MCP 客户端（Meta Muse、远程 Agent 编排器、基于 Web 的 MCP 客户端）：

npx swt3-mcp-http

这会在 localhost:8080 上启动一个无状态 HTTP 服务，接受 streamable HTTP MCP 连接。使用 --port 配置端口：

npx swt3-mcp-http --port 9090

有关可直接复制粘贴的设置说明，请参阅 Muse Connector Guide。

Claude Desktop

添加到 claude_desktop_config.json：

{
  "mcpServers": {
    "swt3": {
      "command": "npx",
      "args": ["@tenova/swt3-mcp"]
    }
  }
}

Cursor

添加到 .cursor/mcp.json：

{
  "mcpServers": {
    "swt3": {
      "command": "npx",
      "args": ["@tenova/swt3-mcp"]
    }
  }
}

Claude Code

claude mcp add swt3 -- npx @tenova/swt3-mcp

工作原理

1. Add server to your MCP config         (one line)
2. Start using AI tools as normal         (zero code changes)
3. Ask your agent to witness inferences   (anchors minted locally)
4. Use the signup tool when ready          (free account, never leave your editor)
5. Anchors persist to the SWT3 ledger     (cryptographic compliance trail)

三种模式

模式	所需配置	运行方式
演示	无	仅本地锚点，即时启动
仅 API 密钥	SWT3_API_KEY	自动解析租户，持久化锚点
完整配置	SWT3_API_KEY + SWT3_TENANT_ID	显式指定租户，持久化锚点

监管覆盖

每个锚点都映射到具体的监管义务：

• EU AI Act：第 9、10、12、13、14、53、72 条
• NIST AI RMF：GOVERN、MAP、MEASURE、MANAGE 职能
• OWASP Agentic Top 10：工具滥用、提示词注入、链式利用
• CMMC：为国防承包商自动化生成 2 级证据
• NIST 800-53：SI-7（完整性）、AU-2/AU-3（审计）、AC 控制措施
• SR 11-7：金融服务的模型风险管理
• ISO 42001：附录 A AI 管理控制措施

工具（75）

见证： witness_inference -- 为任意 AI 推理铸造加密锚点。提示词和响应仅在本地进行哈希处理，不会发送到服务器。返回判定结果（PASS/FAIL）、锚点令牌和验证 URL。 witness_rag_context -- 见证 RAG 检索溯源和可选的相关性评分（AI-RAG.1/RAG.2）。数据块仅在本地进行哈希处理。 witness_guardrail -- 见证护栏实现和激活状态（AI-GRD.1）。记录触发状态和采取的操作。 witness_human_review -- 见证对 AI 输出的人工参与审核（AI-HITL.1）。记录结果、审核者绑定信息和延迟。

委派与资源治理： witness_delegation_tree -- 见证带范围绑定、级联撤销和深度跟踪的分层权限委派（AI-DEL.1）。 witness_resource_consumption -- 见证累计令牌用量、API 调用次数和预估成本（AI-COST.1）。

治理关卡： gate_evaluate -- 解析并验证 .swt3-gate.yml 治理配置。可进行离线验证，也可针对服务器锚点进行实时评估。

取证重建： reconstruct_timeline -- 按周期、Agent、指纹、链或时间窗口重建见证锚点的取证时间线。

验证： verify_anchor -- 验证现有锚点的加密完整性。

信任网格： verify_agent_trust -- 验证其他 Agent 的合规凭证。 present_trust_credential -- 出示你的 Agent 凭证以供验证。

审计会话： start_audit_session -- 使用会话 ID 开始限定范围的审计会话。 end_audit_session -- 结束会话并获取包含 Merkle 根的摘要。

Agent 链： start_chain -- 使用周期 ID 初始化多 Agent 链。 chain_handoff -- 记录链中 Agent 之间的交接。 report_violation -- 按严重程度和类别报告策略违规。

模型治理： witness_model_integrity -- 见证模型权重哈希，以检测篡改。 witness_adapter_stack -- 见证 LoRA/适配器配置。

技能证明： attest_skill_manifest -- 见证已加载的技能和插件。 attest_memory_context -- 见证 Agent 访问的记忆来源。

授权： witness_authorization -- 见证推理前的授权决策。

合规智能： resolve_crosswalk -- 查询法规交叉映射。给定一个程序（例如 AI-FAIR.1），返回其满足的所有框架控制项。给定一个框架（例如 EU-AI-ACT），返回所有映射的要求。可离线使用，无需 API 调用。 coverage_report -- 报告当前审计会话中已见证程序的框架覆盖情况。显示已覆盖/剩余程序及覆盖率百分比。

发现： list_procedures -- 浏览 UCT™ 程序注册表（293 个程序，10 个命名空间）。 suggest_procedures -- 根据你的使用场景获取推荐程序。 check_posture -- 检查当前租户的合规状况。 signup -- 创建免费账户，无需离开编辑器。

提示词（1）

compliance-check -- 生成用于某个法规框架的自适应合规见证会话提示词。参数：framework（必需）、model_id（可选）、context（可选）。列出适用程序、可用 MCP 工具和会话工作流。

环境变量（可选）

变量	默认值	描述
SWT3_API_KEY	演示模式	API 密钥（以 axm_ 开头）
SWT3_TENANT_ID	自动解析	租户 ID（若省略，则从 API 密钥解析）
SWT3_ENDPOINT	https://sovereign.tenova.io	见证端点
SWT3_CLEARING_LEVEL	1	数据清理级别（0=分析，1=标准，2=敏感，3=机密）
SWT3_AGENT_ID		AI-ID.1 的 Agent 身份
SWT3_SIGNING_KEY		HMAC-SHA256 签名密钥（在服务器端注册以供验证）

清除级别

级别	离开设备的数据
0	所有元数据
1	哈希值 + 模型 ID + 上下文
2	哈希值 + 模型 ID
3	仅因素，模型 ID 经哈希处理

无论处于哪个清除级别，原始提示词和响应文本都不会离开你的设备。

资源

• SWT3 协议规范 -- 含 ABNF 语法的正式规范
• UCT 注册表 -- 完整的流程目录及因素定义
• 锚点验证器 -- 验证任意锚点，无需调用服务器
• 一致性测试向量 -- 用于跨语言一致性的 13 个测试向量
• swt3://registry/procedures -- MCP 资源：完整的 UCT 流程目录
• swt3://health -- MCP 资源：服务健康状态

许可证

Apache 2.0。专利申请中。

由 TeNova™ 构建。问题请联系：[email protected]

SWT3、swt3-ai、TeNova、Axiom Sovereign Engine、UCT 和 Sovereign Score 是 Tenable Nova LLC 的商标。本项目与任何第三方 AI 提供商均无关联，也未获得其认可或赞助。MCP（Model Context Protocol）是 Anthropic PBC 的商标。所有其他第三方商标均为其各自所有者的财产。使用这些名称仅用于识别和互操作目的。