2026/01/30 4:45
**幻覚防御**
RSS: https://news.ycombinator.com/rss
要約▶
日本語訳：
主旨：
ログだけでは、人間がAIエージェントの行動を許可したことを証明できません。なぜなら、ログはイベントを記録するに過ぎず、付与された権限の範囲を示さないからです。この記事では warrants（証書）―人間がパスキー/WebAuthn で署名した暗号化・限定・時間制約付きオブジェクト ― を提案し、マルチホップ委任にわたる耐久性のある検証可能な認可を提供します。
主要な論理：
- マルチエージェントシステムでは、サブエージェントが元の監査ドメイン外で動作したり、広範囲の統合クレデンシャルを使用するため、単一の検証可能な委任チェーンが欠如しやすい。
- 高リスク領域（例：銀行業）は、長期間有効なセッションに頼るよりも明示的な認可アーティファクトを必要とする。
- ワラントは人間の署名をエージェントの公開鍵に結び付け、機能・制約を指定し、TTL を含み、使用時にレシートを生成します。
証拠／例：
$50 k の送金先任意のワラントが署名されました。後に $48 k の未承認送金が発生しました。レシートは広範なスコープが人間によって許可されたことを示していましたが、具体的な取引は許可されていませんでした。これにより、ワラントが 許可された ものを捉える一方で、必ずしも実際に起こった事象を反映するわけではないことが明らかになります。
セキュリティ上のメリット：
• ワラントは経路または機能制限を強制するため、攻撃者がセッションを乗っ取っても許可された機能外の行動は決定的に拒否されます（プロンプト注入攻撃の緩和）。
• 署名デバイスが侵害された場合、フォレンジック調査で使用されたパスキーと時刻を追跡できます。盗まれた OAuth ベアラートークンにはこのような証拠はありません。
• 所有者結合により、盗まれたワラントは無効になります。
技術的実装：
Tenuo は Ed25519 署名と機能ベースの委任を使用したオープンソースフレームワークです。AI モデル内部の信頼仮定に関係なく、ワラントを 27 µs で検証します。
行動への呼びかけ：
この記事は、プロダクション環境でワラントと Tenuo を導入し、アカウンタビリティを向上させ、侵害されたセッションやトークンからのリスクを低減し、監査要件を満たすことについて議論するよう呼びかけています。
本文
「AIが幻覚を起こした。そんなことは指示していないんだ。」
これが主な弁護です。そして問題点は、しばしば自信を持って反論するのが難しいということです。
ファイナンシャルアナリストが「四半期報告書を要約する」ためにAIエージェントを使います。３か月後、フォレンジック調査で競合他社の受信トレイからM&Aターゲットリストが発見されます。エージェントはファイルへアクセスし、メールを送った―しかしプロンプト履歴は削除済みです。元々の指示は？アナリストの言葉とログの対立。
人間にスコープ付き委任を結ぶ耐久性のある暗号証明がなければ、「AIがやった」という防御が簡単になります。エージェントは証言できず、記憶もなく、防御すらできません。
ログは証拠ではない
「でも全てをログに残しているよ。OAuthのログもあるんだ。」
ほとんどの本番エージェントシステムは多くをロギングします―それは良い実践です。ログは何が、いつ、誰が行ったかを可視化します。
2026-01-15T14:32:01Z agent=research-bot action=file_read path=/data/ma/target-corp.pdf 2026-01-15T14:32:03Z agent=research-bot action=email_send to=external@competitor.com
適切な設定（append‑only ストレージ、署名付きタイムスタンプ、保持制御）をすれば、ログは改ざん検知可能です。システム内部でイベントが起きたことの証拠として優れています。
しかし争点になるのは「何かが起きたか？」ではなく：
- どこのエージェントに対し、この種のアクションを許可したのか、どんな制約で、どれくらいの期間、そしてその権限はどう流れたのか。
エージェント事故の典型的な失敗は「何が起きたかわからない」ではなく：
「特定の人間がこのアクションを可能にしたスコープを明示的に承認した証拠を提示できない。」
このギャップはマルチエージェントシステムで広がります。
- 人間がオーケストレーターを許可
- オーケストレーターがサブエージェントを生成
- サブエージェントがプラグイン、第三者サービス、外部ランタイムを呼び出す
- 最終アクションはあなたのアイデンティティドメインや監査システム、ポリシーエンジンと共有しない場所で実行される可能性がある
この世界ではログは「有効なセッションが存在した」「アクセス権を持つコンポーネントが動作した」ことを示せます。しかし単一の検証可能チェーンで、最終アクターが人間に委任されたスコープ内で動いていたかどうか（汎用セッショントークンや広範な統合資格ではなく）を示すのは難しくなります。
これはロギング、承認、ポリシーエンジン、トークン強化を否定するものではありません。責任追及には「マルチホップ実行を経ても生き残る独立して検証可能な委任証拠」がもう一つ必要だという主張です。それがリスクギャップ ― 「イベントを記録した」ことと「そのイベントの検証可能な委任チェーンを作成できる」ことの間にあります。
実際のお金が動く場合、機関は「誰かがセッションを持っていた」という事実だけではなく、明示的な承認ステップ（ステップアップ認証、承認、デュアルコントロール、コールバック）と承認決定の耐久記録を要求します。組織間レールではメッセージが認証され、参加者はそのレール内で誰が何を送ったかを検証できます。
すべての銀行利用者が各指示に暗号署名を行うわけではありませんが、一般的なポイントがあります：
高リスクシステムでは、責任単位は「アクションとその承認記録」であり、長寿命セッションではない。
チェックシステムは多くのドキュメントされた欠陥を持ちつつも興味深いです。なぜなら、承認を後で提示できるアーティファクトとして扱うからです。緩やかな非暗号化的手法で、エージェント委任に求められる二つの特性を示唆します。
-
指定交渉 ― チェックは受取人へ向けられ、裏付け/預金ルールが誰が楽器を成功させるか、どこで行うかを制御しようと試みます。制限付きの裏付け（「預金のみ…」）は保持者バインディングへの粗い手続き的アプローチです。暗号的強制ではありませんが、形は正しい：特定の保持者またはルート向けに作られた承認アーティファクトであり、再生可能な資格情報ではありません。
-
非増幅 ― チェックは希少資金を清算します。多く書いても、最終的には限られた残高（または信用枠）に対して和解されます。失敗は遅れて検出されるかもしれませんが、委任は価値を創造しません。
Tenuo Warrants は両方のアイデアを現代的な強制力でエージェント行動に適用します：ワラントは特定のエージェントキーに保持者束縛され、遷移する際に委任スコープが狭まるように縮小可能です。これが非否認性ポイントです：ツールやサブエージェントを横断して委任が行われる場合、後で「誰が何を承認したか」を示す耐久アーティファクトが必要になります。
しかしエージェントシステムでは「セッションを認証（Bobがログイン）し」、ロギング、プロンプト履歴、下流効果の混合から意図を推論します。これが機能するまでに役立ちますが、委任パスが曖昧だったり、第三者ツールや自律サブエージェントが関わる事案では機能しなくなります。
OAuth は設計目的に優れています：アクセスを委任しトークンレベルでスコープを表現します。しかしベアラートークンはポータブル資格情報です。保持者はそれを使用できます。送信者制限付きトークン（mTLS、DPoP）で再生リスクを減らせますが、それでも次のような原始的な要素が欠けています：
「この人間がこのエージェントアイデンティティに対し、これらの制約内で何クラスの操作を行うか許可したアクションレベルの承認アーティファクトはどこ？」
ワラント：すべてのアクションへの署名付き承認
Tenuo ワラントは暗号的、スコープ付き、時間限定の承認オブジェクトで、エージェントランタイムから独立して検証可能であり、マルチホップ委任を経ても意味があります。
# 人間がパスキー/WebAuthn で署名（手動キー管理は不要） warrant = Warrant.mint( issuer=alice_passkey, holder=agent_public_key, capability="file_read", constraints={"path": Subpath("/data/reports")}, ttl=timedelta(hours=1), )
エージェントがファイルを読み取るとき、このワラントを提示します。ファイルサーバは署名を検証し、制約をチェックし、認可証拠とアクションメタデータをペアにしたレシートを発行します。
検証者は次を確認：
- 発行者署名（誰が承認したか）
- 保持者バインディング（ワラントに記載されたエージェントキーを持っていることの証明）
- 機能 + 制約 + 有効期限（何が許可され、どこで、いつまでか）
- 委任チェーン（権限がホップごとにどう流れたか、エージェントが委任できるか）
レシートは：
- アリスの署名（暗号的承認証明）
- 制約（許可された範囲の暗号的証明）
- 検証時刻（いつ承認・受諾されたかの証拠）
- アクションメタデータ（何が要求/実行されたかの証拠）
ログは記述する。レシートは証明する。
攻撃を再現
同じシナリオ。アナリストはベンダー請求書のバッチ処理をしたい。ワラントに高制限で署名し、エージェントが残りを処理させる方が簡単です。
3:12 PM にパスキーで署名されたワラント：
tool: transfer amount: range(0, 50000) to: * ttl: 3600
その日他のアナリストも同様のバッチサイズを処理しました。彼らは 12–15 個のワラントに署名しました：
tool: transfer amount: range(0, 500) to: vendors/approved/* ttl: 60
3か月後、フォレンジックで外部アカウントへ $48,000 の送金がバッチ内で混在していたことを検出。
アナリストの弁護：「AIが幻覚を起こした。効率的にやっていただけだ。」
あなたの回答：他の全員は同じボリュームをタスクスコープ付きワラントで処理しました。あなたは 1 時間で任意の受取人に対し 100 倍以上の上限を許可するワラントに署名した。それが証拠です。
レシートはログでは不可能な「何を許可したか」を明らかにします。
「プロンプトインジェクションはどうなる？」
攻撃者がセッション中にエージェントを乗っ取ると責任追及が崩れるのでは？
ワラントはプロンプトインジェクションを無効化するわけではありません。範囲を明示的に限定し、承認を不可逆にします。
- 制約 は何が起こり得るかを制限します。ワラントが
を指定していれば、インジェクションでSubpath("/data/reports")
を読むことは決定的に拒否されます。機能が存在しないので、プロンプトの内容に関係なく許可されません。/etc/shadow
攻撃は成功しますが、アクションは起きません。レシートは何が承認されたかを証明します。もし何かが発生したなら、ワラントチェーンはそれを許可した署名者を示します。
承認は明示的です。 UI は「エージェントを承認する」ではなく、「エージェントに /data/reports を 1 時間読むことを承認する」と表示されます。広範な承認は選択肢であり、署名すれば責任が伴います。
ワラントはガードレール（制約による防御）とレシート（署名による責任追及）の両方です。
署名デバイスが侵害されたら？
-
パスキーが盗まれた場合、犯罪現場があります。攻撃者は特定のデバイスを侵害したことになります。誰がいつ何を署名したかが分かり、フォレンジックで指摘できます。
-
OAuth トークンが盗まれた場合、幽霊が残ります。ベアラートークンには所有証明がなく、保持者はどこからでも使用可能です。ログは何が起きたかを示すだけで、行動とデバイス・ユーザー・意図の瞬間を結び付けません。
ログはシステム側の主張です。レシートは承認者による署名声明です。
数学を信頼する
プロンプトフィルタが証言できないとき、違反が起きた時、召喚状が届いた時、規制機関から「これが承認されたことを証明してください」と問われた時に、プロンプトエンジニアリング戦略を説明したくありません。
署名は人間と行動を結び付けます。保持者バインディングで盗まれたワラントは無効になります。制約が爆風半径を限定します。いずれもモデルに頼る必要はありません。
レシートが欲しいのです。
Tenuo は AI エージェント向けのオープンソース認可フレームワークです。
Ed25519 署名、機能ベース委任、27 µs の検証速度。
本番でエージェントをデプロイするなら、ぜひお話しください。