検証済みサポートエージェント

実際のAIエージェントであり、Claude Agent SDK で構築され、バックエンドへの唯一の経路は KYA-OS で保護されたMCPサーバーです（Vouched によって Decentralized Identity Foundation に寄贈された、オープンなエージェンティックIDおよび委任標準）。

このシナリオは、Vouched自身が繰り返し用いる例を反映しています。つまり、50ドルの返金は自動で処理できるが、それ以上の金額には人間の承認が必要なサポートエージェントです。ここにあるものはすべて本物です。実際のEd25519署名による暗号化ID、実際のW3C委任資格情報、それを発行する実際の同意HTTPサーバー、そしてツール呼び出しを行う実際のエージェントです。モックされているのは注文データだけです（下記の「モックにする理由」を参照）。

Agent calls issue_refund($30)  -> executes immediately, proof attached
Agent calls issue_refund($500) -> needs_authorization -> human approves at a real URL -> agent retries -> succeeds

これが存在する理由

AIエージェントは現在、ユーザーに代わって行動します。注文状況の確認、返金の発行、送金など、ユーザー本人と区別がつかない資格情報を使用します。セッションCookieは、3つの別々の質問を1つの区別できないHTTPリクエストにまとめます。実際に行動しているのは誰か、誰の権限で、その特定のアクションがその権限の範囲内か。KYA-OSはこれら3つの質問に個別に答えるため、リスクの低いアクションは完全に自動化でき（誰が行ったかの署名付き証明付き）、リスクの高いアクションでは、エージェントがその特定の権限を委任されたことを証明する必要があり、多くの場合、人間のライブ同意ステップが必要です。

Vouched自身の資料では、2つの例が繰り返し登場します。サポート/返金エージェント（「50ドルの返金は自動で処理するが、5,000ドルを超える場合は承認が必要」）と旅行予約エージェント（「フライト状況の確認はできるが、承認なしでフライトを予約することはできない」）です。このリポジトリは、最初の例を実際にエンドツーエンドで構築します。

Related MCP server: Commerce Operations MCP Server

クイックスタート

npm install
npm run verify   # deterministic, no LLM needed - proves the whole lifecycle works
npm run agent    # the real thing - a live Claude Agent SDK agent driving 3 scripted turns

npm run verify は src/verify-lifecycle.ts を実行します。これは、1つのプロセスでライフサイクルのすべての部分を実行する自己完結型スクリプトです（証明の生成、証明の検証、意図的に失敗する改ざんテスト、needs_authorization -> real consent-server approval -> auto-applied retry -> success の完全なループ）。各チェックごとに PASS/FAIL を出力します。APIキーは不要で、LLMを呼び出すことはありません。

npm run agent は src/agent.ts を実行します。これは、Claude Agent SDK で構築された実際のエージェントで、stdio を介して MCP ツールソースとして src/server.ts に接続されます。3つのプロンプトを実行します。注文の確認、30ドルの返金の発行、500ドルの返金の発行です。そして、3つ目で意図的に認可リンクで停止します。その一時停止がポイントです。エージェントは証明や資格情報を一切見ず、時々人間に認可リンクを中継するよう求めるツールを見るだけです。ANTHROPIC_API_KEY が設定されている必要があります（または認証済みの claude CLI セッション）。

各ファイルの内容

これを独自のMCPサーバーに適用する

kya-tools.ts のパターンは、任意のMCPサーバーに一般化できます：

1. サーバーのIDをラップします：createKyaOsMiddleware({ identity, session: {...}, autoSession: true }, crypto)。

2. 各ツールを分類します。読み取り専用またはリスクの低いもの：kyaos.wrapWithProof('tool_name', handler) - 署名付き証明によって属性を付与でき、ゲートされません。リスクの高いもの：kyaos.wrapWithDelegation('tool_name', { scopeId, consentUrl, formatChallenge }, kyaos.wrapWithProof('tool_name', handler)) - そのスコープを持つ委任資格情報が提示されるまでブロックされます。

3. consentUrl を独自の承認ページに指定するか、consent-server.ts と public/consent.html をそのまま再利用します。

4. 委任ゲートされたハンドラーを formatAsConsentLink() でラップします（kya-tools.ts を参照）。これにより、承認された資格情報が呼び出し側の再試行時に自動的に適用され、誰も手動で資格情報を貼り付ける必要がなくなります。

これは、このデモが動作するという証拠だけでなく、統合ガイドの形をしています。

モックにする理由、実際の統合ではない理由

check_order_status と issue_refund は、小さな固定のインメモリデータセットで動作します。実際の注文、実際の顧客、実際の決済処理業者、PCI/PII関連のものは一切ありません。ここで実証されているのは、KYA-OSのIDと委任であり、eコマースや決済エンジニアリングではありません。実際の統合を追加すると、データ処理とセキュリティの表面が増えるだけで、そのストーリーには何の利益もありません。

これが意図的にまだカバーしていないもの

• Checkpoint（Vouchedのエージェントトラフィック検出レイヤー）- 実際の無料セルフサービスサインアップがありますが、これはこのリポジトリの範囲外の個人アカウント作成ステップです。

• Multiple frameworks - Vouched自身のドキュメントには、Next.js、Express、Python、HTML、直接APIがリストされています。このリポジトリはNode/TypeScriptのみです。@kya-os/mcp のAPIはトランスポートに依存しないため、Expressバリアントは自然な次のステップです。

• IdentiClaw / KnowThat.ai - VouchedのKYAスイートの他の2つのレイヤー。公開ドキュメントはまだ薄いです。

基盤

@kya-os/mcp - Model Context Protocol 向けの KYA-OS の MIT ライセンスのリファレンス実装。Vouched から Decentralized Identity Foundation の Trusted AI Agents Working Group に寄贈されました。