Threat modeling OpenClaw plugins as capabilities
Plugin ecosystems fail at the boundaries. A capability-first model makes the blast radius explicit—and reviewable.
OpenClaw plugins can be a superpower or a liability, depending on how much power you grant by default. The safest posture is to treat every plugin as untrusted code that must earn each capability.
Start with assets: request payloads, tokens, routing decisions, and policy packs. Then map trust boundaries: the gateway runtime, the plugin sandbox, and any external calls the plugin is allowed to make.
A capability manifest turns “can this plugin do X?” into a diffable answer. Network egress, environment reads, filesystem access, and crypto operations should all be explicit capabilities.
For reviewers, the workflow is straightforward: compare manifests, read intent, and reject any change that expands capability without justification. For operators, enforcement is equally direct: deny what you don’t mean to allow.
Incidents still happen, but the question shifts from “how did it do that?” to “why did we allow it?”—which is at least tractable.