Vazamento de raciocínio interno do OpenClaw, o que está realmente acontecendo e como impedir isso

Por que "vazamento de raciocínio interno do openclaw" é uma classe de incidente real, não um meme

"vazamento de raciocínio interno do openclaw" soa como um relatório de bug único. Na prática, é um modo de falha recorrente: O OpenClaw acaba envio de texto de planejamento interno ou traços de "pensamento" para superfícies visíveis ao usuário-às vezes como mensagens normais no Discord ou Telegram, às vezes renderizadas na interface do usuário da Web e às vezes emitidas como uma mensagem separada que precede a resposta final.

Isso é importante porque o conteúdo de "raciocínio" não é um preenchimento inofensivo. Em tempos de execução de agentes, o planejamento detalhado frequentemente inclui intenção da ferramenta, URLs, caminhos de arquivos, resultados intermediários e, ocasionalmente, tokens ou identificadoresos mesmos artefatos que as equipes de segurança passam anos tentando manter fora dos logs de bate-papo, sistemas de tíquetes e pacotes de suporte.

A boa notícia é que você pode tratar isso como qualquer outro problema de engenharia de segurança: defina o que nunca deve cruzar um limite de saída, imponha isso no código e na configuração e teste continuamente as regressões. O restante deste artigo está estruturado exatamente em torno disso.

O que é raciocínio interno nos termos do OpenClaw e o que conta como vazamento?

O OpenClaw fica entre os canais de mensagens e um ou mais provedores de LLM. Nesse pipeline, você pode ver alguns tipos diferentes de carga útil "interna":

• Bloqueios de pensamento / raciocínio internoplanejamento produzido por modelo que deve permanecer interno.
• Narração da ferramenta: "Deixe-me verificar X... agora vou executar Y..."
• Prompts do sistema / prompts de saudação: instruções e políticas ocultas que nunca devem ser renderizadas como conteúdo do usuário.
• Saída de ferramenta detalhadaDados de saída: stdout bruto, argumentos de ferramentas, URLs e dados recuperados durante as ações.

Um vazamento acontece quando qualquer um deles é emitido como conteúdo visível para o usuário em um canal que deveria receber somente a resposta final.

A própria orientação de segurança do OpenClaw indica explicitamente que o raciocínio e a saída detalhada podem expor detalhes internos e devem ser tratados apenas como depuração, especialmente em grupos. (OpenClaw)

Evidência verificada de que o vazamento está ocorrendo em todos os canais

Esse não é um medo teórico. Vários relatórios de problemas públicos mostram raciocínio interno e até mesmo conteúdo de prompt do sistema sendo exibido aos usuários.

Discord, pensando no conteúdo publicado como mensagens regulares

Um problema no GitHub documenta o raciocínio/pensamento interno sendo transmitido diretamente para as mensagens do Discord em diferentes modelos. Ele também observa dois componentes suspeitos: um parâmetro "thinking=low" sendo definido mesmo para modelos sem raciocínio e uma falha ao filtrar o raciocínio antes de enviar para o canal. (GitHub)

Webchat, prompt do sistema e blocos de pensamento renderizados na interface do usuário

Outro problema relata que iniciar uma nova sessão pode exibir o prompt de saudação do sistema como se tivesse sido enviado pelo usuário, e que os blocos de pensamento também são visíveis na interface de bate-papo. (GitHub)

Telegrama, mensagens separadas de "Motivo:" aparecem

Um relatório específico do Telegram descreve um vazamento intermitente em que uma mensagem extra aparece começando com "Reasoning:" e é confirmada como visível para o usuário no Telegram, em vez de nos registros internos. (GitHub)

WhatsApp, "[openclaw] Reasoning:" aparece antes da resposta

Um problema do WhatsApp descreve uma mensagem visível para o usuário contendo um texto de raciocínio interno (prefixado com "[openclaw] Reasoning:") antes da resposta final do assistente. (GitHub)

Por que isso se espalhou tão rapidamente na comunidade de segurança

Quando isso começa a aparecer em plataformas de bate-papo externas, duas forças o amplificam:

