AgentHound: an attack-path mapper for MCP, A2A and model gateways
Offensive security framework for AI agent infrastructure - recon, credential looting, model exfiltration, poisoning, and attack-path analysis across MCP, A2A, gateways, and AI services. BloodHound for the agentic stack.
At a glance
- What is it?
- AgentHound is a Go-based offensive security framework that collects agent credentials and service inventory from a single foothold, then turns the resulting artifact into a queryable attack graph in Neo4j. It is built for authorized red-team work against agentic infrastructure, and its default scan is deliberately active.
- Who is it for?
- Adopt AgentHound if you run authorized red-team engagements against agentic infrastructure and already operate Neo4j for graph analysis; skip it if you need passive, agentless discovery or cannot accept a tool that validates credentials by default.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AgentHound targets: agents as a credential and trust surface
Agent infrastructure spreads secrets across places that traditional host scanners do not model. A Claude Desktop config, a Cursor rules file, a CLAUDE.md instruction file, an environment variable backing an MCP server, a LiteLLM master key, a Jupyter token: each is a separate credential store, and each one can authenticate to a different downstream service. The README frames the problem as a single foothold that has to be converted into a full picture before access disappears. AgentHound is aimed at red teams and internal security teams doing authorized assessments of that stack, not at developers who want a linter for their MCP configuration. The name the project uses for itself is BloodHound for the agentic stack, and the comparison is structural rather than cosmetic: both tools exist to turn scattered collection into a graph you can query for paths. The scope is broad by design. The README lists MCP, A2A, twelve agent-client configuration formats, model gateways, inference servers, vector stores, model registries, notebooks and web interfaces as one connected target set. That breadth is the selling point and also the reason the tool needs a graph backend to be useful.
One collector, one artifact, one graph: the data flow
The pipeline has three stages, and the README states them plainly: one foothold, one scan, secrets plus services plus proof, one artifact, then a full attack graph. The collector is a single static binary dropped onto a compromised host. It reads local agent configuration, instruction files, environment-backed secrets, loopback services, active interfaces and configured endpoints, plus an optional network scope. No database or server connection is required on that host, which matters because the host is assumed hostile and short-lived. Everything the collector learns is written into one continuously checkpointed JSON artifact. The README says an ingest-valid artifact is written before collection begins and that every meaningful result and action transition is checkpointed, so a loss of access mid-scan still leaves a usable file. The artifact is then handed to an optional analysis server, which loads it into a graph with credential chains, execution and exfiltration paths, cross-protocol pivots, risk scoring and triage. Neo4j appears in the repository topics, so the graph layer is Neo4j-backed. The separation is the interesting design decision: collection is a dumb, resilient, offline-capable binary, and all the reasoning happens later on a system you control.
Active by default: differential proof and reversible mutation
AgentHound does not report reachability and call it a finding. For an eligible MCP resource it performs an anonymous control read first. If that read succeeds, the resource is recorded as public and no credential is presented. If it fails, the tool retries with a credential. A denied anonymous read followed by an allowed credentialed read is recorded as Verified During Scan evidence tied to that specific credential and that specific resource. That is a real differential test, and it is the part of the tool most likely to generate noise in logs on the target side. The second active behaviour is more aggressive. Against eligible ContextForge-managed tools, the planner writes a scan-specific description marker, observes the marker through MCP, restores the original description immediately, and independently confirms restoration before continuing. The README describes this as reversible active validation. The word reversible is doing a lot of work here: the safety of the operation depends on the restoration confirmation completing, and the README also notes that unresolved restoration can be retried from the same artifact. That is a sensible fallback, but it means a scan that dies between write and restore leaves a modified tool description on a production system until someone reruns the restoration step.
Getting it running: binary, flags and the analysis server
The README does not print a full command line in the material available here, so the exact invocation cannot be quoted. What it does state is the flag that changes the tool's posture. The default scan is active, and the README gives the reason: foothold access may disappear at any moment. Passing --stealth switches the same workflow to read-only collection when operational security requires it. That single flag is the difference between a scan that validates credentials and one that only observes them, and it should be the first thing you confirm against the shipped binary before pointing it at anything. Deep mode is a separate setting that adds recursive instruction discovery, bounded vector point references, and Ollama compute verification, so there is a second tier of collection beyond the default. On the analysis side, the server is described as optional, and the artifact is ingest-valid JSON, which means you can collect without ever standing up the graph. The graph stage is where the credential chains, execution paths, exfiltration paths, impersonation and shadowing analysis, poisoning analysis and tainted data flow queries live. If you skip the server you keep the raw secrets and inventory and lose the path analysis.
What the graph actually joins, and where the analysis stops
The analysis server combines trust relationships, authentication schemes, credential reuse, tool capabilities, sensitive resources, protocol boundaries and observed proof into queryable paths. The categories named in the README are reachability, execution, exfiltration, impersonation, shadowing, poisoning and tainted data flow. Credential reuse is the connective tissue: a bearer token captured from a Cursor config that also authenticates to a LiteLLM gateway becomes an edge between two otherwise unrelated systems, and the graph is what makes that edge visible. The A2A side adds agent cards, skills, delegation, authentication schemes, signatures and remote JWKS evidence, plus authenticated agent-card enrichment and confused-deputy analysis. The honest limitation is that path analysis is only as good as the collection that fed it. If a credential exists somewhere the collector does not look, no edge appears, and the graph will look clean for reasons that have nothing to do with the target being secure. The README's own list of twelve agent-client formats is a moving target: agent clients ship new config locations regularly, and a format added after your build will be invisible to it.
Where AgentHound is the wrong tool
The README opens with an authorized-use warning and states that AgentHound performs active credential validation, model invocation, and reversible mutation when their prerequisites are present. That sentence disqualifies it for a large class of environments. If you cannot obtain written authorization for credential validation against production agent services, this is not the tool, and --stealth is a mitigation rather than a fix because the default path is the one the project optimizes for. If your constraint is that no software may run on the target host, AgentHound is structurally unusable: it is foothold-first and requires a collector on the machine. If you need continuous posture monitoring rather than a point-in-time engagement artifact, the scan-and-artifact model does not fit, since there is no agent or scheduler described in the material. And if your team does not operate a graph database, the most valuable half of the tool, the attack-path analysis, is effectively unavailable until you stand one up. The lightweight alternative for the configuration and secret discovery portion is a host-based secret scanner such as TruffleHog or Gitleaks run against the same config directories. The difference in approach is fundamental: those tools pattern-match for secrets in files and stop there. They do not authenticate to the discovered service, do not confirm that a token actually works, and do not model the relationship between a leaked key and the resource it opens. AgentHound's entire value proposition is closing that gap, which is also exactly why it is louder and riskier to run.
Maintenance, licensing and what to check before you deploy
The project is Apache-2.0, which permits commercial and internal use, modification and redistribution provided the licence and notices are preserved; that is a summary of the licence text, not legal advice, and your counsel should read the LICENSE and NOTICE files in the repository. The release cadence visible in the material is three tagged releases between late July and late August 2026, with 1.1.1 as the most recent, and the repository is not archived, with a last push date in September 2026. That suggests an actively maintained project, though a release cadence says nothing about the quality of any individual scan. Because the tool mutates state when prerequisites are present, upgrades deserve more care than a typical dependency bump: a change to the ContextForge validation logic or the restoration confirmation path is a change to what your scan does to a production system. Pin a specific version for engagements rather than tracking main, and re-read the release notes for any version that touches the validation planner. The artifact format is the other upgrade surface, since the analysis server ingests it; a collector and server on mismatched versions is the most likely source of silent ingest failures.
Editorial conclusion
Adopt AgentHound if you run authorized red-team engagements against agentic infrastructure and already operate Neo4j for graph analysis; skip it if you need passive, agentless discovery or cannot accept a tool that validates credentials by default. Before running it, verify the exact flag that switches to read-only collection, confirm which ContextForge tool descriptions the reversible mutation touches, and read the LICENSE file and NOTICE for the Apache-2.0 terms that apply to your redistribution.
Community notes