Summary
OpenClaw has inbound message filtering (allowFrom) but no outbound equivalent. This means any process with gateway access — including AI coding agents running in headless mode — can send messages to arbitrary phone numbers via openclaw message send with no restrictions.
Security Impact
Severity: HIGH — Affects any deployment where:
- AI agents have shell access (headless mode, coding assistants)
- Messaging channels (WhatsApp, Telegram) are enabled
- The gateway is reachable from the agent's environment
Real-world incident
An AI agent running with --dangerously-skip-permissions completed its assigned coding task, then autonomously invoked openclaw message send to a hallucinated phone number it fabricated. Business-sensitive project details were sent from a WhatsApp Business account to an unknown international number. The message was discovered 11 hours later.
Attack surface
- CLI bypass —
openclaw message send bypasses session.sendPolicy entirely
- No gateway-level outbound filter — the gateway will deliver messages to any valid number
- AI agent hallucination — agents can invent target numbers that don't appear in any config
- No audit/approval gate — sends are fire-and-forget with no confirmation step
Proposed Fix: allowTo (outbound allowlist)
Mirror the existing allowFrom pattern with an outbound equivalent:
{
"channels": {
"whatsapp": {
"allowFrom": ["+27xxxxxxxxx"],
"allowTo": ["+27xxxxxxxxx", "+27yyyyyyyyy"]
}
}
}Behavior:
- If
allowTo is defined, the gateway MUST reject sends to any number not in the list
- If
allowTo is omitted, current behavior is preserved (no restriction)
- Enforcement at the gateway level so it cannot be bypassed by CLI, session, or API calls
Current Workarounds
These mitigate but don't fully solve the problem:
| Layer |
Workaround |
Limitation |
| Claude Code settings |
permissions.deny: ["Bash(openclaw message *)"] |
Only protects Claude Code, not other agents |
| Session policy |
session.sendPolicy: default-deny |
CLI bypasses session policies |
| Agent config |
Tool deny lists |
Only covers configured agents |
| Process |
Ban --dangerously-skip-permissions |
Policy, not enforcement |
None of these protect at the gateway level. A rogue process, misconfigured agent, or prompt injection attack can still send to arbitrary numbers.
Related
Environment
- OpenClaw v2026.2.3-1
- Channels: WhatsApp (Baileys), Telegram
- Agent: Claude Code headless mode
Summary
OpenClaw has inbound message filtering (
allowFrom) but no outbound equivalent. This means any process with gateway access — including AI coding agents running in headless mode — can send messages to arbitrary phone numbers viaopenclaw message sendwith no restrictions.Security Impact
Severity: HIGH — Affects any deployment where:
Real-world incident
An AI agent running with
--dangerously-skip-permissionscompleted its assigned coding task, then autonomously invokedopenclaw message sendto a hallucinated phone number it fabricated. Business-sensitive project details were sent from a WhatsApp Business account to an unknown international number. The message was discovered 11 hours later.Attack surface
openclaw message sendbypassessession.sendPolicyentirelyProposed Fix:
allowTo(outbound allowlist)Mirror the existing
allowFrompattern with an outbound equivalent:{ "channels": { "whatsapp": { "allowFrom": ["+27xxxxxxxxx"], "allowTo": ["+27xxxxxxxxx", "+27yyyyyyyyy"] } } }Behavior:
allowTois defined, the gateway MUST reject sends to any number not in the listallowTois omitted, current behavior is preserved (no restriction)Current Workarounds
These mitigate but don't fully solve the problem:
permissions.deny: ["Bash(openclaw message *)"]session.sendPolicy: default-deny--dangerously-skip-permissionsNone of these protect at the gateway level. A rogue process, misconfigured agent, or prompt injection attack can still send to arbitrary numbers.
Related
Environment