1. Ele se torna um violação de privacidade e confiança que as partes interessadas não técnicas percebem imediatamente.
2. Ele se torna um assinatura de incidente pesquisável-Os engenheiros podem colar a frase exata "vazamento de raciocínio interno do openclaw" e acessar os tópicos relevantes sobre problemas e atenuação.

É por isso que essa frase se comporta como um "IOC para falha operacional", e não como uma curiosidade de nicho.

Modelo de risco, o que pode vazar e por que os defensores devem se preocupar

As equipes de segurança devem tratar o vazamento de informações como exposição de informações com raio de explosão crescente. Não se trata apenas do texto em si; trata-se do que o texto revela sobre seu ambiente e plano de controle.

O que os vazamentos geralmente contêm nos tempos de execução do agente

Mesmo quando os modelos tentam ser cuidadosos, o raciocínio e os rastros detalhados frequentemente incluem:

• Intenção de ferramenta e ação, incluindo o que está prestes a ler ou executar
• URLs, nomes de host, pontos de extremidade internos e parâmetros de consulta
• caminhos de arquivos, dicas de estrutura de diretórios e nomes de espaços de trabalho
• "Vou buscar a configuração/verificar as variáveis de ambiente/abrir o histórico da sessão"
• resultados parciais da ferramenta ou dados intermediários estruturados

A documentação de segurança do OpenClaw adverte que a saída detalhada pode incluir argumentos de ferramentas, URLs e dados que o modelo viu, e recomenda manter o raciocínio/verbose desativado em salas públicas.OpenClaw)

Por que isso é pior do que um vazamento normal de chatbot

Em um tempo de execução agêntico, o modelo não está apenas respondendo a perguntas. Ele está incorporado em um sistema que:

• rotas entre aplicativos de bate-papo
• mantém a memória da sessão
• pode executar ferramentas e interagir com recursos do host

Isso significa que um vazamento pode expor não apenas o conteúdo, mas como influenciar ações futuras. O próprio modelo de segurança do OpenClaw enfatiza que ele foi projetado em torno de um único limite de operador confiável e não se destina a ser um limite hostil de vários locatários para usuários adversários que compartilham um gateway. (OpenClaw)

Uma tabela prática de impacto

Artefato de vazamento	Por que é sensível	Risco típico de downstream
fragmentos do prompt do sistema	revela políticas, permissões de ferramentas, lógica de controle	a injeção imediata se torna mais fácil, as tentativas de desvio de política se tornam direcionadas
Args e URLs da ferramenta	expõe pontos de extremidade internos, tokens em strings de consulta, formas de solicitação	Sondagem no estilo SSRF, reutilização de credenciais, hipóteses de movimento lateral
caminhos e nomes de arquivos	revela onde os segredos provavelmente vivem	Tentativas de exfil direcionadas, coerção no estilo "vá ler ~/.ssh/..."
resultados intermediários	expõe dados recuperados de ferramentas	vazamento não intencional de PII/IP em registros de bate-papo de terceiros
identificadores de canal/sessão	revela como o roteamento funciona	engenharia social e tentativas de repetição contra operações

Como causa raiz, o vazamento geralmente vem de uma das cinco lacunas de engenharia

Você verá sintomas diferentes dependendo do provedor, do adaptador de canal e do caminho da interface do usuário, mas as causas principais se agrupam em um pequeno conjunto.

1) O provedor retorna um campo de raciocínio e o adaptador o encaminha

O problema do Discord descreve explicitamente uma falha na filtragem de raciocínio antes de enviar a saída para o Discord. (GitHub)

Essa é a falha mais simples: o pipeline recebe corretamente campos estruturados separados, mas não consegue impor o "final-only" no limite do canal.

2) Os caminhos de fluxo tratam o "pensamento" como tokens normais

Mesmo que o seu caminho de resposta sem streaming elimine o raciocínio, o streaming geralmente tem um caminho de código diferente. Se o sistema montar blocos e encaminhá-los, ele poderá encaminhar acidentalmente o tipo errado de bloco para um canal.

