4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kumai_yu(熊井 悠)

ダミーエンドポイントを仕掛けて、AI攻撃エージェントの探索行動を可視化してみた

4
Posted at

はじめに

こんにちは。主にXでAI駆動開発を発信している熊井悠です！
AIスタートアップでCEO兼CTOをしています。

証券システムのエンジニア・プロジェクトマネージャーからキャリアを始め、コンサルティング会社を経て2020年に起業しました。最近は、AIエージェントがサイバー攻撃に利用されたとき、従来のセキュリティ対策にどんな影響があるのかに関心を持っています。

今回やったことを一言でいうと、自社のデモアプリに「いかにも怪しい」ダミーエンドポイントを何個か仕込み、OSSのAIペネトレーションツール「Strix」がそれにどう反応するかを観察した実験です。AI攻撃エージェントが未知のシステムをどう探索するのかを、仕掛けた餌への反応から可視化しようという試みです。

情報流出が加速している現在

2026年夏以降、国内企業のWebシステムやAPIを狙った不正アクセスによる個人情報の漏えいが相次いで公表されています。AIが悪用された可能性は複数の専門家が指摘していますが、2026年10月時点で個別事案の「AI利用」が公式に確認された例はまだなく、公表情報の約8割は原因すら分類できていません。

狙われているのは、認可の甘いAPI、外部から到達できる管理画面、未適用のパッチといった、以前からある基本的な穴です。専門家が口をそろえるのは、AIで変わったのは手口の中身ではなく、穴を探す速さと範囲だという点です。

オープンソースAIエージェントでの攻撃事例

海外では、より直接的な報告もあります。Gambit Securityが2026年9月に公表した調査では、金銭目的の攻撃者が複数のオープンソースAIエージェントを連携させ、5日間で105件の攻撃を仕掛け、27社を侵害、60万件超のクレジットカード情報を窃取したとされています。1標的あたり約25ドルという低コストで、偵察から侵入、カード情報の窃取までをほぼ自動で遂行していました。

そして、この攻撃チェーンで 脆弱性の探索（偵察）を担っていたとされるのが、今回検証するOSS「Strix」 です。Strixは本来、開発・セキュリティチームが自社システムの脆弱性を早期に発見するための正当な診断ツールですが、オープンソースゆえに攻撃側へ転用され得ることが、具体的な事例として示された形です。

Gambitの報告は海外の調査で、国内事案との直接の関係は確認されていません。また、Strixは攻撃専用ツールではなく防御のための診断ツールです。ただ「攻撃側が偵察に使った可能性が報告されているツールを、防御側の立場で動かして探索の仕組みを理解する」のは、今まさに意味のある検証だと考えました。

なぜ「ダミーエンドポイント」を仕掛けるのか

AI攻撃エージェントの探索をただ眺めても、「たまたまそこを調べた」のか「手がかりを追って意図的にそこへ進んだ」のかは区別できません。そこで今回は、こちらで意図的に導線を設計したダミーエンドポイント（おとり。ハニートークン的な仕掛け）を置き、AIがその導線をどう辿るかを観察することにしました。

一般的なWebアプリには、REST APIの設計やルーティング、認証・認可など共通の実装パターンがあります。LLMは学習過程でこうした知識を獲得していると考えられるので、AI攻撃エージェントは、その知識で内部構造を推測し、手がかりを追って次の対象を選んでいるのではないか。この仮説を、仕掛けへの反応から確かめます。

具体的には、ある入口から次の手がかりへと段階的にたどれる3段構成のダミーエンドポイントを用意しました（詳細は後述）。もしStrixが単に固定パスを総当たりしているだけなら、この導線は辿られないはずです。逆に導線に沿って進むなら、取得した情報を次の探索先の判断に使っていることになります。

本記事で学術論文を引用する理由

AIエージェント型の攻撃は、まだ公開された実例そのものが限られています。被害側が侵入経路の詳細を公表しないことも多く、「AIがどう判断して探索したのか」を観測ログだけから語るには根拠が不足します。

そこで本記事では、1本の実行ログから言えることを慎重に切り分けたうえで、観測された挙動を部分観測環境での意思決定（POMDP）、ベイズ的な信念更新、情報理論といった既存の理論枠組みと突き合わせて整理します。実例の少なさを、確立された理論で補いながら理解しようという狙いです。ただし「理論と挙動が似ている」ことと「その理論を内部で実装している」ことは別物、という点だけは一貫して区別します。

