The core security property of this channel is that reachability starts from an invitation, not from a public bot identity. OpenClaw then adds policy checks before a sender can trigger agent work. There are three boundaries to keep straight:Documentation Index
Fetch the complete documentation index at: https://openclaw-simplex.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
- the SimpleX invite or address link controls who can reach the agent at all
- OpenClaw policy controls who is allowed to trigger agent work after a message arrives
- the external
simplex-chatruntime boundary controls where process and relay trust live
Access controls
DM policy
open, allowlist, pairing, or disabled. This is the first policy gate OpenClaw applies to direct messages after they arrive from SimpleX.Allowlist
Explicit sender allowlist through
allowFrom. Use this when only known SimpleX contacts should be allowed to reach the agent.Group policy
open, allowlist, or disabled for group traffic. Combine this with mention requirements if you want the bot present in a group without answering every message.Pairing
Explicit approval flow for newly discovered contacts before they become trusted senders.
Operational boundaries
- OpenClaw only talks to an already-running
simplex-chatendpoint over WebSocket. - You decide where the runtime runs, which relay path it uses, and whether relays are public or self-hosted.
- If you need a fully internal deployment, keep
simplex-chatand your relays inside that network boundary. - External runtime mode is the supported deployment model for this plugin. OpenClaw does not spawn or supervise
simplex-chathere.
What this does not protect against
- Anyone with a currently valid invite or address link can attempt to contact the agent. Use pairing and allowlists if that link may be shared beyond your intended audience.
- If you set
dmPolicy: “open”andallowFrom: [”*”], a shared link becomes broad access to the agent. - If
simplex-chatuses public relays, traffic still traverses third-party relay infrastructure even though message contents are end-to-end encrypted.
Recommended production posture
- Start with
dmPolicy: "pairing"andgroupPolicy: "allowlist". - Keep
allowFrom/groupAllowFromnarrow. - Prefer one-time invite links for onboarding and revoke address links when they are no longer needed.
- Monitor status snapshots and logs for repeated authorization failures.