Você pode ver a realidade operacional no relatório do Discord: o conteúdo de raciocínio aparece "antes ou no lugar da resposta real", o que é típico de bugs de montagem de várias mensagens ou de streaming. (GitHub)

3) Erros de renderização da interface do usuário, o prompt do sistema se torna conteúdo do usuário

O problema do webchat é um exemplo claro de falha de renderização: o texto do prompt de saudação do sistema é exibido no chat como se tivesse sido enviado pelo usuário, e os blocos de pensamento são visíveis. (GitHub)

Isso não é um "comportamento de modelo". É uma falha no front-end ou no limite de formatação da mensagem.

4) Depurar recursos usados em salas públicas

A orientação de segurança da OpenClaw adverte explicitamente que /argumentação e /verbose pode expor o raciocínio interno ou a saída da ferramenta que não se destina a canais públicos, e recomenda mantê-los desativados em salas públicas.OpenClaw)

Mesmo que o vazamento que você está vendo não seja intencional, ele geralmente piora quando os recursos de depuração são amplamente ativados.

5) Configuração incorreta e exposição, a Internet encontra os fuzis rapidamente

Mesmo que você conserte o vazamento de raciocínio, a postura mais ampla do OpenClaw é importante porque os gateways expostos atraem sondagem imediata. A Bitsight descreve a observação de dezenas de milhares de instâncias expostas e observa que as sondas podem chegar rapidamente quando um gateway pode ser acessado. (Bitsight)

É nesse ponto que o "vazamento de raciocínio" se torna parte de uma cadeia de falhas maior: a saída de depuração vaza detalhes, a exposição traz os invasores, e o invasor agora tem contexto.

Um plano de contenção de 15 minutos, estancar o sangramento antes de depurar tudo

Se estiver vendo ativamente "vazamento de raciocínio interno do openclaw" em qualquer canal, faça o seguinte primeiro. Essas etapas foram criadas para reduzir os danos, mesmo que você não tenha identificado o bug exato.

1) Trate o fato como uma violação de limite, apague o que pode ter sido exposto

Suponha que qualquer coisa que o agente possa ver pode estar presente nos registros de bate-papo. Rodar ou invalidar:

• tokens de bot para a plataforma de mensagens afetada
• chaves de API do provedor usadas pelo agente
• Tokens de atualização do OAuth e aprovações de aplicativos aos quais o agente pode ter tido acesso
• quaisquer segredos armazenados no host que o agente possa consultar

Se você precisar de um lembrete de que a exposição de tokens pode ser operacionalmente catastrófica, os avisos do OpenClaw incluem casos em que os tokens podem aparecer em registros ou rastreamentos de erros sem redação. (GitHub)

2) Desativar o raciocínio e o verboso em contextos de grupo

A orientação de segurança da OpenClaw é explícita: mantenha /argumentação e /verbose deficientes em salas públicas. (OpenClaw)

Mesmo que o seu vazamento seja "não intencional", a desativação de superfícies do tipo depuração reduz a chance de a plataforma ecoar os rastros internos.

3) Reduzir a exposição da rede, manter o gateway fora de redes não confiáveis

A documentação do OpenClaw destaca a porta de gateway, os modos de associação e o risco de expandir a superfície de ataque ao se associar a interfaces que não sejam de loopback. (OpenClaw)

Se for necessário acessar remotamente, prefira uma solução que preserve a ligação de loopback e adicione uma camada de controle de acesso em vez de expor o gateway diretamente.

4) Atualizar para versões corrigidas de problemas conhecidos de alta gravidade

Mesmo que o seu incidente imediato seja um vazamento de informações, a execução de versões sabidamente vulneráveis torna todos os outros controles mais fracos. Os problemas da classe ClawJacked e outras vulnerabilidades tiveram ciclos de correção rápidos, com vários relatórios aconselhando atualizações imediatas para versões corrigidas. (BleepingComputer)

A correção durável, impor a saída "somente final" no limite do canal

A contenção lhe dá tempo. A correção que funciona é uma regra simples:

