Not every dangerous tool in your codebase is an active risk. A tool with arbitrary code execution that no agent actually references is a very different situation from one actively called by your researcher agent on every task. Reachability analysis tells you which is which.
What reachability means
Reachability is the answer to: does any agent actually use this tool?
Without reachability, every tool finding has equal weight regardless of whether it’s wired into an agent or just sitting unused in your codebase. This produces noisy results that make it hard to prioritize. Drako uses AST traversal to build a map of which agents reference which tools, then uses that map to classify each finding.
How it works
When Drako scans your project, it:
- Parses all agent definitions to extract the
tools= argument from each Agent() constructor and class definition.
- Parses all
Task() constructors to extract per-task tool assignments (supporting CrewAI’s task-level tool override pattern).
- Compares each detected tool against the agent and task tool maps.
- Classifies each tool as
REACHABLE, POTENTIALLY_REACHABLE, or UNREACHABLE.
Classification logic:
| Status | Meaning |
|---|
REACHABLE | Tool appears in at least one agent’s tools= list |
POTENTIALLY_REACHABLE | Tool name appears in source code near agent definitions, but not in an explicit tools= list |
UNREACHABLE | No agent or task references this tool |
Reading reachability in scan output
Reachability status appears inline with each finding:
SEC-001 API key hardcoded in source (src/main.py)
⚠ REACHABLE — used by agent 'researcher'
Related: DRAKO-ABSS-2026-003
Impact: Attacker inherits all agent permissions
Ref: CWE-798, OWASP LLM06
SEC-005 Arbitrary code execution in tool (tools/runner.py)
○ UNREACHABLE — no agent references this tool
⚠ REACHABLE findings are actively exploitable and should be prioritized.○ UNREACHABLE findings are still reported — the tool exists and could be wired in — but they are lower priority.
Impact on scoring and prioritization
Reachability affects how you should prioritize remediation, but both reachable and unreachable findings contribute to the governance score. The score reflects your actual codebase posture, not just the currently-active paths.
In practice, use reachability to triage:
- Fix all CRITICAL and HIGH findings marked
REACHABLE first.
- Address CRITICAL
POTENTIALLY_REACHABLE and UNREACHABLE findings before they get wired in.
- Use
--fail-on critical in CI to gate on reachable CRITICAL findings in changed files.
Run drako scan . --diff HEAD~1 to scope reachability analysis to only the files changed in your latest commit. This is useful for fast CI feedback on pull requests.
Supported frameworks
Reachability analysis supports all frameworks where Drako can detect agent-to-tool wiring via AST:
| Framework | Agent detection | Tool list extraction |
|---|
| CrewAI | Agent(tools=[...]), @CrewBase YAML | tools= argument, Task(tools=[...]) |
| LangGraph | Graph node definitions | Tool bindings in node config |
| AutoGen | AssistantAgent, UserProxyAgent, ConversableAgent | Tool registrations |
| Semantic Kernel | Kernel plugin imports | Plugin function registrations |
| PydanticAI | Agent class definitions | @agent.tool decorators |
| LangChain | Agent executor definitions | Tool list arguments |
Reachability analysis is a best-effort static approximation. Dynamically constructed tool lists (e.g., tools assembled at runtime from a database) may not be fully captured. In those cases, Drako classifies tools as POTENTIALLY_REACHABLE.