---
title: ClawKeeper Security Framework
url: https://www.emergentmind.com/topics/clawkeeper
type: topic
---

# ClawKeeper Security Framework

ClawKeeper is a security framework for OpenClaw-style autonomous agents that is presented most directly as a three-layer system combining **skill-based protection**, **plugin-based protection**, and **watcher-based protection** to mitigate sensitive data leakage, privilege escalation, dangerous command execution, malicious third-party skill execution, and related lifecycle risks in always-on, tool-using agents [2603.24414]. In adjacent OpenClaw literature, the term also functions as a broader architectural shorthand for a governor, control plane, or security supervisor around agent runtimes, skill ecosystems, and evaluation pipelines; this suggests that “ClawKeeper” denotes both a specific framework and a wider design pattern for constraining high-privilege autonomous systems [2603.12644][2606.01494].

## 1. OpenClaw context and the problem ClawKeeper addresses

OpenClaw is described as an open-source autonomous agent runtime with local file access, shell command execution, tool integration, communication-platform connectors, background services, and persistent memory, making it effectively a long-lived user-space execution environment for agents rather than a stateless chatbot [2603.24414]. This operational model substantially enlarges the attack surface: model errors become system actions, third-party skills become executable extensions of agent behavior, and persistent state can carry compromise across sessions.

The broader OpenClaw security literature reinforces this framing. A tri-layered risk taxonomy for OpenClaw identifies vulnerabilities across **AI & Cognitive Security**, **Software & Execution Security**, and **Information & System Security**, while the Full-Lifecycle Agent Security Architecture advocates **zero-trust agentic execution**, **dynamic intent verification**, and **cross-layer reasoning-action correlation** [2603.12644]. A systems-oriented analysis reaches a similar conclusion by treating Claw-like agents as “agentic computer systems” with OS-like mediation responsibilities, persistent access to credentials and tools, and classical missing protections such as process isolation, per-application sandboxing, credential vaulting, and signed extensions [2606.30755]. Within this context, ClawKeeper is designed as an integrated defense-in-depth response to the mismatch between agent autonomy and available security controls.

A recurrent misconception is to equate ClawKeeper with prompt filtering or skill scanning alone. The framework is explicitly broader: it spans instruction-level policy shaping, runtime hardening and monitoring, and an external supervisory process that can intervene in real time [2603.24414]. Related work on ClawHub also shows why a single-stage defense is insufficient: among 67,453 latest public OpenClaw skill versions, any pair of scanner families overlaps on at most 10.4% of their combined positives, only 0.69% of skills are flagged by all three, and 81.9% of flagged skills are identified by a single scanner [2606.01494].

## 2. Threat model and attack classes

ClawKeeper’s benchmarked threat model is organized into seven categories: **T1: Prompt Injection**, **T2: Credential / Sensitive Data Leakage**, **T3: Privilege Escalation & Tampering**, **T4: Dangerous Command Execution**, **T5: Configuration File Tampering**, **T6: Vulnerability / Threat Detection (OWASP ASI)**, and **T7: Malicious Skill Installation** [2603.24414]. These categories are operational rather than purely conceptual: they include adversarial prompts hidden in external content, explicit requests to reveal credentials, attempts to modify `AGENTS.md` or `openclaw.json`, obfuscated destructive commands such as Base64-encoded `rm -rf / --no-preserve-root`, and third-party skills that install cron-triggered exfiltration logic.