Independentemente do que o modelo retorne e do que a interface do usuário renderize, somente o "conteúdo da resposta final" pode passar do OpenClaw para os canais de mensagens externos.

Isso significa que você precisa de um desinfetante que funcione após a saída do modelo é montada e antes de ele é emitido para um adaptador de canal.

Um projeto de desinfetante de referência

Um higienizador robusto deve lidar com tudo isso:

• remover estruturado raciocínio campos, se presentes
• remover as linhas com prefixo "Reasoning:" que aparecem como mensagens separadas
• bloquear fragmentos de prompt de sistema conhecidos (padrões de alta confiança)
• impedir que a narração da ferramenta seja emitida em canais que exigem uma saída limpa
• opcionalmente, redigir segredos por padrão (chaves AWS, tokens Slack, tokens GitHub, etc.)

Abaixo está um exemplo em pseudocódigo no estilo TypeScript. Adapte-o à arquitetura real do seu adaptador OpenClaw, mas mantenha a ideia: sanitizar no último momento possível, próximo ao limite de saída.

// Defensive output sanitizer for messaging channels.
// Goal: ensure only final, user-intended content is emitted.

type ModelResponse = {
  content?: string;        // final user-facing content
  reasoning?: string;      // internal-only reasoning field (provider-specific)
  tool_calls?: any[];
  raw?: any;               // provider raw payload (optional)
};

const RE_REASONING_PREFIX = /^\\s*(?:\\[openclaw\\]\\s*)?Reasoning:\\s*/i;
const RE_SYSTEM_PROMPT_HINTS = /(A new session was started|Do not mention internal steps|system prompt)/i;

// Minimal secret patterns (extend carefully; avoid false positives in normal text).
const RE_SECRETS = [
  /AKIA[0-9A-Z]{16}/g,                           // AWS access key id
  /xox[baprs]-[0-9A-Za-z-]{10,}/g,               // Slack tokens
  /ghp_[0-9A-Za-z]{30,}/g,                       // GitHub PAT (classic)
];

export function sanitizeForExternalChannel(input: ModelResponse | string): string {
  let text = typeof input === "string" ? input : (input.content ?? "");

  // If the provider returned a separate reasoning field, ignore it completely.
  // Never append it to user content.
  // (If your pipeline currently merges reasoning->content, stop doing that.)

  // Drop stray "Reasoning:" lines if they slipped into content.
  text = text
    .split("\\n")
    .filter(line => !RE_REASONING_PREFIX.test(line))
    .join("\\n");

  // Block obvious system-prompt leakage patterns.
  if (RE_SYSTEM_PROMPT_HINTS.test(text)) {
    text = "I can’t display internal instructions. Please rephrase your request.";
  }

  // Redact common secret formats.
  for (const re of RE_SECRETS) text = text.replace(re, "[REDACTED]");

  // Trim to avoid empty / whitespace-only posts.
  text = text.trim();

  // As a last resort, ensure something safe is returned.
  if (!text) text = "Done.";

  return text;
}

Isso não substitui as correções de upstream, mas evita toda uma classe de regressões, especialmente o tipo descrito no problema do Discord, em que o raciocínio aparece antes da saída final porque o adaptador não consegue filtrá-lo. (GitHub)

Adicione um teste de regressão que simule o modo exato de falha

A maneira mais rápida de evitar que isso ocorra é um pequeno teste que injeta um objeto de resposta contendo um raciocínio e uma mensagem com o prefixo "Reasoning:".

importar { sanitizeForExternalChannel } de "./sanitize";

test("não vaza o campo de raciocínio ou Reasoning: lines", () => {
  const resp = {
    content: "Reasoning: Vou pesquisar os registros internos\\nAqui está a resposta final.",
    reasoning: "cadeia interna de pensamento que nunca deve vazar",
  };

  const out = sanitizeForExternalChannel(resp);
  expect(out).toBe("Aqui está a resposta final.");
});

