← パースペクティブに戻る
/Intellicon FDE Team

AI Agent が脆弱性を発見した後、どの操作で停止して人の承認を待つべきか?

AI Agent は脆弱性を整理し、修正案を提示できますが、検証テストが本番システムに影響を及ぼす可能性があります。本記事では、6段階のプロセスをどのように分類し、どの作業を自動実行できるのか、またどの作業で承認者を明記した許可が必要なのかを解説します。

AIEgentWrX人機協作導入
AI Agent が脆弱性を発見した後、どの操作で停止して人の承認を待つべきか?

セキュリティチームが AI Agent を活用してスキャン結果を継続的に整理していると、ほどなく現実的な問題に直面します。AI Agent が脆弱性の疑いを発見した場合、自ら検証してよいのでしょうか。すでに修正プログラムを生成している場合、そのまま本番システムを更新してよいのでしょうか。経営層が「重大な操作は人が責任を負う」と指示するだけで、AI Agent がどの段階で停止し、人の承認を待つべきかを明確に定めていなければ、問題が発生した際に、誰が実行を承認したのかを特定することも困難になります。

Cloud Security Alliance(CSA)は近年、脆弱性運用(VulnOps)モデルを提唱しています。これは、開発段階、導入済みシステム、外部で開示された脆弱性情報を企業が継続的に統合し、定期スキャンと一括修正だけに依存しない運用を目指すものです。セキュリティ分野への AI Agent 導入を検討する企業にとって、この考え方はさらに実務的な課題を浮き彫りにします。企業は、AI Agent の操作権限と人による承認ゲートを明確に定め、検証可能な完全な記録を残すことで、AI Agent にどの段階まで実行を認めるのかを明確にしなければなりません。

前工程のどの作業を AI Agent に任せられるのか?

AI Agent は、システムを変更しない作業を先に担当するのに適しています。たとえば、複数のスキャンツールやベンダーのアドバイザリーの集約、重複項目の削除、影響を受けるソフトウェアバージョンの照合、影響を受ける可能性があるホストやアプリケーションの整理などです。AI Agent は、あらかじめ定められたルールに基づいて対応の優先順位を付け、修正案を提示することもできます。ただし、その結果には、使用したデータと、確認が必要な資産情報を明記しなければなりません。「影響を受ける可能性がある」状態を、そのまま「脆弱性が確認された」と記載してはなりません。

対応の優先順位を決める際も、Common Vulnerability Scoring System(CVSS)のスコアだけで判断するべきではありません。CSA は、システムがインターネットに公開されているか、事業運営にとってどの程度重要か、脆弱性が悪用される可能性、実際に悪用された証拠があるかといった要素も併せて検討するよう推奨しています。また、チームは CISA の Known Exploited Vulnerabilities(KEV)カタログや Exploit Prediction Scoring System(EPSS)も参照できます。AI Agent はこれらの条件を総合して対応タスクの優先順位を付けられますが、資産情報と事業運営に関する情報が正しいかどうかは、引き続きセキュリティ担当者が確認する必要があります。

したがって、導入初期には「読み取り、整理、照合、提案」の4種類の権限だけを付与し、AI Agent による外部接続、攻撃コマンドの実行、本番システムの変更を禁止することができます。試験運用を始める前に、AI Agent が読み取れるデータ、呼び出せるツール、出力した結論の根拠となるデータを追跡できるかどうかについても、チーム内で確認しておく必要があります。

どの脆弱性対応に人の承認が必須なのか?

脆弱性を検証する際、AI Agent が実際に攻撃用のペイロードをシステムへ送信したり、テストアカウントを作成したり、サービスの状態を変更したりする可能性があります。目的がリスクの確認に限られていても、データの変更、サービス停止、システムからのアラート発報を引き起こすおそれがあります。そのため CSA は、AI Agent が脆弱性の悪用検証を行う前に、必ず人の承認を得たうえで、許可された環境内に限って実行するべきだとしています。承認申請には、少なくとも対象システム、許可されるテスト方法、実行時間帯、停止条件、責任者を明記する必要があります。「テストを承認する」という一文だけが、最終的に対象範囲を限定しない許可として解釈される事態を避けるためです。

本番環境への修正適用は、別途管理する必要があります。AI Agent は、修正案、テスト手順、ロールバック計画、変更申請書の草案を作成できます。しかし、アップデートのインストール、設定変更、アクセスルールの調整、サービスの再起動など、本番環境を変更する操作については、引き続き承認者を明記したうえで人が承認することが推奨されます。クラウドネイティブアプリケーションでは、自動デプロイによってアップデートを迅速化できますが、従来型の企業システムや産業制御システムには、依存関係、停止リスク、メンテナンス時間帯といった要素も関係します。同じ自動更新方式をそのまま適用することはできません。