Contemporaneous attack papers show that these categories are not exhaustive but are representative. “Clawdrain” demonstrates a Trojanized OpenClaw skill that induces a multi-turn **Segmented Verification Protocol** through `SKILL.md` instructions and companion tool outputs, producing approximately **6–7x token amplification** over a benign baseline and reaching approximately **9x** in a costly failure configuration [2603.00902]. “Trojan’s Whisper” introduces **guidance injection**, in which malicious bootstrap guidance reframes harmful actions as routine best practices; across 52 natural user prompts and six LLM backends, the attacks achieve success rates from **16.0% to 64.2%**, and **94%** of malicious skills evade detection by existing static and LLM-based scanners [2603.19974]. SafeClawArena extends the threat surface further to **Skill Supply-Chain Integrity**, **Persistent State Exploitation**, **Cross-Boundary Data Flow**, and **Indirect Prompt Injection**, reporting overall attack success rates between roughly **20% and 70%**, with malicious Plugins succeeding in **100%** of cases when the platform permits them [2606.30755].

These results show that the ClawKeeper threat model sits at the intersection of reasoning-layer compromise, extension-layer compromise, and host-level side effects. A plausible implication is that any practical ClawKeeper deployment must treat skills, memory, tool outputs, logs, and configuration files as coupled security objects rather than independent surfaces.

## 3. Three-layer architecture

ClawKeeper’s core design is a three-layer architecture in which each layer addresses a different point in the agent lifecycle [2603.24414].

| Layer | Mechanism | Stated role |
|---|---|---|
| Skill-based protection | Markdown security rules plus optional scripts | Instruction-level policy injection and environment-specific constraints |
| Plugin-based protection | Internal OpenClaw security plugin | Configuration hardening, threat detection, monitoring, integrity checks, behavioral scanning |
| Watcher-based protection | Decoupled external security middleware | Real-time verification of agent state evolution and runtime intervention |

**Skill-based protection** operates by loading structured markdown security policies and scripts as skills, thereby injecting system-specific and software-specific rules into the agent context [2603.24414]. The rules can encode cross-platform boundaries, red-line behaviors for communication surfaces such as Feishu/Lark, daily system scans, interaction summaries, and guidance on when to request confirmation. Because this layer is instruction-level, it is easy to deploy and update, but it remains LLM-mediated: the model must read and obey the injected security markdown.

**Plugin-based protection** is the internal runtime enforcer. It includes a **Threat Detection module** for scanning configuration and environment in line with OWASP Agentic Security and known CVEs; a **Hardening module** that can apply fixes such as binding the gateway to `127.0.0.1` and injecting safety rules into `AGENTS.md`; **Configuration Protection** that maintains cryptographic hash backups of critical files such as `openclaw.json`, `AGENTS.md`, and `SOUL.md`; **Monitoring & Logging** for continuous instrumentation of user instructions, LLM I/O, tool calls, and command outcomes; and **Behavioral Scanning** that performs asynchronous analysis over logs to detect jailbreak attempts, suspicious tool usage, recurrent failures, and malicious skill behavior [2603.24414].

**Watcher-based protection** is the framework’s most distinctive layer. The Watcher is a separate OpenClaw instance connected via WebSocket that receives streamed runtime events from the task agent, reasons over tool calls, outputs, failures, and action trajectories, and can return control signals such as `stop` or `ask_user` [2603.24414]. The Watcher is explicitly decoupled from the task agent’s internal logic, which means it can supervise, pause, or require human confirmation without being removable through ordinary skill-level manipulation. The paper argues that this “Watcher paradigm” may generalize beyond OpenClaw to any agent framework that can expose event streams and accept external pause or confirmation hooks.

## 4. Operational workflow and enforcement logic

ClawKeeper’s runtime path begins when a user request reaches the task agent and OpenClaw constructs the LLM context from the system prompt, memory, conversation history, tool and skill descriptions, and security markdown supplied by the skill layer [2603.24414]. The agent then plans tool use and action sequences. As these actions move through the runtime, the plugin layer intercepts configuration loads, shell commands, file accesses, and tool invocations, performing integrity checks, threat detection, and event logging. A subset of events is streamed to the Watcher, which classifies trajectories as safe, suspicious, or dangerous and issues `ask_user` or `stop` when needed.