Se você operar vários adaptadores de canal, execute o mesmo conjunto de testes em cada caminho de adaptador. Os relatórios do Telegram e do WhatsApp mostram que o vazamento pode se manifestar como mensagens ou prefixos extras, dependendo do adaptador. (GitHub)

Detecção operacional, captura de vazamentos em registros antes que os usuários os denunciem

Você quer um sistema de alerta antecipado que lhe diga que "o raciocínio está escapando" antes que ele caia em um canal público.

Uma abordagem leve é acompanhar os registros de mensagens de saída (ou registros de carga útil de webhook) e alertar sobre padrões de alta confiança.

# Exemplo: verificar os registros de mensagens de saída em busca de marcadores de vazamento de raciocínio
# Ajuste o caminho do registro à sua implantação.

LOG=/var/log/openclaw/outgoing.log

grep -E -n "(\\[openclaw\\]\\s*Reasoning:|^Reasoning:|internal monologue|Do not mention internal steps)" "$LOG" \\
  | tail -n 50

Isso nunca será perfeito, mas captura as formas visíveis mais comuns vistas em relatórios de questões públicas: Prefixos "Reasoning:" e vazamentos explícitos do tipo "não mencionar etapas internas". (GitHub)

Fortalecimento do ambiente, supondo que o agente tenha privilégios e isolando-o

Mesmo com uma sanitização de saída perfeita, você deve fortalecer o tempo de execução, pois o OpenClaw é um plano de controle de alto privilégio por padrão.

A própria documentação de segurança do OpenClaw é direta quanto ao seu modelo de confiança: ele pressupõe uma implantação de assistente pessoal com um limite de operador confiável e não foi projetado como um limite de segurança hostil para vários locatários. (OpenClaw)

Os relatórios de segurança externos fazem eco à mesma recomendação prática: tratar o OpenClaw como execução de código não confiável com credenciais persistentes e executá-lo em ambientes isolados em vez de em estações de trabalho corporativas padrão. (TechRadar)

Movimentos de endurecimento mínimos viáveis

• mantenha o gateway vinculado ao loopback, a menos que você tenha controles de acesso rígidos
• usar um host ou uma VM dedicada para o tempo de execução do agente
• minimizar as credenciais e alterná-las com frequência
• manter o acesso ao canal na lista de permissões e evitar DMs públicas abertas
• tratar as extensões e habilidades como um limite da cadeia de suprimentos

A análise da Bitsight das instâncias expostas ressalta o motivo: uma vez que o gateway é acessível, a sondagem pode ocorrer rapidamente, e os invasores podem ignorar totalmente a "camada de IA" e visar o plano de controle. (Bitsight)

CVEs e alertas que tornam os vazamentos de raciocínio mais perigosos

O vazamento de raciocínio geralmente é registrado como um "bug", não como um CVE. Mas o impacto na segurança é ampliado quando você o combina com vulnerabilidades conhecidas que afetam o manuseio de tokens, o acesso a arquivos locais e a conectividade de gateway.

CVE-2026-25253, vazamento de tokens por meio da conexão automática do gatewayUrl

A NVD descreve o CVE-2026-25253 como um problema em que o OpenClaw obtém um gatewayUrl a partir de uma string de consulta e estabelece automaticamente uma conexão WebSocket sem solicitar, enviando um valor de token. (NVD)

Por que isso é importante para vazamentos de raciocínio:

• Os rastreamentos detalhados e detalhados geralmente incluem URLs e contexto de roteamento
• Qualquer vazamento que revele como a URL do gateway e o token são tratados pode encurtar o caminho de um invasor para o roubo do token
• ele reforça a política: os tokens nunca devem aparecer nos registros, no bate-papo ou na interface do usuário

CVE-2026-25475, o manuseio do caminho MEDIA permite a leitura arbitrária de arquivos locais

A NVD descreve o CVE-2026-25475 como uma falha em que, antes da versão 2026.1.30, uma função permite caminhos de arquivo arbitrários e um agente pode ler qualquer arquivo no sistema ao gerar um caminho MEDIA, permitindo a exfiltração para o usuário/canal. (NVD)

Isso interage com o vazamento de raciocínio de uma forma desagradável:

