SWT3 AI Witness

@tenova/swt3-mcp

MCP Registry に io.tenova/swt3-witness として登録されています

SWT3™ AI Witness プロトコル用の MCP サーバーです。あらゆる MCP 互換 AI エージェントに、暗号技術によるコンプライアンス証明を追加します。

SWT3（Sovereign Witness Traceability）は、AI の入出力をローカルでハッシュ化し、数値要素（レイテンシ、トークン数、ガードレールの状態）を抽出して、誰でも個別に検証できる暗号フィンガープリントに記録します。プロンプトと応答がデバイスの外に出ることはありません。監査担当者は改ざん防止された証拠を取得でき、データはそのまま手元に残ります。

プロトコル仕様： swt3.ai/spec | レジストリ： swt3.ai/registry | 検証： swt3.ai/verify

v0.7.9 の新機能

v0.7.9 は、エコシステムアダプターのリリースです。開発者が日常的にデプロイしている 4 つのプラットフォーム、すなわち高速な Groq、オープンウェイトモデルのホスティングに対応する Together AI、費用対効果の高い推論を提供する DeepSeek、エンタープライズクラウド向けの Azure OpenAI に、Python と TypeScript の両方で完全な自動検出に対応したネイティブの Witness アダプターが追加されました。新たに 6 つのプロバイダー別 Witness ガイドで、初回インストールから本番環境へのデプロイまでを解説しています。アダプターエコシステムは、10 の SDK 言語で 47 のプロバイダーに対応するようになりました。

MCP にとっての重要性： MCP サーバーは、これらすべてが集約される統合ポイントです。Claude Desktop ユーザーが、すばやい推論のために Groq を呼び出し、二次チェックのために Azure OpenAI を呼び出す MCP ツールを実行すると、どちらの呼び出しも同じ形式で Witness アンカーを生成します。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 個のツールを通じて連携するアンカーを生成します。プロバイダー別の設定は不要です。個別の監査ダッシュボードも必要ありません。1 つの MCP サーバーで、1 つの証拠ストリームを実現します。

新しい 6 つのガイドでは、最も一般的な MCP のデプロイパターンを解説しています。

ガイド	内容
OpenAI GPT の Witness	GPT-4o、o1、o3 のストリーミングとシステムフィンガープリントの取得
Anthropic Claude の Witness	Claude のストリーミング、ツール使用チェーン、拡張思考
Google Vertex/Gemini の Witness	OpenAI 互換エンドポイント経由の Vertex AI ＋ Google ADK エージェントの Witness
DeepSeek GPAI の Witness	R1 推論チェーンの取得、GPAI Code of Practice へのマッピング
Groq の Witness	レイテンシ証明に対応した LPU 推論
LangChain/LangGraph の Witness	チェーンとグラフのオーケストレーション向けコールバックハンドラーとプロキシアダプター

v0.7.9 の新しいアダプター

アダプター	プロバイダータグ	備考
wrap_groq / wrapGroq	groq	レイテンシ取得に対応した LPU 推論
wrap_together / wrapTogether	together	オープンウェイトモデルの提供
wrap_deepseek / wrapDeepSeek	deepseek	R1 推論チェーンの Witness
wrap_azure_openai / wrapAzureOpenAI	azure-openai	デプロイ名の保持、コンテンツフィルターの検出

ディスカバリーファイルの同期

v0.7.9 では、すべての MCP ディスカバリーメタデータも統一されます。mcp.json、agent-card.json、llms.txt、server.json の各ファイルで、バージョン番号、フレームワーク数、ガイド数が同一になりました。MCP クローラーとエージェントディスカバリーボットは、すべてのエンドポイントで一貫したメタデータを確認できます。

対応範囲の拡大

• 10 個の名前空間にわたる 293 個のプロシージャ
• 75 個の MCP ツール、340 個のコンプライアンスガイド、78 個の規制フレームワーク、47 個のアダプター、10 言語の SDK

v0.7.8 の新機能

6 つの新しいアダプターにより、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	エージェントの呼び出し可能オブジェクトの実行（AI-INF.1）	AWS のエージェントオーケストレーションフレームワーク。120 社以上のエンタープライズ顧客が利用していますが、監査機能は組み込まれていません
Mistral AI	wrap_mistral	chat.complete()、chat.stream()、非同期処理	欧州の主権 AI。Mistral は EU のインフラ上で稼働し、8 月 2 日以降は GPAI コンプライアンスが必須です
NVIDIA NemoClaw	NemoClawWitness	ポリシーエンジンの判断（AI-GRD.1）	ハードウェアレベルの AI ガバナンス。NeMo Guardrails のポリシー判断を独立して記録します
NVIDIA ROSClaw	ROSClawWitness	ROS 2 ロボティクスの監査ログイベント	ロボティクスのコンプライアンス。EU 機械規則（2027 年 1 月）では、安全性が重要なロボットにおける AI の判断証拠が求められます