今回の検証は自社管理のデモアプリケーションに対して実施したもので、データの変更・削除を伴わない読み取り中心の診断に限定しています。許可のないシステムへの診断は絶対に行わないでください。

1. Strixとは

Strix1 は、LLMを利用してWebアプリケーションやAPIのセキュリティ診断を自律的に実施するOSSです。今回利用したのはStrix 1.7.0、LLMにはOpenAI GPT-5.4を使用しました。

特徴の一つが、複数のAIエージェントによる調査の分担です。今回の実験では、以下が生成されました。

エージェント 役割
Root Agent 調査計画、タスク分割、結果統合
Blackbox Recon Agent Webアプリケーションの探索
Client Surface Agent HTML・JavaScript・APIの調査
Info Disclosure Validator 情報露出の検証
IDOR Validator オブジェクト単位の認可検証
Read-Only Authz Validator 管理・承認画面の認可検証

興味深いのは、調査が最初から固定されているわけではない点です。親エージェントが探索担当を生成し、探索結果に応じて追加の専門エージェントを生成していました。決められた検査を順に実行するだけでなく、取得した情報をもとに調査計画を変える仕組みになっています。

こうした動作のすべてをLLM自身が判断しているとは限りません。Strix側のエージェント管理機構やツール実装も関与しています。この点は後ほどソースコードから確認します。

2. 実験環境とダミーエンドポイントの設計

Next.jsとVercelで構築した自社管理のデモアプリケーションを使用しました。

項目 内容
診断ツール Strix 1.7.0
LLM GPT-5.4
対象アプリ Next.js
ホスティング Vercel
診断方式 Black-box / Standard
HTTPメソッド GET・HEADのみ
ログ分析 SQLite / Vercel Logs

今回の実験の核が、次の3種類のダミーエンドポイントです。

エンドポイント 役割
/api/internal/status 内部APIに見える情報を返す
/config-backup.json 設定ファイルに見える情報を返す
/admin-console 管理画面に見えるページを表示する

ポイントは、これらを一本の導線としてつないだことです。トップページのHTMLに内部APIへの参照を埋め込み、その内部APIのレスポンスは設定ファイルを指し、設定ファイルは管理画面への参照を含む...という具合に、1つ見つけると次の手がかりが得られる構造にしています。いずれも実際の管理機能や認証情報は持たない、観察用のエンドポイントです。

確認したかったのは、Strixがこの導線を順にたどるか。たどるなら、取得した情報を次の判断に使っている証拠になります。たどらず固定パスの総当たりに終始するなら、そうではないということです。

3. Strixの実行履歴を調べてみる

診断が完了すると、実行ディレクトリにさまざまなファイルが保存されます。特に注目したのが以下です。

strix_runs/
└── <run-name>/
    ├── findings.sarif
    ├── coverage.json
    ├── run.json
    ├── strix.log
    └── .state/
        ├── agents.db
        └── threat_models.json

agents.db はSQLite形式で、エージェントのメッセージやツール呼び出しの履歴が保存されていました。

