AIペンテストは、実際のシステムに対していつ安全に実行できるのでしょうか？
AIペネトレーションテストに関して不安を感じているのであれば、時代遅れではありません。むしろ、時代の先を行っていると言えるでしょう。
セキュリティテストは、AIが人間を支援するだけでなく、自律的に動作する最初の分野の一つです。現代のAIペンテストシステムは、アプリケーションを独立して探索し、実際のアクションを実行し、観測結果に基づいて適応します。
これは強力です。同時に、制御、安全性、信頼性に関する非常に現実的な疑問も提起します。
この投稿は、AIペンテストが機能するかどうかについてではありません。実際にいつ安全に実行できるかについてです。
AIペンテストに対する懐疑論が妥当である理由
私たちが話を聞いたほとんどのセキュリティリーダーは、AIに反対しているわけではありません。彼らは慎重であり、それには十分な理由があります。
彼らが懸念しているのは、次のような点です。
- テスト対象の制御を失うこと
- エージェントが誤って本番システムと対話すること
- ノイズが実際の課題をかき消してしまうこと
- 機密データが不明確な方法で処理されること
- ツールが内部的に説明できないブラックボックスのように振る舞うこと
これらの懸念は正当です。特に、今日「AIペンテスト」と称されるものの多くが、この点での信頼構築に役立っていないためです。
一部のツールは、LLMを追加したDASTです。また、エージェントが一つずつ課題をテストするチェックリストベースのシステムもあります。どちらのアプローチも限定的であり、システムが自律的に動作する場合に何が起こるかについて、準備をさせるものではありません。
真のAIペネトレーションテストは異なります。そして、その違いが安全性の基準を変えます。
真のAIペネトレーションテストで何が変わるのか
スキャナーや指示に従うツールとは異なり、真のAIペネトレーションテストシステムは次の特徴があります。
- 自律的な意思決定を行います
- 実際のツールやコマンドを実行します
- 稼働中のアプリケーションやAPIと連携します
- フィードバックに基づいて動作を適応させます
- 多くの場合、多数のエージェントが並行して大規模に実行されます
このレベルの自律性に達すると、意図や指示だけでは不十分になります。システムが予期せぬ動作をした場合でも、安全性は技術的に強制される必要があります。
それはシンプルな疑問につながります。
「安全な」AI ペンテストには実際に何が必要でしょうか？
実際にAI ペンテストシステムを運用した経験に基づくと、明確な基準が見え始めます。これらは、AI ペンテストが安全に実行可能と見なされる前に存在すべきだと私たちが考える要件です。
このリストは意図的に具体的なものです。各要件は、原則やベストプラクティスではなく、検証、強制、または監査が可能なものを記述しています。
1. 所有権の検証と悪用防止
AI ペンテストシステムは、オペレーターが所有しているか、明示的にテストを許可されているアセットに対してのみ使用可能でなければなりません。
最低限、次の通りです。
- テスト開始前に所有権が検証されなければなりません
- 承認は、ユーザーの宣言によるものではなく、技術的に強制されなければなりません
これがなければ、AI ペンテストプラットフォームは一般的な攻撃ツールになってしまいます。安全性は最初のリクエストが送信される前から始まります。
2. ネットワークレベルのスコープ強制
エージェントはいずれ逸脱します。これは予期される動作であり、バグではありません。
そのため、次の通りです。
- すべての送信リクエストはプログラムによって検査されなければなりません
- ターゲットは明示的に許可リストに登録されなければなりません
- すべての未承認の宛先はデフォルトでブロックされなければなりません
スコープの強制はプロンプトや指示に依存できません。すべてのリクエストにおいて、ネットワークレベルで実行される必要があります。
例：
- ステージング環境をテストするよう指示されたエージェントは、本番環境へのリンクをたどろうとすることがあります。ネットワーク強制がなければ、その間違いはターゲットに到達してしまいますが、それがあれば、リクエストはシステムを離れる前にブロックされます。
3. 推論と実行の分離
エージェント型ペンテストシステムは、bashコマンドやPythonスクリプトなどの実際のツールを実行します。それが実行リスクをもたらします。
最低限の安全要件は以下の通りです。
- エージェントの推論とツール実行の厳格な分離
- サンドボックス化された実行環境
- エージェント間および顧客間の分離
エージェントが異常な動作をしたり、操作されたりした場合でも、実行は完全に封じ込められる必要があります。
例：
- 初期段階のコマンド実行試行は成功したように見えることがありますが、実際にはローカルで実行されます。検証と分離により、これらの結果が誤解されたり、サンドボックスを超えてエスカレートしたりするのを防ぎます。
4. 検証と誤検知対策
自律システムは間違った仮説を生成します。これは想定内です。
安全なシステムは以下を行う必要があります。
- 初期検出結果を仮説として扱う
- 報告前に動作を再現する
- 検出とは分離された検証ロジックを使用する
これがないと、エンジニアはノイズに圧倒され、実際の問題を見過ごしてしまいます。
例：
- エージェントは、応答の遅延により潜在的なSQLインジェクションを検出します。検証ステップは、さまざまなペイロードでリクエストをリプレイし、遅延が一貫して増加しない場合にその検出結果を却下します。
5. 完全な可観測性と緊急制御
AI ペンテストはブラックボックスであってはなりません。
運用担当者は以下を行う必要があります。
- エージェントによって実行されたすべてのアクションを検査する
- リアルタイムで動作を監視する
- 何か異常が見られた場合、すべてのアクティビティを即座に停止する
緊急停止機能は、高度な機能ではなく、基本的な安全要件です。
6. データレジデンシーと処理保証
AI ペンテストシステムは、機密性の高いアプリケーションデータを扱います。
最低限の要件は以下の通りです。
- データがどこで処理され、保存されるかについての明確な保証
- 必要に応じたリージョン分離
- デフォルトでリージョン間のデータ移動なし
これがなければ、多くの組織は技術的な能力に関わらずAI ペンテストを導入できません。
7. プロンプトインジェクションの封じ込め
エージェントは設計上、信頼できないアプリケーションコンテンツと対話します。プロンプトインジェクションは想定されるべきです。
安全なシステムは以下を行う必要があります：
- 制御されていない外部データソースへのアクセスを制限する
- データ流出経路を防止する
- 注入された命令がスコープから逸脱できないように実行環境を分離する
プロンプトインジェクションはエッジケースではありません。脅威モデルの一部です。
本機能が提供するものと提供しないもの
自律システムは、人間と同様に、いくつかの問題を見落とすことがあります。
目標は完璧さではありません。目標は、既存の特定時点のテストモデルよりも、実質的にエクスプロイト可能なリスクをより速く、より安全に、より大規模に顕在化させることです。
安全基準を公開した理由
私たちはセキュリティチームと同じ会話を繰り返し行っていました。
彼らはより多くのAIを求めていたわけではありませんでした。彼らは、そもそもシステムが安全に実行できるかどうかを評価する方法を尋ねていました。
共通のベースラインがなければ、チームはAI ペンテストツールが責任を持って動作しているのか、それとも単に安全性を無視しているのかを推測するしかありません。
そこで私たちは、最低限の基準と考えるものを書き出しました。製品のチェックリストでも、比較でもありません。チームがツールを評価し、より良い質問をするために使用できる、強制力のある要件のセットです。
完全な安全基準を読む
社内で共有したり、ツールを評価する際に使用したりできる、このリストの簡潔でベンダーニュートラルなバージョンを希望する場合は、PDFとして公開しています。
また、付録には、透明性のために、Aikido Attackという一つの実装がこれらの要件にどのように対応しているかが示されています。
こちらでご覧ください：AI ペンテストはいつ安全か？自律型セキュリティテストのための最低安全要件
これが実際にどのように機能するかを見る
これらの安全要件が実際のAI ペンテストシステムでどのように実装されているかに関心がある場合は、当社のAI駆動型セキュリティテストへのアプローチであるAikido Attackもご覧いただけます。
これは、AI ペンテストシステムが実際のアプリケーションに対して大規模に動作するようになった場合に何が必要になるかに基づいて、これらの制約を満たすように構築されました。
動作原理をご確認いただくか、検討中のツールを評価するためにこのリストをご活用いただけます。
