Two AI‑agent platforms released in August added a persistent “coworker” UI, but they chose different places to draw the bot security boundary. Hermes ships Bot Mode by default, isolating each bot in its own profile directory, while SpaceXAI’s Grok Bot keeps every bot on a single user account with shared workspace, cookies, and credentials. The distinction matters because a mistake in one bot can now either stay confined to its profile or spill over to every other bot, depending on the product.
Different Isolation Models
Grok Bot treats the user account as the security perimeter. All bots run on a single persistent cloud machine; the filesystem path /workspace and the browser session are common to the entire roster. The UI presents separate screens, but the documentation calls them “work surfaces, not security boundaries.” Consequently, any credential or file placed on the machine is reachable by every bot, and a login session opened by one bot is automatically available to the others.
Hermes flips the model: each bot is a profile with its own directory that stores configuration, memory, skills, credentials, and chat history. Handoffs invoke the target profile rather than passing a shared blob. Bot Mode is enabled automatically in version v0.20.3, so new users receive a roster without opting in. While profiles keep state separate, they still share the host OS user and filesystem permissions, and the credential store does not enforce distinct secrets unless the operator configures them.
OpenClaw adds an optional Docker‑based sandbox. When enabled, each agent runs inside an isolated container, with a per‑agent workspace and auth file. Operators can tune network isolation, resource limits, and tool policies. The default is sandbox off, and a Docker‑socket failure silently disables the sandbox, leaving the agent running on the host.
ClawFleet (mentioned briefly) defines the boundary at the container level, similar to OpenClaw’s containerized approach.
Operational and Security Implications
- Shared account (Grok Bot) means any credential leakage or malicious file created by one bot is instantly visible to the rest of the roster. Operators must treat the entire machine as a single trust zone.
- Profile‑based isolation (Hermes) reduces accidental spillover but does not prevent a deliberately shared credential or a mis‑configured profile from exposing secrets across bots.
- Container sandbox (OpenClaw) offers the strongest technical isolation, but the default off setting and silent fallback on Docker errors can give a false sense of security.
- All four products still rely on the same host OS user, so OS‑level permissions, patching, and host hardening remain critical regardless of the chosen boundary.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
When adopting a persistent AI‑agent interface, start by mapping the product’s isolation model to your risk tolerance. If you need strict separation of credentials, prefer a container‑based sandbox and verify that it stays enabled even after setup failures. With profile‑based tools, audit each profile’s credential store and enforce least‑privilege OS permissions. For shared‑account solutions, treat the entire workspace as a single privileged entity and avoid placing sensitive material on the machine.
Key actions:
- Document which security boundary each bot platform uses and align it with your organization’s isolation requirements.
- Validate that sandbox or container modes are active and monitor for fallback behavior that disables isolation.
- Implement host‑level controls (file permissions, OS user separation, regular patching) to compensate for any residual shared‑resource risk.
- Regularly review bot profiles or accounts for unintended credential duplication.
Choosing the right boundary now prevents a single bot’s error from becoming a platform‑wide breach later.
