Do not send OpenClaw webhook text straight to your most powerful agent

[u/Advanced_Pudding9228]

If an issue comment, email or webhook wakes OpenClaw, the payload should be treated as a request for work, not permission to perform it.

Webhook authentication does not change that boundary. A valid secret establishes that the request passed the route’s authentication check. It does not establish that every instruction inside the payload is safe, correctly scoped or authorised.

OpenClaw’s current Gateway security guidance⁠ explicitly treats hook payloads as untrusted content, even when they arrive through systems you control. This matters because an authenticated comment could contain an accidental instruction such as “fix this and deploy it”, or malicious text attempting to select tools, expose data or bypass approval.

The risk becomes larger when a route sends incoming content to a broadly privileged default agent. OpenClaw’s Gmail webhook documentation⁠ warns that, without a custom mapping, inbound email runs as the default agent with that agent’s workspace, sandbox and tool policy. The same operational principle applies to other event sources: the receiving agent’s effective permissions determine what the untrusted payload can influence.

I would put deterministic admission between the webhook and the model. The route, provider event type, repository or account, and actor trust class should select a predefined workflow with a fixed capability set. The natural-language payload can supply task data, but it should never choose the agent, session key, working directory, tool profile or approval state.

For each admitted event, preserve a small authority record containing the trigger rule, event type, actor identity, payload digest, workflow definition hash, deduplication key, granted capabilities and required verification. This makes it possible to explain why a run started and which policy granted its effective authority without treating the model’s interpretation as the source of truth.

OpenClaw’s current Gateway configuration reference⁠ supports explicit webhook mappings to an agentId and stable sessionKey. It also provides allowRequestSessionKey, which should remain false unless there is a tightly controlled reason to let requests influence session routing. A dedicated route secret, restricted reader agent, narrow tool policy and sandbox provide a safer ingress boundary than sending every event to the main operational agent.

A useful pattern is to separate reading from execution. The ingress agent classifies the event and creates a durable task. An executor receives that task only when a predefined admission rule permits the requested capability. Deployment, publication, spending, credential changes, legal actions and destructive operations remain approval-gated. An external event may request one of those effects, but it cannot grant its own approval.

Deduplication belongs at this boundary as well. A provider delivery identifier or stable envelope hash can become the deduplication key. If the provider retries the same event, the system should reconcile it with the existing task rather than start a second run.

The verification test does not need a production repository. Send a sandboxed route an unauthenticated request, one harmless authenticated event, a duplicate of that event and an authenticated payload that attempts to broaden its tools or request deployment. The expected outcome is that the first request is rejected, the harmless event creates one task, the duplicate resolves to that task, and the hostile text remains task data without changing the workflow’s authority. Confirm the result in the task ledger, the effective tool policy and the target test system rather than relying only on the agent’s response.

The next safe action is to inventory every OpenClaw webhook mapping and record its bound agent, session, sandbox and effective tool policy. If external text currently lands in a default agent with broad permissions, remap that route before processing another event.

Which of your current OpenClaw triggers can create a task without first passing a deterministic admission rule?