脆弱性の外部開示も、AI Agent の判断だけで行ってはなりません。開示内容には、修正スケジュール、影響範囲、法的責任が関係する可能性があるためです。企業は「検証テスト、本番デプロイ、外部開示」の3つを、必ず停止して人の承認を待つゲートとして個別に設定し、セキュリティ担当者、システム責任者、対外コミュニケーション窓口をそれぞれ指定する必要があります。AI Agent が承認された対象、ツール、実行時間帯のいずれかを逸脱した場合、ワークフローは直ちに停止し、元の承認をそのまま適用して処理を継続してはなりません。

承認ルールを会議の議事録だけでなく、ワークフローに組み込むには?

企業はまず、脆弱性対応プロセスを「情報収集、影響確認、検証テスト、修正提案、本番デプロイ、外部開示」の6段階に分け、それぞれの作業を「自動実行可能」「実行前に承認が必要」「AI Agent に実行させてはならない」のいずれかに分類できます。各段階ではさらに、入力データ、使用可能なツール、閲覧可能なデータの範囲、承認を担当する役割、例外発生時の対応方法を明確に定める必要があります。これにより、開発、セキュリティ、IT 運用の各チームが同一のルールに基づいて判断できるようになります。

企業は、EgentWrX のワークフローを次の工程へ引き渡す前に、人による承認を設定できます。AI Agent が前工程の作業を完了すると、プロセスはいったん停止し、担当者の承認を得てから再開します。また、組織構造や職務に応じて、AI Agent を利用できるユーザーと、各ユーザーが閲覧できるデータを階層的に設定することも可能です。プラットフォームには AI Agent が実行した操作が記録されるため、企業は監査記録の完全性を検証し、記録をエクスポートできます。管理者が監査記録をダウンロードした場合も、その操作がシステムに記録されます。企業はこれらの仕組みを利用して承認ゲートを設定し、後から処理プロセス全体を検証できます。ただし、誰が承認し、どの基準に基づいて判断するかは、事前に定義しておく必要があります。

企業は少なくとも、脆弱性ごとの対応記録に、AI Agent の実行内容、ユーザー、承認者、承認日時、デプロイ結果、例外対応を残す必要があります。効果を評価する際も、クローズした脆弱性の件数だけを見るのではなく、変更失敗率、脆弱性が再発していないか、未対応のリスクがどれだけ残っているかを追跡しなければなりません。脆弱性を一時的に修正できない場合は、アクセスを制限するか、その他の補完的統制(compensating controls)を導入できます。ただし、その場合も責任者と対応期限を指定し、その後の修正状況を継続的に追跡する必要があります。

CSA が提唱する脆弱性吸収率(Absorption Rate)は、直近30日間に解決した項目数を、同じ期間に新たに発生した項目数で割った値です。値が1未満の場合は、解決した項目より新規項目のほうが多いことを示します。1を上回る場合は、未処理項目が徐々に減少していることを意味します。企業はまず、実際に稼働している一部のシステムと開発プロセスを対象に試験運用を行い、セキュリティチームと運用チームが毎月共同で、承認記録、変更の失敗、脆弱性の再発状況を抜き取り確認するとよいでしょう。その結果を踏まえて、前工程のどの作業を AI Agent による自動実行へ拡大できるかを判断できます。

よくある質問

AI Agent は本番システムを自らスキャンできますか?

可能ですが、事前に承認され、対象と実行時間帯が明確に限定されたスキャンだけに限られます。企業は、AI Agent が使用できるツール、ネットワークセグメント、データ範囲も事前に制限する必要があります。スキャンがサービスに影響を与える可能性がある場合や、脆弱性の悪用テストを含む場合は、別途人の承認を得なければならず、通常の脆弱性スキャンに対する許可をそのまま適用することはできません。

AI Agent が高リスクの脆弱性を発見した場合、アップデートを直接インストールできますか?

AI Agent に本番システムを直接更新させることは推奨されません。AI Agent は、影響範囲、修正案、テスト手順、ロールバック計画を整理できますが、アップデートをインストールする前に、システム責任者が依存関係、停止リスク、メンテナンス時間帯を確認する必要があります。特に、従来型の企業システムや産業制御システムでは慎重な対応が求められます。

すぐに修正できない脆弱性には、どのように対応すればよいですか?

企業は、アクセスを制限するか、その他の補完的統制を導入し、脆弱性が悪用されるリスクを低減できます。ただし、責任者と対応期限を指定し、未解消のリスクとその後の修正状況を継続的に追跡する必要があります。一時的な対策をもって、恒久的に対応を完了したものとして扱ってはなりません。

人による承認では、どのような記録を残す必要がありますか?

少なくとも、AI Agent の実行内容、ユーザー、承認者、承認日時、承認範囲、デプロイ結果、例外対応を記録する必要があります。また、企業はこれらのデータを、変更の失敗、脆弱性の再発、未解消のリスクと照合し、修正作業のどの段階で問題が発生したのかを特定できるようにする必要があります。

参考資料

30 分で、AI に先に任せられる業務を一緒に洗い出します

社員一人ひとりに AI の分身を持たせませんか。

コンサルタントより速やかにご連絡いたします。

ISO/IEC 27001:2022 情報セキュリティ認証