arXiv:2605.10763v1 [cs.AI] 11 May 2026
MATRA: Modeling the Attack Surface of Agentic AI Systems OpenClaw Case Study Tim Van hamme, Thomas Vissers, Javier Carnerero-Cano, Mario Fritz, Emil C. Lupu, Lieven Desmet, Dinil Mon Divakaran∗†
Abstract
1
LLMs are increasingly deployed as autonomous agents with access to tools, databases, and external services, yet practitioners (across different sectors) lack systematic methods to assess how known threat classes translate into concrete risks within a specific agentic deployment. We present MATRA, a pragmatic threat modeling framework for agentic AI systems that adapts established risk assessment methodology to systematically assess how known LLM threats translate into deployment-specific risks. MATRA begins with an asset-based impact assessment and utilizes attack trees to determine the likelihood of these impacts occurring within the system architecture. We demonstrate MATRA on a personal AI agent deployment using OpenClaw, quantifying how architectural controls such as network sandboxing and leastprivilege access reduce risk by limiting the blast radius of successful injections.
Large Language Models (LLMs) are increasingly being embedded into enterprise software systems that ingest untrusted content and produce operational decisions, recommendations, or even executable plans. In these LLM-integrated applications, security failures are increasingly driven not only by the behavior of the model in isolation, but by how model outputs are connected to, e.g., privileged tools, databases, retrieval pipelines, and downstream services [1]. Recently, researchers have demonstrated a growing catalogue of LLM safety and security failures, including jailbreaking and prompt injection, and the ecosystem has responded with guardrails [2, 3, 4], automated red-teaming methods [5, 6, 7], and benchmarks for attacks and defenses [8, 9]. Yet, a persistent disconnect remains between vulnerability-centric evaluations and the concrete risks faced by enterprises deploying LLMs in real business workflows, where harm is realized only after a model failure propagates through application logic and connected assets [10, 11]. Prompt injection is now widely recognized as a practical and difficult-to-mitigate attack [12] in LLMintegrated systems. Beyond direct user-to-model injections, indirect prompt injection can be delivered via retrieved documents or tool outputs, allowing adversaries to influence an application without a direct interface [13]. This risk is amplified in agentic workflows, where an LLM iteratively plans and executes tool calls: agentic pipelines blur the boundary between instructions and data [14], making agents susceptible to being steered by untrusted contents they
∗ Tim Van hamme, Thomas Vissers and Lieven Desmet are with DistriNet, KU Leuven, 3001 Leuven, Belgium ({tim.vanhamme, thomas.vissers, lieven.desmet}@kuleuven.be), Javier Carnerero-Cano with IBM Research ([email protected]), Mario Fritz with CISPA Helmholtz Center for Information Security ([email protected]), Emil C. Lupu with Imperial College London ([email protected]) and Dinil Mon Divakaran with A*STAR Institute for Infocomm Research ([email protected]). † Accepted for presentation at the 5th International Workshop on Designing and Measuring Security in Systems with AI (DeMeSSAI 2026), co-located with the 11th IEEE European Symposium on Security and Privacy (EuroS&P 2026), Lisbon, Portugal, July 10, 2026.
1
Introduction
process as part of the task. Recent benchmarks show that attacks can succeed at multiple stages of the agentic loop and existing defenses provide limited and inconsistent protection [12, 15, 16]. A fundamental constraint underlies these threats: prompt injection is functionally equivalent to delivering new instructions to the LLM, much as code injection delivers executable instructions to a computer. Existing defenses can reduce the probability of successful injection or potentially detect the injection, but cannot eliminate it [12, 17, 18]. Moreover, the attack surface extends beyond a single promptresponse interaction—persistent components such as system prompts, long-term memory, and retrievalaugmented generation (RAG) knowledge bases can be targeted for long-horizon influence and crosssession compromise [19]. In response, the community has produced valuable taxonomies and governance guidance for GenAI risks, including the OWASP Top 10 for LLM Applications [20], the OWASP Agentic AI Threats and Mitigations guide [21], as well as NIST’s profile for generative AI risks [22]. However, these resources primarily describe what classes of issues exist. Enterprises still lack a systematic framework to (i) ground threats in a specific deployed workflow, (ii) trace paths from impact scenarios to concrete attack vectors across tools, memory, and retrieval components, and (iii) prioritize mitigations based on business impact. We address this gap with MATRA1 (Modeling Attacks and Threats for Risk Assessment), an impact-driven threat and risk modeling framework for agentic AI systems. MATRA is inspired by NIST SP 800-30 risk assessment concepts [23] and models system risks by constructing attack trees that connect CIA-based impact scenarios to attacker objectives, techniques, and architecture-specific vectors. MATRA captures not only on adversarial manipulation but also non-adversarial pathways in which unexpected LLM behavior combines with autonomous tool execution to produce high-impact outcomes. We demonstrate MATRA on OpenClaw, an opensource single-agent, multi-tool personal assistant architecture that integrates messaging channels, high-
privilege tools (shell, file I/O, web), and persistent memory [24]. Our case study shows how architectural patterns determine the feasible attack surface and how controls can be evaluated for risk reduction from two complementary perspectives: (i) the weakest-link (easiest-path) risk; and (ii) the full-attack surface exposure across feasible vectors.
2
MATRA: Threat and Risk Modeling Framework
MATRA framework is inspired by NIST Special Publication 800-30, “Guide for Conducting Risk Assessments” [23]. We demonstrate it using a semiquantitative approach to risk assessment, where structured scales translate expert judgment into ratings that enable relative risk comparison and prioritization while remaining accessible to decision-makers. Other assessment approaches, e.g., fully quantitative or purely qualitative, can be used within MATRA. The assessment is impact-oriented: it begins with the identification of critical assets and the business impacts of concern, then traces backward to the threat events and sources that could cause those impacts. This ensures that vulnerabilities and adversarial actions are examined in the context of their potential to create unacceptable outcomes rather than in isolation. Figure 1 summarizes the framework’s information flow. A practitioner proceeds through four stages: system analysis, impact assessment, attack tree construction, and risk quantification.
2.1
System Analysis
The assessment begins by collecting system properties from the stakeholder: architecture documentation, source code, deployment configurations, and any existing security documentation. From these inputs, the practitioner constructs a data flow diagram (DFD) that maps processes, data stores, external actors, and trust boundaries. The DFD serves two purposes. First, it identifies the system’s assets, i.e., the critical resources requiring protection, such as databases, credentials, user
1 Mātrā in Sankskrit denotes measure, quantify, etc.
2
Figure 1: MATRA framework overview. System properties and threat sources are collected from the client. Assets identified from system documentation feed into a stakeholder-driven business impact assessment, which produces impact scenarios. A data flow diagram (DFD), combined with known attack techniques from established catalogs, informs the construction of attack trees that decompose each impact scenario into objectives, techniques, and architecture-specific vectors. data, and integration interfaces. Systematically identifying assets is a prerequisite for the impact assessment that follows, as it enables the direct mapping of potential impact scenarios to specific system components. Second, the DFD exposes the system’s communication paths and trust boundaries, which later inform the identification of concrete attack vectors.
by [threat source]?” Impact is rated on a three-grade scale: Low: Disruption, financial loss, or reputation harm is limited. Mitigation is quick and recovery is straightforward. Moderate: Disruption or losses are noticeable. Recovery requires effort and additional resources. High: Major disruption of operations, significant financial losses or reputation harm. Recovery is prolonged or potentially impossible. 2.2 Impact Assessment From this matrix, the practitioner derives impact scenarios that are distinct, architecturally viable adWith assets identified, the practitioner selects the verse outcomes, rated at the highest assessed level threat sources relevant to the deployment. Threat across threat sources. Each impact scenario names sources are entities or conditions capable of exploita specific asset, a CIA dimension, and the concrete ing vulnerabilities within the system; ranging from harm (e.g., “customer PII exfiltrated from the pronation-state actors and competitors to insiders and duction database”). accidental causes (see Appendix B for the full taxonomy adapted from NIST SP 800-30 [23]). Only threat sources with credible motivation and a viable 2.3 Attack Tree Construction access path to the system under review are retained To connect impact scenarios to concrete threats, the for analysis; this scoping step filters out actors that practitioner builds attack trees [25]—hierarchical lack intent or a realistic targeting path. diagrams that decompose high-level impacts into conFor each retained threat source, or per threat trollable, architecture-specific attack paths. The source category when impact is independent of the nodes of an attack tree are: attacker’s identity, the stakeholder assesses business impact across the CIA triad—confidentiality, in• Root: The impact scenario. Focusing on the tegrity, and availability—for every asset in scope: most consequential impacts helps manage scale. “What is the business impact if this asset’s [con• Attack Objectives: One or more high-level fidentiality / integrity / availability] is compromised 3
goals that must be achieved to realise the impact Within each objective the most favourable (high(e.g., LLM behavioural manipulation combined est) vector likelihood is chosen, reflecting that an atwith data exfiltration). tacker will pursue the path of least resistance. Across objectives the overall scenario likelihood is the weak• Attack Techniques: Methods to achieve an est link, i.e., the minimum of those maxima, because objective such as indirect prompt injection. every objective must succeed for the impact to occur. An impact scenario’s risk is Risk = Likelihood × • Attack Vectors: Concrete instances of a technique in the system architecture, e.g., indirect Impact, where qualitative levels (low, moderate, high) combine into a final rating from very low to prompt injection via a support email. very high via Table 3 (Appendix A). We draw mitigaThe practitioner constructs trees in three stages. tion decisions from two complementary perspectives: First, each impact scenario is decomposed into (i) weakest-link risk, which measures the single easiest one or more attack objectives. Second, well- attack path an adversary is most likely to exploit first established LLM-specific threat repositories (or that is most likely to manifest non-adversarially); from, say, OWASP [20, 21, 26], MITRE [27], and (ii) full attack surface, which captures total expoNIST [22] CSA [28], and Cisco [29] are consulted sure across all feasible vectors, revealing cases where alongside the DFD and system model to select the multiple comparable paths create material risk even most relevant attack techniques and to identify if no single path dominates. Using both perspectives existing security controls. Third, each technique is ensures that defences address not only the most obmapped to the concrete attack vectors present in the vious entry point but also the full spectrum of exapplication architecture, informed by the different ploitable opportunities. paths in DFD and the trust boundaries. This method ensures that each attack tree reflects both recognised industry threats and the specific ar3 Use Case: Personal AI Agent chitecture of the system under review.
2.4
We demonstrate MATRA on OpenClaw, an open-source personal AI agent that follows a single-agent, multitool architecture: one LLM agent with simultaneous access to shell execution, file I/O, web browsing, cross-channel messaging, and persistent memory [24]. We model a solo developer using OpenClaw as a productivity tool for their SaaS booking platform, with an email plugin for customer support. The full deployment scenario, data flow diagrams, asset inventory, threat source selection, and complete attack trees are provided in Appendix C. From the full assessment, we select one threat source–impact combination to illustrate MATRA’s endto-end process: a malicious customer (threat source) targeting the confidentiality of customer PII (business impact). This combination is compelling because the threat source has a natural, legitimate access channel, i.e., customer support email, and requires no technical sophistication beyond crafting a convincing message with embedded instructions.
Risk Quantification
For each attack vector, likelihood is derived in two steps. First, capability fit compares the threat source’s technical capability with the skill level required for the vector, using Table 1 (Appendix A); because the scoping step in Section 2.2 already filters for intent and targeting, capability remains the discriminating factor at the vector level. For non-adversarial threats, capability does not apply; instead, each vector receives an inherent manifestation likelihood reflecting the probability of the event occurring independently of any actor (e.g., hallucination probability). Second, residual success likelihood estimates the probability that the vector succeeds given existing security controls; a vector with no applicable controls receives a high residual likelihood, while effective controls reduce it. The overall vector likelihood is obtained by combining these two values via the combination matrix (Table 2, Appendix A). 4
3.1
Deep Dive: Malicious Customer × they reach the messaging channel. With both controls in place, all exfiltration vectors are reduced to Customer PII Confidentiality
Low, yielding Moderate risk. The injection objective remains at High regardless—customer emails are expected input that the agent is designed to process.
In this scenario (IS6 in Table 5), a malicious customer exploits the agent’s email channel to exfiltrate other customers’ PII (personally identifiable information) and booking records, following the indirect prompt injection pattern demonstrated by Zhao et al. [30]. Two objectives must jointly succeed: LLM behavioral manipulation (redirecting the agent’s actions) and data exfiltration (transmitting customer records outside the trust boundary). The attacker sends a support email with hidden instructions embedded in an attachment (e.g., via HTML comments or zero-width Unicode characters). When the agent processes the email, the injected instructions direct it to query customer records via the exec tool and exfiltrate the results through toolbased channels (curl, email) or rendered-markup channels (embedding data in a markdown image URL that the Telegram client auto-fetches). The entire chain executes within a single agent turn.
3.2
Key Observations
Prompt Injection and Architectural Defense Prompt injection is functionally equivalent to delivering new instructions to the LLM: like code injection in traditional systems, the injected payload executes with whatever capabilities the host process provides. Because current defenses can reduce but not eliminate the probability of successful injection [12], the impact of an attack is ultimately determined by what the agent can do with the tools, integrations, and permissions available to it. This has a direct consequence for risk mitigation. Rather than relying primarily on input-level defenses (prompt injection detectors, guardrails), the most effective controls are architectural : sandboxing that limits network access, allow-listing that restricts which tools and commands the agent may invoke, and least-privilege configurations such as read-only database roles. The IS8 analysis (Appendix C.8) demonstrates this clearly: a read-only database role eliminates the action execution objective entirely, reducing risk from High (6) to Moderate (3). However, the IS6 analysis reveals that no single architectural control is sufficient when multiple exfiltration channels exist—container sandboxing blocks execbased vectors but leaves message-based and renderedmarkup vectors unaffected. Effective defense requires layered architectural controls that address each exfiltration category.
Attack Tree with Likelihood Scores We assess this scenario under two control configurations: (a) default unsandboxed deployment, and (b) Docker sandboxing enabled (network=none). The resulting attack tree is shown in Figure 2. Risk Assessment Impact is rated High due to the regulatory implications of customer PII disclosure. Without sandboxing, the scenario reaches Very High risk (9). Docker sandboxing with network=none blocks exec-based exfiltration (curl) but does not reduce the overall exfiltration objective: the message tool runs on the gateway host outside the container, so email-based exfiltration remains viable, and the agent’s Telegram response can embed queried data in a markdown image URL that the client autofetches (zero-click). The scenario therefore remains at Very High (9) even with sandboxing. Reducing IS6 to Moderate (3) requires controls that address the surviving exfiltration vectors: an email allow-list that restricts outbound recipients, and output sanitisation that strips or rewrites URLs containing encoded data from agent responses before
Non-Adversarial Threats Autonomous tool execution creates a qualitatively new risk category: highimpact scenarios requiring no attacker. As demonstrated in the IS8 analysis (Appendix C.8), a hallucinated UPDATE with a missing predicate can corrupt customer booking records, trigger erroneous refunds, and produce incorrect reports—all from a routine developer request. In traditional systems, integrity impacts of this magnitude typically require adversarial 5
IS6: Customer PII and booking records exfiltrated Default: High = min(High, High) Sandboxed: High = min(High, High) Obj: LLM Behavioural Manipulation Default: High = max(High, High) Sandboxed: High = max(High, High) Tech: Indirect Prompt Injection Vec: support email with attachment High (capfit: High → res: High → High) High (capfit: High → res: High → High)
Vec: support email body High (capfit: High → res: High → High) High (capfit: High → res: High → High)
Obj: Data Exfiltration Default: High = max(High, High, High, Mod) Sandboxed: High = max(Low, High, High, Mod) Tech: Tool-based Exfiltration Vec: exec: curl to attacker High (capfit: Mod → res: High → High) Low (capfit: Mod → res: Low → Low)
Vec: message: email to attacker High (capfit: High → res: High → High) High (capfit: High → res: High → High)
Tech: Rendered-Markup Exfiltration Vec: Telegram: image with data in URL High (capfit: High → res: High → High) High (capfit: High → res: High → High)
Vec: Telegram: link with data in URL Mod (capfit: Mod → res: Mod → Mod) Mod (capfit: Mod → res: Mod → Mod)
Figure 2: Attack tree for IS6 (customer data exfiltration; refer Table 5), assessed for threat source: malicious customer (capability: Low). Likelihood scores shown under default configuration (red) and with Docker sandboxing (blue). Vector labels follow the format capfit: capability fit → res: residual success likelihood → combined likelihood (see Tables 1 and 2). Sandboxing blocks exec-based network access (res: Low for curl) but does not affect message-based or rendered-markup vectors, which operate outside the container (res: High); the link vector’s requirement for a user click partially reduces success likelihood (res: Mod). vector classes. Several limitations point to future work. Attack tree completeness is bounded by an analyst’s knowledge and the threat catalogs consulted. However, the hierarchical structure makes gaps localizable; when a new technique emerges, the affected objectives and impact scenarios are immediately identifiable. MATRA currently relies on expert judgment for likelihood assignment; we bound this subjectivity through deliberately coarse scales and auditable per-node ratings, but integrating empirical data from red-teaming benchmarks or operational logs could improve calibration. Furthermore, the min-max composition heuristic may underestimate risk when multiple moderate paths interact; the full attack surface perspective partially addresses this, but formal composition under uncertainty is a future direction. MATRA has been demonstrated on a single-agent architecture; applying it to multi-agent orchestrations with inter-agent communication would test its scalability and may require extensions to model cross-agent propagation paths. Finally, our assessment does not address privacy-specific threat modeling (e.g., LINDDUN[33]), which is an important complementary dimension for systems processing personal data.
action. In agentic systems, the LLM’s imperfect reasoning combined with unrestricted tool access means that normal usage can trigger destructive operations. This has implications for risk frameworks: accidental threat sources must be assessed with the same rigor as adversarial ones when the system has autonomous execution capabilities.
4
Conclusions
We presented MATRA, an impact-driven threat and risk modeling framework for agentic AI systems. MATRA provides a structured process comprising system analysis, stakeholder-driven impact assessment, attack tree construction informed by established threat catalogs, and risk quantification. They connect high-level business impacts to architecturespecific attack vectors. Inspired by NIST SP 800-30 and grounded in data flow analysis, MATRA enables practitioners to move beyond generic vulnerability lists toward deployment-specific risk prioritization. Our case study on OpenClaw reinforces a central insight: because prompt injection cannot be eliminated [12], the most effective risk reduction comes from limiting what injected instructions can achieve through layered architectural controls via Acknowledgments This research is partially dedicated planner and executer LLMs [31, 32], sand- funded by the Internal Funds KU Leuven, and by boxing, allow-listing, output sanitisation, and least- the Cybersecurity Research Program Flanders. privilege configurations, each addressing different This research is also supported by the National 6
Research Foundation, Singapore, and the Cyber Security Agency of Singapore under the National Cybersecurity R&D Programme (NCR25-CRPO-0001) and the CyberSG R&D Programme Office (Award CRPO-GC5-ASTAR-001). Any opinions, findings, conclusions, or recommendations expressed in these materials are those of the author(s) and do not reflect the views of the National Research Foundation, Singapore, the Cyber Security Agency of Singapore, or the CyberSG R&D Programme Office. Last but not the least, the authors thank Schloss Dagstuhl – Leibniz Center for Informatics for hosting Seminar 25461 on “Security and Privacy of Large Language Models,” 2 and its organizers and participants for stimulating discussions that sharpened this work.
[6] L. Derczynski, E. Galinkin, J. Martin, S. Majumdar, and N. Inie, “garak: A framework for security probing large language models,” 2024. [7] A. Zou, Z. Wang, J. Z. Kolter, and M. Fredrikson, “Universal and transferable adversarial attacks on aligned language models,” 2023. [8] E. Debenedetti, J. Zhang, M. Balunovic, L. Beurer-Kellner, M. Fischer, and F. Tramèr, “Agentdojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents,” in The Thirty-eight Conference on Neural Information Processing Systems Datasets and Benchmarks Track, 2024. [9] P. Chao, E. Debenedetti, A. Robey, M. Andriushchenko, F. Croce, V. Sehwag, E. Dobriban, N. Flammarion, G. J. Pappas, F. Tramèr, H. Hassani, and E. Wong, “Jailbreakbench: An open robustness benchmark for jailbreaking large language models,” in NeurIPS Datasets and Benchmarks Track, 2024.
References [1] Meta AI, “Agents rule of two: A practical approach to AI agent security.” Meta AI Blog, Oct. 2025. Accessed: 2026-03-16.
[10] Hack The Box, “Inside CVE-2025-32711 (EchoLeak): Prompt injection meets AI exfiltration.” Hack The Box Blog, 2025. Accessed: 202603-16.
[2] ProtectAI.com, “Fine-tuned DeBERTa-v3-base for prompt injection detection.” Hugging Face Model Hub, 2024. [3] Google, “Model armor overview.” Google Cloud Documentation, 2025.
[11] S. Willison, “The summer of johann: Prompt injections as far as the eye can see.” Simon Willison’s Weblog, Aug. 2025. Part of the series [4] S. Chennabasappa, C. Nikolaidis, D. Song, Prompt Injection. Accessed: 2026-03-16. D. Molnar, S. Ding, S. Wan, S. Whitman, L. Deason, N. Doucette, A. Montilla, A. Gampa, [12] M. Nasr, N. Carlini, C. Sitawarin, S. V. SchulB. de Paola, D. Gabi, J. Crnkovich, J.-C. Testud, hoff, J. Hayes, M. Ilie, J. Pluto, S. Song, K. He, R. Chaturvedi, W. Zhou, and J. Saxe, H. Chaudhari, I. Shumailov, A. Thakurta, K. Y. “LlamaFirewall: An open source guardrail sysXiao, A. Terzis, and F. Tramèr, “The Attem for building secure AI agents.” arXiv tacker Moves Second: Stronger Adaptive Atpreprint, May 2025. tacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections.” https://arxiv.org/ [5] A. Mehrotra, M. Zampetakis, P. Kassianik, abs/2510.09023, 2025. B. Nelson, H. S. Anderson, Y. Singer, and A. Karbasi, “Tree of attacks: Jailbreaking black[13] K. Greshake, S. Abdelnabi, S. Mishra, C. Enbox LLMs automatically,” in The Thirty-eighth dres, T. Holz, and M. Fritz, “Not what you’ve Annual Conference on Neural Information Prosigned up for: Compromising real-world llmcessing Systems, 2024. integrated applications with indirect prompt 2 https://www.dagstuhl.de/25461 injection,” in Proceedings of the 16th ACM 7
Workshop on Artificial Intelligence and Security, [21] OWASP Agentic Security Initiative, “Agentic AISec ’23, (New York, NY, USA), p. 79–90, AsAI – Threats and Mitigations,” security guide, sociation for Computing Machinery, 2023. OWASP Foundation, February 2025. First guide from the OWASP Agentic Security Initia[14] E. Zverev, S. Abdelnabi, S. Tabesh, M. Fritz, tive providing a threat-model-based reference of and C. H. Lampert, “Can llms separate instrucemerging agentic threats and mitigations. Covtions from data? and what do we even mean by ers autonomous AI systems enabled by large lanthat?,” in Thirteenth International Conference guage models, with structured threat taxonomy on Learning Representations (ICLR), 2025. covering Agent Design, Agent Memory, Planning & Autonomy, Tool Use, and Deployment & Op[15] J. Shi, Z. Yuan, G. Tie, P. Zhou, N. Z. Gong, erations. Expands on the OWASP Top 10 for and L. Sun, “Prompt injection attack to tool seLLMs and GenAI to address the unique security lection in LLM agents,” in NDSS, 2026. challenges of agentic AI systems. [16] R. Wang, Y. Jia, and N. Z. Gong, “ObliIn[22] National Institute of Standards and Technology, jection: Order-Oblivious Prompt Injection At“Artificial intelligence risk management frametack to LLM Agents with Multi-source Data,” work: Generative artificial intelligence profile,” in NDSS, 2026. Tech. Rep. NIST AI 600-1, National Institute of Standards and Technology, July 2024. [17] N. V. Pandya, A. Labunets, S. Gao, and E. Fernandes, “May I have your attention? breaking [23] NIST, “Guide for conducting risk assessments,” fine-tuning based prompt injection defenses usTech. Rep. SP 800-30 Rev. 1, National Institute ing architecture-aware attacks,” arXiv preprint of Standards and Technology, 2012. arXiv:2507.07417, 2025. [18] S. Abdelnabi, A. Fay, G. Cherubin, A. Salem, [24] P. Steinberger and OpenClaw Contributors, “OpenClaw: Your own personal AI assistant. M. Fritz, and A. Paverd, “Get my drift? catching any OS. any platform..” https://github.com llm task drift with activation deltas,” in IEEE /openclaw/openclaw, 2025. Accessed: 2026-03Conference on Secure and Trustworthy Machine 16. Learning (SaTML), 2025. [19] D. Goodin, “New hack uses prompt injection to [25] B. Schneier, “Attack trees,” December 1999. Accessed: 2025. corrupt Gemini’s long-term memory.” Ars Technica, Feb. 2025. Accessed: 2026-03-16. [26] OWASP GenAI Security Project, “OWASP top [20] OWASP Foundation, “OWASP Top 10 for 10 for agentic applications for 2026.” OWASP Large Language Model Applications,” 2025. Foundation, https://genai.owasp.org/reso A community-driven standard awareness docurce/owasp-top-10-for-agentic-applicati ument identifying the top 10 most critical seons-for-2026/, Dec. 2025. Developed through curity risks to Large Language Model (LLM) collaboration with more than 100 industry exapplications, including prompt injection, sensiperts. Accessed: 2026-03-16. tive information disclosure, supply chain vulnerabilities, data poisoning, improper output han- [27] MITRE Corporation, “MITRE ATLAS™: dling, system prompt leakage, vector and embedAdversarial threat landscape for artificialding vulnerabilities, misinformation, unbounded intelligence systems.” MITRE Corporation, consumption, and excessive agency. Part of the 2025. Living knowledge base; accessed: 2026OWASP GenAI Security Project. 03-16. 8
[28] Cloud Security Alliance, “Introductory guidance Table 2: Combination matrix for deriving overall vecto AICM: The AI controls matrix.” Cloud Secutor likelihood from capability fit (rows) and residual rity Alliance, Nov. 2025. Accessed: 2026-03-16. success likelihood (columns). [29] Cisco, “Cisco AI defense: Integrated AI security and safety framework.” Cisco Systems, Inc., ht tps://www.cisco.com/site/us/en/learn/t opics/artificial-intelligence/ai-secur ity-safety-framework.html, 2025. Accessed: 2026-03-16.
Res. likelihood Capability
Low
Mod
High
Low Mod High
Low Low Mod
Low Mod High
Mod High High
[30] A. Zhao, “Why OpenClaw poses new AI-era seB Threat Source Taxonomy curity risks.” https://aaronzhao123.substac k.com/p/why-openclaw-poses-new-ai-era-s MATRA adopts the threat source taxonomy from ecurity, 2025. Substack. NIST SP 800-30 [23], which distinguishes adversarial and non-adversarial sources. Adversarial sources [31] E. Debenedetti, I. Shumailov, T. Fan, J. Hayes, are characterised by capability, intent, and targetN. Carlini, D. Fabian, C. Kern, C. Shi, A. Terzis, ing; non-adversarial sources are characterised by the and F. Tramèr, “Defeating prompt injections by range of effects and inherent likelihood of occurrence. design.” https://arxiv.org/abs/2503.18813, Table 4 summarises the taxonomy with examples rel2025. evant to agentic AI deployments. The practitioner selects threat sources from this [32] M. Costa, B. Köpf, A. Kolluri, A. Paverd, M. Russinovich, A. Salem, S. Tople, taxonomy based on credible motivation and a viL. Wutschitz, and S. Zanella-Béguelin, “Se- able access path to the system under review (see curing ai agents with information-flow control,” Section 2.2). For example, an agentic system exposed to customer email may warrant a customer 2025. (organisation-level adversarial) source, while a sys[33] L. Sion, D. Van Landuyt, K. Wuyts, and tem with autonomous tool execution should always W. Joosen, “Robust and reusable linddun pri- include an accidental (non-adversarial) source to acvacy threat knowledge,” Computers & Security, count for hallucination-driven impacts. vol. 154, p. 104419, 2025.
A
C
OpenClaw: Full Case Study
C.1
Deployment Scenario
Risk Quantification Matrices We model a realistic deployment in which a solo developer runs a small B2B SaaS product—an online booking platform—and uses OpenClaw on their personal workstation as a productivity tool. The product’s PostgreSQL database serves the web application, a background worker for payment processing, and a reporting dashboard; it is the single source of truth for customer data, bookings, and invoices. The developer interacts with the agent primarily via Telegram, issuing day-to-day instructions such as “check
Table 1: Capability fit lookup: adversary capability (rows) versus vector skill requirement (columns). Skill Req. Capability
Low
Mod
High
High Mod Low
High High High
High High Mod
High Mod Low
9
Table 3: Risk Assessment Matrix
Likelihood
Impact Low
Moderate
High
High
Moderate (3)
High (6)
Very High (9)
Moderate
Low (2)
Moderate (4)
High (6)
Low
Very Low (1)
Low (2)
Moderate (3)
Table 4: Threat source taxonomy adapted from NIST SP 800-30 [23]. Type Adversarial Individual Group Organisation Nation-State
Examples
I/O), message (cross-channel messaging), memory_search/memory_get (long-term memory). • Database access: The production PostgreSQL database, shared with the web application and background workers; the agent queries it by running psql commands via the exec tool.
Outsider, insider, privileged insider Ad hoc, established Competitor, supplier, partner, customer State-sponsored actor
• Workspace: ~/.openclaw/workspace/ containing product source code, configuration files, and a .env file with database credentials and API keys.
Non-adversarial Accidental User error, automated process failure
• Sandboxing: Off (default configuration). the latest sign-ups,” “why is customer X getting errors,” or “deploy the fix to staging.” An email plugin allows the agent to read and reply to customer support messages on the developer’s behalf. The workspace contains the product’s source code, deployment scripts, and a .env file with production database credentials and third-party API keys. This deployment is configured as follows:
This scenario is directly grounded in OpenClaw’s documented capabilities and default configuration. The addition of email is motivated by its prevalence as a community extension and its role as a highvalue attack surface demonstrated in recent security research [30].
C.2
Assets and Impact Scenarios
Following the process in Section 2.1, we identify • Messaging channels: Telegram (primary inseven assets from the DFD (Figure 3): API creterface for instructing the agent) and email (via dentials (A1), messaging accounts (A2), workspace community extension plugin, for reading and files (A3), conversation history and memory (A4), the sending customer support email). agentic application (A5), the production PostgreSQL • LLM provider: Anthropic Claude, database (A6), and the platform’s end users (A7). accessed via API key stored in The database is particularly critical: it is shared with the web application, payment processing worker, ~/.openclaw/credentials/. and reporting dashboard, making it the single source • Tools enabled: exec (shell com- of truth for customer PII, bookings, and invoices. mands), browser (Playwright-based web End users are an asset because the agent can send automation), read/write/edit (file messages on the developer’s behalf—an attacker who 10
compromises the agent can use this trusted channel to phish customers for their credentials. Applying the impact assessment process from Section 2.2, we assess each asset against the CIA triad for each threat source. The full impact matrix is provided in Table 6. From this matrix, we derive nine distinct impact scenarios, presented in Table 5. Eight of the nine scenarios are rated High impact, reflecting the deployment’s broad attack surface and the sensitivity of the connected assets.
C.4
Attack Tree Construction
Following the process in Section 2.3, we construct attack trees in three stages: impacts to objectives, objectives to techniques, and techniques to architecturespecific vectors. Each impact scenario decomposes into two objectives that must both succeed. For adversarial confidentiality impacts, these are LLM behavioural manipulation (redirecting the agent’s actions) and data exfiltration (transmitting data outside the trust boundary). For integrity impacts, the second objective becomes unauthorized action exeC.3 Threat Source Selection cution—reflecting OpenClaw’s broad write access to shell, files, messaging, and database. For availabilFollowing the process in Section 2.2, we select ity, it becomes excessive resource consumption. Nonfour threat sources from the NIST taxonomy (Ap- adversarial paths mirror this structure, with unexpendix B, Table 4) whose capability and access real- pected LLM behaviour (hallucination) replacing deistically intersect with the deployment’s attack sur- liberate manipulation. face: Two architectural features shape the resulting trees. First, OpenClaw supports two categories of • Malicious customer (Organisation → Cus- exfiltration techniques: tool-based exfiltration, where tomer; low capability): exploits the support the agent explicitly invokes a tool to transmit data email channel—a natural, legitimate access (e.g., exec: curl, message: email, Figure 9), path—to inject instructions into the agent’s con- and rendered-markup exfiltration, where the agent text. This is the most realistic adversarial threat embeds queried data in a URL within its Telegram resource due to the combination of low barrier, di- sponse and the client auto-fetches the resource (Figrect access, and clear motivation. ure 10). A critical distinction for sandbox effectiveness is that only exec-based tools run inside the • Competitor (Organisation → Competitor; Docker container; the message tool and browser run moderate capability): targets the customer on the gateway host, meaning their exfiltration vecdatabase or source code via email or poisoned tors survive container-level network isolation. Secweb pages. ond, because Telegram and email are accessible to external parties, direct prompt injection (Figure 7) • Opportunistic outsider (Individual → Out- is a primary concern—unlike systems where the only sider; low–moderate capability): relies on indi- input channel is an authenticated internal chat. Indirect prompt injection via web content the agent rect prompt injection vectors are particularly numerous due to the agent’s broad input surface (Figure 8). encounters during browsing. • Accidental (Non-adversarial; no capability assessment): particularly significant because the agent autonomously executes tool calls without human confirmation. LLM hallucinations can trigger high-impact outcomes—such as corrupted database records—without any malicious input. 11
Not all vectors apply to all scenarios; only architecturally viable combinations are included in each tree. For example, exfiltration vectors do not appear in integrity trees, and expensive query vectors apply exclusively to the database availability scenario. This scoping ensures each tree is realistic and prevents double-counting in aggregate risk assessment. The full trees are provided in Appendix C.7.
database records, or poisoning the agent’s long-term memory. Figure 3 presents the high-level data flow diagram for In OpenClaw’s single-agent architecture, the nonthe OpenClaw deployment, showing processes, data adversarial path deserves particular attention. Bestores, external actors, and trust boundaries. cause the agent autonomously executes tool calls without human confirmation, the bottleneck for C.6 Business Impact Assessment Ma- non-adversarial impacts shifts from action execution trix (which happens automatically) to the hallucination Table 6 presents the stakeholder-assessed business probability itself. The two-objective decomposition impact for each asset and CIA dimension in the correctly captures that both the hallucination and OpenClaw deployment. For availability, the impact the harmful action must co-occur for an impact to is independent of the threat source, so a single rating materialise. is assigned. Cells marked “—” indicate combinations that are not applicable to this deployment. The matrix assesses impact only; the specific threat source’s C.7.2 From Objectives to Techniques capability is introduced during attack tree construction (Section 2.3), where it determines the capability Figure 6 maps each objective to the attack techniques fit for each vector. Not every threat source is assessed applicable in the OpenClaw architecture. against every impact scenario: if a threat source lacks credible intent or a viable targeting path for a given scenario, that combination is excluded from analysis C.7.3 From Techniques to Vectors (see Section 2.2).
C.5
Data Flow Diagrams
C.7
Attack Tree Construction Details for each technique, grounded in the OpenClaw archi-
Figures 7–13 enumerate the concrete attack vectors
This appendix presents the full attack tree decomposition for the OpenClaw deployment, constructed in three stages following the process in Section 2.3. The decomposition proceeds from impacts to objectives (Figures 4 and 5), objectives to techniques (Figure 6), and techniques to architecture-specific vectors (Figures 7–13). C.7.1
From Impacts to Objectives
Figures 4 and 5 show the decomposition of adversarial and non-adversarial impact scenarios into their constituent objectives. The integrity objective reflects OpenClaw’s broad write access. In read-only architectures, integrity impacts are limited to manipulating the text returned to the user. OpenClaw’s single agent has full write access, i.e., shell execution, file I/O, cross-channel messaging, and persistent memory, so integrity impacts extend to system state changes such as modifying files, sending messages as the user, corrupting 12
tecture and its DFD (Figure 3).
C.8
Deep Dive: Database Risks— Availability and Integrity (IS5, IS8)
This deep dive examines two database-related impact scenarios that arise from the agent’s unrestricted SQL access via the exec tool (see Figures 14 and 15 for the full attack trees and Table 7 for the risk scores). Because the production database is shared with the booking platform’s web application, payment processing worker, and reporting dashboard, any disruption or corruption directly affects paying customers. We present IS5 (availability) as a primarily adversarial concern and IS8 (integrity) as a realistic non-adversarial risk. This pairing illustrates how the same asset can be threatened through fundamentally different paths, each requiring different controls.
Table 5: Impact scenarios for the OpenClaw deployment, derived from the business impact assessment (Appendix C.6). ID
Asset
CIA
Impact Scenario
Business Impact
IS1 IS2 IS3 IS4 IS5 IS6 IS7 IS8 IS9
A1 Credentials A2 Messaging A3 Workspace A4 Memory A6 Database A6 Database A5 Agentic App A6 Database A7 End Users
C I C I A C I I C/I
API keys exfiltrated Unauthorized messages sent to customers or contacts Source code / secrets leaked Long-term memory poisoned Booking platform and payments disrupted (heavy queries) Customer PII and booking records exfiltrated Security controls weakened via config change Booking or invoice records corrupted Customers phished via agent-sent messages
High High High Moderate High High High High High
Table 6: Business impact assessment matrix for the OpenClaw deployment. The adversarial column covers all adversarial threat sources, as the business impact of a given compromise is independent of the attacker’s identity. Asset
CIA
Adversarial
Accidental
All (Avail.)
A1 Credentials
C I A
High — —
Low — —
— — —
A2 Messaging
C I A
— High —
— Moderate —
— — —
A3 Workspace
C I A
High High —
— Moderate —
— — —
A4 Memory
C I A
— Moderate —
— Moderate —
— — —
A5 Agentic App
C I A
— High —
— Moderate —
— — Moderate
A6 Database
C I A
High High —
— Moderate —
— — High
A7 End Users
C I A
High High —
— — —
— — —
13
C.8.1
IS5: Booking Platform Disrupted (Ad- arises from the LLM’s imperfect understanding of versarial) the business logic encoded in the database schema.
Objectives. Two objectives must succeed: LLM C.8.3 Full Attack Trees with Likelihood behavioural manipulation (to direct the agent to isScores sue a specific query) and excessive resource consumption (the query must be expensive enough to degrade C.8.4 Risk Assessment availability for all connected services). In the default configuration, IS5 reaches Very High risk (9): both the injection and resource consumpNarrative. An attacker places a crafted instruc- tion objectives are High, and the shared production tion in a web page that the developer asks the database drives impact to High. IS8 reaches High agent to research. The injected instruction directs risk (6) with Moderate likelihood, bottlenecked by the agent to execute a query such as SELECT * the hallucination objective (Moderate inherent probFROM bookings a CROSS JOIN bookings b against ability), while the action execution objective is High the production database via the exec tool (see Fig- because the agent has unrestricted write access. ure 12 for the full set of expensive query vectors). Despite arriving at different default risk levels, This cartesian join produces an exponentially large both scenarios benefit significantly from targeted conresult set, consuming all available database connec- trols, each reducing to Moderate (3). The two scetions and CPU, taking down the booking platform narios require different controls because they are botfor all customers. tlenecked by different objectives. C.8.2
IS8: Booking Records (Non-adversarial)
Corrupted
C.8.5
Objectives. Two objectives must co-occur: unexpected LLM behaviour (the agent generating an incorrect write query) and unauthorized action execution (the query must actually modify data). A hallucinated but syntactically invalid query, or one that is read-only, does not cause an integrity impact; both conditions must be met.
Control Effect Analysis
IS5 and IS8 require different database-level controls, illustrating that the same asset can demand distinct mitigations depending on the CIA dimension under threat. IS5 (Availability). • Query timeout: A PostgreSQL statement_timeout caps resource consumption per query.
Narrative. The developer asks the agent to • Query validation: Running EXPLAIN on gener“mark all unpaid bookings older than 90 days ated queries before execution and rejecting those as cancelled.” The agent generates a syntactiabove a cost threshold. cally valid but semantically incorrect query (see Figure 13)—for example, UPDATE bookings SET • Connection limiting: A PostgreSQL status = ’cancelled’ WHERE created_at < max_connections setting or connection pool now() - interval ’90 days’ omitting the AND limit prevents concurrent session exhaustion. payment_status = ’unpaid’ predicate. The query cancels all bookings older than 90 days, including IS8 (Integrity). paid and confirmed ones. Customers receive erroneous cancellation notifications, the payment worker • Read-only database user: A read-only Postattempts refunds for already-completed transactions, greSQL role eliminates UPDATE, DELETE, and and the reporting dashboard shows incorrect revenue INSERT, reducing the action execution objective figures. No malicious input is required; the impact from High to Low. 14
Table 7: Risk scores for IS5 and IS8 under different control configurations. Scenario
Threat Source
Configuration
Likelihood
Impact
Risk
IS5 IS5
Competitor Competitor
Default + query guardrails
High Low
High High
Very High (9) Moderate (3)
IS8 IS8
Accidental Accidental
Default + read-only DB role
Moderate Low
High High
High (6) Moderate (3)
• Transaction review: Wrapping write queries in BEGIN/ROLLBACK with human confirmation before COMMIT. Notably, Docker sandboxing does not help with either scenario; the database must remain accessible for the tool to function. IS6 (confidentiality) presents a parallel challenge: while sandboxing blocks exec-based exfiltration, message-based and renderedmarkup vectors survive because they run outside the container. All three scenarios illustrate that effective controls must operate at the layer where the threat materialises, i.e., the database layer for IS5 and IS8, and the messaging and output layer for IS6.
15
Trust Boundary: Host Device
Config & Credentials
User via Telegram / email
load
Gateway + Agent (LLM)
messages
Telegram
LLM Provider (Anthropic)
tool calls
Workspace Files rea
Email Server
prompt / response
d/
wr
ite
HTTP
Tool Engine
Web (untrusted)
Docker Sandbox psql
search/store
Memory & Sessions
PostgreSQL Database
Figure 3: High-level DFD of the OpenClaw deployment scenario. The gateway process mediates all interactions between messaging channels, the LLM provider, and the tool engine. Bidirectional arrows on Telegram and email reflect that the gateway both receives inbound messages and sends outbound messages (the message tool runs on the gateway, outside the Docker sandbox). Only the tool engine (exec, file I/O) runs inside the optional sandbox container.
16
Impact: Confidentiality (requires both)
Impact: Integrity (requires both)
Impact: Availability (requires both)
Objective: LLM Behavioural Manipulation Objective: Data Exfiltration Objective: LLM Behavioural Manipulation Objective: Unauthorized Action Execution Objective: LLM Behavioural Manipulation Objective: Excessive Resource Consumption
Figure 4: Adversarial: Impact → Objectives (both required).
Impact: Confidentiality (requires both)
Impact: Integrity (requires both)
Impact: Availability (requires both)
Objective: Unexpected LLM Behaviour Objective: Data Exfiltration Objective: Unexpected LLM Behaviour Objective: Unauthorized Action Execution Objective: Unexpected LLM Behaviour Objective: Excessive Resource Consumption
Figure 5: Non-adversarial: Impact → Objectives (both required). The decomposition mirrors the adversarial case, with “Unexpected LLM Behaviour” replacing “LLM Behavioural Manipulation” as the first objective.
17
Technique: Direct Prompt Injection
Objective: LLM Behavioural Manipulation
Technique: Indirect Prompt Injection Technique: Tool-based Exfiltration
Objective: Data Exfiltration
Technique: Rendered-Markup Exfiltration Objective: Unauthorized Action Execution
Technique: Tool-based Action Execution
Objective: Excessive Resource Consumption
Technique: Expensive Query Execution
Objective: Unexpected LLM Behaviour
Technique: LLM Hallucination
Figure 6: Objectives → Techniques in the OpenClaw architecture. Vector: via Telegram direct message
Technique: Direct Prompt Injection
Vector: via email to agent
Figure 7: Attack vectors for Direct Prompt Injection in OpenClaw. Vector: via email body Vector: via email attachment (.md, .pdf) Technique: Indirect Prompt Injection
Vector: via web page (browser tool) Vector: via poisoned memory (MEMORY.md) Vector: via Telegram group message Vector: via workspace file
Figure 8: Attack vectors for Indirect Prompt Injection in OpenClaw. 18
Vector: exec: curl to attacker endpoint Technique: Tool-based Exfiltration
Vector: browser: HTTP request with encoded data Vector: message: email to attacker address
Figure 9: Attack vectors for Tool-based Exfiltration in OpenClaw.
Vector: Telegram: markdown image with data in URL (zero-click)
Technique: Rendered-Markup Exfiltration
Vector: Telegram: markdown link with data in URL (click required)
Figure 10: Attack vectors for Rendered-Markup Exfiltration in OpenClaw. The agent encodes queried data in a URL embedded in its Telegram response. Telegram auto-fetches image URLs (zero-click); links require user interaction. Vector: exec: modify system configuration Vector: exec: install persistence (crontab, startup scripts) Technique: Tool-based Action Execution
Vector: message: send phishing email/message as user Vector: file write: modify workspace or project files Vector: memory write: poison MEMORY.md or session logs
Figure 11: Attack vectors for Tool-based Action Execution in OpenClaw. Vector: exec: psql with cartesian join Technique: Expensive Query Execution
Vector: exec: psql with full table scan Vector: exec: concurrent psql sessions
Figure 12: Attack vectors for Expensive Query Execution targeting the PostgreSQL database. Vector: incorrect SQL query generation Technique: LLM Hallucination
Vector: unintended shell command Vector: fabricated response to user
Figure 13: Attack vectors for LLM Hallucination in OpenClaw.
19
IS5: Booking platform disrupted Default: High = min(High, High) + query guardrails: Low = min(High, Low) Obj: LLM Behavioural Manipulation High = max(High, High) High = max(High, High)
Obj: Excessive Resource Consumption High = max(High, High, High) Low = max(Low, Low, Low)
Tech: Indirect Prompt Injection
Tech: Expensive Query Execution
Vec: web page (browser) High (capfit: High → res: High → High)
Vec: email attachment High (capfit: High → res: High → High)
Vec: cartesian join High (capfit: Mod → res: High → High) Low (capfit: Mod → res: Low → Low)
Vec: full table scan High (capfit: Mod → res: High → High) Low (capfit: Mod → res: Low → Low)
Vec: concurrent psql sessions High (capfit: Mod → res: High → High) Low (capfit: Mod → res: Low → Low)
Figure 14: Attack tree for IS5 (database availability, adversarial path), assessed for threat source: competitor (capability: Moderate). Vector labels follow the format capfit: capability fit → res: residual success likelihood → combined likelihood (see Tables 1 and 2). Query guardrails reduce the resource consumption objective from High to Low: statement_timeout and EXPLAIN cost validation cap query execution (res: Low for cartesian join and full table scan), while max_connections limits prevent concurrent session exhaustion (res: Low for psql sessions). Injection vectors have no applicable controls (res: High).
IS8: Booking records corrupted Default: Mod = min(Mod, High) + read-only DB role: Low = min(Mod, Low) Obj: Unexpected LLM Behaviour Mod = max(Mod) Mod = max(Mod)
Obj: Unauthorized Action Execution High = max(High) Low = max(Low)
Tech: LLM Hallucination
Tech: Tool-based Action Execution
Vec: incorrect SQL UPDATE/DELETE Mod (inherent: Mod → res: High → Mod) Mod (inherent: Mod → res: High → Mod)
Vec: exec: psql with destructive query High (inherent: High → res: High → High) Low (inherent: High → res: Low → Low)
Figure 15: Attack tree for IS8 (database integrity, non-adversarial path), assessed for threat source: accidental (non-adversarial). Vector labels follow the format inherent: manifestation likelihood → res: residual success likelihood → resulting likelihood. For non-adversarial threats, inherent likelihood replaces capability fit; the inherent probability bounds the resulting likelihood regardless of residual success. Hallucination has an inherent Moderate probability; no control reduces it (res: High), but the result remains Moderate. In the default configuration, the agent has unrestricted database write access (res: High). A read-only database role blocks all write operations (res: Low), reducing the action execution objective from High to Low.
20