obsidian-tc: 人による確認が拒否された場合、HTTP経由での破壊的な操作が可能になる可能性がある。
### 概要
`auth.jwtSecret`が設定されたStreamable HTTP環境において、2026年7月28日頃のクライアント（`elicitation.form`をサポートしていると宣言）が、ディスパッチによって制限されたツール（`destructive: true`、またはHITLによる制限）に対して、`inputRequired`の確認を提示した場合、ユーザーが拒否したり、キャンセルしたり、またはエリシテーションの応答が省略または不正な場合でも、クライアントが有効な`requestState`を再送信した場合、操作が完了する可能性がある。サーバーは、認証された、コールに紐づいた状態を承認の証拠として信頼する。この状態は、エリシテーションの段階が開始される前に生成されるため、再送信が同じコールに属していることを示すに過ぎない。
### 詳細
再現手順：`destructive: true`のツールに対して`inputRequired`を提示し、`elicitation/create`の段階で`{action: "decline"}`と応答すると、操作が実行される。これは、v1.13.0でリリースされた2026年7月28日のバージョンから存在する問題（THE-583）。ディスパッチによって制限されたツールのみがアクセス可能であり、ハンドラ側で条件付きに制限された16種類のツール（ノートの上書き、ノートの移動など）は、最新の通信プロトコルでエリシテーションの状態を一切読み取らないため、拒否も承認も通さない。
### 影響
ユーザーが拒否後に状態を再送信する場合、ユーザーが明示的に拒否した破壊的なVault操作（削除、フォルダ間の移動、フロントマターの置換、リンクの書き換えなど）を実行できてしまう可能性がある。この前提条件は、正しく動作しないクライアント、または攻撃者の制御下にあるクライアントである。サーバーは、ユーザーの拒否を強制しない。
### 修正点
バージョン1.31.4で修正：サーバーは、エコーされた状態を信頼する前に、確認プロセス側の応答 (`inputResponse`) が `{action: "accept", content: {approve: true}}` であることを要求するようになりました。拒否、キャンセル、または承認されなかったラウンドでは、通常の `elicit_required` エラーが発生し、同じ確認プロセスに対する再試行は行われません。このバージョンでは、stdio（レガシー）環境でサーバーが開始するインバンド確認機能が追加されたため、stdioエージェントは `elicit_token` を自身で生成する必要がなくなりました。
### 対応していない点
悪意のあるクライアントまたは準拠していないクライアントは、人間の発言に関係なく、自身の `elicitation/create` プロセスで承認の応答を送信することができます。サーバーは、クライアントがフォームを表示したかどうか、または人間がそれを閲覧したかどうかを確認できません。これは、2026-07-28プロトコルのクライアント主導部分に内在する制限です。サーバーが送信し、所有するレガシーの仕組みでは、この制限はありません。
### 対策
影響を受ける環境をstdio経由で実行するか、`auth.jwtSecret` を設定しないようにすることで、`requestState` コーデック（および `inputRequired`）が提供されないようにします。どちらの場合も、CLIの `elicit_token` へのフォールバックが行われます。
### 貢献者
GH #967で報告。THE-1106（PR #969）で発見され、修正されました。残りの情報はSECURITY.mdに記載されています。
### 参照
- PR #969, GH #967, CHANGELOG `## [1.31.4] ### Security`
- `packages/server/src/mcp/server.ts` (`tools/call` ハンドラ), `packages/server/src/vault/hitl.ts`
影響を受けるパッケージ：
- npm (JavaScript) obsidian-tc: 影響あり >= 1.13.0, <= 1.31.3、バージョン1.31.4で修正。