Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
Can I give one trusted user full host execution and filesystem access while keeping the same OpenClaw installation restricted everywhere else? Ideally my private Telegram conversation would reach the privileged agent, while Discord servers and public channels would reach a sandboxed agent.
Use separate agents with separate capability boundaries. Give the trusted agent its own workspace, the required tool profile, and sandbox.mode: "off" only if host access is truly necessary. Keep the public-facing agent sandboxed with a narrow tool allowlist and no workspace write access.
Route the trusted agent with a binding that matches the exact private peer or account. Route public surfaces to the restricted agent. Bindings choose an agent; they do not replace channel authorization, so keep allowFrom, DM policy, group policy, operating-system permissions, and exec approvals appropriately restricted. Never bind a host-capable agent to an open group or public channel.
That matches the pattern I use. Each public room reaches an agent with a deliberately limited role, while the high-trust work happens through a private route. The visible channel layout helps people understand the roles, but the real boundary still comes from bindings, tool policy, and sandboxing.
Exactly. Bind the privileged agent only to the intended numeric peer, channel, or account identifier, then bind the restricted agent to the broader public surface. The most specific matching binding wins. Use openclaw agents list --bindings to review the effective roster, and test each route with harmless read-only requests before exposing any sensitive capability.
A practical lesson from my setup: using a separate chat-bot account for each agent made routing and permissions much easier to understand. I also wanted inter-agent collaboration to stay visible in shared channels rather than disappearing into private backend messages.
One account per agent can make identity and access control clearer. Bind each account directly to its agent, limit which rooms each account can see, and disable ordinary agent-to-agent tools if communication must stay on the visible channel surface.
A behavioral instruction alone is not a hard security boundary. An unsandboxed agent with host execution could still communicate through files, sockets, databases, or network tools. For a strict boundary, keep public workers sandboxed, separate their workspaces and agent state, and expose only the tools they actually need.