Clarify the relationship between plugin and watcher

[Mango999378]

Problem

The docs present three protection layers (skill / plugin / watcher), but the plugin and watcher READMEs both describe overlapping capabilities such as:

• audit
• hardening
• monitoring
• logs / scan
• skill scanning

Question

It is not entirely clear how the plugin and watcher are intended to relate to each other.

• Are they designed to be used together in the same deployment, or are they alternative approaches to similar problems?
• Does the watcher internally depend on or wrap the plugin, or are they fully independent implementations?
• If both are installed, is there any duplication of functionality or potential conflict?

[AmeerArsala]

Based on the paper, here's what my AI said:

Based on the text, here is the clarification regarding the relationship between plugins and watchers:

1. Designed to be used together or as alternatives?
They are designed to be used together as complementary layers in a unified framework, though they can technically function independently. The text explicitly states that ClawKeeper "unifies protective measures across three complementary architectural layers" (Skills, Plugins, and Watchers). The goal is to provide "holistic protection" where the plugin handles internal runtime hardening and the Watcher provides external, regulatory oversight. While a user could choose one based on specific needs (e.g., prioritizing low cost with plugins or maximum security with Watchers), the framework's strength lies in their combination to address the limitations of each.

2. Does the Watcher depend on or wrap the Plugin?
The Watcher is an independent agent and does not wrap the plugin. However, it relies on the plugin (or similar internal mechanisms) to function effectively:

• The Watcher is a separate OpenClaw instance running on its own.
• To monitor the target agent, the target agent must have plugins installed that "continuously stream live session information" (context, tool calls, messages) to the Watcher via a WebSocket connection.
• Therefore, the Watcher depends on the data output provided by the target agent's internal plugins, but it does not contain or wrap the plugin logic itself. The Watcher analyzes this stream to make independent safety decisions.

3. Duplication of functionality or potential conflict?
There is minimal duplication and no conflict because they operate at different levels and with different scopes:

• Plugin Scope: Operates inside the agent. It performs static configuration checks, hardens the environment, and logs events. It is "hard-coded" and reacts to predefined patterns.
• Watcher Scope: Operates outside the agent. It analyzes the stream of events provided by the plugin to detect complex, evolving threats (like prompt injection chains or dangerous tool loops) that static rules might miss. It can intervene by pausing execution or requesting human confirmation.
• Conflict Resolution: The text highlights that the Watcher specifically solves the "Task-Safety Coupling" and "Vulnerability to Adversarial Manipulation" issues inherent in plugins. Because the Watcher is external, an adversary cannot disable it by manipulating the agent's internal plugin list. Instead of conflicting, the Watcher acts as a "regulatory" layer that can override or pause the agent if the internal plugin fails to stop a threat, ensuring a "defense-in-depth" strategy.

In summary, the plugin is the internal sensor and hardener, while the Watcher is the external auditor that uses the plugin's data to make high-level safety decisions. They are intended to work in tandem to create a robust, multi-layered security posture.