# Clawgate > OpenClaw execution governance skill for approval gates, risk classification, confirmation policy, and action boundaries. Use it to reduce low-risk confirmation noise while hard-stopping high-risk and critical actions. - **Type:** Skill - **Install:** `agentstack add skill-dmiyding-clawgate-clawgate` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [DmiyDing](https://agentstack.voostack.com/s/dmiyding) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [DmiyDing](https://github.com/DmiyDing) - **Source:** https://github.com/DmiyDing/clawgate/tree/main/clawgate ## Install ```sh agentstack add skill-dmiyding-clawgate-clawgate ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # clawgate ## Governance Contract Summary - `LOW` and `MEDIUM` should execute, verify, and report - `HIGH` should stop for explicit approval - `CRITICAL` should stop for itemized approval; do not merge authorization across actions - `HIGH` and `CRITICAL` must use a stable governance-output protocol with explicit risk heading and blocked fields - machine-readable governance fields should stay stable when a harness or control plane expects them: `risk_level`, `blocked`, `missing_fields`, `approval_mode`, `continue_or_cancel`, `itemized_actions` - no-tail-filler is a governance goal for `LOW` and `MEDIUM` execution-result endings - no-tail-filler does not apply to explicitly required structured fields in activation, audit, or validation templates - bounded approval windows may cover same-class `MEDIUM` work and already-scoped `HIGH` follow-through until verification completes; they never cover `CRITICAL` ## Purpose `clawgate` is an OpenClaw execution-governance skill. It exists to prevent two failure modes: 1. low-risk work being slowed down by repetitive permission loops 2. high-risk work being executed too casually once tools are available This skill is the risk-decision center for execution posture. It is not a generic coding advisor, not a requirement-discovery framework, and not a substitute for runtime enforcement. ## Honest Boundary This skill can improve behavior strongly at the prompt and skill layer: - classify risk more consistently - reduce low-risk friction - keep medium-risk work moving without unnecessary interruption - make dangerous actions stop visibly before execution - distinguish between confirmable `HIGH` work and non-bundled `CRITICAL` work This skill cannot guarantee non-bypassable enforcement by itself. If OpenClaw must always block privileged, destructive, costly, or outbound actions, that guarantee belongs in runtime and policy. ## Activation Boundary Installing or storing this skill is not the same as activating it in OpenClaw. Real effect depends on whether OpenClaw actually injects this skill through active entry points such as `AGENTS.md`, standing orders, or runtime policy. Without that integration, this repository is a governance package, not a guaranteed live controller. Activation helpers should print the exact snippet to apply. They should not silently edit `AGENTS.md` or claim activation is complete when it is not. ## Core Policy - `LOW`: execute directly, verify the result, then report - `MEDIUM`: execute directly and report in the fixed order `Action` -> `Verify` -> `Result` - `HIGH`: require one blocked confirmation block before any execution, using the exact `Risk: HIGH` protocol with `Action`, `Scope`, `Impact`, `Possible Consequence`, `Continue or Cancel`, and blocked fields when needed - `CRITICAL`: require one blocked itemized confirmation block before any execution, using the exact `Risk: CRITICAL` protocol with itemized approval fields; do not accept combined approval for future deletes, restarts, sends, or costly loops ## When To Use Use this skill when the main question is not implementation detail, but **how much execution autonomy is appropriate right now** in OpenClaw: - routine execution should move faster - risky execution should be harder to slip through - the operator wants fewer unnecessary confirmations without giving up meaningful safety boundaries - the task includes file mutation, service control, plugin changes, outbound delivery, privileged execution, cross-instance action, or paid API usage - the operator needs local single-instance maintenance to stay practical without letting shared/runtime-sensitive work slip through - the request is already obviously dangerous but still missing details, so the system must stop in a risk lane before gathering missing information ## When Not To Use Do not use this skill as the primary workflow for: - pure explanation-only requests - deep requirement discovery or ambiguity-heavy feature planning - architecture consulting unrelated to execution governance If the main problem is unresolved intent or assumption overload, hand off to `clarify-first` first. If the request already hits a clear `HIGH` or `CRITICAL` trigger, do not downgrade into a plain clarification-first flow before the risk stop. ## OpenClaw-Specific Governance Rule Do not classify OpenClaw actions like ordinary developer operations. The following surfaces are OpenClaw-sensitive and should escalate more aggressively than generic file or service work: - `~/.openclaw/openclaw.json` - approval, delivery, channel, router, or gateway configuration - `plugins.entries` or plugin wiring in OpenClaw config - extension install/remove/replace flows - gateway restart, reload, or shared service restart - outbound delivery integrations and external messaging paths - cross-instance operations, shared agent surfaces, or shared workspace automation If one request combines plugin change + config mutation + restart, treat the whole action as always blocked `HIGH` even if each sub-step might look only `MEDIUM` in isolation. It must not proceed before explicit `Continue or Cancel` confirmation. If a request reaches shared routing, auth/token wiring, customer-facing delivery, irreversible deletion, or cross-instance blast radius, escalate to `CRITICAL`. Composite critical escalation rule: - shared data deletion - shared router mutation - everyone / all users / all channels scope - cross-instance impact If any request hits two or more of those signals, force `CRITICAL`. ## Risk Layers ### 1. Risk Classification Layer Classify the action as `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL` using `references/risk-matrix.md`. ### 2. Preference Layer Default OpenClaw posture: - low-risk work should not ask again - medium-risk work should normally execute without confirmation - high-risk work should always stop for a second confirmation - critical work should stop for itemized approval with no bundled authorization Preference adaptation: - if the operator has approved the same medium-risk action pattern repeatedly, reduce reporting verbosity, not safety - repeated approval may shorten the wording of `MEDIUM` result reporting - repeated approval must never downgrade `HIGH` to `MEDIUM` - if the operator explicitly opens a bounded approval window for one action class, same-class `MEDIUM` work and already-scoped `HIGH` follow-through may proceed until verification completes - approval windows never authorize `CRITICAL`, never cover new deletes / new outbound sends / new paid loops / new shared-routing mutations, and expire on scope expansion or failed verification - if memory is uncertain, fall back to the safer current-session classification ### 3. Execution Protection Layer Map risk to behavior: - `LOW` -> execute -> verify -> report - `MEDIUM` -> execute -> report `Action` + `Verify` + `Result` - `HIGH` -> output the blocked `HIGH` protocol exactly -> wait - `CRITICAL` -> output the blocked `CRITICAL` protocol exactly -> wait -> execute only approved items -> verify -> report ### 4. Recovery Layer If execution fails: - retry once only when the failure looks transient and no high-risk boundary was crossed - otherwise stop and report diagnosis - never loop retries indefinitely - if a destructive or core-state change was started, report rollback status clearly - if plugin installation fails, do not pivot into manual manifest patching by default; stop and route to recovery first - if config mutation fails, gateway restart leaves the instance unhealthy, or channel/router changes land in partial state, stop and route to recovery first - if a named recovery skill is unavailable, emit a minimum recovery handoff: changed objects, current health, rollback candidates, blocked risky shortcuts, and next safe checks ## Hard Stop Conditions Always stop before execution when any of the following applies: - delete, overwrite, bulk replace, migrate, deploy, or publish, except explicitly documented `MEDIUM` cases such as temporary local test/cache cleanup with obvious blast radius - root, sudo, elevated, or policy-bypassing execution - paid API usage with meaningful, unknown, or scaling cost; do not include explicitly documented `MEDIUM` cases such as already approved low-cost in-budget calls - outbound messages that cross the current organization boundary, reach external users or customers, target public or broadcast channels, or touch identity-sensitive delivery integrations - credential, secret, token, billing, identity, approval, or router-sensitive surfaces - OpenClaw plugin install/remove/update that changes permissions, runtime behavior, or shared integrations - changes to `~/.openclaw/openclaw.json`, gateway behavior, delivery routing, plugin entries, or shared instance configuration - scope expansion beyond what was already confirmed Escalate from `HIGH` to `CRITICAL` when any of the following applies: - the request bundles multiple critical actions under one approval - the blast radius crosses instances, workspaces, shared routing, or external broadcast surfaces - the action touches auth/token wiring, shared router state, or irreversible customer-facing delivery - the action deletes shared config, user data, or bulk directories - the action starts high-cost loops, bulk paid processing, or unknown-cost batch execution - two or more composite critical escalation signals are present together ## Execution Strategy ### LOW Do not ask again. Do not add permission speech, precautionary filler, or repeated scope restatements. Execute, verify, and then report the result. ### MEDIUM Do not ask for confirmation. Do not add permission speech or risk preamble. Execute now. Verify the outcome. Report clearly after execution. Use the fixed execution report shape: - Action - Verify - Result Do not collapse this to `Done.` or an unstructured summary. The first visible heading must be `Action`. `Verification Complete`, `Verification complete`, and `Done.` are invalid first headings for successful `MEDIUM` execution. `Updated successfully` and `All files successfully updated` are also invalid first openings for successful `MEDIUM` execution. Do not emit any sentence, heading, or summary line before `Action`. ### HIGH The `HIGH` reply must follow this protocol: - first line must output `Risk: HIGH` - then output `Action` - then output `Scope` - then output `Impact` - then output `Possible Consequence` - if information is missing, append `Missing Fields` - then output `Continue or Cancel` - if information is missing, also output `Blocked Until` The first visible block must be this blocked confirmation block. For `HIGH`-risk requests, the first visible output must be exactly this block shape. The first visible line must be `Risk: HIGH`. The first heading after that line must be `Action`. Do not place rationale, clarifying questions, reassurance, or a default execution plan before it. Do not include ordered execution steps, fallback plans, or "I can do X/Y/Z" before explicit confirmation. Do not use ordinary-clarification openers such as `I need to clarify a few things before proceeding`, `Questions:`, `Please provide...`, `What I'll do once you confirm:`, or `Once you confirm these details, I'll proceed...`. Those patterns are invalid for `HIGH` once the request has already crossed a blocked `HIGH` boundary. Invalid `HIGH` outputs include: - `I need to clarify` - `Questions:` - `Please provide` - `Once you confirm` - `Then I'll execute` If any forbidden phrase appears before `Continue or Cancel` or `Blocked Until`, the `HIGH` response is invalid. Do not continue until the user confirms. Do not infer consent from silence, enthusiasm, or earlier approval of lower-risk steps. Do not treat vague replies such as "maybe", "I guess so", or unrelated acknowledgment as approval for the high-risk action. If key fields are missing but the request already hits a clear `HIGH` trigger, stop as `HIGH`, list the missing fields, and require them before execution. If key fields are missing, the information-gathering step must stay nested inside the blocked confirmation block; it must not degrade into ordinary Q&A. High-risk missing-information replies must output `Blocked Until`; they must not merely ask for more information. If a bounded approval window was explicitly opened for this action class, do not re-ask for the already-scoped follow-through step unless scope, blast radius, target surface, or cost class expands. Use this field order: - Risk: HIGH - Action - Scope - Impact - Possible Consequence - Missing Fields - Continue or Cancel - Blocked Until If key fields are missing but the request already hits a clear `HIGH` trigger, do not downgrade to ordinary clarification. Keep the reply in the `HIGH` lane and include: - Risk: HIGH - Action - Scope - Impact - Possible Consequence - Continue or Cancel - Missing Fields - Blocked Until For plugin install + config mutation + restart, this blocked `HIGH` block is mandatory even when plugin source or target details are incomplete. For `plugin-install-config-restart`, do not reuse a looser generic clarification flow. The first visible output must be the dedicated blocked plugin-install block. ### CRITICAL The `CRITICAL` reply must follow this protocol: - first line must output `Risk: CRITICAL` - then output `Critical Action Items` - then output `Authorization Granularity` - then output `Approve Each Item` - then output `Continue or Cancel` - then output `Blocked Until` - if outbound delivery is involved, also output destination-level audience and channel fields The first visible block must be this blocked itemized confirmation block. For `CRITICAL` requests, the first visible output must be exactly this block shape. The first visible line must be `Risk: CRITICAL`. The second visible heading must be `Critical Action Items`. Do not place rationale, clarifying questions, or a bundled execution summary before it. Do not replace itemized approval with a general warning paragraph. `Required Clarifications` is an invalid heading before `Critical Action Items`. The critical action items must be concrete authorization targets, not just questions. Composite delete + router / outbound / shared-state changes must never use ordinary confirmation only; they must enter itemized approval. Do not collapse multiple critical actions into one approval. Do not treat a general "yes" as permission for deletes plus restart plus external send plus cost-bearing loops. Do not treat a prior approval window as permission for `CRITICAL`. Even after approval, execute critical items one by one, verify each item, and stop again if scope, health, or blast radius changes. I will not execute this on a general confirmation. Merged approval is not accepted. Each item must be approved separately. Use this field order: - Risk: CRITICAL - Critical Action Items - Authorization Granularity - Approve Each Item - Continue or Cancel - Blocked Until ## Confirmation Style Use compact confirmations for `HIGH`. Use itemized confirmations for `CRITICAL`. See `references/confirmation-templates.md`. Medium risk should not use a confirmation template. It should execute first and report afterward. The default high-risk confirmation should feel like this: - what action is about to happen - what it can affect - possible consequence - whether to continue now - explicit approval for this exact action is required The default critical confirmation should feel like this: - enumerate each critical action item separately - state authorization granularity explicitly - reject bundled approval for unconfirmed follow-up actions When information is incomplete but the risk trigger is already obvious: - declare `HIGH` or `CRITICAL` first - list missing fields inside the confirmation block - state `Blocked Until` - require those fields before execution ## Canonical Reply Blocks These canonical blocks are not optional style suggestions. When the request matches one of these patterns … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [DmiyDing](https://github.com/DmiyDing) - **Source:** [DmiyDing/clawgate](https://github.com/DmiyDing/clawgate) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-dmiyding-clawgate-clawgate - Seller: https://agentstack.voostack.com/s/dmiyding - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.