Agentic apps are attack graphs — and the guardrail is the missing node

The most useful thing an outside model can do for a security argument is state the argument in terms you were not allowed to choose. ATAG — AI-Agent Application Threat Assessment with Attack Graphs, from Ben-Gurion University of the Negev — does exactly that. It models an agentic application as a formal attack graph, and in its own logic the thing that breaks a prompt-injection chain is a guardrail on the boundary. MoorAI is a concrete guardrail on that boundary. We did not build it from their paper, they have never heard of it, and the connection is stronger for it: two independent lines arriving at the same interception point.

What ATAG actually does

Attack graphs are old and load-bearing in classical network security: enumerate the facts true about a system, apply rules that say “if these facts hold, this new fact becomes reachable,” and you get a graph whose paths are the ways an attacker can walk from a foothold to a goal. ATAG extends MulVAL, a well-known logic-based attack-graph generator, with custom Datalog facts and interaction rules written for the shape of an AI-agent topology rather than a network of hosts.

The facts describe the app: inputAgent() and outputAgent() mark the agents at the edges of the system, execCode(Agent,Tool) says an agent can run a tool, hacl() is a direct agent-to-agent link and dataFlow() an indirect one through shared storage, externalInteraction(Source,Destination,Service,DataType) captures a call out to the world, and vulExists(Llm,Procedure,Technique,Impact,Severity) records a known weakness of the underlying model. In the rendered graph, rectangles are facts, circles are interaction rules, diamonds are attack goals, and edges are the prerequisite dependencies between them. It is, deliberately, a threat-modelling tool: it finds the paths at design time, before anything runs.

The rule everything turns on

Here is the detail that makes this a MoorAI post. One of ATAG’s interaction rules (Listing 4 in the paper) decides when an agent is vulnerable to prompt injection. This is it, verbatim:

vulnerableToPromptInjection(Agent) :-
    inputAgent(Agent),
    vulExists(LLM, 'Malicious_Link_Injection', 'LLM_Jailbreak', _Impact, _Severity),
    llmEngine(Agent, LLM),
    missingGuardrail(Agent, 'inputSanitization').

Read the last line again. The attack is reachable because a guardrail is absent — and that is not a footnote to the model, it is missingGuardrail(Agent, 'inputSanitization'), a literal term in the rule. It is a literal node in the graph, too: in the paper’s Trip Planner attack graph (Figure 3), fact (14): missingGuardRail(citySelection, inputSanitization) is one of the preconditions feeding (13): RULE 0, the rule that makes the first agent injectable. In attack-graph logic a rule with an unmet precondition does not fire, and a rule that does not fire produces no downstream fact — which means the edges leading out of it never appear. So in ATAG’s own formalism, adding an input-sanitization guardrail to an agent boundary does something precise and visible: it removes edges from the attack graph. The chain that reached the goal now stops one node short. The guardrail is the missing node — not as a metaphor, as fact 14.

Both case studies run through the boundaries

ATAG is evaluated on two testbed applications, and the reason they are worth walking through is that every step in both chains is data crossing an edge — an agent boundary, a tool call, a shared store. That is the same set of crossings MoorAI is built to watch: its interception stages are prompt, file, output, index, session and tool. The mapping below — the stage each step touches, and the shipped MoorAI rule that would fire on it — is ours, not the authors’; the rule numbers are entries in MoorAI’s published threat rule-base. We did not run MoorAI against ATAG’s testbeds; the only measured figure on this page is the 12-of-12 below.

Case study 1 — the Trip Planner

A sequential three-agent app: City Selection hands to Travel Research hands to Itinerary Generation. The attack is a single poisoned link that rides the data flow all the way to the output.

The attack goal is misinformation. What makes it instructive is that no single agent does anything obviously wrong — the harm is assembled from data moving across three boundaries. Watch the boundaries and the chain has nowhere to hide.

Case study 2 — the Automated Email Responder

A hierarchical app: an Orchestrator drives a Fetcher, a Categorizer and a Prioritizer, then a Drafter. This chain has two goals — leak the instructions, then exfiltrate the data — and it takes two emails to do it.

Note the last step: the Drafter uses legitimate permissions to do the exfiltration. There is no privilege escalation and no malformed request to catch — the tool call is well-formed and authorised, and only its resolved effect is harmful. That is precisely the case a control at the tool boundary is for, and why arguing with the model earlier in the chain is not enough. It is the same reasoning behind MoorAI’s action layer: 12 of 12 malicious tool calls stopped in our own testing after a jailbreak had already succeeded, under an enforcing policy on Claude Code. It is a related argument — MoorAI’s numbers are ours and unconnected to ATAG — but the shape is the same.

Assessment and enforcement are different jobs

It would be easy, and wrong, to blur ATAG and MoorAI into the same thing. They sit at opposite ends of the same problem, and both ends are needed.

A model that maps your attack surface and a control that enforces on it are complementary, not competing. You would want the first to know where to place the second. Nothing in ATAG endorses that pairing — it is simply where their logic and our product happen to meet.

The catalogue idea worth stealing

ATAG is backed by the LLM Vulnerability Database (LVD) — published openly — 44 records across 37 LLM versions at publication, drawn from three prior papers plus the authors’ own implementations. Each record is richly structured — an attack procedure and description, the LLM version, an OWASP-based vulnerability category such as “Sensitive Information Disclosure” or “System Prompt Exfiltration,” a MITRE ATLAS tactic and technique, tool type and permissions, a CIA impact, an attack success rate, a CVSS severity and a source.

A boundary control that mapped what it observed to a shared, OWASP- and ATLAS-tagged catalogue like that — so a blocked action came out labelled in a vocabulary a security team already uses — is a genuinely good idea, and one worth doing. We are naming it as an aspiration, not a shipped feature: MoorAI does not consume the LVD today, and the LVD is the authors’ work, not ours.

What ATAG does not yet claim

The paper is candid about its own limits, and repeating them here is the honest thing to do — an assessment framework in its early days is not a finished product any more than a benchmark is.

None of that weakens the one observation this post rests on. Whether ATAG has been run on two apps or two hundred, its rule for a prompt-injection attack still carries “no input-sanitization guardrail” as a precondition — and a control on that boundary still removes the edge. That is a statement about the model’s structure, and it holds at any scale.

ATAG is the work of Gandhi, Shukla, Tayouri, Ifland, Elovici, Puzis and Shabtai at Ben-Gurion University of the Negev — preprint at arXiv:2506.02859, published version doi:10.1145/3779208.3785380 (ACM AsiaCCS ’26). MoorAI is content-free, open-core (AGPL-3.0) security for AI agents, enforced at the action layer on the developer’s endpoint; all MoorAI figures are our own measurements, self-reported. See also: Prompt injection: content scanning won’t stop it and Obfuscated prompts beat content scanning.