依存パッケージの脆弱性スキャンや監視の自動化を、AIエージェント（自律的にツールを呼び出して作業するプログラム）に任せる構成を検討している運用担当者に向けた内容です。クラウド移行後の監視基盤にAIエージェントを組み込む際、権限設計をどう考えるべきかを整理します。
最近、npmパッケージの依存関係を自動チェックし、GitHub上にトリアージ用のIssue（課題管理票）を自動作成する仕組みが話題になりました。あるActor（Apifyというクラウド実行基盤上で動くスクリプト単位）が、GitHubの3つのツールだけを使って、公開リポジトリから16件の脆弱性アドバイザリを検出し、Issueを自動作成・更新した事例です。同じ入力で2回実行しても、重複せず同一Issueが更新される挙動が確認されています。
何が起きるか: 権限過多なエージェントが招く事故
この手法自体は便利ですが、設計を誤ると重大な事故につながります。AIエージェントにGitHubやAWS、Slackなどの外部サービスへの操作権限を渡すと、意図しないファイル書き換えや、無関係なリポジトリへの投稿が発生する可能性があります。
クラウド運用の現場でよくあるのは、監視ツールやChatOps（チャット経由での運用操作）ボットに「何でもできるトークン」を渡してしまうケースです。スキャン用のはずのボットが、誤操作や設定ミスでプルリクエストをマージしたり、本番環境のリソースを削除したりする事故は、実際に運用障害の原因調査でよく出てくるパターンです。
なぜ起きるか: 権限設計の3段階を分解する
原因は、たいてい権限の「宣言」「認可」「実行」という3段階のどこかが甘くなっていることにあります。
1段目は、そもそもエージェントに何ができるかを明示的に宣言していない状態です。前述の仕組みでは、ActorのInput Schema（実行時に渡す設定の定義ファイル）に mcpServers として使えるツール名を get_file_contents、search_issues、issue_write の3つに限定していました。これはMCP（Model Context Protocol、AIエージェントが外部サービスと連携するための標準規格）を使った接続で、ファイル読み取りとIssueの検索・作成しかできず、ファイル編集やブランチ作成、マージは一切呼び出せません。
2段目は、宣言した範囲と実際のクレデンシャル（認証情報）のスコープが一致しているかどうかです。Apifyのプロキシは tools/list をフィルタし、宣言外の呼び出しを拒否しますが、それでもGitHub側のトークンのスコープが広すぎれば、実効権限は「宣言・コネクタ権限・トークン権限の3層の積集合」になります。どこか1層でも広く設定すれば、そこが弱点になります。
3段目は、書き込み実行時の確認ステップです。この仕組みでは confirmWriteTarget に対象リポジトリの owner/repo を正確に一致させないと書き込みが実行されない仕組みになっていました。デフォルトはドライラン（実際には書き込まない試験実行）で、チェックボックス一つの誤操作で意図しないリポジトリに投稿される事故を防いでいます。
クラウド移行の文脈で言うと、オンプレ運用時代は人間が手動でチケットを起票していたため、対象を誤る事故は少なかったはずです。自動化・エージェント化によって速度は上がりますが、確認ステップを省略すると誤爆のリスクが跳ね上がる、という構造が背景にあります。
自分のプロジェクトが該当するか確認する方法
まず、監視・自動化ツールに渡している認証トークンのスコープを確認してください。GitHubであれば、Personal Access Token（個人アクセストークン）の設定画面で、付与している権限（repo全体か、issues限定かなど）を見直します。
# GitHub CLIでトークンのスコープを確認する例
gh auth status次に、自動化基盤側の設定ファイルで、ツール呼び出しの範囲がホワイトリスト方式（許可リスト方式）になっているかを確認します。上記の例のように required で使えるツールを明示的に列挙する形式かどうかがポイントです。ブラックリスト方式（禁止リストのみで残りは許可）になっている場合は要注意です。
さらに、書き込み系の操作に確認ステップ（ドライラン・対象リポジトリの明示指定など）が入っているかを確認します。CI/CDパイプラインの設定ファイルや、Actor・Lambda・Cloud Functionsなどのサーバーレス実行環境の環境変数一覧を見て、書き込み先を固定するパラメータが存在するかを探します。
対策の手順
対策は次の順で進めるのが現実的です。
- 使用中の全トークン・APIキーの棚卸しをする(誰が何にどの権限で発行したか一覧化)
- 各ツールが呼び出す操作を「読み取り専用」「書き込み」に分類する
- 書き込み系の操作には対象リソースの明示指定と確認フラグを必須化する
- ドライランをデフォルト動作にし、書き込みは明示的なオプトイン(選択的に有効化する仕組み)にする
- 同じ入力での再実行テストを行い、重複作成や意図しない上書きが起きないか確認する
再実行テストは特に見落とされがちです。監視のアラートやスキャン結果を元にIssueやチケットを自動作成する仕組みは、定期実行されることが前提です。1回目は正しく動いても、2回目以降に重複起票してしまう設計は、運用が始まってから気づく典型的な落とし穴です。前述の仕組みでは、同一入力を2回実行しても既存Issueを更新するだけで、リポジトリ内のIssue数が1件のまま保たれることが確認されていました。この「べき等性（同じ操作を何度実行しても結果が変わらない性質）」の有無を、本番投入前に必ず検証してください。
クレデンシャルの取り扱いについても確認が必要です。コネクタ経由の接続では、実行環境がコネクタIDとプロキシのベースURL、実行トークンだけを受け取り、実際のGitHubトークン自体はサーバー側に留まる設計になっていました。これに対し、トークンをコード側に直接渡す設計だと、ログ出力やエラーメッセージに認証情報が漏れるリスクが上がります。運用コストの観点でも、漏洩対応や再発防止のインシデント処理は、事前の権限設計より圧倒的に高くつきます。
導入前に確認すること
自動化・エージェント化を監視や運用フローに組み込む前に、次の3点は必ず押さえておきたいところです。
- ツールの呼び出し範囲がホワイトリスト方式で宣言されているか
- 書き込み操作にドライランと対象明示の確認ステップがあるか
- 同一条件での再実行で重複や誤上書きが起きないか、実際にテストしたか
まずは今使っている自動化ツールのトークンスコープを gh auth status や各クラウドのIAMコンソールで一度洗い出してみることから始めるのが良さそうです。権限を絞ることは初速を落としますが、障害対応の現場では「絞っておいてよかった」と感じる場面のほうが多いはずです。