エージェントツールには今すぐサプライチェーン管理が必要だ

管理されていないエージェントツールが使われているリポジトリは、優れたプロンプトでは救えない。

コーディングエージェントは進化している。もはやチャットボックスの中に留まる存在ではない。指示を読み、ツールを呼び出し、マーケットプレイスに接続する。ファイル、プルリクエスト、内部APIに干渉するワークフロー内で動作するのだ。

もはや「モデルは十分に賢いか？」という問いではない。

真に問われるべきは以下の点だ：

  • 誰がこのツールをワークフローに許可したのか？
  • このツールは何にアクセスできるのか？
  • アクセス権限が変更された場合、どのように検知するのか？

これはプロンプトエンジニアリングではない。サプライチェーン管理である。

不適切な提案は一つの問題に過ぎない。しかし、シェル、リポジトリトークン、あるいはパッケージインストーラーへのアクセス権を持つ不適切な提案は、全く次元の異なる問題だ。モデルはもはや単にテキストを生成しているのではない。それは実行能力の前に位置しているのだ。

エージェントツールを依存関係（dependencies）として扱え。

「なんとなく」でパッケージをインストールしたりはしない。レジストリ、メンテナー、そしてバージョンを気にするはずだ。エージェントツールにも、それと同じレベルの疑いを持つべきである。

エージェントツールがリポジトリ、ファイルシステム、またはネットワークに影響を与える可能性がある場合は、以下のルールに従ってください：

• エージェントツールのインベントリを維持する。ソースと所有者を文書化すること。 • エージェントの指示をバージョン管理する。指示の変更はCI設定の変更と同様に扱うこと。 • ツールのソースを許可リスト（allowlist）化する。既知のマーケットプレイスを使用すること。 • 読み取り用ツールと書き込み用ツールを分離する。検索ツールには、編集ツールとは異なる権限が必要である。 • ツールの呼び出しを明確にログに記録する。人間が実際に読める監査証跡（audit trail）が必要である。 • リスクの高い機能（capabilities）を明確にする。シェルへのアクセスやファイルシステムへの書き込みは、レビュー時に一目でわかるようにしなければならない。 • 無効化ルートを作成する。ツールが失敗した場合、迅速に削除できるようにしておく必要がある。

目標は、「偶発的な信頼」から「意図的な信頼」へと移行することだ。

次なる大きな優位性を手にするのは、最も派手なプロンプトを操るチームではない。地味なインベントリ、地味な許可リスト、そして地味なログを管理しているチームである。

それこそが、実際のプロジェクトを生き抜くバージョンなのだ。

Source: https://dev.to/hefty_69a4c2d631c9dd70724/agent-tools-need-supply-chain-controls-now-1co2

Optional learning community: https://t.me/GyaanSetuAi