本文へ移動

AI Buildersのための最新のニュース、知見、事例を毎日お届け

運営会社
企業のセキュリティ対策Postman

Postmanが開発AIに「無断で」プラグイン フックの自己承認を撤回

米PostmanのデスクトップアプリがCodexとClaude Codeにプラグインを自動で入れ、Codexの起動時フックの信頼まで自ら記録していた問題で、同社は自己承認をやめ、Codex向けのフックを外した。

記事の内容を自社でどう進めるか、内容が固まっていない段階でも相談できます。仕事の相談

毎週 1 回、その週の記事から 5 本と実践の 1 本を選んでメールで届けます。ニュースレターを購読する(無料)

緑のフェルトの上の巣に青い卵が3個、オレンジの斑点の卵が1個だけ縁に押し出されている
Created with Grok

API開発ツールを提供する米Postmanのデスクトップアプリが、利用者の手元のCodexとClaude Codeに自社のプラグインを自動で入れていたことが、10月26日に立てられたGitHubのissueで明らかになった。Codexには起動のたびにエージェントへ指示を渡すフックが加わり、その実行を許す信頼の記録まで、インストーラーが自ら書こうとしていた。同社はフックの自己承認をやめ、11月6日にはCodex向けのフックそのものを外した。別のアプリが開発AIの設定を書き換えられる時、利用者が確かめる場面を誰が設けるのかが問われている。

アプリを開いただけで設定が変わった

報告者がPostmanのアプリのGitHubに立てた自動インストールを訴えるissueによると、きっかけはMacで久しぶりにPostmanを開いたことだった。その後、CodexでMCP(AIと外部の道具をつなぐ標準の手順)の認証の警告が繰り返し出て、API関連の作業がPostmanのスキルへ回されるようになったという。

報告者が調べると、Postmanのログに10月24日付で、既存の利用者向けの自動アップグレードとして「claude-code」と「codex」へのインストールが済んだという記録が残っていた。Codexの利用者全体の設定ファイルには、Postmanのマーケットプレイスとプラグインの登録、起動時フックの信頼の記録が加わっていた。Claude Codeの設定でもPostmanのプラグインが有効になり、Postmanのコマンドラインツールも手元に置かれていた。報告者は、情報が外へ送られたとは主張していないと断ったうえで、同意の境界を越えた重大な問題だと訴えた。

報告者がPostmanに求めた対応は6つある。既存の利用者への自動インストールを、明示の同意を得るまで止めること。インストーラーがフックを自ら承認するのをやめ、信頼するかどうかはエージェントの側で利用者が決めるようにすること。設定・フックの承認・接続先・コマンドラインツールまで戻せる削除の手順を用意すること。起動時の指示を、利用者がPostmanを使うと頼んだ時だけに絞ること。残る2つは、重大な事案として扱うことと、自動インストールの仕組みと書き換え得るファイルを明らかにすることだった。

フックが作業の向きを変える

問題を大きくしたのは、Codexが起動するたびに動くフックだった。フックが読み込ませる起動時の指示の文書には、APIの設計・実装・テスト・監視・文書化・デプロイといった作業に答える前に、Postmanの「api-engineer」スキルを読み込んで従うよう書かれていた。利用者がPostmanを使うと頼んでいなくても、APIに関わる作業ならエージェントがPostmanの手順を選ぶことになる。

Codexでは、プラグインのフックは利用者が信頼すると決めるまで動かない。ところがインストーラーのフック承認の処理は、インストールの後にフックのハッシュを取り、信頼の記録を設定に書き込むようになっていた。報告者は、設定に残った記録を誰が作ったかまでは記録だけで証明できないと断りつつ、承認を試みる処理がコードにあることを示した。つまり、利用者が判断するはずの関門を、入れる側が自分で通ろうとしていたことになる。

Postmanは自己承認をやめた

issueは11月5日に「完了」として閉じられた。同じ日、Postmanはプラグインのリポジトリで、インストーラーからフックの自動承認を外す変更に取りかかった。11月6日に取り込まれたCodex向けの起動時フックを外す変更は、自動承認の削除を含んだうえで、Codex向けのフックの定義そのものを消した。CodexはスキルとMCPの接続を引き続き受け取るが、起動時の指示は受け取らない。

この変更の説明によると、Codexはセッションの開始時にgitのマーケットプレイスからプラグインを更新し、中身が変わるたびにフックは未承認に戻る。だからフックを残せば、利用者は毎回確認を求められる。同社は確認を省くのでなく、フックをやめる道を選んだ。同じ日には、この変更を含むプラグインの0.7.0版を出す変更も取り込まれた。

一方、Postmanが入れた物をまとめて消す手段はまだ整っていない。削除のコマンドが入れた物すべてを片づけるようにするアンインストールを完全にする変更は、確認日の時点で取り込まれていない。この変更の説明によると、これまでの削除のコマンドはプラグインの登録だけを外し、マーケットプレイスの登録やフックの承認の記録を残していた。デスクトップアプリが既存の利用者に自動で入れる仕組みをどう改めるかは、公開された資料からは分からない。

承認の関門は入れる側に握らせない

この件で分かるのは、エージェントの設定ファイルを書ける別のアプリが、プラグインの追加にとどまらず、起動時にエージェントへ渡す指示まで足せるということだ。Codexがフックに信頼の手続きを設けていても、外のプログラムが信頼の記録を書けば関門は効かない。Postmanはフックを外したが、関門を利用者の手に戻すことが今回の対応の核心だった。

編集部の見方

編集部は、この件の核心を、承認の関門を入れる側が自分で通れたことにあると見る。Codexはフックに信頼の手続きを設けていたが、インストーラーが信頼の記録を書いた時点で、利用者が確かめる工程は消えていた。CodexやClaude Codeを使う読者は、利用者全体の設定ファイルにある見覚えのないマーケットプレイスやフックの信頼の記録を一度見直すとよい。ただし、他のツールが同じことをしているかは、今回の資料からは分からない。

この記事をシェア

この記事は役に立ちましたか