ガイド：IBM Granite Adapter | AWS Bedrock Guardrails | Mistral AI Adapter | NVIDIA NemoClaw

MCP にとって重要な理由： MCP サーバーは、プロバイダー間のツール呼び出しをオーケストレーションします。Granite モデルが Bedrock Guardrail を起動し、それが Strands エージェントの動作を制御する場合、MCP サーバーは単一の証跡ストリームを通じて、判断チェーン全体を把握できるようになりました。6 つの新しいアダプターにより、主要なクラウド AI プラットフォーム上で稼働する MCP 接続ツールは、プロバイダーごとの統合作業なしに、MCP サーバーが集約、照会、エクスポートできるアンカーを生成します。

v0.7.6 の新機能

2026 年第 3 四半期から第 4 四半期にかけて、NIST、FIDO Alliance、G7、Singapore IMDA、EU（DORA）の 5 つの標準化団体が、エージェントガバナンス要件について合意しました。v0.7.6 では、委任チェーンの追跡可能性、スコープ境界の監視、エージェントの中断可能性に関する最後の証拠不足を解消する 3 つのプロシージャが追加されました。

MCP にとって重要な理由： MCP プロトコルは、NIST AI Agent Interoperability Profile で「分断が進む前にガバナンスの意見を必要とする構造的な進展」と明示されています。エージェントの割り込み証跡（AI-SAFE.2）とスコープ境界の証明（AI-SAND.2）は、MCP ツールサーバーに直接関係します。ポリシーによって MCP クライアントのツール呼び出しがブロックされた場合、それは監査人が証拠を必要とするガバナンスイベントです。NIST Agent Profile のフレームワークテンプレートは、事前にマッピング済みで、仕様が 2026 年第 4 四半期に公開されれば、同日中に内容を反映できます。

3 つの新しいプロシージャ

• AI-DEL.3（委任チェーンの完全性）：複数エージェント間の引き継ぎにおける委任チェーンの完全性を記録します。MCP クライアントがサブエージェントに委任すると、チェーンの完全性を証明できるようになります。
• AI-SAND.2（スコープ境界の証明）：境界の適用状況に関するレポートを記録します。ツールサーバーがアクションを宣言済みのスコープに制限すると、このプロシージャによって境界への準拠を証明できます。
• AI-SAFE.2（エージェントの割り込み証明）：トリガー元、一時停止されたアクション、状態の保持状況とともに、キルスイッチのイベントを記録します。EU AI Act 第 14 条 4 項（e）の割り込み可能性に直接対応しています。

新しいクロスウォーク

• G7 AI-SBOM -- 50 の最低限の要素を 18 の SWT3 プロシージャに対応付け
• DORA -- EU の金融機関向けに 20 のプロシージャを対応付け
• Singapore IMDA Agentic MGF -- 4 つのガバナンス領域にわたって 24 のプロシージャを対応付け
• NIST Agent Profile -- 3 つの柱（アイデンティティ、ロギング、封じ込め）に事前対応付けしたフレームワークテンプレート

更新された対応範囲

• 10 の名前空間にわたる 293 のプロシージャ
• 75 の MCP ツール、340 のコンプライアンスガイド、78 の規制フレームワーク
• G7 AI-SBOM クロスウォーク | DORA + ECB クロスウォーク

v0.7.4 の新機能

NVIDIA は OpenShell を 120 以上のパートナーに提供しました。エージェントの封じ込めは、今やインフラストラクチャです。しかし、サンドボックスポリシーが適用されたことを証明する MCP ツールは存在しませんでした。v0.7.4 では、蒸留の来歴および誘導検出とともに、witness_runtime_containment を追加しました。新しいツール 3 つにより、ガバナンス上の課題 3 つを解消します。

MCP サーバーにとっての重要性： witness_runtime_containment により、あらゆる MCP クライアントが SDK を一切インポートせずに、OpenShell、gVisor、Kata、Firecracker、または WASM サンドボックスから暗号学的な封じ込めの証拠を生成できます。witness_distillation は、教師モデルから生徒モデルへの系譜を記録します。witness_elicitation は、プロンプト境界への違反を記録します。いずれもダックタイピングに対応し、クリアリングレベルを認識します。

