Claw EA makes WhatsApp a controlled entry point for enterprise agents by running the agent in OpenClaw and forcing every sensitive action through policy checks, scoped credentials, and verifiable model-call evidence. You use a WPC to define what the agent is allowed to do, a CST to bind each run to that policy, and gateway receipts plus proof bundles to audit what the model actually asked for and what the system allowed.
WhatsApp is a good control plane when you want approvals and lightweight operator intervention to happen in the same conversation users already use. It is not a magic security boundary, so the execution layer must be permissioned (policy-as-code), not “prompt-only,” because prompts can be overwritten by user messages and injection attempts.
Step-by-step runbook
Use this flow when you want a WhatsApp-facing agent that can answer questions, request approvals, and perform limited work with a paper trail. The WhatsApp integration itself can be done via official API or via an MCP server, depending on your environment and vendor choice.
-
Define the WhatsApp channel contract. Decide what counts as “in-scope”: which WhatsApp numbers, which conversation types (1:1 vs group), and what the agent is allowed to do without approval. Write those rules into a WPC so enforcement does not depend on the prompt.
-
Register the WPC and record the policy hash. Store the signed Work Policy Contract (WPC) in the WPC registry (served by clawcontrols). Treat the policy hash as a deploy artifact that you can reference in tickets and change control.
-
Issue a CST for this job, pinned to the policy. Use a CST (issued by clawscope) that includes a scope hash and, when you want fail-closed behavior, optional policy hash pinning to the WPC. This prevents a WhatsApp-triggered run from silently widening privileges.
-
Run the agent in OpenClaw with conservative local controls. Configure OpenClaw tool policy (allow and deny lists) and sandbox mode so that tool execution has a smaller blast radius. Make “no tools by default” the starting point, then allow only what the WPC requires.
-
Route model traffic through clawproxy. Send model calls through clawproxy so you get gateway receipts for each call, including binding to the job-scoped CST. If you use OpenRouter via fal, route it through clawproxy for the same receipt behavior.
-
Build approvals into the WhatsApp conversation. For actions that change state (refunds, cancellations, outbound emails, updates to CRM), require an explicit “approve” message and tie that approval to a single job-scoped CST so it cannot be replayed later. Store the approval decision as part of the run metadata that is included with the proof bundle.
-
Produce a proof bundle and store it for audit. At the end of the run, output a proof bundle that includes gateway receipts and the policy identifiers used. Optionally store and view the artifact in Trust Pulse when you need a reviewable record.
Threat model
WhatsApp increases operational risk because any inbound message is untrusted input, and operators tend to treat chat threads as “informal.” The safe pattern is: treat WhatsApp as the UI, and treat execution as a separate permissioned system that enforces WPC and CST constraints.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection from a user message | The model is instructed to ignore policy and take an unsafe tool action. | Enforce permissions in code via WPC plus OpenClaw tool policy; the prompt can suggest, but the runtime denies disallowed tools and operations. |
| Impersonation of an approver | Someone spoofs an “approve” message to trigger a sensitive action. | Require approver identity checks outside the model (enterprise buildout) and bind the approval to a job-scoped CST so it cannot be replayed in another run. |
| Replay of an earlier approval | An attacker copies an “approved” snippet from an old chat and reuses it. | Marketplace anti-replay binding using job-scoped CST binding, and verify that the approval is attached to the current job id and policy hash. |
| Model-provider dispute or audit gap | You cannot prove what the model call contained or which model was used. | Route model calls through clawproxy and retain gateway receipts; verify receipts and package them in a proof bundle for audit. |
| Over-broad local tool access | The agent can read files, hit internal URLs, or execute shell commands beyond intent. | Use OpenClaw sandboxing where appropriate and keep tool allowlists tight; treat “elevated” host execution as exceptional and explicitly gated. |
Policy-as-code example
This snippet is intentionally small and operational. It models a WhatsApp-triggered agent that can answer questions and open tickets, but requires explicit approval for state-changing actions and pins the run to a specific WPC hash.
{
"wpc_version": "wpc.v1",
"channel": {
"type": "whatsapp",
"inbound": {
"allowed_senders": ["+15551230001", "+15551230002"],
"allow_groups": false
},
"approvals": {
"required_for": ["refund", "cancel_order", "send_external_message"],
"format": "APPROVE "
}
},
"execution": {
"runtime": "openclaw",
"sandbox": { "mode": "all", "workspaceAccess": "ro" },
"tools": {
"allow": ["kb.search", "ticket.create"],
"deny": ["shell.exec", "filesystem.read", "filesystem.write"]
}
},
"auth": {
"cst": {
"require_scope_hash": true,
"pin_policy_hash": "b64u:POLICY_HASH_FROM_WPC_REGISTRY"
}
},
"model_calls": {
"must_go_via": "clawproxy",
"receipts": "required"
}
}
The key idea is separation of concerns: the WhatsApp message can request a refund, but the refund tool is not available unless an approval step is satisfied and the WPC permits that action. If the model tries anyway, the tool call is denied and the attempt is visible in logs and proofs.
What proof do you get?
For each model call routed through clawproxy, you get gateway receipts that can be verified later. Those receipts are bound to the CST used for the job, so you can show that a given run was operating under a specific scope and, when pinned, a specific WPC hash.
At the run level, you get a proof bundle that collects receipts and the metadata needed to audit the run. When you need a reviewable artifact for risk, audit, or customer support escalation, you can store and view the proof bundle in Trust Pulse.
Rollback posture
Chat-driven agents fail in messy ways: wrong tool call, wrong recipient, wrong timing. Rollback is mostly about having tight permissions, quick disable paths, and evidence that lets humans remediate fast.
| Action | Safe rollback | Evidence |
|---|---|---|
| Policy mistake (too permissive) | Rotate to a stricter WPC and require CST policy hash pinning for new jobs; stop issuing CSTs for the old policy. | WPC hash in the proof bundle, and CST metadata showing which jobs ran under which policy. |
| Compromised or misused token | Revoke CST issuance path and re-issue short-lived CSTs for new jobs; invalidate the job scope. | CST usage can be correlated to gateway receipts, showing which model calls were made under that token. |
| Bad model output that triggers unsafe intent | Deny the tool call at policy enforcement; require explicit approval for the action class going forward. | Gateway receipts show the attempted model call sequence; the proof bundle shows that the runtime denied disallowed actions. |
| Wrong recipient or conversation routing | Disable the WhatsApp channel mapping (via official API or enterprise buildout) and re-enable only after allowlist review. | Run metadata plus your channel logs; proof bundle anchors the timing and job id that produced the outbound attempt. |
FAQ
Why isn’t prompt-only control sufficient for WhatsApp agents?
Because the next inbound message can overwrite instructions, and the model can be coerced into attempting disallowed actions. Policy-as-code (WPC plus runtime enforcement) makes the permission boundary non-negotiable even when the conversation is adversarial.
How do approvals show up in WhatsApp?
Approvals can be a simple explicit message like “APPROVE <job_id>” in the same thread, with the agent refusing to proceed without it. The approval is then tied to the job-scoped CST binding so it cannot be reused for a different run.
What exactly is auditable after an incident?
You can produce gateway receipts for model calls and a proof bundle that groups them with job metadata and policy identifiers. That lets an auditor verify which policy was supposed to apply, which token scope was used, and what model calls were made through the proxy.
Can Claw EA connect directly to the WhatsApp Business Platform?
It depends on your setup. Integrations are done via official API or via an MCP server, and enterprise buildout is typical when you need strict identity, approvals, or custom routing.
Where does OpenClaw fit compared to Claw Bureau primitives?
OpenClaw is the baseline agent runtime that runs tools, channels, and sandboxing locally. Claw Bureau primitives add portable policy (WPC), scoped authorization (CST), and verifiable evidence (gateway receipts and proof bundles) around those runs.