ACPバウンドコマンド認可（提案）

ステータス: 提案中、未実装。

このドキュメントでは、ACPバウンド会話におけるネイティブコマンドの長期的な認可モデルについて説明する。これは実験的な提案であり、現在の本番動作を置き換えるものではない。

実装済みの動作については、以下のソースとテストを参照:

  • src/telegram/bot-native-commands.ts
  • src/discord/monitor/native-command.ts
  • src/auto-reply/reply/commands-core.ts

課題

現在、コマンドごとの個別チェック（例: /newや/reset）があり、許可リストが空でもACPバウンドのチャンネル/トピック内で動作する必要がある。これは当面のUX上の問題を解決するが、コマンド名ベースの例外処理はスケールしない。

長期的な設計方針

コマンド認可を、アドホックなハンドラーロジックからコマンドメタデータ＋共有ポリシー評価器に移行する。

1) コマンド定義に認可ポリシーメタデータを追加

各コマンド定義で認可ポリシーを宣言する。形式の例:

type CommandAuthPolicy =
  | { mode: "owner_or_allowlist" } // デフォルト、現在の厳格な動作
  | { mode: "bound_acp_or_owner_or_allowlist" } // 明示的にバウンドされたACP会話で許可
  | { mode: "owner_only" };

/newと/resetはbound_acp_or_owner_or_allowlistを使用。 他のほとんどのコマンドはowner_or_allowlistのまま。

2) チャンネル間で1つの評価器を共有

以下を使用してコマンド認可を評価する単一のヘルパーを導入:

  • コマンドのポリシーメタデータ
  • 送信者の認可状態
  • 解決された会話バインディング状態

TelegramとDiscordの両ネイティブハンドラーが同じヘルパーを呼び出し、動作の乖離を防ぐ。

3) バインディングマッチをバイパス境界として使用

ポリシーがACPバウンドバイパスを許可する場合、現在の会話に対して設定されたバインディングマッチが解決された場合にのみ認可する（単にセッションキーがACP風に見えるだけでは不十分）。

これにより境界が明示的に保たれ、意図しない拡大を最小限に抑える。

この設計が優れている理由

  • コマンド名の条件分岐を追加することなく、将来のコマンドにもスケール。
  • チャンネル間で一貫した動作を維持。
  • 明示的なバインディングマッチを要求することで、現在のセキュリティモデルを保持。
  • 許可リストを普遍的な要件ではなく、オプションの強化として維持。

ロールアウト計画（将来）

  1. コマンドレジストリ型とコマンドデータに認可ポリシーフィールドを追加。
  2. 共有評価器を実装し、TelegramとDiscordのネイティブハンドラーを移行。
  3. /newと/resetをメタデータ駆動のポリシーに移行。
  4. ポリシーモードごと、チャンネルサーフェスごとのテストを追加。

非目標

  • この提案はACPセッションのライフサイクル動作を変更しない。
  • この提案はすべてのACPバウンドコマンドに許可リストを要求しない。
  • この提案は既存のルートバインディングセマンティクスを変更しない。

注意

この提案は意図的に追加的であり、既存の実験ドキュメントを削除・置換するものではない。

次へ
Overview
arrow_forward