AgentFlow: static analysis that finds prompt-to-tool risks in agent code

What is this?

On July 2, 2026, researchers posted AgentFlow: Building Agent Dependency Graphs for Static Analysis of Agent Programs to arXiv. The paper tackles a problem that has grown quietly as agents moved from demos to production: an LLM agent is now a source-code application, and nobody has a good way to read its security-relevant structure the way we read ordinary programs.

An agent program mixes conventional host-language code with framework-defined semantics — model bindings, prompt templates, tool declarations, memory stores, and multi-agent handoff logic. Its behaviour depends not only on classic control and data flow, but on a new class of agent dependencies expressed through framework idioms such as agent constructors, tool decorators, and handoff declarations. Ordinary static-analysis and dependency tools don’t understand those idioms, so they walk straight past them. AgentFlow is presented as the first static-analysis framework built specifically to recover and reason about that structure. This is a defensive tooling writeup, not an exploit.

How it works

AgentFlow parses an agent program and builds an Agent Dependency Graph (ADG) — a framework-agnostic representation in which agents, prompts, models, capabilities, memory states, and control policies become typed nodes, and their relationships become typed edges for component dependency, control flow, and data flow.

   [prompt/template] --data-flow--> [agent] --capability--> [tool]
          ^                            |
   untrusted input?              control-policy
                                       |
                                 [memory state] --handoff--> [agent B]

Once the graph exists, it supports two security analyses that plain code review struggles to do by hand. The first is Agent Bill of Materials (BOM) generation: an inventory of which models, prompts, tools, memory stores, and sub-agents a program actually wires together — the agent-native equivalent of a software BOM. The second is prompt-to-tool risk detection, a taint-style analysis that traces whether text flowing into a prompt can reach a powerful capability without an intervening control, which is the structural precondition behind indirect prompt injection and tool-selection hijacking.

The authors implement AgentFlow for five representative agent frameworks and evaluate it on AgentZoo, a corpus of 5,399 real-world agent programs. They report that it recovers richer agent entities and dependencies than existing AST-based agent analysers, produces more dependency-aware Agent BOMs, and surfaces 238 taint-style prompt-to-tool risks in real code. The framework names are given in the paper; the takeaway that matters here is the coverage and the count, both of which come from the authors’ own measurements.

Why it matters

Most agent-security tooling looks at runtime — guardrails, output filters, runtime authority checks. AgentFlow looks earlier, at the code itself, and that fills a real blind spot. Supply-chain and composition risk in agents lives in how components are wired: a prompt built from retrieved content, handed to an agent that holds a shell or payment tool, is the lethal trifecta expressed in source. You cannot govern what you cannot enumerate, and today most teams cannot enumerate their own agents’ tool graph.

An Agent BOM is directly useful for governance: it lets a reviewer or auditor see, per program, which models and tools are in scope, where memory persists across turns, and which sub-agents can hand control to which others. The 238 flagged prompt-to-tool flows are a reminder that these risky wirings are not hypothetical — they are already present in shipped agent code, waiting for someone to notice.

Defenses

Treat this as a technique to adopt, not just a paper to read.

Generate an inventory before you audit. An Agent BOM — however you produce it — turns “we have some agents” into a concrete list of models, prompts, tools, and memory stores you can actually review and sign off on.

Run taint analysis for prompt-to-tool flows. The dangerous pattern is untrusted input reaching a high-impact capability with nothing in between. Flag those paths in code review and require an explicit control (validation, human confirmation, or a capability boundary) on each one.

Make framework constructs first-class in review. Tool decorators, agent constructors, and handoff declarations carry authority. If your review process only reads plain functions, it misses exactly the edges that matter.

Keep static analysis paired with runtime controls. Static graphs cannot see everything an agent does at runtime — tool calls the model improvises, dynamically loaded skills, or content fetched mid-task. Use the ADG to shrink and prioritise the attack surface, then back it with least-privilege tool scoping and runtime monitoring rather than trusting either layer alone.

Status

Item	Detail
Disclosure	Academic preprint, arXiv, July 2, 2026
Contribution	Static-analysis framework; Agent Dependency Graph (ADG) representation
Analyses	Agent Bill of Materials generation; taint-style prompt-to-tool risk detection
Evaluation	Five agent frameworks; AgentZoo corpus of 5,399 real-world agent programs
Key result	Richer entity/dependency recovery than AST-based tools; 238 prompt-to-tool risks found
Caveat	Static analysis only — dynamic runtime behaviour and framework coverage beyond the five studied remain open