3 つの新しい MCP ツール（合計 75 個）

ツール	プロシージャ	記録内容
witness_runtime_containment	AI-SHELL.1	ランタイムのサンドボックスポリシー適用状況、違反数、OCSF イベント数、観測期間
witness_distillation	AI-DIST.1	教師モデルから生徒モデルへの系譜、蒸留の種類（logit/feature/attention/data/hybrid）、ToS 準拠状況
witness_elicitation	AI-MCP.6	ツールの応答を介したプロンプト境界への違反、同意状況、スコープ違反の種類、検出方法

更新された対応範囲

• 10 の名前空間にわたる 278 のプロシージャ（従来は 277）
• 75 の MCP ツール（従来は 74）
• 277 のコンプライアンスガイド
• NVIDIA OpenShell クロスウォーク -- OpenShell、gVisor、Kata、Firecracker のランタイム封じ込めの証拠
• 引受審査に関するやり取り向け AI 保険証拠ガイド
• Meta Muse およびその他の HTTP ネイティブ MCP クライアント向け Streamable HTTP トランスポート（swt3-mcp-http）

v0.7.3 の新機能

A2A（Google のエージェント間プロトコル）は、150 以上の対応組織、3 つすべてのハイパースケーラー、Linux Foundation のガバナンス下にある v1.0 安定仕様を擁しています。しかし、監査証跡は組み込まれていません。MCP OAuth の採用率は 8.5％にとどまり、60 日間で 30 件以上の CVE が報告されました。v0.7.3 では、専用プロシージャ、ライフサイクルを認識するアダプター、新しいクロスウォーク CLI コマンドにより、SWT3 が両方のエージェント通信プロトコルの証拠レイヤーになります。

MCP サーバーにとっての重要性： 新しいツールが 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、レジストリ、または紹介を通じたエージェントの検出
witness_context_chain	AI-A2A.3	フォレンジック分析での再構築に向けた、複数エージェントの委任チェーンにおける 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) という 1 つの関数呼び出しでこれを変えます。Witness Middleware は、Stdio、SSE、HTTP、カスタムなど、あらゆる MCP トランスポートをラップし、すべてのツール呼び出しに対して 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);

1 行だけです。すべてのツール呼び出しを記録します。当社のものに限らず、あらゆる MCP サーバーで動作します。

これが重要な理由： MCP の導入は加速していますが、コンプライアンスの証拠は後回しにされています。既存の MCP サーバーに Witness を組み込むには、すべてのツールハンドラーに手を加える必要があり、ツールが何十個もあるサーバーや、自分たちが所有していないサーバーでは現実的ではありません。ミドルウェアパターンを使えば、この障壁を取り除けます。JSON-RPC レイヤーを監視し、ツール名とタイミングを抽出してアンカーを生成し、バックグラウンドで送信します。既存のサーバーをリファクタリングすることなく、暗号学的なアテステーションを追加できます。ミドルウェアは次の機能にも対応しています。

• バッチ処理 — ペイロードをバッファーに保存し、サイズのしきい値、時間間隔、またはトランスポートの終了時に送信します
• サンプリング — 大量の呼び出しがあるサーバー向けに、ツールごとのサンプリング率を決定論的なハッシュに基づいて設定します。スキップされた呼び出しはカウントされ、AI-SAMPLE.1 アンカーに要約されます
• マルチテナント解決 — 各ツール呼び出しがどのテナントに属するかを解決するコールバックです。1 つのミドルウェアインスタンスでフリート全体をカバーします
• 再試行 — 失敗したバッチに対して、指数バックオフを使用する、有界なインメモリーキューで再試行します
• デモモード — API キーが設定されていない場合は標準エラー出力にログを記録するため、バックエンドがなくてもアンカーを確認できます

5 つの新しいハーネスガバナンス手順

AI ハーネスレイヤー（オーケストレーション、委任、コンテキスト管理、サンドボックス化、評価ゲート）は、AI インフラストラクチャの中で最も注目されているカテゴリです。2026 年末までにエンタープライズアプリの 40% に AI エージェントが含まれると予測されている一方で、ハーネスレイヤーで暗号学的なアテステーションを実施している組織はありません。v0.7.2 では、ハーネスレベルのガバナンス判断を監査可能にする 5 つの手順を追加します。

