Taming OpenClaw: Security Analysis and Mitigation of Threats in Autonomous LLM Agents

Autonomous LLM agents face cross-stage compound threats in long-horizon, high-privilege operations, and point defenses do not match such risks.

• Scenario: The authors state that OpenClaw connects intent and execution via instant messaging, orchestrates third-party plugins, maintains persistent memory, and performs software engineering and system administration. The authors believe persistent memory, cross-system integration, and privileged access expand the attack surface.
• Existing shortcomings: The authors state that most defenses only harden isolated interfaces, such as guardrail filtering, structured query separation of prompts and data, preference optimization training, and injection detection. The authors believe these are largely orthogonal to lifecycle-level guarantees and struggle to handle multi-stage attacks across time.
• Observation: The authors divide the lifecycle into initialization, input, inference, decision, and execution, and believe that indirect prompt injection, skill supply chain contamination, memory poisoning, and intent drift compound across stages.
• Our approach: Propose an analysis framework aligned with these five stages, discuss threats using the OpenClaw case study, and organize plugin review, instruction filtering, memory integrity verification, intent verification, and capability enforcement.
• Threat model:
  • Goals: Computationally bounded adversary seeking data exfiltration, privilege escalation, or decision manipulation.
  • Knowledge: No white-box access at inference time (gradients or hidden states); cannot bypass host-level cryptographic authentication or break the TCB.
  • Capabilities: External Content Attacker operates only through malicious web pages, API responses, or files; Supply Chain Attacker distributes trojanized plugins, compromises community repositories, or manipulates external tools; Malicious Tenant is an authorized malicious user attempting to escape isolation, access cross-tenant memory, or execute unauthorized commands.
  • Boundaries: The TCB includes the agent kernel, hardware, host OS, standard cryptographic primitives, inference infrastructure, and base model weights. Weight poisoning, model extraction, adversarial prefix optimization, hardware side channels, network-layer denial of service, and out-of-band social engineering are excluded. The focus is on untrusted external interactions (Section 3).

Autonomous agent architecture

• The generative agents of Park et al. (2023) are used to divide the five stages; RAG, Chain-of-Thought, and ReAct are treated as technical sources for retrieval, reasoning, and tool planning.
• OpenClaw (Steinberger et al., 2026) is the object of analysis: a kernel–plugin architecture, with pi-coding-agent responsible for memory, planning, and execution orchestration, and plugins extending capabilities.
• The paper only treats this architecture as a source of trust boundary expansion and does not experimentally compare it with other agent frameworks.

Attacks and empirical audits

• Indirect prompt injection comes from Greshake et al. (2023), Liu et al. (2025), and AgentVigil (2025); memory-side references cite MemoryGraft (2025) and Sunil et al. (2026); goal hijacking cites Deng et al. (2026); context drift cites Dongre et al. (2025).
• Liu et al. (2026) audit community skills; Chen et al. (2026) conduct a trajectory security audit of Clawdbot/OpenClaw; Wang et al. (2026) discuss turning OpenClaw from an assistant into a dual-use agent.
• The paper explicitly says AgentDojo (2024) and ASB (2025) mainly characterize attacks rather than doing real-time mitigation; and it says conventional sandboxes can be bypassed (Bors, 2026; Zou et al., 2025).

Point defenses

