AI Agent による自動ペネトレーションテストは合法なのでしょうか。短く言えば、認可、範囲、影響、データ処理、開示手順によります。AI ツールであることやオープンソースであることは、合法性を保証しません。
Strix のようなツールは、Agent、動的実行、脆弱性検証、報告、修正提案を組み合わせます。防御には有用ですが、境界を明確にする必要があります。
これは法律助言ではありません。実案件、bug bounty、顧客システム、本番環境、越境テストでは、契約、プラットフォーム規則、現地法、法務判断に従ってください。
まず結論
AI Agent pentesting は大きく 3 つです。
| 場面 | リスク |
|---|---|
| 自分のコード、テスト環境、認可済みリポジトリ | 比較的低いが制御は必要 |
| 契約に基づく顧客システム | 書面認可、範囲、時間、報告規則が必要 |
| 未知の公開サイト、クラウド資産、第三者 API | 明示的許可なしでは高リスク |
実行前に確認します。
- 対象の所有者は誰か。
- 認可は書面で明確か。
- scope に対象ドメイン、API、アカウント、環境が含まれるか。
- Agent がデータを閲覧、コピー、変更、破壊し得るか。
- 脆弱性をどう報告し保護するか。
- ログ、承認、レビュー記録を残すか。
答えられないなら実行しない方が安全です。
AI Agent がコンプライアンスを敏感にする理由
従来の scanner は比較的予測可能です。AI Agent はページを探索し、手がかりを組み合わせ、ツールを呼び、検証アイデアを作り、ブラウザや proxy を使い、レポートを保存することがあります。
認可された環境では有用ですが、未認可対象ではリスクが増えます。
認可が第一線
認可は書面で監査可能にするべきです。
- 対象者;
- 許可された domain、IP、repo、app、API;
- 除外対象;
- テスト時間;
- テストアカウント;
- 自動化の可否;
- 脆弱性検証の可否;
- 実データアクセスの可否;
- 緊急停止連絡先;
- レポートと秘密保持。
AI Agent の場合はさらに:
- 動的探索の可否;
- PoC 生成の可否;
- CI/CD 実行の可否;
- ログ、コード片、リクエストを外部モデルへ送れるか;
- モデル provider とデータ保持。
公開サイトは自由にテストできるわけではない
公開アクセス可能でも、API、認証、業務ロジックを自動探査してよいとは限りません。
特に注意:
- 政府、医療、教育、金融;
- 重要インフラ;
- 第三者 SaaS やクラウド;
- 競合サービス;
- ユーザーデータを持つ platform;
- disclosure policy がないシステム;
- 自動化テストを禁止するサイト。
Bug bounty や VDP も無制限ではありません。scope、禁止行為、rate、報告手順を守ります。
善意の研究にも境界がある
米国 DOJ の CFAA charging policy は good-faith security research に触れていますが、「研究」と呼べばすべて安全という意味ではありません。目的、被害回避、情報の使い方、管轄が重要です。
国や地域によって扱いは異なります。越境テストは特に慎重に扱います。
越境しやすい行為
1. 認可なしの scan
未知の対象に自動 Agent を走らせるのは高リスクです。
2. scope 超過
staging.example.com だけが許可されているのに、本番、決済、vendor、社員システムへ進むと scope 外になり得ます。
3. 実ユーザーデータへのアクセス
脆弱性証明のために大量の実データを読む、保存する、スクリーンショットするのは避けます。
4. 破壊的検証
削除、停止、費用発生、アカウントロック、メール送信、支払い変更は個別認可と隔離環境が必要です。
5. 早すぎる公開
合意された窓口から報告し、修正期間を与えます。
6. 脆弱性で支払いを迫る
合意済み bounty 以外で支払いを迫る行為は重大なリスクです。
企業で Strix 系ツールを安全に使うには
低リスクから始めます。
- ローカルコード;
- 専用テスト環境;
- staging;
- PR の quick scan;
- 制限された本番 read-only 検証;
- 正式な pentest。
初日から本番全体に接続しないでください。
認可チェックリスト
| 項目 | 確認すること |
|---|---|
| 対象範囲 | domain、IP、repo、API、account |
| 除外 | 第三者サービス、決済、SMS、メール、本番データ |
| 強度 | concurrency、rate、時間、深さ |
| データ境界 | 何を閲覧・保存できるか |
| ツール境界 | network、command、外部モデル |
| secrets | API key、test account、cookie |
| logs | request、output、report、approval |
| 緊急停止 | contact と rollback |
| disclosure | 宛先、応答時間、公開ルール |
| 人間レビュー | AI findings を誰が確認するか |
Agent へのコンプライアンス指示
|
|
ただしプロンプトだけに頼らず、network、account、environment でも制限します。
CI/CD 自動化にも境界が必要
- 変更コードまたはテスト環境だけを scan;
- untrusted PR に secrets を渡さない;
- 機密ログを不明な場所へ送らない;
- 高リスク findings は人間が確認;
- merge を止めるのか report のみかを明確にする。
脆弱性レポート自体が機密情報です。
個人研究者への注意
- 自分の project、lab、CTF を優先;
- bug bounty scope を読む;
- 許可された方法だけ使う;
- 破壊的検証をしない;
- 実ユーザーデータを保存しない;
- 公式窓口へ報告;
- 最小証拠だけ残す;
- 「AI が自動でやった」を免責にしない。
許可や disclosure policy がない場合、能動的な自動テストは避けます。
合法でも実施すべきとは限らない
契約上許可されていても、運用リスクがあります。
- 本番ピーク時間;
- 実顧客データ;
- アラート疲れ;
- rollback がない;
- 外部モデルに機密コードや request を送る。
コンプライアンスは違法かどうかだけでなく、説明、制御、監査できるかも含みます。
参考
- U.S. Department of Justice:Computer Fraud and Abuse Act charging policy
- CISA:BOD 20-01 Develop and Publish a Vulnerability Disclosure Policy
- NIST:AI Risk Management Framework
まとめ
AI Agent による自動ペネトレーションテストの合法性は、AI かどうかではなく、認可、scope、影響制御、データ処理、開示、監査可能性で決まります。明確な境界内では防御に役立ちますが、境界がなければツール自体がリスクになります。