• um vazamento de raciocínio pode revelar caminhos de arquivos que valem a pena ser atacados
• um vazamento de canal pode se tornar um mecanismo de exfiltração se houver primitivos de leitura de arquivo
• isso reforça a necessidade de sanitização de saída e permissões rigorosas de ferramentas

A CISA também lista esse CVE em seu resumo de vulnerabilidades, o que é um sinal útil para os defensores que rastreiam a priorização autorizada. (CISA)

CVE-2026-26329, passagem de caminho de upload de ferramenta de navegador e leitura de arquivo local, observação sobre sincronização de NVD

Há um registro CVE para o CVE-2026-26329 que descreve uma passagem de caminho na ação de upload da ferramenta do navegador que permite que invasores autenticados leiam arquivos arbitrários do host do gateway antes da versão 2026.2.14. (OpenCVE)

No momento em que escrevo, a página do NVD pode mostrar "CVE ID Not Found", que normalmente reflete o tempo de sincronização do banco de dados em vez da ausência do registro subjacente. (NVD)

Mais uma vez, a ligação é direta: se o seu sistema puder ler arquivos e você vazar o contexto operacional interno em uma superfície de bate-papo, os limites de confidencialidade serão borrados tanto na camada da ferramenta quanto na camada de saída.

ClawJacked, sites que sequestram agentes locais, urgência de patches

Vários veículos de segurança relatam um problema de alta gravidade chamado ClawJacked, que permitia que sites mal-intencionados assumissem o controle de instâncias locais do OpenClaw, com correções lançadas no período 2026.2.26. (BleepingComputer)

Isso não é um "vazamento de raciocínio", mas muda a forma como você deve pensar sobre todo o tempo de execução:

• Se um ataque originado no navegador puder assumir o controle, os resultados e os rastreamentos do seu agente se tornarão controlados pelo invasor
• O vazamento de raciocínio torna-se, então, um veículo para engenharia social e extração de dados, mesmo que tenha começado como um bug

Avisos de exposição de registros e tokens

Os avisos do OpenClaw também descrevem casos em que os tokens podem ser expostos em mensagens de erro e rastreamentos de pilha se os registros não forem redigidos. (GitHub)

Isso reforça uma verdade incômoda: é preciso defender toda superfície onde o texto possa escapar-chat, interface do usuário, registros, relatórios de falhas e pacotes de suporte.

Garantia contínua, torne "nenhum vazamento de raciocínio" uma propriedade que você testa

Se você opera o OpenClaw em qualquer ambiente sério, trate "nenhum vazamento de raciocínio interno" como uma propriedade testada por regressão.

Use regularmente a auditoria de segurança integrada do OpenClaw

Os documentos de segurança do OpenClaw recomendam explicitamente a execução de auditoria de segurança do openclaw (incluindo os modos profundo e fixo), especialmente após alterar a configuração ou expor superfícies de rede. (OpenClaw)

No mínimo, crie uma rotina do tipo:

auditoria de segurança do openclaw
auditoria de segurança do openclaw --deep

Em seguida, conecte a saída ao seu fluxo de trabalho operacional, da mesma forma que faria com o desvio de infraestrutura.

Uma matriz de teste simples em nível de canal

Crie uma matriz de teste básica e execute-a após cada atualização:

Canal	Solicitação de teste	Esperado	Assinatura de falha
Discórdia	prompt que aciona o uso da ferramenta em várias etapas	única resposta final	"O usuário é...", "Raciocínio:...", narração da ferramenta
Telegrama	prompt que aciona o planejamento	única resposta final	mensagem separada "Reasoning:" (GitHub)
WhatsApp	prompt que aciona o planejamento	única resposta final	Mensagem "[openclaw] Reasoning:" (GitHub)
Webchat	/new ou /reset	nenhum prompt do sistema é exibido	prompt de saudação do sistema visível (GitHub)

Adicione uma camada de redação de segredos, mesmo que você "não registre segredos"

