openclaw - 💡(How to fix) Fix [Feature]: Optional pre-tool runtime governance hook for agent actions

Summary

Add an optional pre-execution validation hook so external governance systems can approve, flag, or reject tool actions before OpenClaw executes them.

Problem to solve

Lack of a runtime governance for AI Agents.

OpenClaw is powerful because it can act across many real channels, tools, and host surfaces. Some users may want an additional runtime trust layer before actions execute, for higher-risk tool calls.

Users rely on prompts, sandboxing, allowlists, and configurationS, but there does not appear to be a general optional hook for “the agent intends to do X; let an external policy/governance service validate that action before execution.”

This is most relevant for users who want:

• an explicit runtime decision before tool execution
• audit-friendly approve/flag/reject outcomes
• optional external policy enforcement without replacing OpenClaw’s existing model/tool architecture

Current behavior is sufficient for many users, but for users evaluating external governance systems, there is no obvious supported seam to integrate pre-execution validation cleanly.

Proposed solution

Add a small optional extension point for pre-tool validation.

Conceptually:

1. Agent decides to invoke a tool/action
2. OpenClaw calls an optional validator hook with structured action data
3. Validator returns one of:
   • approved
   • flagged
   • rejected
4. OpenClaw applies configured behavior:
   • approved -> execute
   • flagged -> warn and either continue or follow configured policy
   • rejected -> block execution

Suggested shape:

• plugin-first if possible, not core-only policy logic
• disabled by default
• no behavior change unless explicitly configured
• invoked immediately before tool execution
• payload should include at least:
  • tool/action name
  • tool parameters
  • optional context metadata
  • session/agent identity as appropriate
• validator result should include:
  • decision/result
  • optional trust score
  • optional reason/violations/metadata

I am not attached to a specific API surface. I mainly want guidance on whether this should be:

• a third-party plugin
• a bundled plugin
• or a small core hook that plugins can implement

My main goal is to use the right extension point rather than force a new architecture into core. I’m interested in integrating Cerone (pip install cerone) as one example of an external runtime governance system. Before building anything, I wanted to ask whether OpenClaw has, or should have, a generic optional hook for validating tool actions before execution.

Alternatives considered

1. Prompt-only governance This is weaker because it influences model behavior but does not create a hard pre-execution checkpoint.

2. Sandbox-only controls Sandboxing helps contain execution, but it is not the same as validating the semantic intent of a tool/action before it runs.

3. Per-tool bespoke wrappers Possible, but harder to maintain and less reusable than a single pre-execution seam.

4. Direct core integration for one governance vendor This seems weaker than a generic hook because it couples OpenClaw core to one provider and is less likely to be broadly acceptable.

Impact

Affected users/systems/channels:

• users running OpenClaw with real external tools and messaging channels
• especially users with higher-sensitivity workflows, shared environments, or governance requirements

Severity:

• low for casual/personal-only users
• medium to high for users who need a runtime trust checkpoint before actions execute

Frequency:

• potentially every tool/action invocation when enabled

Consequence:

• without a clean hook, users must rely on prompts or ad hoc wrappers
• this increases integration complexity and makes governance/audit behavior inconsistent
• users evaluating external governance systems may avoid OpenClaw integration entirely if there is no supported seam

Evidence/examples

Example minimal optional middleware:

• disabled by default
• no effect when not configured
• validates actions before tool execution
• supports approved / flagged / rejected
• fail-open on transport/timeouts
• blocks only on explicit rejected

That experience suggests the feature can stay small if there is already a good interception point.

Example desired action payload shape:

{
  "tool": "gmail_send",
  "parameters": {
    "to": "[email protected]",
    "subject": "Hello"
  },
  "context": {
    "source": "openclaw"
  }
}


### Additional information

Important aspects:

- remains optional and backward-compatible
- does not change default behavior for existing users
- will be a plugin-first if that matches OpenClaw’s architecture
- will preserve existing sandbox/tool/channel boundaries rather than bypass them

The main thing I’m asking for right now is architectural guidance:

- Is this in scope?
- If yes, what is the right extension point?
- Should this be proposed strictly as a plugin rather than a core feature?

Disclaimer : Cerone is available on PyPI ( https://pypi.org/project/cerone/ ) and on the Homer Semantics website : https://www.homersemantics.com/ai-agent-governance-and-oauth

Thank you.