This produces three distinct enforcement modes. First, the skill layer shapes the policy prior seen by the model. Second, the plugin layer performs deterministic or rule-driven checks inside the runtime. Third, the Watcher performs decoupled trajectory-level analysis over the evolving session. The framework’s qualitative examples illustrate these modes: the Watcher decodes Base64 payloads and flags dangerous commands, halts repeated failed privileged operations, and asks for confirmation when tool-call counts exceed a configured threshold [2603.24414].

A useful comparison is the deterministic tool-call boundary enforcement proposed by ClawGuard. That system derives task-specific rules from the user’s objective before any external tool invocation and then enforces allow, deny, or queue decisions at every tool-call boundary without model modification or infrastructure change [2604.11790]. ClawGuard blocks all three injection pathways it studies—web and local content injection, MCP server injection, and skill file injection—by checking each tool call against baseline and task-derived rules, while sanitizing inputs and outputs and logging every verdict [2604.11790]. This suggests a complementary relationship rather than a substitute: ClawKeeper’s Watcher and plugin layers provide broad supervisory and forensic capabilities, whereas ClawGuard provides deterministic boundary enforcement at the action interface.

The broader FASA literature makes a similar distinction between policy reasoning and system mediation. Its **Perception**, **Decision**, **Execution**, and **Governance** layers correspond closely to ClawKeeper’s combination of context-level policy injection, runtime enforcement, and external supervision [2603.12644]. A plausible implication is that mature ClawKeeper deployments would benefit from combining trajectory-level Watcher analysis with boundary-level access control and OS-level telemetry.

## 5. Empirical evaluation and reported effectiveness

ClawKeeper is evaluated on **140 adversarial cases**, constructed as **7 task categories × 20 instances each**, with **10 simple and 10 complex examples** per category, all run on a clean OpenClaw installation with **GLM-5** as the underlying LLM [2603.24414]. Outcomes are labeled by two human annotators as success or failure depending on whether the threat was blocked without undesirable regression, and **Defense Success Rate (DSR)** is defined as the number of successfully defended instances divided by the total instances in the category.

The reported DSRs are **90** for T1, **85** for T2, **85** for T3, **90** for T4, **90** for T5, **85** for T6, and **90** for T7 [2603.24414]. The baselines are markedly more fragmented, each covering only part of the threat space.

| Category | ClawKeeper DSR | Best baseline cited |
|---|---:|---:|
| T1 | 90 | 65 |
| T2 | 85 | 70 |
| T3 | 85 | 60 |
| T4 | 90 | 45 |
| T5 | 90 | 65 |
| T6 | 85 | 65 |
| T7 | 90 | 60 |

The paper states that ClawKeeper outperforms the best baseline per category by **15–45 percentage points** [2603.24414]. Qualitative cases align with these numerical gains: skill-based policies block credential transmission in Feishu messages, the plugin hardens insecure gateway settings and detects jailbreak prompts in logs, and the Watcher prevents execution of decoded destructive commands or repeated privileged retries [2603.24414].

The Watcher is also evaluated as a self-evolving mechanism. In a simulated online scenario, its DSR rises from approximately **90%** to approximately **95%** over **100 adversarial cases** as it updates its internal state [2603.24414]. The paper interprets this as a consequence of accumulated threat vocabulary and better calibrated confirmation thresholds. Related endogenous-security work provides a stronger mechanistic account for this effect: ClawdGo’s **weakest-first ASAT** raises average TLDT score from **80.9 to 96.9 over 16 sessions**, while **CSMA** retains the full gain across sessions and a cold-start ablation recovers only **2.4 points**, leaving a **13.6-point gap** [2604.24020]. This suggests that a Watcher-like component may benefit from structured persistent security memory rather than static prompt updates alone.

## 6. Position within the broader Claw ecosystem

