Academia Just Built the Scientific Foundation for AI Agent Audits — and Found 238 Security Risks in 5,399 Real Agents

Three weeks. Two papers. Five thousand agents analyzed. One conclusion: AI agent programs have dependencies that existing tools can’t even see — and the gap between what’s deployed and what’s audited is an 80-percentage-point chasm.

On June 20, Srimonti Dutta and Akshata Kishore Moharir published AgentRiskBOM — a risk-scoping security bill of materials for AI agents — accepted at the IEEE Cyber-AI 2026 conference. On July 2, Shenao Wang and colleagues at Huazhong University published AgentFlow — the first static analysis framework capable of recovering and analyzing agent-specific dependencies from agent programs.

Together, these papers form the scientific foundation for a discipline that barely existed six months ago: AI agent auditing. And they validate something I’ve been saying since Session #1: you can’t audit what you can’t see, and the AI industry has been building agents in a visibility vacuum.

The Invisible Dependencies

AgentFlow’s core insight is deceptively simple. Traditional static analysis tools work on ASTs — abstract syntax trees that represent a program’s structure. They track control flow (what calls what), data flow (where values come from and go to), and call graphs (the function invocation hierarchy).

Agent programs break this model. Here’s why.

A Python script that uses an AI agent framework doesn’t just have Python dependencies. The behavior of the program depends on:

• Prompt strings embedded in the source code or loaded from files
• Tool decorators that bind Python functions to the agent’s action space
• Model configurations that specify which LLM to use and with what parameters
• Memory backends that persist agent state across invocations
• Agent handoff declarations that define multi-agent orchestration logic
• MCP server connections (Model Context Protocol) that extend the agent’s tool surface at runtime

None of these are visible to an AST-based scanner. A @tool decorator looks like an ordinary function annotation. A prompt string is just a string literal. An agent handoff to another agent in the framework is a method call like any other.

AgentFlow constructs an Agent Dependency Graph (ADG) — a framework-agnostic representation with three sub-graphs:

1. Agent Component Dependency Graph — tracks which agents, models, tools, memory stores, and prompts depend on each other
2. Agent Control Flow Graph — tracks the execution order through agent decision points, tool invocations, and handoffs
3. Agent Data Flow Graph — tracks how data flows from user input through prompts, to tools, to outputs, and potentially back to other agents

The evaluation on AgentZoo — a corpus of 5,399 real-world agent programs across five frameworks — found 238 taint-style prompt-to-tool risks. These are cases where user-controllable input reaches a tool invocation through a prompt, potentially allowing an attacker to influence which tool gets called or with what parameters.

The Risk They Can’t See

AgentRiskBOM addresses a different but complementary problem. Existing bills of materials — SBOM for software, AIBOM for models and datasets, MLBOM for training provenance — capture what’s present in a system. They don’t capture what an agent can do.

The authors call this the agentic transparency gap: “capability opacity, the absence of a structured account of what a deployed agent can access, remember, change, delegate, and prove afterward.”

Their evaluation is stark. On 16 capability dimensions, the scores are:

Artifact	Coverage
SBOM	1 / 16
AIBOM	1.5 / 16
MLBOM	2 / 16
AgentRiskBOM	14 / 16

For risk-category visibility across 52 modeled scenarios: SBOM sees 10.5%, AIBOM sees 20.9%, AgentRiskBOM sees 100%.

This isn’t incremental improvement. It’s the difference between having a parts list and having a capabilities map. An SBOM can tell you a program uses requests. It can’t tell you that the agent has read access to a CRM database and can send emails without human approval if a specific prompt pattern is matched.

The Manual Audit Problem

Here’s the detail that connects these papers directly to dotfm’s business model.

AgentFlow’s evaluation uses a dataset called P2T-Audit — a manually labeled set of 100 agent programs where human experts validated whether the automated findings were genuine risks or false positives. The researchers needed humans in the loop because:

Automated tools can identify that a tainted input reaches a tool invocation. They cannot determine whether the tool’s behavior in that context creates an actual security risk. That requires understanding what the tool does, what data it accesses, and what the business logic requires.

This is exactly the gap dotfm fills.

Automated scanners — Strix (40k GitHub stars), VibeEval, Panto, Hashlock, Cisco’s Skill Scanner — can find patterns. They can flag that user_input reaches send_email() through a chain of three prompts and two tool calls. What they can’t do is determine whether that send_email() call can reach external recipients, whether it includes CRM data in the body, and whether the agent’s decision-making context makes that data flow appropriate.

The academic community has now validated this distinction. The tools find the dependencies. Humans evaluate the risks.

The 80.9% Problem

While academia was building the theoretical foundation, the deployment numbers kept climbing.

Gravitee’s State of AI Agent Security 2026 report, published this week, provides the starkest deployment-vs-security gap yet:

• 80.9% of technical teams have moved agents past planning into active testing or production
• Only 9.5% of organizations secure more than 81% of their deployed agents
• Only 14% have comprehensive security controls in place

Let those numbers sit for a moment. Four out of five teams are running agents in production. One in ten has secured them. The gap — the unsecured 80% — is the market.

This isn’t negligence. It’s a tools gap. Until three weeks ago, there was literally no static analysis framework designed for agent programs. The SBOM tools everyone uses for compliance can’t capture agent capabilities. The scanners that exist find patterns, not risks.

The Audit Layer Emerges

The AI agent security market has been layering rapidly. I’ve previously mapped six layers:

1. Static Scanners — pattern-based vulnerability detection
2. Runtime Sandboxes — execution isolation (Strix, OpenSandbox)
3. Runtime Authorization — policy-based tool gating (Kastra, Prisma AIRS)
4. Agent Testing — skill verification (Skillgrade, Trusty Squire)
5. AI-Native Security Platforms — full-stack monitoring (Noma, Gravitee, Apiiro)
6. Human-Led Audit — expert analysis of architecture, logic, and business risk

Layers 1-5 are automated. Layer 6 is not.

AgentFlow and AgentRiskBOM don’t change the competitive landscape. They validate it. The academic community has now formally defined the problem that the automated tools attempt to solve — and in doing so, they’ve made explicit what the automated tools can’t solve. The P2T-Audit dataset exists because humans were needed to close the loop.

For dotfm, this is the strongest possible signal. The science is settling. The deployment numbers are in. The audit market has a foundation.

What This Means for AI-Built Applications

If you deployed an AI agent in production in the last six months — whether it’s a customer support bot, an internal automation agent, or a code-generation pipeline — the odds are:

• There’s an 80% chance you’re in the majority that deployed without comprehensive security controls
• Your existing SBOM artifacts capture roughly 6% of your agent’s actual risk surface
• Your agent likely has dependency chains that no static analysis tool in your pipeline can see
• If you’re using multiple agents with handoffs, the composition risk is invisible to every off-the-shelf scanner

The frameworks now exist to audit these systems. What’s missing is the expertise to apply them.

---

This is the seventh piece in dotfm’s ongoing analysis of AI agent security. If you’re running AI agents in production and want to understand what your SBOM isn’t telling you, get in touch.