AIHackerOne

ペネトレーションテストAIエージェント「Trident」、HackerOne VDPで世界一位に

株式会社Layer8が開発するペネトレーションテストAIエージェント「Trident」を使った研究用アカウントが、HackerOne VDPの2026 Q3の四半期ランキングで世界一位を獲得しました。

はじめに

株式会社Layer8が開発するペネトレーションテストAIエージェント「Trident」を使った研究用アカウント(l8_trident)が、HackerOne VDPの2026 Q3(7/1〜9/30)の四半期ランキングで世界一位を獲得したことをお知らせします。

TridentとはWebアプリケーションの脆弱性を自律的に探索し、攻撃が成立する条件と影響を検証するAIエージェントです。2025年5月からペネトレーションテストAIエージェントの研究開発を始め、VCからの資金調達を行わず、日本のソフトウェア & セキュリティエンジニア3名で徹底的な性能改善と安全性強化を進めてきました。この度、HackerOne VDPにて実環境に対する有効性を検証しました。

日本人3名からなる開発体制の中で、HackerOne運用は1名で行いました。毎日1時間程度、Tridentの実行結果を確認・提出するだけで、残りの工程は全て自動化されています。

HackerOneでの実績

VDP(脆弱性開示プログラム)とは企業や組織が定めたポリシーの下、外部の研究者に脆弱性診断を許可する仕組みです。脆弱性レポートには、攻撃が成立する条件と悪用時のビジネスインパクトを示すことが求められ、悪用余地のない脆弱性はトリアージ対象外となります。

2026年7月1日〜9月30日には、50プログラムで計568件のレポートがトリアージされました。

severityレポート件数
Critical65件
High104件
Medium378件
Low21件
合計568件

具体的な攻撃事例

詳細は伏せますが、具体的な攻撃事例をご紹介します。

ご紹介するターゲットは販売店向けの部品発注システムで、社外利用を禁止しているWebアプリケーションです。Tridentは、正規アカウントなしで認証バイパスとSQLインジェクションを組み合わせた攻撃を行いました。

認証バイパスとSQLインジェクションの攻撃経路

Tridentは、まずサーバがIdPの認証結果を確認せず、Webブラウザから送られた情報を信じてセッション発行する問題を見つけました。ただし架空のユーザ名では、その後の登録ユーザ照合により止められてしまいます。

この照合処理ではセッションに保存されたユーザ名をサニタイズすることなく、次の画面でSQL文にそのまま組み込んでいました。SQLインジェクションで検索条件を変えることで、登録ユーザ照合を突破できます。

残るのは送信した拠点コードと登録ユーザの所属拠点コードの一致判定です。ただし不一致時のエラーメッセージに正しいコードが含まれており、その拠点コードを使うことで業務システムへの不正アクセスが成立しました。

まとめると、本ターゲットでは

  • データの漏洩・改竄リスク
    • SQLインジェクションにより、機密情報の流出とデータの改竄が成立する。注文データが改竄されれば、部品調達にも影響する。
  • 業務システムへの不正アクセス
    • 認証バイパスにより、外部の第三者がユーザ・注文管理画面にアクセスできる。

の脆弱性がヒットし、速やかにレポート提出しました。

運用フロー

Tridentはペネトレーションテストを全自動で遂行するAIエージェントをコアとし、対象の把握から脆弱性の探索、攻撃の検証、再現手順・証跡・影響の記録までを自動化しています。結果は脆弱性台帳に蓄積し、社内のセキュリティエンジニア1名がレポートの確認・提出を担います。

この役割分担により、少人数における大規模検証を偽陽性なくワークすることに成功しました。

Tridentによる探索・検証からHackerOneでの評価まで

アーキテクチャと設計判断

Tridentでは、偵察・脆弱性分析・エクスプロイト・再現確認などを24個のエージェントが協調しながら遂行するマルチエージェント構成を採用しています。

ペネトレーションテストAIエージェントを全自動で動かす上で、設計上の悩みどころは大きく2つありました。

  1. 偵察、脆弱性探索、Exploit、再現確認で異なる要求をどう扱うか
  2. 人間の監督なしで動かす際に、スコープ外アクセスや過剰なリクエストをどう防ぐか

以下、特に重要な 2 つの設計判断を説明します。

なぜマルチエージェント構成にしたのか

以下の理由から、Tridentはマルチエージェント構成で構築しました。

  • フェーズごとのチューニングがしやすい: モデル、システムプロンプト、ツールセット、ガードレールをフェーズ単位で個別に最適化できる。偵察とExploitでは必要な能力もガードレールも大きく異なるため、この自由度は大きい。
  • フェーズ特化の偽陽性チェッカーを差し込める: 機械的なフィルタを各フェーズに合わせて最適化できる。
  • 状態管理を分離できる: フェーズによっては、独自のステート管理や忘却処理が欲しくなることがある。

代償として複数エージェントと共有状態を管理する複雑性は増えます。それでも、上記のメリットが上回ると判断しました。

全自動で動かすためのガードレール

Human-in-the-Loopを介さない全自動化を選ぶ以上、人間の監督なしで安全に動作するためのガードレールは不可欠です。

Tridentではガードレールを2層で実装しています。

  • プロンプトレベルのガードレール: 各エージェントのシステムプロンプトに、対象スコープや禁止行為を明示する。
  • システムレベルのガードレール: 全トラフィックを中間者プロキシ (L7 Egress Gateway)に通し、スコープ外のホストへのリクエスト、過剰なリクエストレート、未知のプロトコルなどをプロキシ側で機械的に遮断する。

プロンプトレベルだけに頼ると、LLMが指示を無視または誤解した時点で安全性が崩れます。全自動運用には、LLMの挙動と独立した経路で制約をかけるシステムレベルのガードレールが必要です。なお中間者プロキシを通過したリクエスト / レスポンスは記録され、後段で自動的にスキャナによる検査に回されます。

既存ベンチマークだけでは足りなかったこと

マルチエージェント構成の利点であるフェーズごとのチューニングを継続的に回すには、フェーズ単位で性能差分を測れるベンチマークが必要です。

ペネトレーションテストAIエージェントの性能評価では、PortSwigger Academy LabやXBOW Benchmarkなどが使われることが多いです。

これらは攻撃チェーン全体としての強さを測る評価として有用であるものの、Tridentの改善ループでは以下の点が課題になりました。

  1. モデル性能の進化により、既存ベンチマークは上位帯でスコアが飽和しつつある
  2. Webブラウザを使った初期偵察やExploitの安全性検証など、細かなチューニング差分を測りにくい
  3. モデル切り替え時に、特定フェーズだけ性能が落ちるデグレを検知しにくい

そこで弊社では、フェーズごとの性能改善・コスト最適化に向けた独自ベンチマークを開発し、継続的な評価に利用しています。

まとめ

今回のHackerOne VDPでの実証実験では、脆弱性の探索から攻撃の検証までを全自動で行い、実環境に対するTridentの有効性を確認しました。レポートの確認・提出を1名・毎日約1時間で行う体制で、2026 Q3の世界一位を獲得しました。

今後はより高度な攻撃チェーンの自動化と、より広範な攻撃対象への対応を目指して研究開発を続けていきます。

Powered by Trident

お問い合わせ

診断・共同検証・技術連携のご相談

対象システムや検証したい内容、希望時期が固まっていなくても構いません。ご相談の内容をもとに進め方を整理します。