
Agent Graph Auditor
io.github.4hmetuyarPublished by GitHub account 4hmetuyarv0.1.2Updated Nov 10, 2026
Finds transitive excessive agency across LangGraph/CrewAI/AutoGen orchestration graphs
Overview
Scans LangGraph, CrewAI and AutoGen Python source to find agents that can reach dangerous tools indirectly through delegation.
- What you can do
- Scan Python snippets, single files or whole directories for agent and tool definitions
- Build a reachability graph of agents, tools and delegation edges and report direct versus transitive excessive agency
- List the dangerous-capability catalog by category (code execution, process execution, filesystem write, network, credentials access)
- Produce SARIF output and honor a guardbee.yml config for CI/CD use
- When to use it
- Use it when reviewing or auditing a multi-agent Python codebase and you want to know whether a seemingly harmless agent can reach a shell, eval or SQL tool by delegating to another agent. Also useful as a CI check on agent orchestration code.
- Requirements
- Runs locally over stdio via npx from the npm package @guardbee/mcp-agent-graph-auditor, so Node.js and network access for the package download are needed. No accounts, API keys or environment variables are declared. Only Python source is scanned.
Installation
In SourceWeft
- Open Agent Graph Auditor in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
@guardbee/mcp-agent-graph-auditor
🇬🇧 English | 🇹🇷 Türkçe | 🇨🇳 中文 | 🇯🇵 日本語 | 🇰🇷 한국어 | 🇧🇷 Português | 🇪🇸 Español | 🇩🇪 Deutsch
[npm version] [npm downloads] [License: MIT]
An MCP (Model Context Protocol) server that builds a reachability graph across a multi-agent orchestration and finds transitive excessive agency — an agent that was never directly given a dangerous tool, but can still reach one through another agent it's allowed to delegate to.
mcp-server-auditor catches an MCP server whose own tool grants shell/eval/SQL access directly. ai-code-scanner catches a single agent's tool list containing execute_command. Both of those are one hop: agent → tool. Multi-agent frameworks add a second kind of edge — delegation, group chat, function-execution routing — and a "safe-looking" agent with only a web_search tool can become dangerous the moment it's allowed to hand work off to a coworker that holds a shell tool. That two-hop path is invisible to a scanner that only looks at one agent's own tool list at a time.
Telemetry is off by default. With
GUARDBEE_TELEMETRY=1it sends the server, tool, success, duration and short parameter values such as a file path; longer strings and fields likecontent,tokenorpasswordare replaced with a placeholder. See@guardbee/mcp-telemetry.
How the graph is built
- Extract. Framework-specific regex extractors pull agent/tool nodes and relationship edges out of the source:
has_tool(an agent's own toolset),delegates_to(CrewAIallow_delegation, LangGraphadd_edge),group_member(AutoGenGroupChatco-membership — any member's output can be routed to any other by the manager),executes_via(AutoGenregister_function's caller/executor split). - Classify. Every tool node is checked against a name-based capability catalog (code execution, process execution, filesystem write, network, credentials access) — the same kind of heuristic
ai-code-scanner's excessive-agency pattern uses, just applied to a graph of tools instead of one server's tool list. - Reach. A breadth-first search runs from every agent node. A capability tool reached via a straight
has_tooledge is a direct finding (still reported — useful even without a second agent in the picture). A capability tool reached only after crossing at least onedelegates_to/group_member/executes_viaedge is transitive — the finding this package exists for — and is always reported as critical, regardless of the tool's own base severity, because the agent holding it was never audited for it directly.
LangGraph is the most reliable target: add_node/add_edge calls are the orchestration graph in the source, no inference needed. CrewAI and AutoGen require inferring delegation from framework semantics (allow_delegation, GroupChat membership) rather than an explicit edge in the code, so treat those as heuristic — see Limitations below.
Features
- 3 frameworks: LangGraph (structural), CrewAI (heuristic), AutoGen/ag2 (heuristic)
- 7 capability rules across 5 categories (code-execution, process-execution, filesystem-write, network, credentials-access)
- Distinguishes direct (single-agent) from transitive (delegation-crossing) excessive agency — the transitive case is what no single-agent scanner in this monorepo catches
- Multi-hop aware — a 3+ agent delegation chain is found the same way a 2-agent one is
- SARIF 2.1.0 output — CI/CD integration (GitHub Code Scanning, etc.)
- Config file support via
guardbee.yml - 31 unit tests, plus end-to-end verification against realistic fixtures for all three frameworks
Quick Start
Claude Desktop / MCP Client
CLI (CI/CD)
MCP Tools
Example
researcher never holds shell_tool — but allow_delegation=True plus co-membership in the same Crew as ops means it can hand work off to an agent that does. This scanner reports:
writer — no tools, no delegation — gets no finding at all.
Configuration (guardbee.yml)
Limitations (by design)
- Single-file scope. Each file's graph is extracted independently — Python variable references don't resolve across files. A
Crew(agents=[researcher, ops])call will only connect toAgent(...)definitions found in the same file, even when scanning a whole directory. - CrewAI/AutoGen extraction is heuristic, not a real Python parser — constructor bodies are captured with a bounded text window rather than exact paren-matching (the same tradeoff
ai-code-scanner's pattern-window matching makes), and it doesn't track reassignment, conditional agent construction, or dynamically built tool lists. - AutoGen's
speaker_selection_methodisn't modeled —GroupChatco-membership is always treated as a bidirectional reachability edge, which is the conservative (over-inclusive, not under-inclusive) assumption. - Capability classification is name-based. A tool named
search_toolthat secretly shells out internally won't be flagged; a tool namedshell_tool_disabledwill be. Review findings; don't take them as ground truth. - Only Python source is scanned in v1 — LangChain/LangGraph's JS/TS API isn't covered yet.
Development
License
MIT — GuardBee
Feedback
Questions, ideas, or a false positive? Start a thread in GitHub Discussions or open an issue. If GuardBee is useful to you, a ⭐ on the repository helps others find it.
Source: packages/agent-graph-auditor/README.md at commit 040e072
Tools
0Version history
1- v0.1.2LatestSep 29, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts