O OpenClaw 2026.9.2 altera uma definição importante nos sistemas com vários agentes. O acesso normal de um agente às sessões dos restantes passa a estar ativo por predefinição, os instrumentos de sessão podem ver todo o Gateway e a funcionalidade experimental Swarm também fica ativa por defeito.
Não se trata de uma vulnerabilidade descoberta à margem do modelo de segurança. O próprio projeto define cada Gateway como uma única zona de confiança e diz que utilizadores que não confiam uns nos outros não devem partilhá-lo. Ainda assim, a mudança é relevante para equipas que tratavam agentes ou perfis separados como fronteiras de confidencialidade.
As sessões ficam visíveis em todo o Gateway por predefinição
A versão publicada a 5 de setembro indica que os instrumentos de sessão passam a usar visibilidade sobre todas as sessões e que o acesso normal entre agentes é ativado. A documentação de segurança explicita os valores: tools.sessions.visibility assume all e tools.agentToAgent.enabled assume true por predefinição.
Nessa configuração, um agente não isolado com acesso aos instrumentos de sessão pode, segundo o OpenClaw, listar, ler, pesquisar e contactar as sessões de todos os agentes, incluindo conversas de outros utilizadores. Um agente executado num ambiente isolado continua, quando atua como originador, limitado à árvore de sessões que criou. Essa limitação, porém, não impede um agente não isolado de ler as transcrições do agente isolado.
O projeto não apresenta este comportamento como isolamento entre entidades independentes. O acesso de operador autenticado dentro de um Gateway faz parte da mesma zona de confiança. Para níveis de confiança diferentes, a recomendação oficial é separar Gateways e credenciais e, de preferência, utilizar contas do sistema operativo ou máquinas diferentes.
Por isso, seria incorreto descrever a alteração como uma falha de autorização. A pergunta relevante é outra: a estrutura real de confiança da organização coincide com a fronteira que o OpenClaw atribui a cada Gateway?
Swarm aumenta a capacidade de coordenação sem conceder novas ferramentas
A mesma versão ativa o Swarm por predefinição. Esta funcionalidade experimental permite coordenar vários subagentes em paralelo, recolher resultados estruturados, limitar a concorrência e acompanhar o progresso.
Há salvaguardas importantes. O Code Mode continua a exigir ativação separada. As regras de ferramentas, listas de permissões, fornecedores e isolamento mantêm-se. Ativar o Swarm não concede uma ferramenta que já estivesse proibida. Os subagentes de recolha também recusam ações que exigiriam uma aprovação interativa do operador.
As duas alterações atuam, portanto, em níveis diferentes. O Swarm determina como o trabalho pode ser distribuído. A visibilidade das sessões determina a que conversas e contexto cada agente pode chegar. Em conjunto, tornam mais importante explicitar a arquitetura de confiança num sistema com vários agentes.
A fronteira de confiança é o Gateway, não o nome do agente
A conclusão prática da Aipolix é que um perfil de agente separado não deve ser tratado como fronteira de confidencialidade se a configuração não impuser essa separação.
Imagine um único Gateway com um assistente pessoal, um agente financeiro e um agente de engenharia. Se estes papéis tratam dados com sensibilidades diferentes ou servem utilizadores com níveis de confiança distintos, separar as instruções dadas aos agentes e as regras de acesso às ferramentas não chega. A documentação do OpenClaw afirma que os perfis de ferramentas não reduzem o alcance dos instrumentos de sessão e que um agente não isolado pode continuar a ler as sessões de um agente isolado com as definições atuais.
Para agentes que pertencem efetivamente à mesma zona de confiança, a configuração predefinida pode ser uma opção consciente e conveniente. Quando existem níveis de confiança diferentes, o projeto recomenda definir tools.sessions.visibility como agent ou self, limitar os pares permitidos através de tools.agentToAgent.allow, ou desativar o acesso direto entre agentes. Para utilizadores adversos ou inquilinos verdadeiramente separados, a recomendação é utilizar Gateways distintos.
Esta abordagem é mais útil do que assumir que cada identidade de agente funciona automaticamente como uma fronteira de segurança autónoma. Depois desta versão, a arquitetura deve associar cada Gateway a uma zona de confiança real da organização.
Atualizar exige rever a fronteira de confiança
Como a mudança chega através de uma nova predefinição, a atualização não deve ser avaliada apenas pela lista de funcionalidades. Equipas com vários agentes ou utilizadores no mesmo Gateway devem comparar o acesso efetivo às sessões antes e depois da versão 2026.9.2.
Três perguntas ajudam a fazer essa revisão: que agentes não isolados conseguem usar os instrumentos de sessão? Algum deles serve utilizadores, canais ou dados com expectativas de confidencialidade diferentes? Esses papéis devem, de facto, continuar no mesmo Gateway?
O comando openclaw security audit verifica o acesso cruzado às sessões e pode emitir avisos quando a visibilidade global por predefinição aparece juntamente com sinais de níveis de confiança distintos, como isolamento, restrições específicas por agente ou entrada de vários utilizadores.
As fontes consultadas não demonstram qualquer exploração nem um contorno das salvaguardas existentes. As restrições de ferramentas e isolamento mantêm-se, e o OpenClaw documenta claramente o modelo de uma zona de confiança por Gateway. A importância do 2026.9.2 é arquitetural: quando a partilha de contexto entre agentes se alarga por predefinição, a topologia de confiança passa a fazer parte da decisão de atualização.