AIエージェントの権限を守る―ツール実行前のチェックと再テスト

1. 対象と「誰が何をできるか」を決める

例として、下書きを更新するAIツールを扱います。一般利用者は自分の下書きだけ更新でき、他人・他組織の下書きは更新できない、という仕様です。自社の業務ルールに置き換えてください。

以下の［ ］を埋めて使います。対象パス、ローカルのテストコマンド、許可する操作を具体化し、外部の送金・投稿APIはテスト用の代替処理へ切り替えます。プロンプトの指示に加え、作業環境でも本番の認証情報を渡さない構成にします。

2. まず調査を依頼し、修正箇所を確認する

最初は読み取り調査に絞ります。IntentKitを使っていなくても、同じ種類の実行時チェックの不足がないか確認できます。AIが脆弱性と断定したら、入口から実行までつながる根拠を読みましょう。

このリポジトリのAIツール実行処理を、読み取りのみでレビューしてください。
対象：［ディレクトリ／機能名］
対象操作：［例：下書き更新］
期待する権限：匿名は不可、一般利用者は自分の下書きのみ更新可。他人・他組織のデータは不可。
この権限仕様が既存の仕様と食い違う場合は、修正せず確認事項にしてください。

入力受付 → 利用者の認証 → ツール選択 → 実行 → データ更新まで追跡し、次を確認してください。
・モデルに見せるツール一覧と、実行できるツールの範囲が一致するか
・実行時に、サーバーが確認した利用者・対象データ・引数で権限判定するか
・モデル出力やリクエスト中の「所有者」「承認済み」を信用していないか
・別利用者の会話履歴や、権限変更前の呼び出しを再利用できないか

変更・攻撃実行・外部通信はしないでください。秘密情報を読み出さないでください。
指摘ごとに、ファイルと行、成立条件、想定される影響、最小の修正案、必要なテストを示してください。
確認できた事実と仮説を分け、問題がない箇所も根拠を示してください。

3. 問題を絞って、修正と回帰テストを依頼する

調査結果と業務ルールを人が確認した後、合意した問題だけを修正させます。権限不足なら操作前に拒否することが重要です。所有者専用の操作に承認を追加する場合も、承認を権限判定の代わりにしません。

先ほどの調査で確認した［指摘ID／ファイルと問題］を修正し、回帰テストを追加してください。
許可範囲：［対象パス］内の編集と、ローカルの［テストコマンド］の実行。
本番・実データ・実際の送金や投稿には接続せず、テスト用DBと外部APIのモックを使ってください。

利用者の識別はサーバーが検証した情報を使い、実行直前に対象と操作の権限を確認してください。
権限が不明・失効・判定エラーの場合は拒否し、モデルの出力だけで許可しないでください。
変更は最小限にし、既存の無関係な変更を上書きしないでください。

次をテストしてください。
1. 一般利用者が自分の下書きを更新できる
2. 匿名・別利用者・別組織からの更新を拒否する
3. モデル向け一覧にないツールを実行層へ直接渡しても、許可外なら拒否する
4. 他人の履歴の再利用と、権限失効後の再実行を拒否する
5. 拒否時はDBが変わらず、外部APIのモックも呼ばれない

新しいテストが修正前に失敗し、修正後に成功することを、元の作業を壊さない隔離環境で確認してください。
実行できないテストは理由付きで未検証としてください。合格と推測しないでください。
変更ファイル、修正理由、実行コマンドと結果、未確認事項を報告してください。
commit・push・デプロイは行わないでください。

4. 「直りました」ではなく、差分と結果を見る

確認するのは、権限判定が実行側にあるか、拒否が状態変更より前に行われるか、テストが実際の実行経路を通るかです。判定関数自体をモックにして常に拒否させたテストでは、実装の不備を検出できません。

外部APIを呼ばないモックテストは、実際の接続先の権限設定までは保証しません。配備する版・設定・接続先の権限も確認して反映し、モデルやツールを変更した際は同じテストを再実行します。