clawthority
Security checks across static analysis, malware telemetry, and agentic risk
Overview
Clawthority is broadly purpose-aligned as an authorization plugin, but its default safety documentation conflicts with the implementation for unrecognized sensitive actions.
Before installing, decide whether default open mode is acceptable. For stronger safety, run in closed mode, verify every tool alias is registered, review npm setup scripts and dependencies, and carefully scope any Slack or Telegram approval credentials.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal engine telemetry is currently stale for this artifact.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user may believe unrecognized sensitive tools are blocked by default when they may actually be allowed in open mode.
This claims default open mode blocks unknown_sensitive_action, but the included implementation says unknown_sensitive_action is intentionally excluded from open mode, making the default safety claim misleading.
By default Clawthority runs in **`open` mode** — implicit permit, with a critical-forbid safety net (`shell.exec`, `code.execute`, `payment.initiate`, `credential.read`, `credential.write`, `unknown_sensitive_action`).
Treat open mode as fail-open for unrecognized tools; use closed mode for stronger containment and require the publisher to align the documentation and implementation.
If a dangerous tool is not correctly registered, the agent may be able to run it without human approval under the default mode.
The default mode can permit unrecognized tools, which is a material concern for an authorization boundary because misregistered high-risk tools may bypass the expected default block.
NOTE: `unknown_sensitive_action` is intentionally excluded from OPEN mode. In OPEN mode, unrecognised tools fall through to the implicit permit
Use `CLAWTHORITY_MODE=closed`, register all tool aliases, and test policy coverage before relying on the plugin for high-risk tools.
Installing the plugin runs local Node/npm code on your machine.
The setup path runs package installation and build scripts locally. This is expected for a plugin, but it is still local code execution from the package source.
git clone https://github.com/OpenAuthority/clawthority ~/.openclaw/plugins/clawthority cd ~/.openclaw/plugins/clawthority npm install && npm run build
Review the repository, package scripts, and dependencies before running npm install/build, especially in sensitive environments.
If configured, the plugin will rely on messaging-service credentials that can authorize bot actions or approval interactions.
The plugin can use Slack and Telegram credentials for human-in-the-loop approval channels. This is purpose-aligned but not declared in the registry env-var metadata.
const botToken = process.env.TELEGRAM_BOT_TOKEN ?? policyConfig?.botToken; ... const botToken = process.env.SLACK_BOT_TOKEN ?? policyConfig?.botToken; ... const signingSecret = process.env.SLACK_SIGNING_SECRET ?? policyConfig?.signingSecret;
Use least-privilege bot tokens, keep secrets out of shared policy files where possible, and rotate tokens if they may have been exposed.
Approval prompts or decision metadata may pass through external messaging systems if those integrations are enabled.
The artifacts include Slack and Telegram HITL channel configuration, indicating optional external approval-channel communication. This is expected for HITL but introduces provider and channel-boundary considerations.
resolveTelegramConfig(policyConfig) ... TELEGRAM_BOT_TOKEN ... TELEGRAM_CHAT_ID ... resolveSlackConfig(policyConfig) ... SLACK_CHANNEL_ID ... SLACK_INTERACTION_PORT
Only enable Slack or Telegram approvals in trusted workspaces/chats, and avoid including unnecessary sensitive payload details in approval summaries.