ツール	手順	記録する内容
witness_orchestration_topology	AI-ORCH.1	ルーティングパターン（並列／逐次／階層型）、エージェント数、依存関係の深さ
witness_agent_handoff	AI-ORCH.2	委任元から委任先への ID の関連付け、権限差分の方向
witness_context_window	AI-CTX.1	削除前後のトークン数、削除方法
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 を公開しました。MCP サーバーの 30～82％が、ツールポイズニング、不十分な認証、シャドーサーバーの増殖に対して脆弱です。v0.7.1 では、残る OWASP のギャップを埋める 3 つの新しいツールを追加しました。SWT3 は、暗号学的証拠によって OWASP MCP リスクの 10 項目すべてに対応する初の MCP サーバーになりました。

3 つの新しい MCP ツール（合計 68）

ツール	手順	記録内容	OWASP MCP リスク
witness_mcp_tool_integrity	AI-MCP.2	接続時と呼び出し時のスキーマハッシュ。差異があれば FAIL。	MCP-03 ツールポイズニング
witness_mcp_server_auth	AI-MCP.3	認証方式、検証状況。認証なしの場合は FAIL（IA-9 の指摘事項）。	MCP-07 不十分な認証
witness_mcp_server_discovery	AI-MCP.4	検出方法、許可リストの確認。シャドーサーバーがあれば FAIL。	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 では、AI インフラストラクチャスタック全体にわたる証跡の取得を拡張する 22 の新しい MCP ツールを追加しました。ツールは合計 59 個です。

22 個の新しい MCP ツール（合計 59 個）

AI が依存するインフラストラクチャをカバーする、3 つの新しいツールファミリーが追加されました。

認証情報ガバナンス（NHI） -- 6 個のツール。 AI エージェントは、サービスアカウント、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	深度の追跡を伴う、エージェント間の認証情報の委任
witness_nhi_revocation	NHI-REV.1	カスケード対応の認証情報失効

ハードウェアおよびバッテリーパスポート（HBOM/DPP） -- 10 個のツール。 EU バッテリー規則では、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 のトレーニングは、小規模な都市と同程度の電力を消費します。デマンドレスポンスイベントをめぐる精算の紛争は、実際に何が起きたのかを独立して証明する仕組みがないため、6 桁の金額に達します。これらのツールは、系統信号、ベースライン、出力抑制、精算、炭素クレジット、系統との相関という、ライフサイクル全体をカバーします。

ツール	手順	記録する内容
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 個のツールは、エージェントがどのような認証情報を使って認証するか、どのようなハードウェア上で動作するか、どれだけのエネルギーを消費するかという、インフラストラクチャのライフサイクルをカバーします。MCP 経由で SWT3 を使用する AI エージェントは、認証に使う認証情報から、生成する推論、そしてその生成に消費する電力に至るまで、すべてをカバーできるようになりました。ツールは合計 59 個です。

数字で見る

• MCP ツール 59 個（37 個から増加）
• 75 個の名前空間にまたがる 266 個の手続き（118 個／64 個から増加）
• 約 2,950 件のテストに合格
• コンプライアンスガイド 237 件（222 件から増加）

v0.6.6 の新機能

サプライチェーンの説明責任：新しいツール 4 個（合計 37 個）、TypeScript SDK のガバナンス機能の同等化、OTel GenAI 規約、CI/CD ゲートアクションが追加されました。テーマは、個々の推論が適切に振る舞ったかどうかだけでなく、AI のサプライチェーンが把握され、範囲が限定され、監視されていることを証明することです。

新しい MCP ツール 4 個（合計 37 個）

ツール	手続き	機能	重要な理由
witness_model_provenance	AI-PROV.1	モデルの系譜を記録します。ベースモデル、トレーニングパイプライン、ファインチューニングの系譜、親モデルのフィンガープリントが含まれます	G7 広島 AI SBOM と EU AI Act 第 53 条では、来歴の文書化が求められています。派生モデルを暗号学的フィンガープリントで祖先モデルに結び付けます。
witness_delegation_boundary	AI-DEL.2	エージェントに許可されていない操作を記録します。ブロックされたツール、制限されたスコープ、エスカレーションのトリガーが含まれます	EU AI Act 第 14 条では、AI の制限事項を文書化することが求められています。エージェントが動作する前に制約が宣言されていたことを証明します。
witness_anchor_density	AI-DENSITY.1	一定期間内の証跡付きイベント数と全イベント数の比率を記録します	評価者が気付く前に、カバレッジが 100％ から 2％ に低下するドリフトを検出します。監視が単に設定されていただけでなく、一貫して実施されていたことを証明します。
witness_mcp_security	AI-MCP.1	MCP サーバー接続のセキュリティ特性 8 項目を評価します。合格したチェック数と全チェック数を記録し、具体的にどのチェックに失敗したかは決して記録しません	NSA／CISA は、脆弱な MCP デプロイが 20 万件以上あると警告しました。攻撃マップにならずに、セキュリティ評価の証拠を作成します。

