AgentHound：AI Agent インフラを攻撃経路グラフとして見る
AI agent が team の toolchain に入ると、security boundary はかなり細かく割れる。以前なら主に application、database、CI、cloud account を見ればよかった。今は MCP server、A2A endpoint、local agent client config、model gateway、vector store、notebook、Open WebUI、LiteLLM、Ollama、さらに working directory に置かれた instruction file まで見る必要がある。一つひとつは普通の設定に見えても、つなげて見ると別の問題になる。Local token はどの MCP resource に届くのか。Agent card は別 service に permission を委任していないか。Notebook、vector collection、model gateway は、本来アクセスできない caller に内部 data を渡していないか。
今日見るのは adithyan-ak/AgentHound。Repository は自分自身を AI agent infrastructure の offensive security framework と説明している。もう少し実務寄りに言うと、agentic stack の config、credential、service、resource、cross-protocol relationship を artifact として集め、analysis side で attack path graph として扱う tool だ。Red team にとっては foothold 後に agent 面を素早く把握するための道具になる。Blue team や platform engineering team にとっては、agent ecosystem の risk が「prompt injection 一点」ではなく、複数の tool surface と identity boundary がつながった path の問題であることを見せてくれる。
GitHub repository page、GitHub API、README、CHANGELOG、LICENSE、latest release、recent commit を 2026-08-22 18:10 Asia/Shanghai 時点で確認すると、adithyan-ak/AgentHound は 269 stars、57 forks。主要言語は Go、license は Apache-2.0。Repository created time は 2026-04-05 20:37:16 UTC、latest public push は 2026-08-22 07:55:01 UTC、default branch は main。最新 GitHub Release は 1.1.0、published time は 2026-08-20 05:10:51 UTC。Recent commit は b50de7c6657f、message は “build(deps): bump the actions-all group across 1 directory with 10 updates (#132)”、commit time は 2026-08-22 07:25:13 UTC。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | adithyan-ak/AgentHound |
| 位置づけ | AI agent infrastructure の authorized security assessment と attack path analysis |
| Stars | 269 |
| Forks | 57 |
| 主要言語 | Go |
| ライセンス | Apache-2.0 |
| 作成日時 | 2026-04-05 20:37:16 UTC |
| Latest push | 2026-08-22 07:55:01 UTC |
| Default branch | main |
| 最新 GitHub Release | 1.1.0、2026-08-20 05:10:51 UTC |
| Recent commit | b50de7c6657f、build(deps): bump the actions-all group across 1 directory with 10 updates (#132) |
| キーワード | MCP、A2A、AI security、red team、attack paths、model gateways、agent clients |
なぜ agent infrastructure には graph view が必要か
従来の asset scanning は list を作るのが得意だ。Open port、dependency version、cloud resource、certificate、configuration item。Agent infrastructure にももちろん list は必要だが、list だけだと一番重要な risk を落としやすい。Permission と data は tool call chain を通って広がるからだ。Agent client の config file には MCP server があり、MCP server は resource と tool を expose する。その裏には notebook、vector database、model gateway、internal API があるかもしれない。Bearer token はただの environment variable に見えるが、実際にどの service に届くかは protocol と config relationship をたどらないと分からない。
AgentHound の README は、MCP、A2A、agent clients、model gateways、inference servers、vector stores、MLOps、notebooks という plane を対象にすると説明している。単に「secret があるか」を見るのではなく、secrets、services、resources、identity、tool capabilities、verified evidence を relationship として整理する。README に出てくる graph primitives には reachability、execution、exfiltration、impersonation、shadowing、poisoned descriptions、tainted data flow などがある。重要なのは用語ではない。ある foothold から sensitive resource へ進む chain があるのかを見たいのであって、configuration item が存在するかだけを知りたいわけではない。
この考え方は agent platform team にとって特に使いやすい。多くの team は Claude Desktop、Cursor、Windsurf、VS Code plugin、internal MCP server、LiteLLM、Ollama、Jupyter、vector database を先につなぎ、workflow が動いたあとで permission boundary を補う。だが agent tools の composability が高いほど、boundary は default config と人間の運用ルールに寄りかかりやすい。Relationship graph を作ると、team は具体的な質問に答えざるを得ない。どの agent config が real credential に触れるのか。どの local service が reachable address で listen しているのか。どの tool description や instruction file を input surface として audit すべきか。どの path は inferred で、どの path には actual evidence があるのか。
普通の secret scanner とは違う
AgentHound は credential を扱うが、単純な secret scanner ではない。普通の scanner は「ここに key らしきものがある」と見つけ、人間に triage を渡すのが得意だ。AgentHound は、その key が agentic stack の中でどの verified path につながるかを重視する。README と 1.1.0 changelog では、collection、service fingerprinting、compatible credential reuse、evidence、analysis artifact を一つの workflow に置く設計が強調されている。
だからこそ慎重に扱う必要がある。Project README は authorized use only と明記し、default scan が active validation を行うことも説明している。Security document も active mode と stealth mode の違いを分けている。つまり、任意の環境に投げて「結果を見てみる」タイプの observation tool ではない。想定されているのは、permission boundary が明確な assessment だ。Red team が foothold 後に証拠を保全する、または security team が自分たちの lab environment で agent toolchain の exposure を検証する、といった使い方になる。
Engineering choice としては、collector と analysis server の分離が目を引く。README は collector side に database や server connection が不要で、scan result をまず JSON artifact として残すと説明している。そのあと analysis side が artifact を queryable attack graph に変換する。この形は assessment 現場に合う。Foothold は短く終わるかもしれないので、その場で大きな service を立てるより、structured evidence を残すほうが現実的だ。一方で analysis side は Neo4j、PostgreSQL、dashboard を含むため、controlled network に置くべきで、新しい exposed surface にしてはいけない。
どういう場面で使えるか
一つ目は、agent platform を production に出す前の security review だ。たとえば team が internal MCP server、model gateway、agent client config template をすでに持っているとする。隔離環境に代表的な config と service を置き、authorized assessment として graph を作る。価値は bug finding だけではない。Team が baseline を決める助けにもなる。どの path は存在してよく、どの path は network、identity、tool permission で切るべきかを議論できる。
二つ目は、red team や internal audit が foothold 後に agent surface を enumerate する場面だ。従来の internal assessment では domain、cloud metadata、CI secrets、database connection string を見る。Agent 時代には MCP config、agent instruction files、local model services、notebook token、vector database も見る必要がある。AgentHound の売りは、それらを同じ graph に置き、「service ごとに別々に scan して、最後は人間の頭でつなぐ」負担を減らすところにある。
三つ目は incident review だ。Agent 関連の incident は single-point failure というより、「ある config exposure + 信頼されすぎた tool description + 広すぎる credential + reachable service」が重なって起きやすい。Attack path graph はそれらの条件を分解し、team が修正箇所を決める助けになる。MCP server の resource permission を絞るべきか。Model gateway を loopback 外から隔離すべきか。Agent client config が high-privilege token を持たないようにすべきか。Graph はその議論を具体化する。
Caveats
第一に、AgentHound は offensive security tool であり、日常的な observability agent ではない。README は default mode が active validation を行うと説明し、security document は plaintext evidence が残ることを明記している。JSON artifact には concrete credential、service content、action result、recovery data が含まれ得る。保存、転送、削除は evidence と sensitive data の扱いに合わせるべきだ。
第二に、project はまだ若い。Repository は 2026-04-05 作成、latest release は 1.1.0、stars は 269。ニッチな security tool としては悪くない成熟度だが、interface、module coverage、analysis model はまだ速く変わる可能性がある。正式な process に入れる前に、固定 fixture と test environment で output の安定性を確認したい。
第三に、coverage が広いほど interpretation risk も上がる。MCP、A2A、agent clients、model gateways、vector stores、notebooks は deployment pattern の差が大きい。Graph に inferred path があるからといって production で必ず exploit 可能とは限らない。逆に path が出なかったから risk がないとも言えない。これは authorized assessment の evidence collection と path modeling tool であり、最終判定器ではない。
第四に、agent stack の permission debt を可視化してしまう。多くの問題は AgentHound が生むのではなく、scan で初めて見えるようになる。Local config に長期 token がある。MCP resource の access control が足りない。Notebook や vector store が default で露出している。Tool description が汚染され得る。これらを直すには、platform、development、security team が一緒に process を変える必要がある。
まとめ
adithyan-ak/AgentHound が面白いのは、AI agent security を single check から path analysis に進めている点だ。Agent 時代の attack surface は、一つの新しい port や一つの prompt ではない。Composable tools、configs、identities、resources、protocols の集合だ。それらをつなげて見て初めて、risk が形になる。
無許可の環境で気軽に走らせる tool ではないし、万能 scanner として扱うべきでもない。だが internal MCP、model gateway、agent client config、local AI toolchain を作っているなら、AgentHound はかなり現実的な問いを投げてくる。Agent infrastructure をまず graph として描き、そのうえでどの path が存在してよいのかを決めるべきだ。