OpenClaw published version 2026.8.1, branded OpenClaw 2.0, at 03:30 UTC on August 31 (11:30 p.m. Eastern on August 30). The project describes it as its largest update yet: more than 16,000 pull requests from 933 contributors, including 569 first-time contributors, after nearly seven weeks without a release. About half of all pull requests ever merged into OpenClaw landed in this cycle, according to the project’s launch post.

The browser rebuild will get immediate attention. Conversations now sit beside files, approvals, settings and live execution. The deeper operational change is multiplayer work.

A session’s coding work can move from the Gateway host to a paired device or cloud worker while the Gateway retains ownership of the conversation, reconciled workspace, model credentials and placement records. Another person can join the live work or take it over with the accumulated context intact. Warm machines and project seeds can then be reused for later cloud sessions, according to OpenClaw’s cloud-session documentation and the v2026.8.1 release.

That sounds like a collaboration feature because it is one. It also changes the object that security teams must model. An agent session may contain conversation history, edited files, an active terminal, approvals, tool permissions, memory and paths to protected credentials. Preserving that state through a human handoff and a move between computers creates continuity of authority as well as continuity of work.

The session carries authority

Before OpenClaw 2.0, an operator could reason about a personal agent largely through the identity of its owner and the machine running it. Shared cloud sessions add at least three questions: who can see the session, who can act inside it, and which execution environment receives its workspace and permissions.

OpenClaw addresses those questions in several layers.

Team operator roles can limit a verified user’s access to agents, other people’s sessions and operator scopes. Administrators may also require sandboxed execution for newly created sessions. The release notes supply the boundary in unusually plain language: these roles are “collaboration controls, not hostile-tenant isolation” (GitHub release).

OpenClaw’s security guidance makes the deployment rule explicit: mutually untrusted users require separate Gateways, ideally on separate OS users or hosts.

Roles help colleagues divide work inside a trusted organization. They provide no documented basis for putting mutually suspicious customers behind one Gateway and treating role assignments as tenant walls. A SaaS operator hosting separate clients needs separate Gateways, with each Gateway treated as one trust domain. Putting two customers inside the same Gateway would rely on controls whose publisher explicitly declines to characterize as hostile-tenant isolation.

OpenClaw’s own launch post describes the intended use through family and team collaboration. Its developers wanted to bring another team member into live work or hand off a task while retaining everything the agent already knew. The project says it now uses this workflow to build OpenClaw itself (OpenClaw blog). That is credible product evidence for trusted collaboration. It supplies no evidence for adversarial separation.

Independent coverage reaches the same deployment verdict. MarkTechPost calls the release suitable for single-operator and single-team deployments while rejecting it for multi-tenant products, citing documentation that describes the controls as neither tenant isolation nor a security boundary (MarkTechPost). The supplied sources contain no independent penetration test or cross-role escape assessment, so that verdict remains an architectural reading of published guarantees rather than proof of a known exploit.

Four permission systems now meet in one session

The role layer controls which person can reach which work. Session permission modes govern what that work can touch. OpenClaw lets operators select an explicit mode while anchoring restricted filesystem access to the recorded workspace or worktree. Newly created worktrees inherit configured policy unless the operator chooses another mode (GitHub release).

Credentials form a separate layer. An agent can request a credential through a masked prompt without placing the value in chat or model context. An optional proxy restricts protected-secret substitution to approved destinations. OpenClaw also adds a team-scoped credential store in SQLite, where secret values are write-only and protected egress can be bound to declared hosts. Environment values remain readable and are distinguished from secrets.

The distinction is sharp. A person may have permission to participate in a session while the agent receives narrower permission to use a credential against one host. That design can reduce casual secret exposure during collaboration, provided the destination policy and session access are configured correctly.

OpenClaw’s optional 1Password broker has a different exposure profile. It resolves selected fields with service-account authentication, per-secret approval and value-free auditing, but an agent-tool read exposes the selected value to the model for that execution. Operators need to classify credential paths by behavior instead of treating every secret integration as equivalent (GitHub release).