この 4 つのツールが連携して重要となる理由

従来の 33 個のツールは、証跡のライフサイクル（発行、検証、署名）とガバナンスのライフサイクル（承認、フィルタリング、レビュー、同意）をカバーしていました。今回追加された 4 個のツールは、サプライチェーンのライフサイクルをカバーします。モデルの出所、エージェントに許可されていない操作、監視が一貫して維持されたかどうか、MCP 接続が保護されていたかどうかを扱います。MCP 経由で SWT3 を使用するエージェントは、モデルの来歴から実行時の動作、監視の忠実度まで、エンドツーエンドでカバーできるようになりました。コンプライアンス要件ごとにツールを 1 回呼び出します。ツールは合計 37 個です。

TypeScript SDK のガバナンス機能の同等化

TypeScript SDK で、ガバナンスの証跡記録に関する Python との完全な機能同等性が実現しました。witnessGovernanceReview()、witnessGovernanceConfig()、witnessGovernanceException()、witnessPolicyEnforcement() など、10 個の新しいメソッドが追加されています。MCP 対応エージェントを構築する TypeScript チームも、ガバナンスの証拠に関して二級市民ではなくなりました。

OTel GenAI セマンティック規約

Python と TypeScript の OTel エクスポーターが、OpenTelemetry GenAI セマンティック規約に従って gen_ai.system、gen_ai.request.model、トークン使用量の属性を出力するようになりました。OTel 経由でエクスポートされた証跡アンカーは、GenAI スパンを取り込む 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 規模のエージェントデプロイに対応した、本番環境向けの準備が整いました。

Witness ミドルウェア

機能： withSWT3(transport) は任意の MCP トランスポートをラップし、すべてのツール呼び出しを AI-TOOL.1 アンカーとして自動的に証跡化します。ツールハンドラーのコード変更は不要です。証跡化が行われる前にレスポンスはすでに送信されているため、処理をブロックせず、ツールが失敗することもありません。当社のものに限らず、あらゆる MCP サーバーで動作します。バッチ処理、サンプリング、マルチテナント解決、上限付きキューによる再試行に対応しています。詳しくは、以下のWitness ミドルウェアをご覧ください。

重要性： MCP の導入は加速していますが、コンプライアンスの証拠を伴わずに提供されている MCP サーバーがほとんどです。ミドルウェアパターンを使えば、既存のサーバーに1行追加するだけで暗号学的な証明を得られます。リファクタリングも、ツールハンドラーの変更も、パフォーマンスへの影響もありません。証跡化が行われる前にレスポンスはすでに送信されています。複数の MCP サーバーを運用するプラットフォームチームでは、マルチテナントコールバックが各ツール呼び出しのテナントを解決するため、1つのミドルウェアインスタンスでフリート全体をカバーできます。

確率的証跡化との互換性

Python および TypeScript SDK が、10億回規模の推論を行う GPAI デプロイメント向けに sampling_rate に対応しました。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 が動作する前に、誰かが実行を承認したことを証明します。EU AI Act 第9条では、導入前のリスク管理が求められています。
swt3_guardrail	AI-GRD.1	ガードレールの有効化状況を記録	推論時に安全フィルターが有効だったことを証明します。単に設定されていただけではありません。
swt3_hitl	AI-HITL.1	人によるレビューの完了を記録	資格を持つ人が AI の判断をレビューしたことを証明します。EU AI Act 第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 は、構造化されたコンプライアンス評価を LLM に促します。プロンプトにフレームワーク ID を指定すると、利用可能な SWT3 ツールを使用した段階的な評価計画が返されます。評価者は Claude Desktop、Cursor、または任意の MCP クライアントで直接実行できます。

33 個のツールが重要な理由

従来の 23 個のツールは、証跡のライフサイクルであるミント、検証、署名、クエリをカバーしていました。新たに加わった 10 個のツールは、ガバナンスのライフサイクルである認可、フィルタリング、レビュー、同意、再構築をカバーします。MCP 経由で SWT3 を利用する AI エージェントは、MCP プロトコルを離れることなく、コンプライアンスワークフロー全体を処理できるようになりました。別途 SDK を統合する必要はありません。別途 API を呼び出す必要もありません。コンプライアンス上の義務ごとに、ツールを 1 回呼び出すだけです。