ClawKeeper sits within a larger OpenClaw ecosystem that now includes security architectures, runtime guards, skill-governance datasets, and realistic evaluation benchmarks. In security architecture terms, the framework is closely aligned with Project ClawGuard’s vision of a central policy and control plane for agents, implementing zero-trust execution, dynamic intent verification, and cross-layer reasoning-action correlation [2603.12644]. In marketplace-governance terms, it addresses the precise problem highlighted by ClawHub Security Signals: skill risk is distributed across malware reputation, static code and text patterns, and semantic agentic-risk advisories, so layered governance is required rather than single-scanner allow/block decisions [2606.01494].

In systems-security terms, SafeClawArena exposes the consequences of omitting classical protections. Across three platforms and five frontier LLMs, the highest attack success rate reaches **70%**; **malicious Plugins succeed in 100% of cases regardless of the LLM**; and a security-first fork, SeClaw, reduces GPT-5.4’s attack success rate from **70% to 22%** partly by eliminating plugin loading and narrowing the configuration surface [2606.30755]. These results reinforce ClawKeeper’s emphasis on runtime supervision and extension control, but they also indicate that feature removal and privilege reduction can matter as much as intelligent monitoring.

ClawKeeper also has an evaluation role. RealClawBench converts real OpenClaw sessions into reproducible benchmark tasks using reconstructed execution environments and deterministic verifiers, yielding **281 executable tasks** whose final-vs-source Jensen–Shannon divergences are all below **0.05 bits** on key axes; even the best evaluated system solves only **65.8%** of tasks [2606.03889]. Claw-Anything expands evaluation to months of logs, multiple devices, and interdependent services, where GPT-5.5 achieves only **34.5% Pass@1** [2605.26086]. This suggests that ClawKeeper cannot be understood purely as a defensive add-on: it is also part of an ecosystem response to the realism gap between laboratory agent benchmarks and deployed, always-on assistant behavior.

## 7. Limitations, misconceptions, and future directions

ClawKeeper does not claim kernel-level or formally verified protection. The framework assumes a trusted underlying OS and OpenClaw runtime, and it does not address physical-world harms or direct compromise of the Watcher process [2603.24414]. Its skill-based layer remains dependent on LLM compliance with markdown policies, and its plugin rules are static enough that previously unseen attack patterns may evade them until updated. Its main evaluation metric, DSR, is based on human judgments rather than formal proofs or purely automated criteria [2603.24414].

A second misconception is that the Watcher eliminates the need for capability isolation. The surrounding literature argues the opposite. “Trojan’s Whisper” concludes that guidance injection reveals an urgent need for **capability isolation**, **runtime policy enforcement**, and **transparent guidance provenance** [2603.19974]. SafeClawArena shows that malicious Plugins remain catastrophic when in-process extension mechanisms are allowed, and that some security gains arise from removing unsafe features rather than from smarter inspection alone [2606.30755]. ClawHub Security Signals shows that malware-oriented and semantics-oriented scanners occupy different parts of the skill-risk space, so provenance, moderation context, and human review remain necessary [2606.01494].

The framework’s forward path is therefore architectural rather than merely classificatory. The ClawKeeper paper itself points toward **richer policy languages**, **stronger static analysis**, **formal verification**, **OS-level integration**, and a **common “Watcher API”** for agent frameworks [2603.24414]. Related work adds more specific candidates: credential vaulting, sandboxed per-skill capability manifests, deterministic tool-call boundary checks, memory integrity controls, and structured calibration of endogenous security awareness to avoid the **Security Awareness Calibration Problem**, in which overtraining raises false positives and erodes utility [2604.11790][2604.24020].

Taken together, the literature presents ClawKeeper as more than a single product or plugin. It is a layered security doctrine for OpenClaw-style agents: treat skills and bootstrap guidance as potentially adversarial, mediate runtime actions through enforceable policies, supervise trajectories with an external Watcher, preserve provenance and auditability across sessions, and evaluate the result against realistic workloads and adversarial security benchmarks [2603.24414][2606.30755][2606.03889].

Source: https://www.emergentmind.com/topics/clawkeeper