Recurring work adds a fourth layer. Version 2026.8.1 allows one approval for an exact automation operation, with later inspection and revocation. A changed job or operation requires fresh approval. This is a sensible capability boundary, though a valid recurring permission can outlive the human collaboration that produced it unless someone revokes it during offboarding.

Access reviews now need to cover people, sessions, credentials and durable automations together.

Handoff creates governance debt

Consider a customer-support agent running in a cloud session. An engineer joins to diagnose a failed integration, opens a shared terminal and approves a recurring operation. The session later moves to another worker, preserving its reconciled workspace. The engineer leaves the account team a week later.

Each feature behaved as designed. The governance failure appears if offboarding removes the engineer’s role while leaving the recurring permission, session participants, worker placement or team-scoped credential bindings untouched. Identity removal alone would give the operator a false sense of closure.

OpenClaw’s shared conversation terminals make the coupling even tighter. Browser viewers can share a terminal, and the agent may inspect or operate a terminal opened by an operator within that exact session and its permission policy. File uploads insert safely quoted paths without executing a command, but the terminal remains an execution surface attached to collaborative state (GitHub release).

Cloud placement deserves the same scrutiny. The new interface shows the active service, profile, machine resources and available worker slots. A cloud node boots from the running Gateway’s verified runtime artifact, and idle workers can be suspended and replaced on the next message while preserving the session and reconciled workspace. The machine changes. The Gateway-owned session and last-reconciled workspace survive.

The Signal's agent gateway primer describes a gateway as the control point for authentication, credentials, logging and emergency stops. OpenClaw 2.0 makes that definition concrete: the session is the durable unit of work, while the Gateway remains the durable unit of trust.

Incognito does not shrink the Gateway boundary

OpenClaw 2.0 adds incognito threads that retain Control UI transcripts and compaction state in Gateway memory until restart, with memory flushing disabled. Provider processing, diagnostic logs and explicit tool writes retain their own behavior (GitHub release).

Incognito therefore changes transcript persistence inside the Gateway. It supplies no general containment for model-provider disclosure, tool output, diagnostics or files already written by the agent. MarkTechPost also notes that incognito is disabled by default and still sends messages to the model provider (MarkTechPost).

Operators should label it as a retention mode. Calling it a private-session boundary would invite bad assumptions during audits and customer reviews.

The deployment decision

A company using OpenClaw internally can place a trusted team behind one Gateway, assign the smallest workable roles, require sandboxing for new sessions, anchor filesystem access to explicit workspaces and review recurring approvals during every role change. Private credential requests and destination-bound substitution can keep routine secrets out of chat and model context.

A managed-service operator should map each customer to a separate Gateway. Infrastructure automation can absorb the added operational cost through per-customer provisioning, updates, backups and recovery tests. OpenClaw already includes an experimental Fleet feature for creating separate cells on Docker or Podman hosts, with per-cell resources, logs, diagnostics and backup or restore, although its “experimental” label argues for validation before production use (GitHub release).

Shared Gateways remain appropriate where users accept the same administrative trust domain. Departments handling materially different data may also warrant separation even when everyone works for one company. Legal privilege, regulated records and production credentials can create hostile-tenant consequences without hostile employees.

The release documentation leaves several questions open. The supplied sources provide no formal Gateway threat model, cross-role authorization matrix, independent security assessment or measured isolation results for shared cloud sessions. They also give no detailed procedure for revoking a collaborator’s inherited access across active sessions, recurring approvals, cloud workers and team credentials in one operation.

The documentation states the limit plainly: one trusted boundary per Gateway.

Watch releases after August 31, 2026 for a formal Gateway threat model, cross-role isolation tests and a single revocation workflow spanning sessions, workers, credentials and recurring approvals.

The Signal is the public edge of a private practice. Sherpa points the same intelligence engine at one owner's business — competitors, suppliers, regulators, watched daily, graded and sourced. Work with a Sherpa →