v0.6.3

新しいツールが 6 個、プロンプトテンプレートが 1 つ追加されました。最新の更新では、自動運転車のコンプライアンスにおける空白を埋めます。NVIDIA は 34B の VLA モデルをオープンソース化し、EU AI Act は自動運転車を高リスク（Annex III, 3a）に分類しています。オープン VLA モデルをファインチューニングするすべての企業には、まだ存在しない説明責任のためのインフラが必要です。

• 軌跡決定の証跡化（AI-MOB.6）-- witness_trajectory ツールです。自動運転の判断ごとに、計画された軌跡と因果的な推論トレースが生成されます。このツールは、VLA モデルまたは経路計画モデルが軌跡を生成したこと、安全性の検証に合格したかどうか、および分類レベル（nominal、cautionary、degraded、emergency、abort）を記録します。コンテキストにはハッシュと件数のみが保存されます。生の座標、ウェイポイント、独自の 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 パイプラインはチャンクを取得しますが、どのチャンクをどのコーパスからどの関連度スコアで使用したかを証明できるものはありません。このツールは、チャンク数、コーパスの識別情報、埋め込みモデルについて、取得ごとに来歴アンカーをミントします。チャンクテキストはローカルでハッシュ化され、サーバーに送信されることはありません。類似度スコアとしきい値が指定されると、2 つ目の AI-RAG.2 アンカーがコンテキストの関連性を記録します。これにより、取得が行われたことだけでなく、品質しきい値を満たしていたことも証明できます。EU AI Act Art. 12（記録保持）および NIST AI RMF MEASURE 2.6 では、この証拠が求められています。これがなければ、RAG システムには来歴チェーンがありません。

• ガードレールの証跡化（AI-GRD.1）-- witness_guardrail ツールです。ガードレールは実行されますが、実行されたことを証明する手段はありません。コンテンツフィルターが応答をブロックした場合、PII レダクターが機密データを削除した場合、または有害性分類器が出力にフラグを立てた場合、このツールはどのガードレールが作動したか、作動したかどうか、どのような措置を取ったか（blocked、redacted、flagged、allowed）を暗号学的に記録します。これは、EU AI Act Art. 9（リスク管理措置）および NIST AI RMF GOVERN 1.7 が求める証拠の欠落を埋めます。証拠の記録のみを行い、実行をブロックすることはありません。

• 人間によるレビューの証跡化（AI-HITL.1）-- witness_human_review ツールです。規制当局は、重要な意思決定の前に人間が AI の出力をレビューしたことを示す証拠を求めています。このツールはレビュー結果（approved、rejected、modified、escalated）を記録し、ハッシュ化されたレビュアーの識別情報に紐付け、レビューにかかった時間を記録します。EU AI Act Art. 14（人間による監督）、GDPR Art. 22（自動化された意思決定）、SR 11-7 Section III.A（有効な異議申し立て）のすべてで、レビューが可能だったというだけでなく、人間によるレビューが実際に行われた証拠が求められています。「レビューのプロセスがあります」と「レビュアー #a8f3 が 45 秒間レビューした後、出力 #7c91 を承認したことを示すアンカーはこちらです」の違いです。

• ガバナンスゲートの評価-- gate_evaluate ツールです。チームは .swt3-gate.yml ファイルでコンプライアンスポリシーを定義しますが、これまでは CLI からしかポリシーを確認できませんでした。このツールを使うと、あらゆる MCP クライアントからゲート設定を解析、検証できます。ゲート数、フレームワークのカバレッジ、モデルのリスク割り当て、警告を確認できます。evaluate_live: true を設定すると、サーバー上の実際の証跡アンカーに対してポリシーを確認できます。これにより、「稼働中のシステムは、現時点で宣言したポリシーを満たしているか」という問いに答えられます。オフライン検証はネットワーク呼び出しなしで実行されます。

• フォレンジックタイムラインの再構築 — reconstruct_timeline ツール。インシデント発生時、監査担当者には、都合よく情報を選別せず、何が起きたのかを順を追ってすべて確認する必要があります。このツールはサーバーに問い合わせ、サイクル、エージェント、フィンガープリント、チェーン、または時間範囲に一致するすべての証跡アンカーを時系列で表示します。手順ラベル、判定、コストデータ、ドリフト／上書き／違反フラグを返します。アプリケーションログが不完全または改ざんされている可能性に頼らず、インシデント対応チームが「AI は何をいつ行ったのか」という問いに答えるために必要な証拠です。

