The Trust Boundary: Pairing, Policy, Sandboxing, and Secrets

OpenClaw’s security question is not simply whether a message is authenticated. It is which person or device may trigger work, which room may expose context, which tools the model may see, where those tools run, and which credentials or side effects cross the Gateway boundary. This chapter separates those gates and shows how to choose a hardened posture without mistaking a narrower policy for true isolation.

The distinction matters because the assistant now has durable memory, scheduled work, plugins, channels, and device capabilities. A malicious prompt can be relevant at several layers, but the layers do not solve the same problem. Pairing can keep an unknown sender out; it cannot make a trusted sender’s shell command safe. A sandbox can reduce filesystem reach; it cannot decide whether the sender was admitted. A protected credential can stay out of model context; it does not protect every file the host process can read.

Authentication is not the whole boundary

Start with a simple scenario: OpenClaw is present in a team chat, and someone asks it to inspect a private document and post a summary. Four different questions appear before any model reasoning should be trusted.

First, may this sender speak to the agent at all? Direct-message pairing and allowlists answer that question. In pairing mode, an unknown sender receives an approval code and the message is not processed until an operator approves it. In allowlist mode, the sender must match the configured identity. Pairing is an explicit access decision, not a claim that the person is safe to obey forever or that they may use every conversation the bot can see.

Second, may this room trigger work, and may this sender trigger it here? Group policy can disable rooms, restrict them to an allowlist, or admit a broader set. Group sender rules can narrow the people who may invoke the agent. Mention gating then decides whether a message addressed the assistant. These decisions are separate because a room can be allowed for context while ordinary chatter remains quiet, or a group can be admitted while only particular senders may activate it.

Third, which agent and session receive the request? Routing bindings choose the most specific matching agent, while session scope determines whether the conversation shares a main personal context or remains isolated as a group or room. This affects what the model can see and which workspace it uses, but it is not authentication. A session identifier is a routing selector, not a secret credential. If a person learns a session label, that fact should not grant them access; if a sender is admitted, that does not mean every session is visible to them.

Fourth, which Gateway operations may the authenticated client perform? Operator scopes and named roles provide a control-plane boundary inside the Gateway. A role can limit which agents a person may use, how they see other people’s sessions, which administrative scopes they can hold, and whether their newly created sessions must be sandboxed. Method authorization is derived from the actual request, so a method with a privileged parameter cannot become low-risk merely because its name sounds ordinary. Unknown scope classifications fail closed rather than silently granting a default permission.

These layers are useful precisely because they answer different questions. If an unknown sender is blocked before dispatch, no model behavior can turn that message into a tool call. If a group passes admission but mention gating fails, the message may remain context without becoming an active request.