O objetivo não é confiar em uma higiene perfeita no upstream. O objetivo é ter uma proteção final contra falhas que bloqueie os segredos quando eles aparecerem acidentalmente.

Seja conservador com os padrões, meça os falsos positivos e certifique-se de redigir antes de enviar para plataformas de terceiros.

Onde Penligent se encaixa, somente quando é natural

Se você é uma equipe de segurança que está validando uma implementação do OpenClaw, a parte mais difícil raramente é "encontrar um bug". É provar que um controle ainda é válido após upgrades, trocas de modelos e desvios de configuração. Uma maneira prática de reduzir essa carga de verificação é tratar o tempo de execução do agente como qualquer outro alvo de alto valor e testar continuamente sua exposição: acessibilidade do gateway, limites de CVE conhecidos e se artefatos confidenciais podem escapar para superfícies de bate-papo.

A Penligent pode ser usada nessa postura de verificação: automatizar verificações em torno das superfícies externamente acessíveis do OpenClaw, confirmar limites de patches para problemas documentados publicamente e gerar resultados com grau de evidência que respondam "ainda estamos seguros depois dessa mudança" em vez de confiar na intuição. Se você já está acompanhando as mudanças nos limites de segurança do OpenClaw, os artigos anteriores da Penligent sobre endurecimento do mercado e interpretação dos limites de segurança fornecem um contexto útil para a criação desses testes em uma prática repetível. (Penligente)

Conclusão, o que fazer em seguida se você pesquisar "vazamento de raciocínio interno do openclaw"?

1. Confirme quais caminhos de canal estão vazando e se estão estruturados raciocínio encaminhamento, renderização da interface do usuário ou montagem de várias mensagens. (GitHub)
2. Contenha imediatamente: desabilite o raciocínio/verbose em salas públicas, reduza a exposição, alterne o que pode estar comprometido. (OpenClaw)
3. Correção duradoura: imponha a saída somente final no último limite, adicione testes de regressão e monitore as assinaturas de vazamento. (GitHub)
4. Proteja-se como se fosse um serviço privilegiado: isole o tempo de execução, mantenha o gateway fora de redes não confiáveis e presuma que ocorrerão desvios. (OpenClaw)
5. Faça o patch além dos "bugs de vazamento": mantenha-se atualizado com os CVEs que afetam o manuseio de tokens e a leitura de arquivos locais, pois eles ampliam as consequências de qualquer vazamento. (NVD)

Links de autoridade e leitura adicional

• Documentação de segurança do OpenClaw, modelo de confiança, comandos de auditoria, raciocínio e orientação detalhada (OpenClaw)
• Relatório de problema de vazamento de raciocínio do Discord, hipóteses de causa raiz sobre raciocínio encaminhamento de campo (GitHub)
• Blocos de raciocínio e de prompt do sistema Webchat renderizados como texto visível para o usuário (GitHub)
• Relatório de vazamento de raciocínio do Telegram (GitHub)
• Relatório de vazamento de raciocínio do WhatsApp (GitHub)
• Análise Bitsight de instâncias expostas do OpenClaw e sondagem da realidade (Bitsight)
• Visão geral da arquitetura do gateway OpenClaw e superfícies de canal da Zscaler (Zscaler)
• Cobertura de aviso vinculada à Microsoft sobre isolamento e tratamento de tempos de execução de agentes como execução de código não confiável (TechRadar)
• Entrada NVD para CVE-2026-25253, token enviado durante a conexão WebSocket automática (NVD)
• Entrada NVD para CVE-2026-25475, o manuseio do caminho MEDIA permite a leitura arbitrária de arquivos locais (NVD)
• Registro de CVE para CVE-2026-26329, passagem de caminho de upload de ferramenta de navegador e leitura de arquivo local, além de nota de sincronização de NVD (OpenCVE)
• Relatório do ClawJacked e contexto da versão do patch (BleepingComputer)
• Penligent, OpenClaw + VirusTotal e ClawHub contexto de limite da cadeia de suprimentos (Penligente)
• Penligent, OpenClaw 2026.2.23 interpretação do limite de segurança (Penligente)