• Input-side defenses include guardrails (Dong et al., 2024; Wang et al., 2026's DataFilter), StruQ (2025), SecAlign (2025), DataSentinel (2025), PISanitizer (2025), and PromptArmor (2025). The paper says most of them assume stateless, single-turn interactions, and indirect injection remains insufficiently mitigated.
• AegisAgent (2025), A-MemGuard (2025), BlindGuard (2025), and AGrail (2025) are used by the authors to illustrate that autonomous detection, persistent memory protection, runtime intent verification, or adaptive enforcement are feasible, but they have not yet been integrated into OpenClaw's full-lifecycle defense.
• Initialization-side plugin review, static analysis, and community reputation (Chen et al., 2026; Liu et al., 2026) are criticized by the authors for assuming the initial state is trustworthy and for failing to stop post-deployment updates or malicious configuration changes (also citing AGrail).

Baselines and benchmarks The paper runs no comparison baselines and reports no scores on AgentDojo or ASB. These two environments are only named in the discussion as evaluation frameworks biased toward attack characterization.

The authors position this paper as: organizing OpenClaw's composite risks according to the full lifecycle and examining stage-wise defenses and cross-stage gaps, rather than proposing another single-interface attack or single-point filter.

The authors align a five-layer defense-in-depth with OpenClaw's five-stage lifecycle, arguing that single-interface point defenses cannot stop cross-stage propagation, for example, a malicious prompt first pollutes persistent memory and then triggers unauthorized calls.

Problem setup and design principles

• Architecture: pi-coding-agent is the minimal TCB, managing memory, task planning, and execution orchestration; the plugin ecosystem extends capabilities. The authors say dynamic loading lacks strict integrity verification, there is implicit trust in external APIs, and code generation carries host privileges.
• Goals: Integrity separates user instructions from untrusted data; Confidentiality protects credentials, session tokens, and long-term memory, preventing exfiltration through seemingly legitimate APIs; Availability isolates compromised plugins, sandboxes execution, and prunes poisoned context, while avoiding infinite reasoning loops and semantic denial of service.
• Three principles: Complete Lifecycle Mediation, where every interface that can change state or behavior is defended; Defense-in-Depth, stacking lexical, semantic, and system-level checks; Least Privilege with Provenance Tracking, using metadata tags or information-flow control to propagate input trust levels forward.
• Invariants: The authors propose that untrusted inputs, state changes, or synthesized plans must first satisfy the corresponding stage's security predicate before they can affect the external environment. The Figure 6 caption says each layer executes a different security goal and passes context verified cryptographically or semantically to adjacent layers.

Five-stage threats

• Initialization: malicious or vulnerable plugins, skills impersonating legitimate capabilities, credential leakage, and disabling plugin signature verification or execution sandboxes. The authors cite Liu et al.'s audit, saying about 26% of community-contributed tools contain various security vulnerabilities.
• Input: indirect prompt injection, system prompt extraction, malicious file parsing. The authors say instructions in external content can rewrite control flow without the user clicking; weaknesses in media ingestion and archive decompression can be used to read sensitive files or escape the sandbox.
• Reasoning and decision-making: memory poisoning turns a single write into behavioral constraints for subsequent sessions; the authors say context drift can deviate even without explicit adversarial manipulation. The decision stage includes goal hijacking, tool-selection manipulation, and alignment-policy bypass; the authors say ambiguous instructions can trigger intent drift even under benign conditions.
• Execution: high-risk commands, privilege escalation, data exfiltration, and lateral movement. The authors say malicious behavior is often split into chains of single steps that look benign, triggering only at the last step. Appendices A–E give cases; the payloads are not repeated here.

Initialization and input defenses

• Initialization: perform AST and taint analysis on external modules, checking for unauthorized dynamic execution, credential collection, and anomalous network sockets; verify that a skill's declared metadata, behavioral embeddings, and executable logic are consistent, and bind provenance with a signed SBOM; validate RBAC, API scope, and memory limits according to deployment policy. After passing, issue a Trusted Execution Manifest, which the authors say is best anchored in a TEE for later auditing.
• Input: treat the system prompt as high privilege and external retrieval as low privilege, using cryptographic token marking or attention masking to handle conflicts. A semantic firewall uses an auxiliary fine-tuned lightweight model for intent classification, flagging instructional content or internal tool-call intent that should not appear. The paper does not name this auxiliary model. Disposition ranges from deletion to isolation.

Reasoning, decision, and execution defenses

• Reasoning: before writing to the vector store, check for contradictions, policy violations, or latent instructions; isolate reads and writes by multi-tenancy. Use a Merkle tree for checkpoints of verified state, rolling back on anomalies. A cross-encoder compares the current working context with the frozen original system prompt. The paper gives no distance threshold. The authors say OpenClaw currently lacks continuous monitoring for gradual subversion of legitimate context.
• Decision: constrained decoding (the paper gives JSON schema as an example) guarantees syntax; a symbolic or formal engine checks hard invariants, with the paper's example being that data in a certain directory must not flow to a certain network port. An independent verification model checks whether subgoals introduce parasitic goals. The paper does not name the verification model. High-risk plans are described as being suspended and fed back to the policy engine. The authors say OpenClaw lacks a mechanism for continuously verifying that plans align with user goals.
• Execution: design under the assumption of compromise. eBPF, seccomp, and containers restrict system calls, file I/O, and outbound traffic; trajectory monitoring detects living-off-the-land, delayed execution, and resource exhaustion; operations that can be atomic transactions are executed in a reversible environment and can be rolled back afterward. Irreversible or high-privilege operations go through Human-in-the-Loop, showing the human the provenance and risk assessment.
• Coverage table: Table 1 uses checkmarks and crosses to indicate which layer the authors believe mitigates which threat class. After plain-text conversion the columns may be misaligned, so it is not transcribed cell by cell here.

Experimental Setup

• Subject: OpenClaw. The paper does not state the name or version of the underlying LLM used in the case study.
• Materials: Section 4 gives one set of cases per stage, with details in Appendices A–E, and Figures 1–5 and 7–12 illustrating the effects. This is not batch testing on a public benchmark.
• Citation audit: Liu et al. [17] state that roughly 26% of community-contributed tools contain various security vulnerabilities. This is not a sample from this paper.
• Metrics: The paper does not define ASR and does not state the review model, thresholds, sample size, or number of repetitions.
• Defense matrix: Table 1 is a design coverage marker, not an interception rate.
• Comparison: The paper does not report side-by-side scores against AgentDojo, ASB, or existing defenses.

Main Results

Swipe horizontally to read the table

Stage	Evidence	Phenomenon reported by the authors	Quantitative metric
Initialization	Figure 1, Appendix A	A benign request triggers an injected skill, and the output is controlled by the attacker	Not reported
Input	Figure 2, Appendix B	Embedded instructions in retrieved content override the user request	Not reported
Reasoning	Figure 3, Appendix C	Injected memory rules cause subsequent sessions to reject benign requests	Not reported
Decision	Figure 4, Appendix D	A check request evolves into unauthorized configuration changes and service restarts, leaving the system inaccessible	Not reported
Execution	Figure 5, Appendix E	A covertly assembled script chain causes resource exhaustion and service interruption	Not reported

• The authors treat these cases as evidence that threats can land across the lifecycle, and state that point defenses cannot handle cross-stage propagation.
• In Sections 4.3–4.4, the authors state that context drift can occur without explicit adversarial input; ambiguous instructions under benign conditions can also push locally reasonable tool calls toward unauthorized outcomes.
• The roughly 26% figure comes from a cited skill audit and cannot be taken as the incidence rate of the cases in the table above.

Defense Discussion in the Cases

• Appendices A–E use the same set of cases to discuss how the corresponding layer would handle them: reject skills whose declaration and behavior are inconsistent, isolate inputs by segment, validate memory writes with rollback capability, verify intent at the plan level, and intercept the final trigger across multi-step trajectories. The authors write in terms of "would reject" or "can block"; the paper does not report implementation, interception counts, or false rejections.
• Appendix D: one configuration write is blocked because the target path lies outside the allowed workspace root; the authors state that the subsequent process termination still disconnects the gateway, leaving the WebUI inaccessible (Figure 4).
• Appendix E: the authors state that after triggering, resource consumption rises from a near-idle baseline to full saturation and causes a gateway disconnect. The Figure 12 caption reads "CPU Utilization Surge." The paper gives no percentage.

Stage Judgment of Existing Defenses

• In Section 5.2, the authors state: static plugin review cannot catch components weaponized after deployment; input defenses mostly assume a single turn, and individually benign inputs can still accumulate across turns to trigger malicious behavior; the reasoning side lacks continuous memory monitoring; the decision side lacks continuous verification of plans against user goals; conventional sandboxes can be bypassed, and lack behavioral monitoring and safe rollback.
• Across stages, the authors state that input sanitization fails once initialization has been compromised, and an execution sandbox cannot remedy previously poisoned memory.
• Table 1 condenses the above judgments into a layered coverage table. The text columns may be misaligned; specific checkmarks are not transcribed.

Other Ablations and Analyses

The paper reports no ablations, parameter sweeps, or repeated experiments.

Limitations and future directions noted by the authors

• Remaining challenges (Section 7.2): The authors write that lifecycle-aware defenses are only a foundation, and several challenges remain; further research is needed to address more complex adversarial threats.
• Hardware root of trust (Section 7.2): The authors propose using TEE–GPU collaboration or edge-side Arm TrustZone to execute critical components and memory parameters, migrating trust lists and memory verification into these environments to reduce computational and latency overhead and establish a hardware trust chain.
• Adaptive strategies (Section 7.2): The authors propose not relying solely on statically configured toxicity or context drift thresholds, but using reinforcement learning to adjust the sensitivity of each layer based on task complexity and environmental uncertainty. The authors believe this may better balance task utility and safety controls.
• Mechanism unification (Section 5.2): The authors write that future work should unify dynamic memory protection, adaptive guardrails, autonomous prompt injection defense, and system-level monitoring into an actionable framework to address temporal, compositional, and memory-oriented threats. Section 6 provides a design synthesis, while Section 7.2 still leaves hardware implementation and adaptive strategies as research directions.

Experimental coverage

• The case study targets OpenClaw, corresponding to the five stages in Section 4; Appendices A–E detail skill poisoning, indirect prompt injection, memory poisoning, intent drift, and high-risk command execution, respectively.
• Section 3 defines External Content Attacker, Supply Chain Attacker, and Malicious Tenant, and specifies the TCB and excluded attack types.
• Table 1 is a design coverage table mapping the five layers to lifecycle threat categories; Section 6 describes plugin review, input filtering, memory integrity, intent verification, and execution isolation by layer.
• The paper does not report the names of the LLM, semantic firewall auxiliary model, or decision verification model used in the case study, nor does it report sample sizes, number of repetitions, query budgets, attack success rates, interception rates, utility degradation, or latency.
• Section 5.2 discusses plugin static review, input guardrails and structured separation, memory monitoring, decision verification, and conventional sandboxing stage by stage; the paper does not report controlled experiments after the authors implemented these defenses.

This is a lifecycle threat analysis of OpenClaw, accompanied by a set of layered mitigation designs.

The problem addressed is: once an autonomous agent connects instant messaging, persistent memory, third-party plugins, and high-privilege execution, attacks are no longer limited to single-turn jailbreaks but can compound across multiple stages from initialization to execution. The authors argue that defenses hardening only a single interface cannot stop such cross-time attacks.

Methodologically, threats and defenses share the same five-stage division. The three defense principles are full-lifecycle mediation, stacked heterogeneous controls, and least privilege with provenance propagation. Initialization verifies plugins and configuration and issues a trust manifest; input separates high-privilege instructions from low-privilege external data; reasoning validates memory writes and detects semantic drift; decision verifies whether plans deviate from authorized goals; execution uses kernel-level capability restrictions, trajectory monitoring, and human confirmation as a backstop.

The evidence the authors give is qualitative cases, with no success rates. In Figure 1, a benign request is taken over by a malicious skill; in Figure 2, retrieved content rewrites the task; in Figure 3, forged memory rules reject benign requests in later sessions; in Figure 4, an inspection request reaches unauthorized changes and makes the system inaccessible; in Figure 5, a stepwise command chain causes resource exhaustion and service disruption. The "about 26%" in the text is from Liu et al.'s skill audit, not a statistic from these cases. Table 1 only marks design coverage.

The authors' conclusion is that existing mitigations remain fragmented and a lifecycle-aware defense-in-depth architecture is needed to avoid single points of failure. They leave hardware primitives such as TEEs and adaptive thresholds for future work.