SidClaw Governance

Add policy evaluation, human approval, and audit trails to any tool. Powered by SidClaw.

Security Scan

The skill is coherent with a governance proxy (it asks for an API key, Agent ID, and node and instructs routing tool calls through a SidClaw proxy), but it asks you to route all MCP/tool traffic through a third-party service and contains small metadata/instruction mismatches — this requires caution and verification before installing.

Purpose & Capability

Name/description, required binaries (node), and required credentials (SIDCLAW_API_KEY, SIDCLAW_AGENT_ID) align with a governance/proxy service that evaluates tool calls. The declared primary credential (SIDCLAW_API_KEY) is appropriate for this purpose.

Instruction Scope

Runtime instructions tell the user to replace their MCP server config so every tool call is proxied through SidClaw. That is expected for a governance proxy, but it is high-impact: the proxy will see tool inputs/outputs and can block or delay actions. The SKILL.md does not instruct the agent to read unrelated files, but it does instruct editing ~/.openclaw/openclaw.json which affects agent-wide behavior.

Install Mechanism

This is an instruction-only skill (no install spec). The README and instructions rely on npx/@sidclaw/sdk at runtime (npx will fetch packages from npm). Fetching and executing packages via npx is a moderate-risk pattern (normal for JS tools but requires trusting the npm package and its publisher). No binary or archive downloads from unknown hosts are present in the skill itself.

Credentials

The two required env vars (SIDCLAW_API_KEY, SIDCLAW_AGENT_ID) are appropriate for a third-party governance service. However, the README lists additional required variables (e.g., SIDCLAW_UPSTREAM_CMD) that are not declared in the skill metadata — an inconsistency. Also, routing all tool traffic to an external API means the API key grants broad access to tool call metadata and possibly payloads; that is expected but high-privilege.

Persistence & Privilege

The skill does not set always:true and does not auto-run, which is correct. However, it explicitly asks the user to change the agent-wide MCP configuration (~/.openclaw/openclaw.json) so all tools are proxied. This is a cross-cutting change that affects every tool and therefore raises privilege/impact concerns if you do not fully trust the SidClaw service or SDK.

What to consider before installing

This skill is coherent for its stated purpose but is high-impact: it routes all tool calls through a third-party proxy. Before installing: 1) Verify SidClaw's identity and trustworthiness (check the official GitHub repo, npm package @sidclaw/sdk, and docs). 2) Back up ~/.openclaw/openclaw.json before making changes. 3) Confirm precisely which env vars are actually required (README mentions SIDCLAW_UPSTREAM_CMD but the skill metadata does not) and avoid putting long-lived secrets in shared configs if you are unsure. 4) Prefer self-hosting or an enterprise deployment of the SidClaw proxy (or reviewing the @sidclaw/sdk code) if you need to keep data on-prem. 5) Test with non-sensitive tools/data first to confirm behavior. If you want higher confidence, provide the skill's source code or the npm package/GitHub repo for review — seeing the @sidclaw/sdk code and release provenance would move this assessment toward 'benign.'

You have SidClaw governance enabled. Every tool call is evaluated against security policies before execution.

How governance affects your behavior

When you use a tool, the SidClaw policy engine evaluates whether the action is allowed. There are three possible outcomes:

1. ALLOWED

The tool executes normally. No changes to your behavior needed. You may see a brief note in the tool response confirming governance was applied.

2. APPROVAL REQUIRED

The tool call is paused pending human review. You will receive an error response containing:

• type: "approval_required"
• approval_request_id: the ID of the pending approval
• reason: why this action requires approval

When this happens:

• Tell the user: "This action requires human approval before I can proceed."
• Share the reason from the policy.
• Direct the user to approve or deny the request in the SidClaw dashboard.
• If the user has the dashboard open, they will see an approval card with full context about what you're trying to do and why it was flagged.
• Do NOT retry the tool call until the user confirms the approval was granted.

3. DENIED

The tool call was blocked by policy. You will receive an error response containing:

• type: "action_denied"
• reason: why this action was blocked

When this happens:

• Tell the user: "This action was blocked by a security policy."
• Share the reason from the policy.
• Do NOT retry the tool call or attempt to work around the block.
• Suggest alternative approaches if possible (e.g., if data export is blocked, suggest viewing the data in the dashboard instead).

Rules

1. NEVER ignore governance errors. If a tool call is denied, respect the denial.
2. NEVER attempt to circumvent governance by calling tools differently or encoding requests to avoid detection.
3. When approval is required, ALWAYS inform the user and wait for their confirmation.
4. Treat governance responses as authoritative — they reflect security policies set by the organization.
5. If multiple tools are governed, each call is evaluated independently.

Dashboard

The SidClaw dashboard is available at the URL configured by the administrator. It shows:

• Approval Queue: Pending approval requests with full context
• Audit Trail: Complete trace of every tool call, policy decision, and outcome
• Policy Rules: The security policies governing your actions

If a user asks about governance policies or why an action was blocked, direct them to the SidClaw dashboard for details.