OpenClaw 2026.9.2 changes the default trust model for multi-agent deployments. The release turns on ordinary agent-to-agent session access by default and sets session tools to Gateway-wide visibility, while also enabling the experimental Swarm orchestration feature by default.
The change is documented, not a security bypass. OpenClaw explicitly defines one Gateway as one trust boundary and says mutually untrusted users should not share it. But the new defaults matter operationally because a team that treated separate agent personas as confidentiality boundaries can now expose their session history to other unsandboxed, tool-enabled agents unless administrators narrow the configuration.
Cross-agent access is now the default
The September 5 release states that session tools now default to all-session visibility and ordinary agent-to-agent access is enabled. The current security documentation is more precise: tools.sessions.visibility defaults to all and tools.agentToAgent.enabled defaults to true.
Under that configuration, OpenClaw says an unsandboxed agent with session tools can list, read, search and message every agent's sessions, including transcripts belonging to other users. Sandboxed agents remain limited as callers to their own spawn tree by default, but their transcripts are still visible to unsandboxed agents.
This is not presented by the project as tenant isolation. OpenClaw says authenticated operator access inside a Gateway is a trusted control-plane role and recommends separate Gateways, credentials and preferably separate operating-system users or hosts for mixed-trust or adversarial deployments.
That distinction is important. A security review should not call the new default an authorization bypass when it matches the documented trust model. It should ask a different question: does the deployment's actual trust model match the Gateway boundary that OpenClaw assumes?
Swarm expands orchestration, but not tool authority
Version 2026.9.2 also enables Swarm by default. Swarm is an experimental orchestration layer for concurrent sub-agents. It supports structured results, bounded concurrency and progress reporting, and can be used through Code Mode or lower-level session tools.
OpenClaw documents several constraints that prevent the feature from automatically becoming unrestricted autonomy. Code Mode remains separately opt-in. Existing tool policies, allowlists, provider rules and sandbox restrictions still apply. Enabling Swarm does not grant tools that an agent could not already use, and collector children deny actions that require an interactive operator approval.
Those limits make the release more interesting, not less. OpenClaw is expanding the ability to coordinate many agents while simultaneously making cross-agent session reach broader by default. The two changes affect different layers: Swarm controls how work is delegated, while session visibility controls what context and conversations another agent can reach.
The real boundary is the Gateway, not the persona
Aipolix's practical conclusion is that an OpenClaw persona should not be treated as a confidentiality boundary unless the configuration makes it one.
This matters for deployments that put several roles under one Gateway, for example a personal assistant, a finance agent and an engineering agent. If those roles have different data sensitivity or different users, separate prompts and tool profiles are not sufficient isolation. OpenClaw's own documentation notes that tool profiles do not narrow session-tool reach, and an unsandboxed agent can still read a sandboxed agent's sessions under the default Gateway-wide visibility.
The control decision therefore belongs at deployment architecture level. For mutually trusted personas, the default can be a deliberate convenience. For different trust levels, OpenClaw recommends setting tools.sessions.visibility to agent or self, restricting allowed agent pairs with tools.agentToAgent.allow, or disabling agent-to-agent access. For genuinely adversarial or separate-tenant workloads, the project recommends separate Gateways.
That is a more useful model than assuming every agent identity is a security principal. The release effectively makes the Gateway the unit that architects must map to a real organizational trust domain.
Upgrades need a trust-boundary check
Because the change arrives as a release default, upgrading deserves more than a feature checklist. Teams should compare the effective session-access configuration before and after 2026.9.2, especially when multiple agents or users share one Gateway.
A defensible upgrade review has three questions. First, which agents can invoke session tools while unsandboxed? Second, are any of those agents serving users, channels or data with different confidentiality expectations? Third, should those roles share one Gateway at all?
OpenClaw's security audit now checks cross-agent session access and warns when default Gateway-wide visibility intersects with signals such as sandboxing, agent-level restrictions or shared-user ingress. That gives operators a first-party way to detect when their configuration and trust assumptions may be misaligned.
There is no evidence here of an exploit or of controls being bypassed. The release preserves tool and sandbox restrictions, and OpenClaw clearly documents its one-boundary-per-Gateway design. The material change is architectural: a default that broadens cross-agent context sharing makes trust topology part of the upgrade decision.