Set channel and trust boundaries before exposure

Verifiedon 2026-07-302026.7.1-2

A channel is an ingress path, not a trust decision

Telegram, Slack, Discord, WhatsApp, WebChat, and other surfaces all connect through the Gateway, but they do not become equivalent because the adapter is installed. A channel controls how messages arrive and how replies are delivered. The operator still has to decide which senders can trigger a turn, what quoted or forwarded material enters context, which tools are visible, and who may receive an external response.

The primary chat channels source lists included and plugin channels, and points to pairing, allowlists, group behaviour, and troubleshooting. The exact-revision security model states the key boundary plainly: one Gateway is designed for one trusted operator boundary, not hostile multi-tenant use by mutually adversarial people. If several untrusted users can message one tool-enabled agent, they share delegated tool authority; separate Gateway cells, credentials, and ideally OS users or hosts are required.

A useful boundary table names both the happy path and the abuse path. “Allowlisted team” answers who may start a turn; it does not say what a forwarded invoice, attachment, or quoted instruction can make the model believe. “Paired browser node” answers a device relationship; it does not say which websites, accounts, or commands the workflow may touch. “Private network” reduces exposure; it does not remove the need for Gateway authentication and least capability. Write those limits down before the first connection so they cannot be forgotten during setup.

Worked example: a fictional four-surface bot

Imagine a team bot with Telegram DMs, a Slack support room, WebChat for the operator, and one browser-capable node. The first draft says “all are approved.” Replace that with a boundary matrix:

The matrix forces a difficult but correct answer: the customer is not made safe by a more descriptive session key. If the bot must serve that customer, create a separate trust cell and review its credentials, tool policy, channel allowlist, and recipient path. “We will keep the customer in a separate session” can be a routing improvement, not a security boundary.

Lab: design before exposure

Use the fictional matrix, or create your own redacted version. For each channel, name the accepted identity pattern, DM/group policy, mention or pairing behaviour, input categories, tool profile, node permissions, recipient class, owner, and rollback. Add a column labelled what this does not protect against. Good entries include “does not sanitize forwarded content,” “does not authenticate a session key,” and “does not make a shared Gateway multi-tenant.”

Do not publish or run a real configuration from this lab. A learner artifact is a review worksheet, not a deployable token-bearing file. Test it with five scenarios: unknown DM sender, allowlisted room with a malicious attachment, operator asking for a browser side effect, paired node with an unexpected capability, and a contractor who must not share operator authority.

surface: support-room
identity: allowlisted-team + mention-required
context: room text + attachments = untrusted
tools: read-only lookup fixture
recipient: same allowlisted room, delivery review required
owner: security-operator
rollback: disable channel + revoke credential + audit

Why remote exposure is a separate decision

The Gateway security source puts network exposure near the top of its triage order. A local loopback Gateway, a private tailnet/VPN route, a reverse proxy, and a public bind are different threat surfaces. Pairing a node also does not remove Gateway authentication requirements. Treat browser-control ports and remote node execution as operator-level access, not as ordinary chat input.

The source documents openclaw security audit and its --deep, --fix, and --json forms as the post-change/pre-exposure check. It also distinguishes pairing, allowlist, open, and disabled DM policies. Do not copy a baseline configuration into production from this lesson: use the current source and the owner’s environment-specific runbook, then capture the audit result without secrets.

Failure cases and rollback

The obvious failure is groupPolicy: open or dmPolicy: open paired with powerful tools. Less obvious failures include an allowlisted sender forwarding untrusted instructions, a shared room receiving private recall, a node that is paired but has more capabilities than the workflow needs, and a “private” reverse proxy that is reachable outside the intended network. Prompt context controls are defense in depth; they are not hostile-user authorization.

If a channel is widened accidentally, do not continue testing through it. Restore the previous approved access posture, disable or unpair the channel/node, revoke any exposed credential, retain a redacted audit record, and request a security review. If the owner or rollback path is unknown, leave the surface disabled. The correct lab rollback is to remove the fictional row or set it to not approved, not to connect a real account “just to see.”

Source receipt and five-question check

Reviewed against OpenClaw stable 2026.7.1-2, revision 2e26244cec32e61f6117740d3ea273b1ecb54efc, on 2026-07-30. Re-read the channel index and security receipt before teaching changed policies or supported channels. This is a source review, not approval to expose a Gateway.

1. Is a channel plugin automatically trusted because it is installed? No; policy, credentials, sender access, and tool scope still matter.
2. Does a paired device remove Gateway authentication requirements? No.
3. What should be fixed first when an open room can access powerful tools? Inbound access and tool blast radius.
4. What access pattern is preferred for remote operation? A private network such as a tailnet/VPN; do not casually publish the Gateway.
5. Who owns a new exposure? The accountable security/operator owner, with rollback evidence.