• コンプライアンス確認プロンプト — compliance-check プロンプトテンプレート。サポート対象の 34 の規制フレームワークのいずれにも対応した、適応型セッションプロンプトを生成します。そのフレームワークに適用される手順と、それをカバーする MCP ツールを一覧表示し、監査の開始からカバレッジレポートの作成までセッションをガイドします。コンプライアンス監査の証跡取得に不慣れな開発者が「何から始めればよいのか」と悩む負担を軽減します。

• 同意の証跡取得（AI-CONSENT.1） — witness_consent ツール。GDPR 第 6／7 条に基づく同意は、欧州で最も訴訟の多い AI コンプライアンスのテーマです。このツールは、処理前に同意または適法な根拠が文書化されていたことを記録します。法的根拠の種類（同意、契約、正当な利益など）、対象者数、撤回手段の有無、管轄区域を記録します。CJT フィールド（jurisdiction、legal_basis、purpose_class）は、あらゆるクリアリングレベルで保持されます。レベル 3（機密扱い）でも、規制上のメタデータは維持されます。監査担当者が最初に求める証拠です。

• 出力安全性の証跡取得（AI-GRD.2） — witness_output_filter ツール。ガードレールの作動を証跡として記録する witness_guardrail（AI-GRD.1）とは異なります。このツールは出力側の分類結果を記録します。モデルの出力はコンテンツ安全性フィルターを通過したのか、どの種類のフィルターが実行されたのか、どのような措置が取られたのか。規制当局が出力違反を理由に AI システムを停止させる場合、問題はガードレールが存在したかどうかではなく、各出力が分類されたことを示す証拠があるかどうかです。EU AI Act 第 15 条 3 項。

• インシデントの証跡取得（AI-INCIDENT.1） — witness_incident ツール。NIS-2 では、24 時間以内のインシデント報告が求められます。EU AI Act 第 62 条では、重大インシデントの報告が求められます。このツールは、インシデントの検知時刻、重大度、種類、当局への通知の有無を改ざん検知可能な記録として作成します。アンカーのタイムスタンプは検知時刻の証明となります。規制上の期限が 24 時間で、「いつ把握したのか」が問われる場合に重要です。

• データ来歴の証跡取得（AI-DATA.1） — witness_data_provenance ツール。学習データの内容を開示せずに、学習データのガバナンスレビューが実施されたことを証明します。データセット名もライセンス文字列も記録せず、ガバナンスレビューの実施（真偽値）、文書のハッシュ（データカードのものであり、データ自体のものではありません）、ライセンスの確認、人口統計的特徴が含まれていないことの確認のみを記録します。EU AI Act 第 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 の統合も不要です。1行で設定できます。

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 を省略すると、アンカーは POST されず、標準エラー出力に記録されます。ローカル開発に便利です。

設定