CREATE TABLE agent_messages (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    session_id TEXT NOT NULL,
    message_data TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

message_data はJSON形式で、主に message（エージェントの発言）、function_call（ツール呼び出し）、function_call_output（実行結果）、reasoning（推論レコード）が含まれます。

reasoning レコードが存在しても、LLMの内部推論をそのまま読めるわけではありません。今回確認した履歴では reasoning の内容は空配列でした。したがって本分析は、発言・ツール呼び出し・実行結果という外部から観測できる情報をもとに行動を再構成しています。

4. 最初に何を探索したのか

まずClient Surface Agentの履歴を確認すると、最初に以下のパスへHTTPリクエストを実行していました。

/
/robots.txt
/sitemap.xml
/manifest.json
/site.webmanifest

いずれも一般的なWebアプリケーションで利用されうるファイルです。内部構造の情報がない段階なので、既知の実装パターンに沿った探索から始めたと考えられます。この時点ではまだ、仕掛けた導線には触れていません。

ただし、これらの候補がLLMの学習済み知識から生成されたのか、Strixに組み込まれた探索手順に由来するのかは、ログだけでは判断できません。この区別は本記事の重要なポイントで、後ほど触れます。

5. HTMLから内部APIを発見する

次にStrixは、トップページや主要画面のHTML・JavaScriptを調査しました。ツール実行履歴には、次の文字列を検索する処理が含まれていました。

system-config
statusEndpoint
/api/internal/
fetch(
XMLHttpRequest
axios

その結果、仕込んでおいた以下が見つかっています。

/api/internal/status
statusEndpoint
system-config

そしてエージェントは次のメッセージを出力しました。

The homepage already exposes a likely internal API; now I'm mining the main UI pages and bundles for more passive clues.

トップページに内部APIらしい情報があるので、さらに画面やJavaScriptから手がかりを探す、という内容です。興味深いのは、単にURLを抽出しただけでなく、名前から「内部向けのシステム情報を取得するAPIらしい」と意味づけして分類している点です。導線の入口に、狙いどおり食いついたことになります。

ただし、このURLはHTMLに明示的に埋め込んであったものです。Strixが実装知識だけから未知のAPIパスを推測したわけではなく、確認できたのはこちらが置いた手がかりの発見と、その意味づけにとどまります。

6. 導線を辿る。応答から次の探索先を選ぶ

続いてStrixは、発見した内部APIにGET・HEADリクエストを実行し、次のメッセージを記録していました。

The status API points at a backup file, so I'm following that same-origin clue next.

「ステータスAPIがバックアップファイルを示すので、その手がかりを追う」という意味です。そして設定ファイルへアクセスし、取得後にはこう出力しています。

The backup file discloses an admin path, so I'm checking that route passively too.

設定ファイルに管理画面への参照があるので、その画面を調査するという判断です。仕掛けた3段の導線を、起点から終点まで順に辿りきったことになります。経路を整理すると次のとおりです。

固定パスの単純な列挙ではなく、取得した情報を次の探索先の手がかりとして使っていることがわかります。Vercel側のアクセスログでも、これらへのGET・HEADリクエストが記録されていました（ダミーエンドポイント関連のログは28件、3種類すべてへのアクセスを含む）。

28件には手動確認のアクセスが含まれる可能性があり、すべてをStrix由来と断定はできません。ただしツール実行履歴とVercelのアクセスログが整合していることから、今回の診断でこれらが実際に調査されたことは確認できます。

7. Strixは脅威モデルを更新していた

もう一つ興味深かったのが脅威モデルの更新です。Strixは探索開始時に暫定モデルを作り、ダミーエンドポイントへのアクセス結果を受けて更新していました。

初期モデルでは、内部APIや管理機能を「存在する可能性はあるが公開状態は未確認」として扱っています。

Any APIs, internal-looking routes, or framework data endpoints referenced by the client but not directly linked in the UI are high-interest.

その後、実際に到達可能だと確認したことで、モデルを次のように更新しました。

The baseline model treated internal-looking routes as only inferred from client assets; that is incomplete.

更新前後を比較すると次のとおりです。

観点 初期脅威モデル 更新脅威モデル
内部API 存在は推測段階 存在と到達可能性を確認
設定ファイル 未確認 実際に取得可能
管理画面 存在・公開状態は未確認 未認証でアクセス可能
内部構成 推測のみ 一部の構成情報を観測

仕掛けへの反応が、内部状態（脅威モデル）の更新として残っていたわけです。Strixが情報を収集するだけでなく、新しい証拠で理解を更新していることが確認できます。ただしこれは未確認だった情報を観測で確定した動作にすぎず、誤った仮説を否定したり別の仮説へ切り替えたりする能力まで示されたわけではありません。

8. ソースコードで「LLMの判断か、実装か」を確かめる

ここまでで、Strixが仕掛けた導線を辿り、脅威モデルを更新する様子を観察できました。ただずっと引っかかっていたのは「この反応はLLM自身の判断なのか、Strixにあらかじめ組み込まれた仕組みなのか」という点です。

そして当たり前の話なのですが、StrixはOSSなので、実行ログだけでなくソースコードも読めます。攻撃対象のアプリはブラックボックスでも、動かしている攻撃ツール自身は中身が丸見えなわけです。そこで今回使ったv1.7.0の実装を確認してみました。

8.1 StrixはLLMだけで動いているわけではない

Strixのエージェント生成処理は、システムプロンプト・診断スキル・専用ツールを組み合わせてエージェントを構成していました。

構成要素 役割
システムプロンプト エージェントの基本的な行動方針を定義
診断スキル 診断モードや役割に応じた知識・手順を提供
探索ツール HTTP通信やブラウザ操作などを実行
エージェント管理 調査タスクの分担やエージェント間の連携
脅威モデル管理 調査対象に関する理解を保存・更新

つまり探索行動は、LLMの学習済み知識だけで成立しているわけではなく、LLMの判断と、Strix側が事前に与える指示・ツールの組み合わせで実現されています。この構図は、LLMを使ったペネトレーションテストの先行研究2でも、調査状態の管理やツール実行・結果解釈を枠組み側が担うものとして報告されています。

8.2 脅威モデルの更新には専用ツールがある

特に興味深かったのが、7で見た脅威モデル更新の裏側です。Strixには get_threat_model / save_threat_model / amend_threat_model という取得・保存・更新のための専用ツールが実装されていました。つまり、あの更新は明示的な状態管理機構に支えられていたわけです。

ただし、ツールが存在することと、更新内容をLLMが自律的に判断したことは別問題です。どの情報を根拠にいつ更新を指示したのかは、実行ログと突き合わせて見る必要があります。

8.3 仮説の反証も事前に指示されている可能性がある

もう一つ注目したのが診断スキルの仕組みです。Strixは役割に応じてスキルを読み込みシステムプロンプトへ組み込みますが、その中には反証の取り扱いに関するスキルも用意されていました。

これは7の観察と直結します。あそこでは「観測による脅威モデルの更新は見えたが、仮説の否定・切り替えは確認できなかった」と述べました。一方、Strix側に反証を扱う指示があるなら、仮説検証型の探索を促す仕組みが存在する可能性があります。ただしスキル本文が実際にどんな指示を与え、今回の診断でどの程度作用したかは、さらに調査が必要です。

8.4 結論：3つの寄与を切り分ける必要がある

ソースコードを踏まえると、今回観測した「導線を辿る」挙動は「固定実装（コードやツールに定義された処理）＋プロンプト・スキルによる指示＋LLMの判断」の重なりで生じていると考えるべきでした。ダミーエンドポイントの導線を辿った事実は確認できましたが、その判断にLLMの学習済み知識がどれだけ寄与したかは、まだ切り分けられていません。

今後は、ソースコード・システムプロンプト・実行ログを対応づけ、この3つがそれぞれ探索にどれだけ寄与するのかを切り分けて検証したいと考えています。特に、導線（明示的な手がかり）を取り除いたとき、実装知識だけでどこまで探索できるのかが次の焦点です。

ソースコード調査の対象

今回の対象はStrix v1.7.0です。継続的に開発されているため、現在のmainブランチとは実装が異なる可能性があります。

9. 観察された探索を「手がかり」で3種類に分ける

8ではStrixの実装レイヤー（誰がその行動を決めたか）による切り分けをしました。ここでは視点を変えて、何を手がかりに次の対象を選んだかで探索行動を3種類に整理します。

  • ① パターンベース探索：一般的な実装パターンに基づいて候補を選ぶ。4章の robots.txt や sitemap.xml の調査が該当し、従来の脆弱性スキャナーでも一般的3。LLMの実装知識がこの候補生成にどれだけ影響するかは今後の課題。
  • ② 証拠ベース探索：取得したHTML・JavaScript・HTTPレスポンスを手がかりに次を選ぶ。今回ダミーエンドポイントの導線（内部API→設定ファイル→管理画面）を辿ったのがこれ。
  • ③ 仮説検証型探索：未知の内部構造に仮説を立て、リクエストで検証し、結果に応じて修正する。例えばREST APIと推測して関連エンドポイントを予測し、実際に試して評価する。

今回確認できたのは①と②、および脅威モデルの更新までで、否定的な証拠による仮説の破棄や優先順位の変更（③の核心）は確認できていません。この実験だけで高度な仮説検証能力が実証されたとは言えません。なお3種類は独立ではなく、パターンから候補を出し、証拠で手がかりを見つけ、その結果で仮説を直す、という形で組み合わさっている可能性があります。

10. 探索を理論的にどう理解するか

8で見たとおり、今回の挙動は実装側の寄与が大きい前提ですが、それでも「挙動のレベル」で見ると、Strixは内部構造を知らない状態から探索を始め、取得情報で次の対象を選んでいました。これは部分観測環境における逐次的な意思決定として整理できます。

10.1 部分観測環境での探索（POMDP）

ブラックボックス診断では内部構造を直接参照できず、HTTPレスポンスやHTML・JavaScriptから推測するしかありません。今回のStrixも未確認だったダミーエンドポイントを探索で確定し、脅威モデルを更新していました。これは部分観測マルコフ決定過程（POMDP）4と関連づけて考えられます。

POMDPの概念 今回のStrix実験
隠れた状態 Webアプリケーションの内部構造
観測 HTTPレスポンス、HTML、JavaScript
行動 APIへのアクセス、追加探索
状態に関する理解 脅威モデル、共有ノート
行動選択 次に調査する対象の決定

StrixがPOMDPを実装しているという意味ではなく、観測された行動を説明するための枠組みです。

10.2 ベイズ的な信念更新との関係

未確認の対象を観測で確定し理解を更新していく過程は、新しい証拠で仮説の確からしさを更新するという意味でベイズ的な信念更新に似ています。あるAPIの存在を実装パターンから推測し、HTMLに参照が見つかれば可能性が高まり、HTTP 200が返れば到達可能性が確定する、という流れです。ただし明示的な確率計算は確認できておらず、ベイズ推論を実行していると主張するのではなく行動上の類似性として扱うのが適切です。

10.3 情報利得と探索効率

もう一つ関連するのが情報利得で、その考え方はShannonの情報理論5に由来します。探索候補は多数あり、網羅は時間・コスト的に非現実的なので、次の調査でどれだけ不確実性を減らせるかが重要になります。100種類のパスを試すより、JavaScriptから命名規則を推測して5種類に絞って到達できるなら効率が高い、という発想です。ただしこちらもStrixが候補の情報利得を比較して選んだ証拠はなく、今後の探索効率研究で使える概念として位置づけています。

Shannonの論文は情報理論の基礎文献であり、AIエージェントが情報利得を使って探索していることを示す研究ではありません。本記事では探索効率を考えるための概念的な補足として参照しています。

11. ダミーエンドポイントは、そのまま防御に使える

ここまでは攻撃側の探索を観察する手段としてダミーエンドポイントを使いましたが、この仕掛けはそのまま防御（早期検知）にも使えます。冒頭の国内事案で狙われたのも、認可の甘いAPIや外部から到達できる管理画面という、今回Strixが辿ったのと同じ種類の穴でした。

攻撃側の探索を予測する：AIが実装パターンから候補を生成しているなら、防御側もある程度先回りできます。使っているフレームワークから、攻撃者が調べやすい設定ファイルやAPIの種類が見え、優先的に守るべき箇所を特定できます。

探索行動を利用した早期検知：今回、業務機能と切り離したダミーエンドポイントを置いたところ、Strixはそれを手がかりに探索を進め、Vercelのログにも残りました。これは裏を返せば、攻撃者が食いつきそうな「おとり」を本番に仕込み、その接触を検知するという防御策（ハニートークン／ディセプション）が成り立つということです。ただし正規の診断やクローラーも同じアクセスをするため、単一アクセスで悪意は断定できず、複数リクエストの関係や順序を組み合わせた分析が要ります。

アプリとクラウドの両面で守る：AIによる探索を前提にすると、防御はアプリ単体では完結しません。AWS上でALB・ECS・RDS/Auroraを使うWebサービスなら、アプリ側の認証・認可の徹底、WAFによる不審通信の検知、CloudWatch Logsでのログ収集、IAM・Secrets Managerの適切な設計、不審な探索の分析・通知・・・などなど、検出脆弱性の継続的な改修を組み合わせます。重要なのは、兆候の検知と脆弱性の修正を分けて考えること。管理APIへの不審アクセスを検知できても、認可不備があるなら根本修正が必要です。

12. 今回わかったこと・わからなかったこと

検証項目 結果
ダミーエンドポイントの導線を順に辿るか 確認
HTML・JavaScriptからの手がかり発見 確認
応答を手がかりにした追加探索 確認
複数エージェントによる調査分担 確認
観測結果による脅威モデルの更新 確認
脅威モデル更新を支える専用ツールの存在（ソースコード） 確認
LLMの学習済み知識による未知APIの推測 未検証
否定的な証拠による仮説の破棄 未確認
LLMの判断・プロンプト・固定実装それぞれの寄与度 未検証
情報利得に基づく探索先の選択 未検証

今回の実験では、仕掛けた3段のダミーエンドポイントをStrixが起点から終点まで辿り、取得した情報で探索対象を変える様子を観測できました。推測段階だった内部向けエンドポイントが、到達可能な対象として脅威モデル上で再分類されるのも確認できました。さらにソースコードから、この挙動が明示的な状態管理や診断スキルに支えられていることもわかりました。

一方、当初の仮説「LLMが学習済みの実装知識を事前知識として使い、未知の内部構造を推測する」については、まだ直接の証拠がありません。今回の導線はこちらがHTMLに埋め込んだ手がかりで成り立っており、未知のURLをLLMが独自生成したわけではないためです。この切り分けは次の実験の宿題とします。

13. まとめ

この記事では、デモアプリに段階的な導線を持つダミーエンドポイントを仕掛け、AIペネトレーションツールStrixの反応を実行ログとソースコードから観察しました。結果、Strixは仕掛けた導線を起点から終点まで辿り、取得した情報を次の探索の判断材料として使い、その理解を脅威モデルに反映していました。

ただしこの挙動は、LLMの判断だけでなく、Strix側の明示的な状態管理や診断スキルにも支えられていました。ログでの観察と、OSSならではのソースコード確認を突き合わせたことで、「どこまでがLLMで、どこからが実装か」という問い自体を切り分けられたのが今回の収穫です。そして、攻撃側の探索を可視化するために使ったダミーエンドポイントは、そのまま防御側の早期検知の仕掛けにもなります。

冒頭で見たとおり、AIの関与が疑われる攻撃の実害はすでに広がっています。こうした攻撃を理解するには、個々の脆弱性や手法だけでなく、攻撃側AIが何を根拠に仮説を立て、どの証拠で次の行動を選ぶのかを分析することが重要です。その仕組みがわかれば、攻撃側の探索を予測し、防御側の検知や設計へつなげられます。今後も実験的に分析を続け、アプリとクラウドの防御技術へつなげていきます。

参考文献

主要な参考文献

  1. Deng et al. (2024). PentestGPT：LLMを利用したペネトレーションテストの自動化、調査状態の管理、ツール実行と結果解釈に関する研究。
  2. Strix：今回の実験で使用したOSS。エージェント構成やツールの動作を理解するための一次資料。
  3. Kaelbling et al. (1998)：部分観測マルコフ決定過程（POMDP）に関する代表的な論文。内部構造が不明な環境での観測と意思決定を説明する理論的背景。
  4. OWASP WSTG：Webアプリケーションの情報収集、認証・認可、設定管理などのセキュリティテストに関する実践的ガイド。

補足資料

  • Shannon (1948)：情報理論の基礎となる論文。エントロピーや情報量の考え方を理解するための参考文献として掲載しています。AIエージェントが情報利得を使って探索していることを示す研究ではありません。

おわりに

ここまで読んでいただきありがとうございました。
AI時代のアーキテクチャの考え方については、共著書籍にもまとめています。本記事のように「AIがどう動くか」を構造で捉える話とも通じるところがあるので、よければ手に取ってみてください。

『AI×アーキテクト 〜『複雑性・不確実性』を構造で受け止める〜』

AI×アーキテクト
Amazon：https://amzn.asia/d/0cuPWCoH

AI×セキュリティ・クラウド

本記事で触れたAI×セキュリティやクラウドまわりは、普段の仕事でも取り組んでいる領域です。AI時代のクラウドセキュリティ、脆弱性診断、24時間365日の監視あたりで「実際どう進めれば」という相談があれば、会社のほうで受けています。気軽に声をかけてください。

ランスティア株式会社

ランスティア株式会社 https://lancetier.co.jp/

  1. Strix：Autonomous AI Security Testing Agent. GitHub Repository, Strix Project. https://github.com/usestrix/strix ↩

  2. Deng et al. (2024). "PentestGPT: An LLM-empowered Automatic Penetration Testing Tool." 33rd USENIX Security Symposium (USENIX Security '24). https://www.usenix.org/conference/usenixsecurity24/presentation/deng ↩

  3. OWASP Foundation：Web Security Testing Guide (WSTG). https://owasp.org/www-project-web-security-testing-guide/ ↩

  4. Kaelbling, L. P., Littman, M. L., & Cassandra, A. R. (1998). "Planning and Acting in Partially Observable Stochastic Domains." Artificial Intelligence, 101(1–2), 99–134. https://doi.org/10.1016/S0004-3702(98)00023-X ↩

  5. Shannon, C. E. (1948). "A Mathematical Theory of Communication." Bell System Technical Journal, 27(3), 379–423; 27(4), 623–656. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x ↩

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?