A self-hosted AI agent fails first on trust design, not on install steps. One Gateway or process that sees shared credentials, shared conversation context, and shared tool authority is one trust boundary. Put mutually adversarial users inside that boundary and you get a shared blast radius, not multi-tenant isolation.
This post is about when one OpenClaw Gateway or Hermes process is enough, and when you must split Gateways, credentials, OS users, or hosts. It extends the OpenClaw business setup guide, the Hermes Agent business setup guide, and the self-hosted AI agent deployment checklist. It does not repeat install commands.
What the platforms actually say
OpenClaw's security guide states the model plainly: one trust boundary per Gateway. A single operator, or a team whose members trust each other, can share a Gateway. Group chats and multi-user operation are supported *inside* that boundary. OpenClaw is not a hostile multi-tenant security boundary for mutually adversarial users sharing one agent or Gateway. For mixed-trust or adversarial-user operation, split trust boundaries: separate Gateway plus credentials, and ideally separate OS users or hosts. After configuration changes, run `openclaw security audit` so drift shows up before a new network surface does.
Hermes Agent's security guide describes layered controls for a personal-agent style deployment: user allowlists and DM pairing that default-deny unknown senders, dangerous-command approvals, file-write guards, container backends, MCP credential filtering, and related checks. Authorization is who may talk to the agent. Approvals and write guards reduce damage inside that operator boundary. Hermes documents write guards as defense in depth, not a full sandbox: a host terminal running as the same OS user can still reach paths those guards block. For production Gateways, prefer container backends (`docker`, `modal`, `daytona`, or `vercel_sandbox`) and never run the Gateway as root. Treat one Hermes process the same way you treat one OpenClaw Gateway: single-tenant style authorization for a trusted operator group, not hostile multi-tenant isolation between customers or rival teams. For a product-level compare, see OpenClaw vs Hermes Agent.
Team sharing is not the same as multi-tenant isolation
A trusted ops team can share one Gateway when everyone inside that boundary may see the same sessions, tools, and secrets. That is a normal team deployment for OpenClaw when you configure it that way, and a normal Hermes profile or Gateway for a known allowlisted operator set.
Mixed trust looks different:
- two client companies on one agent;
- finance and an external contractor on the same credentials;
- a public channel that can reach owner-level tools;
- departments that must not read each other's transcripts or API keys.
Those cases need separate boundaries. Separate means separate Gateway or process, separate credentials, and ideally separate OS users or hosts. Session labels and polite prompts do not create that split.
When one Gateway or process is OK
Keep a single boundary when all of the following are true:
- 1Every person who can talk to the agent is inside one trusted operator group.
- 2Every connected channel (Slack, Telegram, WhatsApp, email, and so on) is allowlisted or paired for that same group.
- 3Tool credentials are scoped to work that group is allowed to perform.
- 4Secrets, workspace files, and transcripts may be visible to that group.
- 5Someone named owns patches, audits, backups, and incident response for that host.
Typical fits: a founder laptop pilot; one ops owner's always-on assistant; a small internal team that already shares CRM and inbox access for the same workflow.
When to split boundaries
Split when any of the following is true:
| Signal | Why it matters | Split at least |
|---|---|---|
| Mutually adversarial users (clients, tenants, rival teams) | One process shares tools, memory, and often credentials | Separate Gateway/process + credentials; prefer separate OS users/hosts |
| Different data classes (PHI vs marketing drafts) | Transcripts and tool results cross-contaminate inside one boundary | Separate hosts or strong OS isolation plus separate credentials |
| Different authority (read-only research vs money-moving tools) | A shared session can reach the higher privilege | Separate agent identities and tool credentials; see permissions and approval |
| Untrusted content surfaces (public webhooks, open DMs, scraped pages) | Prompt injection rides trusted operator paths | Narrow tools, sandbox/container backends, separate low-privilege host |
| Compliance or customer contract requires isolation | Shared logs and keys fail the contract even if "nobody looked" | Separate hosts and credential vaults per boundary |
| One compromised channel would expose unrelated businesses | Blast radius spans customers | Separate Gateways/processes per customer or per trust zone |
OpenClaw's guidance for mixed-trust operation is explicit: separate Gateway and credentials, ideally separate OS users or hosts. Hermes production guidance points the same direction: container backends for Gateways, non-root runtime, explicit allowlists, and network isolation when you need the Gateway away from the execution host.
Decision table: keep one boundary or split
| Situation | One Gateway/process OK? | Action |
|---|---|---|
| Solo operator, private channels, narrow tools | Yes | One host, non-root service account, private bind, audit after config changes |
| Small team that already shares the same CRM/inbox authority | Yes, if all members are trusted peers | One team Gateway; owner-only control plane; documented operator |
| Two departments that must not see each other's tickets | No | Separate Gateways/processes and credentials |
| MSP running agents for multiple customers | No | One boundary per customer; separate hosts when contracts require it |
| Pilot on a laptop, production always-on later | Pilot yes; production separate | Move production to a dedicated VM/host before widening tools |
| Shared Slack workspace plus owner WhatsApp with elevated tools | Usually no | Split elevated personal surface from team surface |
| Research-only agent and payout-capable agent | No for shared tools | Separate identities; approval gates on money tools |
Checklist: team boundary vs one-machine boundary
Use this before you call the deployment ready.
| Check | One-machine / solo | Shared team boundary | Must split |
|---|---|---|---|
| Who may message the agent | Single allowlisted operator | Named trusted peers only | Unknown or adversarial users present |
| Channel policy | Private; pairing/allowlist on | Same; no open DMs in production | Public or customer-mixed channels on one agent |
| Credentials | Dedicated non-root identity | Shared only inside the trusted group | Customer or department keys mixed |
| Tools | Least privilege for one workflow | Same tools everyone in the group may use | Money, delete, or admin tools mixed with research |
| Host isolation | Dedicated user on dedicated host for always-on | Same host OK only while trust holds | Separate OS users/hosts for mixed trust |
| Sandbox / container | Decide explicitly (OpenClaw sandbox is off by default; Hermes production Gateways should prefer container backends) | Same | Untrusted input or hostile tenants require stronger isolation |
| Audit | `openclaw security audit` after changes; Hermes allowlist and approval review | Same, plus who can change config | Per-boundary audits and secret rotation |
| Incident owner | Named person | Named person for the team boundary | Owner per customer or trust zone |
| Backups and logs | Scoped to that boundary | Shared only with the trusted group | No cross-customer transcript or secret backup |
If a row fails, shrink tools or split the boundary. Do not paper over the gap with a longer system prompt.
Practical hardening that stays inside one boundary
Splitting is the isolation control. Inside a single trusted boundary, still harden the host:
- Run as a non-root OS user on a dedicated machine for always-on work.
- Keep the Gateway private (loopback or private network). Do not expose the control plane to the open internet without the platform exposure checklist.
- Keep channel access on pairing or allowlists. Default-deny unknown senders.
- Turn sandboxing or container backends on when tools can touch the filesystem or shell. OpenClaw sandboxing is off by default; enable it when tool execution should leave the host process. Hermes write guards help and are still not a full sandbox on a host terminal.
- Run `openclaw security audit` after config changes. On Hermes, review allowlists, `approvals.mode`, `approvals.deny`, and whether production still runs on a container backend.
- Bind human approval to exact high-impact actions. Approval inside one boundary does not replace a missing boundary between customers.
How this fits OrchestriAI delivery
OpenClaw setup and Hermes Agent setup cover install, channel wiring, and the first hardened baseline for a chosen boundary. AI agent systems define what the agent may do once that boundary is fixed. Systems integration keeps credentials, queues, and side effects on identities that match the split you chose.
The operating rule is short: one trusted group per Gateway or process. Team sharing is configuration inside that rule. Customer or department isolation is a different Gateway, different credentials, and usually a different host.