オプション	デフォルト値	説明
endpoint	https://sovereign.tenova.io	Axiom API エンドポイント
apiKey	デモモード	API キー（axm_...）
tenantId	自動解決	テナント ID
clearingLevel	1	データクリアリングレベル（0-3）
agentId		エージェントの識別情報（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}`);
  },
});

証人記録の成功・失敗にかかわらず、すべてのツール呼び出しでコールバックが実行されます。error フィールドが設定されるのは、証人記録用の POST が失敗した場合のみです。ツール呼び出し自体には影響しません。

これが必要な理由

2026年、Flowise における MCP 設定のインジェクションにより、数千の AI ワークフローインスタンスで任意コード実行が発生しました。侵害されたサードパーティ製 AI ツール（Context.ai）は、Vercel の内部システムに侵入しました。Microsoft は Semantic Kernel の RCE 脆弱性を公表しました。65% の企業が AI エージェントに関するインシデントを報告しています。完全なコンプライアンス承認を得て本番稼働しているエージェントは、わずか14.4%です。

エージェントによるすべてのツール呼び出しを証人記録すべきです。このサーバーはそれらの呼び出しを記録し、宣言されたポリシーに照らして評価し、何が起きたかを証明する暗号学的な証拠チェーンを生成します。監査証跡は変更できません。ツール呼び出しがポリシーに一致しない場合、証人記録に違反が記録され、何が試みられ、どのルールが適用されたかを証明できます。

Trust Mesh -- エージェント間の安全な通信

自分のエージェントを証明することが第一歩です。次の疑問は、相手側のエージェントを信頼できるかどうかです。2つのエージェントがデータを交換したり、互いのツールを呼び出したり、コンテキストを共有したりする前に、双方が相手のコンプライアンス態勢を検証します。アンカーがなければ、ハンドシェイクもありません。

あなたがエージェント A を運用し、パートナーがエージェント 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 witness レイヤーを導入すると、あなたのエージェントとやり取りするために、パートナーやベンダーも同様に導入する必要があります。コンプライアンスが接続プロトコルになります。メッシュ内のすべてのエージェントがネットワークを強化します。

# 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 以上です

署名のないエージェントはレベル 1 が上限です。エージェントが受け入れる最低レベルは自分で決定できます。検証はすべてローカルで行われます。クラウドのオーバーヘッドはゼロです。双方がゲートを通過するまで、データが外部に送信されることはありません。

Policy-as-Code（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 の3つの組み込みプロファイルが用意されています。

設定を検証します：

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

ゼロ設定で開始

npx @tenova/swt3-mcp

以上です。アカウントも API キーも設定も必要ありません。サーバーはデモモードで起動し、ただちにローカルの witness アンカーを発行します。

エージェントに推論の証明を依頼すると、次のように表示されます：

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 ハッシュです。誰でも独立して再計算できます。一致すれば、アンカーは本物です。1ビットでも変更されると、ハッシュは一致しません。

SWT3 台帳へのアンカーの永続化を開始する準備ができたら、エージェントとの会話内で signup ツールを使います。エディターを離れる必要はありません。

セットアップ

Streamable HTTP Transport（Meta Muse、リモートエージェント）

stdio ではなく HTTP 経由で接続する MCP クライアント（Meta Muse、リモートエージェントオーケストレーター、Web ベースの MCP クライアント）の場合：

npx swt3-mcp-http

これにより、ストリーミング可能な HTTP MCP 接続を受け付けるステートレス HTTP サーバーが localhost:8080 で起動します。--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)

3つのモード

モード	必要な設定	動作
デモ	なし	ローカルのみのアンカーで、すぐに開始できます
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 -- サイクル、エージェント、フィンガープリント、チェーン、または時間範囲ごとに、証跡アンカーのフォレンジックタイムラインを再構成します。

検証： verify_anchor -- 既存のアンカーの暗号学的整合性を検証します。

トラストメッシュ： verify_agent_trust -- 別のエージェントのコンプライアンス認証情報を検証します。 present_trust_credential -- 検証のために、自分のエージェントの認証情報を提示します。

監査セッション： start_audit_session -- セッション ID を指定して、スコープ付き監査セッションを開始します。 end_audit_session -- セッションを終了し、Merkle ルートを含む概要を取得します。

エージェントチェーン： start_chain -- サイクル ID を指定して、マルチエージェントチェーンを初期化します。 chain_handoff -- チェーン内のエージェント間の引き継ぎを記録します。 report_violation -- 重要度とカテゴリを指定して、ポリシー違反を報告します。

モデルガバナンス： witness_model_integrity -- 改ざん検出のため、モデルの重みのハッシュを記録します。 witness_adapter_stack -- LoRA／アダプター設定を記録します。

スキル認証： attest_skill_manifest -- 読み込まれているスキルとプラグインを記録します。 attest_memory_context -- エージェントがアクセスするメモリソースを記録します。

認可： 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 用のエージェント ID
SWT3_SIGNING_KEY		HMAC-SHA256 署名キー（検証のため、サーバー側で登録してください）

クリアリングレベル

レベル	送信される情報
0	すべてのメタデータ
1	ハッシュ＋モデル ID＋コンテキスト
2	ハッシュ＋モデル ID のみ
3	ファクターのみ、モデル ID はハッシュ化

どのクリアリングレベルでも、生のプロンプトや応答テキストが端末の外に送信されることはありません。

リソース

• SWT3 Protocol Spec -- ABNF 文法を含む正式な仕様
• UCT Registry -- ファクター定義を含む手順の完全なカタログ
• Anchor Verifier -- サーバーへの呼び出しなしで、あらゆるアンカーを検証
• Conformance Vectors -- 言語間の同等性を確認する 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 の商標です。その他すべてのサードパーティ商標は、それぞれの所有者に帰属します。これらの名称は、識別および相互運用性を目的としてのみ使用しています。