# OpenClaw e ecossistema derivado: relatório técnico, operacional e de segurança ## Resumo executivo OpenClaw é um assistente pessoal “agentic” (agente que executa ações) que roda nos seus próprios dispositivos e responde via apps de mensagem já usados no dia a dia, com suporte a voz (em plataformas suportadas) e a um “Canvas” ao vivo que o usuário pode controlar. citeturn20view0turn18view1 A arquitetura é centrada em um processo **Gateway** (um serviço sempre ligado) que concentra conexões com canais (WhatsApp/Telegram/etc.), oferece um **plano de controle via WebSocket** para clientes (CLI/UI/app) e integra “nodes” (dispositivos auxiliares) com capacidades explícitas. citeturn20view2turn10search6 A “memória” é **Markdown no workspace**, e o modelo “lembra” apenas o que for persistido em disco ou recuperado via ferramentas de memória; há mecanismos de **busca semântica/híbrida** e gatilhos de “flush” antes de compaction para estimular a gravação de memórias duráveis. citeturn20view1turn9search19 Do ponto de vista de segurança, o ecossistema passou por vulnerabilidades relevantes e incidentes recentes: há CVEs de alto impacto no plano web/controle e em superfícies de execução (incluindo exfiltração de token e injeção de comando), e houve ondas de “skills” maliciosas publicadas no marketplace (cadeia de suprimentos) explorando engenharia social e o fato de “skills” serem, na prática, **código/instruções executáveis**. citeturn22view0turn22view1turn23search0turn24search0turn25view1turn12search14 A postura recomendada, de acordo com a documentação e materiais de “trust” do projeto, é “**security-first**”: manter o Gateway **privado** (loopback/tailnet), exigir autenticação e políticas de DM/grupos conservadoras, usar **sandbox** para reduzir blast radius, tratar plugins/skills como **dependências de software** (pin/validação) e executar auditorias e monitoramento contínuos. citeturn20view3turn10search1turn10search5turn13search8turn16view1 ## O que é OpenClaw e suas funcionalidades O OpenClaw se posiciona como um assistente pessoal rodando na infraestrutura do usuário (“your machine, your keys, your data”), com resposta em múltiplas superfícies de chat (incluindo WhatsApp, Telegram, Slack, Discord, Signal, iMessage e WebChat) e recursos adicionais como voz e Canvas. citeturn20view0turn12search28turn18view1 O diferencial funcional é que ele não é apenas um chatbot: por design, pode **executar ações** via ferramentas (ex.: ler/escrever arquivos no workspace, executar comandos, automatizar navegação, agendar tarefas), o que aumenta o leque de automações possíveis — e, simultaneamente, amplia o risco operacional e de segurança. citeturn12search0turn25view0turn19search24 O conjunto de capacidades “de produto” mais estável e diretamente documentado pode ser resumido assim: - **Mensageria multiprotocolo** via um Gateway central; e **clientes** (CLI, web UI, app macOS, automações) conectados ao mesmo plano de controle. citeturn20view2turn10search6 - **Execução de tarefas e automação contínua** via scheduler do Gateway (cron/heartbeat), inclusive jobs persistentes. citeturn18view1turn19search2 - **Skills**: pacotes (diretórios) centrados em `SKILL.md` que ensinam o agente a usar ferramentas dentro de um padrão compatível com AgentSkills, com precedência entre skills “bundled”, `~/.openclaw/skills` e `<workspace>/skills`. citeturn9search2turn18view1 - **Plugins**: módulos que estendem comandos, ferramentas e RPC do Gateway (incluindo slots exclusivos, como memória), carregados em runtime; o projeto lista plugins oficiais e destaca mecanismos de validação por schema. citeturn21search0turn9search1 - **Memória persistente** baseada em arquivos Markdown e ferramentas de busca/recuperação. citeturn20view1 ## Arquitetura e construção do sistema A arquitetura documentada do OpenClaw adota um padrão de “hub-and-spoke”: um único **Gateway** de longa duração controla as superfícies de mensageria e expõe um protocolo WebSocket tipado; clientes e nodes se conectam por esse canal e declaram “role” e permissões/capacidades. citeturn20view2turn10search6 O Gateway também hospeda o Canvas em uma porta separada por padrão e preserva invariantes de topologia (por exemplo, “um Gateway por host” e centralização da sessão do WhatsApp no Gateway). citeturn20view2 O projeto é majoritariamente em TypeScript/Node (com runtime requerido em Node 22+), e usa uma estratégia de “schema como fonte de verdade”: o protocolo WebSocket do Gateway é descrito por schemas em TypeScript e essa mesma base alimenta validação em runtime e geração de código para o app macOS. citeturn9search3turn20view4 ### Diagrama de alto nível: componentes e fluxo ```mermaid flowchart LR subgraph Channels["Canais (mensageria)"] W["WhatsApp"] T["Telegram"] S["Slack/Discord/etc."] WC["WebChat"] end subgraph Gateway["Gateway (daemon)"] WS["WS API tipada + eventos"] SCH["Scheduler (cron/heartbeat)"] CAN["Canvas host (porta dedicada)"] ROUTE["Roteamento/session store"] end subgraph Clients["Clientes de controle"] CLI["CLI"] UI["Control UI (web)"] MAC["App macOS"] AUTO["Automações"] end subgraph Nodes["Nodes (dispositivos)"] MOB["iOS/Android"] HEAD["Headless"] MACN["macOS node"] end subgraph Runtime["Runtime do agente"] LLM["Provedor/modelo LLM"] TOOLS["Ferramentas + skills"] MEM["Workspace + memória (Markdown)"] end Channels --> Gateway Clients <--> WS Nodes <--> WS Gateway --> Runtime Runtime --> LLM Runtime <--> TOOLS Runtime <--> MEM Gateway --> CAN Gateway --> SCH ``` A descrição acima segue a documentação do Gateway (roles, WS API, eventos, Canvas host) e a forma como skills/plugins se integram ao runtime. citeturn20view2turn10search6turn21search0turn9search2 ### Ecossistema e projetos derivados O ecossistema “derivado” pode ser dividido em: (i) repositórios oficiais na organização do projeto; (ii) serviços/registries (ex.: marketplace); (iii) forks e “hardening wrappers” mantidos por terceiros; e (iv) integrações/ambientes alternativos. A tabela abaixo foca em projetos diretamente derivados e/ou explicitamente conectados, com o que foi possível verificar nas fontes analisadas; quando um item não estava documentado, ele aparece como **não verificado**. | Projeto | Papel no ecossistema | Licença (conforme fonte) | Indicadores de comunidade (aprox.) | Observações de maturidade / foco | |---|---|---|---|---| | OpenClaw (core) | CLI + Gateway + runtime do agente | MIT (listagem do org) | ~189k stars / ~32k forks (GitHub org list) | Base do ecossistema, com docs extensas, wizard e comandos operacionais. citeturn14view0turn20view0turn20view4 | | ClawHub | Registry/marketplace de skills + API | MIT | ~1.8k stars / ~404 forks | Superfície crítica de supply-chain (skills), com esforços recentes de scanning (ex.: integração com VirusTotal). citeturn14view0turn12search14 | | trust | Threat model + dados do programa “Trust” | Não verificado na listagem | ~9 stars / ~3 forks | Contém `threats.yaml` baseado em entity["organization","MITRE ATLAS","ai threat framework"] e explicita fronteiras, ameaças e cadeias de ataque. citeturn14view0turn16view1turn13search8 | | openclaw-ansible | Provisionamento automatizado/hardened | MIT | ~290 stars | Instalação em frota e baseline endurecido (menciona VPN/firewall/Docker na descrição do repo). citeturn14view0 | | skills (archive) | Arquivo de versões de skills | MIT | ~921 stars | Útil para auditoria/reprodutibilidade histórica de skills publicadas. citeturn14view0 | | lobster | “Workflow shell”/automação local-first | MIT | ~451 stars | Proposta de orquestração/pipelines (derivado do ecossistema). citeturn14view0 | | moltworker (Cloudflare) | Execução/ambiente alternativo em Workers | Não verificado aqui | Não verificado aqui | Documenta integração com entity["company","Cloudflare","internet infrastructure company"] Zero Trust/Access e proteção de paths. citeturn13search16 | | @dillobot/dillobot | Fork “security-hardened” (terceiros) | Não verificado aqui | Não verificado aqui | Citado como fork endurecido por análise externa; exige validação independente antes de uso. citeturn11search12turn11search19 | ## Características técnicas ### Modelo de memória e persistência de estado O modelo de memória documentado é “file-first”: **a fonte de verdade é o disco**, e a memória é representada por Markdown no workspace do agente. O texto do modelo só “lembra” o que estiver no contexto da sessão (janela atual) e/ou o que for persistido e depois recuperado novamente. citeturn20view1turn9search19 O layout padrão descreve duas camadas: `memory/YYYY-MM-DD.md` (log diário append-only, lido “hoje e ontem” no início da sessão) e `MEMORY.md` (memória curada de longo prazo, carregada apenas na sessão principal/privada; não em grupos). citeturn20view1 Além da leitura direta de arquivos no bootstrap do prompt, o sistema inclui ferramentas/plugins para **busca e recuperação** de memórias (“memory tools”), e o plugin de memória ativo pode ser alterado/disabled via `plugins.slots.memory`. citeturn20view1turn9search1 Há também um mecanismo explícito de “memory flush” associado à proximidade de compaction: quando a sessão se aproxima do limite de tokens, o sistema pode disparar uma “virada silenciosa” para lembrar o modelo de escrever memórias duráveis antes do resumo/compactação. citeturn20view1 **Comportamentos e limitações típicas (com implicações práticas):** - “Esquecer” após compaction ou sessões novas é esperado quando fatos/preferências não foram gravados em `MEMORY.md`/`memory/*.md`. O projeto recomenda explicitamente pedir ao bot para escrever na memória quando você quer que algo “grude”. citeturn20view1 - Em **contextos de grupo**, `MEMORY.md` não é carregado por design (“never in group contexts”), o que reduz vazamento de informações mas também reduz consistência contextual em chats públicos/compartilhados. citeturn20view1turn20view3 - Em execução sandboxed com workspace read-only/none, o flush de memória pode ser pulado por não haver permissão de escrita, aumentando a chance de perda de detalhes relevantes antes de compaction. citeturn20view1turn20view3 ### Janela de contexto, compaction e pressão de tokens A janela de contexto é, em última instância, limitada pelo **modelo/provedor** escolhido; o OpenClaw contabiliza tokens e detalha o que é incluído no prompt: system prompt, histórico de conversa, chamadas e resultados de ferramentas, anexos, artefatos de pruning/compaction e headers do provedor (mesmo invisíveis). citeturn9search19 O sistema injeta arquivos “bootstrap” do workspace (por exemplo `AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`) e pode truncar arquivos grandes via `agents.defaults.bootstrapMaxChars` (default documentado: 20000 caracteres). Isso cria um limite prático: memórias extensas e instruções longas podem ser cortadas no bootstrap, exigindo organização (curadoria) ou recuperação on-demand. citeturn9search19turn20view1 ### Tipos de modelos e modo de execução O core é desenhado para “qualquer modelo” dentro das integrações suportadas; o README destaca suporte a fluxos de assinatura/OAuth para entity["company","Anthropic","ai model provider"] (Claude) e entity["company","OpenAI","ai model provider"] (ChatGPT/Codex) e recomenda o wizard para configurar. citeturn20view0turn18view1 Nas fontes analisadas, não há indicação de que o OpenClaw dependa de **fine-tuning** como mecanismo intrínseco; a arquitetura e o modelo de memória descritos são compatíveis com “inference + ferramentas + persistência em disco”, e a customização do comportamento aparece via skills, plugins e arquivos de identidade/bootstrapping. citeturn9search2turn21search0turn20view1turn12search0 ### Requisitos de hardware Para um Gateway básico em VPS/VM com um canal de chat, a documentação indica: mínimo absoluto de **1 vCPU / 1GB RAM** e recomenda **2GB RAM ou mais** para múltiplos canais, automação de browser ou ferramentas de mídia; menciona também disco na ordem de centenas de MB para o básico e ressalta headroom para logs/mídia. citeturn18view0turn18view3 Para execução em VM, a recomendação é “tratar como VPS” (sempre ligada e alcançável), com OS Ubuntu LTS (ou Debian/Ubuntu modernos) e, em Windows, WSL2 como caminho mais simples. citeturn18view3turn20view4 Tabela sintética (apenas com números explicitados em fonte): | Cenário | Mínimo (documentado) | Recomendado (documentado) | Observações | |---|---:|---:|---| | Gateway + 1 canal (VPS) | 1 vCPU / 1GB RAM | 1–2 vCPU / 2GB+ RAM | Browser automation e ferramentas “node” podem consumir mais. citeturn18view0 | | Gateway em VM | 1 vCPU / 1GB RAM | 2GB+ RAM | VM deve ficar sempre ligada; OS Ubuntu LTS/Debian/Ubuntu; WSL2 recomendado em Windows. citeturn18view3turn20view4 | Requisitos para rodar **modelos locais** (ex.: via servidores/bridges de inferência) não aparecem como números fixos nas fontes analisadas; por definição, dependem do modelo (tamanho/quantização) e do runtime local escolhido. (Não documentado aqui; tratar como variável por modelo.) citeturn20view0turn9search19 ## Instalação em VM e operação básica ### Escolha do SO e pré-requisitos A própria documentação recomenda Ubuntu LTS (ou Debian/Ubuntu modernos) como caminho “mais testado” para Linux, e explicita que em VM vale o mesmo guia de VPS. citeturn18view0turn18view3turn20view4 O instalador oficial exige **entity["organization","Node.js","javascript runtime"] 22+ (o script instala se faltar), e em Windows recomenda-se WSL2. citeturn20view4turn19search19 ### Instalação “nativa” recomendada (Ubuntu LTS em VM) A sequência abaixo segue a lógica do guia oficial: instalar via script e rodar o onboarding wizard (incluindo instalação de daemon), depois validar com `doctor/status/dashboard`. citeturn20view4turn19search3 ```bash # 1) (Opcional) Atualize o sistema e instale utilitários básicos sudo apt-get update sudo apt-get install -y curl ca-certificates git # 2) Instalador oficial (faz instalação + onboarding) curl -fsSL https://openclaw.ai/install.sh | bash # 3) Se quiser apenas instalar sem onboarding automático curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard # 4) Caso tenha instalado via npm/pnpm manualmente npm install -g openclaw@latest openclaw onboard --install-daemon # 5) Verificações básicas openclaw doctor openclaw status openclaw dashboard ``` O script e o caminho via npm/pnpm (com notas específicas para problemas do `sharp`) estão documentados pelo projeto, assim como a validação pós-instalação e dicas de PATH. citeturn20view4 ### Portas, bind e acesso remoto seguro O Gateway usa por padrão `18789` no bind host configurado (default `127.0.0.1:18789`), e o Canvas host aparece como porta separada (default documentado: `18793`). citeturn20view2turn19search23 A documentação é explícita em preferir que o acesso remoto ocorra por VPN/tailnet ou túnel SSH, em vez de expor a interface ao público; e o próprio software tem guardrails para binding além de loopback sem autenticação. citeturn10search3turn10search9turn20view3 Exemplo de túnel local (padrão clássico, pois expõe a UI na sua máquina local sem abrir porta pública): ```bash ssh -N -L 18789:127.0.0.1:18789 user@IP-ou-host-da-VM # depois acesse no navegador local: # http://127.0.0.1:18789 ``` O projeto também menciona explicitamente autenticação no Control UI, allowed origins e requisitos adicionais quando não está em loopback. citeturn10search9turn20view3 ### Opção com containerização O guia oficial de entity["company","Docker","container platform company"] cobre dois modos: (i) Gateway inteiro containerizado; (ii) sandbox por sessão (Gateway no host, ferramentas em containers). citeturn10search16turn10search1turn20view3 A política de segurança do projeto recomenda reduzir superfície com execução não-root e flags como `--read-only`/`--cap-drop=ALL` quando aplicável, e também enfatiza que a UI web é “local use only” (não hardened para exposição pública). citeturn6view0 ### Troubleshooting prático - **`openclaw` “não encontrado”**: o doc oficial recomenda diagnosticar PATH e incluir `$(npm prefix -g)/bin` no PATH em shell startup. citeturn20view4 - **Problemas de build do `sharp`**: o doc sugere `SHARP_IGNORE_GLOBAL_LIBVIPS=1` ou instalar toolchain (node-gyp) dependendo do ambiente. citeturn20view4 - **Diagnóstico de runtime/configuração**: `openclaw doctor` (inclui modo `--repair/--deep`) e sugestões de logs/health/status são documentadas como “loop de debug” inicial. citeturn10search10turn19search3turn19search23 ## Superfície de ataque, vulnerabilidades e melhores práticas ### Superfície de ataque e “por que é diferente” O próprio material de “Trust” do projeto descreve que, por poder executar comandos, ler/escrever arquivos, buscar URLs e agir em canais, o OpenClaw exige um modelo de segurança diferente de apps tradicionais; inclui riscos de prompt injection (direta/indireta), abuso de ferramentas e riscos de identidade/impersonação. citeturn13search8turn12search0 A análise da entity["organization","Trend Micro","cybersecurity company"] dá contexto semelhante: o risco é amplificado por memória persistente, permissões amplas e alta configurabilidade, e recomenda princípios de zero trust e monitoramento contínuo como necessários. citeturn25view0 Na prática, a superfície de ataque se concentra em: - **Plano de controle WebSocket do Gateway** (requests/responses/eventos), clientes de administração e o ciclo de autenticação/origin/allowed origins. citeturn20view2turn10search6turn10search9 - **Ferramentas de execução** (`exec`, browser control, process tool, etc.), principalmente quando “elevated mode” permite execução no host. citeturn20view3turn10search1 - **Skills e plugins** (código e instruções), tratados como extensões com acesso a ferramentas/dados do agente, e por isso relevantes para supply-chain. citeturn9search2turn21search0turn13search8 - **Marketplace/registro de skills** (ClawHub) como mecanismo de distribuição (com histórico recente de abuso). citeturn25view1turn12search14turn16view1 ### Vulnerabilidades conhecidas e CVEs recentes A tabela abaixo resume CVEs explicitamente vinculados ao OpenClaw nas fontes consultadas, com foco em descrição e versões corrigidas. | ID | Vetor e impacto (resumo) | Atinge | Corrigido em | Observações operacionais | |---|---|---|---|---| | CVE-2026-25253 | Control UI aceitava `gatewayUrl` via query string e auto-conectava por WS enviando token; clique/visita pode exfiltrar token e levar a “compromisso total do gateway” (incluindo alteração de config/políticas) | Plano web/controle | 2026.1.29 | Exploit funciona mesmo com bind em loopback (browser da vítima inicia conexão). citeturn22view0turn22view4 | | CVE-2026-24763 | Injeção de comando no mecanismo de execução de sandbox Docker por manejo inseguro de `PATH` ao construir comandos; exige usuário autenticado com controle de env vars | Sandbox Docker | 2026.1.29 | Impacto em “execução dentro do contexto do container” e construção de comandos. citeturn22view1 | | CVE-2026-25157 | Injeção de comando ligada a `sshNodeCommand`/`parseSSHTarget`: path do projeto e parsing de alvo SSH podem permitir execução arbitrária (host remoto SSH e/ou local) | Execução via SSH/node | 2026.1.29 | Descrição do NVD cita falhas de escape em script e parsing de target iniciando com “-”. citeturn23search0 | | CVE-2026-25593 | Cliente local não autenticado conseguia usar WS API do Gateway para escrever config (`config.apply`) e setar `cliPath` inseguro usado em descoberta de comandos, permitindo command injection como usuário do gateway | Gateway WS API | 2026.1.20 | O NVD descreve como “local unauth” + “command discovery” levando a injeção. citeturn24search0 | Além disso, a política de segurança do projeto recomenda uma versão mínima do runtime entity["organization","Node.js","javascript runtime"] (22.12.0+) citando CVEs do runtime (por exemplo CVE-2025-59466 e CVE-2026-21636) como motivação para patches de segurança — esses CVEs são do runtime, não do OpenClaw em si, mas afetam a segurança do deployment. citeturn6view0turn7search2turn7search3turn7search7 ### Incidentes de cadeia de suprimentos e riscos de skills Uma parte central do risco operacional recente foi a exploração do ecossistema de skills (ClawHub). A entity["organization","TecMundo","brazilian tech news site"] reportou ondas de skills maliciosas distribuindo malware e roubo de dados, descrevendo o ataque como supply chain via marketplace, incluindo padrões de engenharia social (documentação longa, comandos ofuscados, links maliciosos) e o argumento de que, para agentes, Markdown funciona como um “instalador”. citeturn25view1 Em resposta, o projeto anunciou parceria com entity["company","VirusTotal","malware scanning service"] (serviço de inteligência de ameaças da entity["company","Google","internet company"]) para escanear skills publicadas no marketplace, incluindo análise por “Code Insight”, e ressaltou que skills são código com acesso a ferramentas e dados do agente. citeturn12search14 O threat model oficial (repo “trust”) também trata explicitamente “malicious skill as entry point” e cadeias de ataque envolvendo persistência e exfiltração de credenciais, reforçando que o marketplace é uma fronteira de confiança (“trust boundary”) que exige controles e monitoramento. citeturn16view1turn13search8 ### Misconfigurações comuns e pontos de atenção As fontes oficiais enfatizam que o web/control UI e o Gateway devem ser considerados componentes sensíveis; a política de segurança alerta para **não expor a interface web na internet** e observa que ela é “intended for local use only”. citeturn6view0turn10search9 O guia de segurança do Gateway fornece um baseline “copy/paste” que mantém o Gateway privado (bind loopback), exige auth por token e adota políticas conservadoras: DM por “pairing” e grupos apenas com menção. citeturn20view3 Há também alertas específicos sobre: - **Modo “elevated”** como escape hatch para executar no host: manter `tools.elevated.allowFrom` restrito e não habilitar para “estranhos”. citeturn20view3turn10search1 - **Browser control**: se o browser/profile tiver sessões logadas, isso equivale a acesso de operador às contas; recomenda dedicar um profile para o agente e tratar downloads como input não confiável. citeturn20view3 - **Bind mounts que “furam” o sandbox**: mount de paths sensíveis e especialmente de `/var/run/docker.sock` efetivamente entrega controle do host para dentro do container. citeturn10search4 - **Logs e transcrições** como fonte de vazamento (mesmo com controles corretos): recomenda manter redaction ativo, adicionar padrões, preferir `status --all` ao compartilhar diagnósticos e reduzir retenção se não necessário. citeturn19search0turn19search17 ### Boas práticas consolidadas e controles recomendados A seguir, uma síntese expositiva do que aparece como “melhores práticas”/guardrails nas fontes do projeto e no material de trust: **Controle de acesso e superfície exposta**: manter o Gateway em `loopback` e usar VPN/tailnet (p. ex., entity["company","Tailscale","vpn software company"]) ou túnel SSH para acesso; exigir auth (token/senha/headers de identidade em cenários suportados) e configurar allowed origins do Control UI quando aplicável. citeturn20view3turn10search9turn10search3 **Isolamento e least privilege**: ativar sandbox de ferramentas quando possível (`agents.defaults.sandbox`) e manter `workspaceAccess` em `none` ou `ro` quando o objetivo é reduzir risco de escrita/exfiltração inadvertida; adotar allow/deny lists por agente (multi-agent) para restringir `exec`, `write`, `browser` etc em agentes menos confiáveis. citeturn20view3turn10search1turn10search23 **Gestão de secrets**: guardar chaves/tokens no host do Gateway, preferir `~/.openclaw/.env` quando o daemon é gerenciado por systemd/launchd, e rotacionar tokens (gateway auth, hooks tokens, credenciais de provedores) em caso de suspeita. citeturn19search13turn10search21turn13search8 **Atualização e patching**: manter o OpenClaw atualizado (especialmente releases que corrigem CVEs recentes) e atender requisitos mínimos de runtime como Node 22.12.0+ por patches de segurança. citeturn20view4turn6view0turn22view0turn22view1turn24search0turn23search0 **Auditoria e observabilidade**: executar `openclaw security audit` (incluindo `--deep` e, quando apropriado, `--fix`) e usar `status/health/logs` para monitorar; habilitar redaction em logs e customizar padrões, manter logs em JSONL e revisar retenção. citeturn10search5turn19search2turn19search1turn19search0turn19search17 **Supply-chain de skills/plugins**: tratar skills/plugins como dependências executáveis; preferir publishers verificados/escaneados, pin de versões, revisão de diff, e grau extra de ceticismo com skills que pedem comandos manuais, downloads externos ou ofuscação. A integração com VirusTotal é um controle adicional, mas não substitui revisão e segmentação (sandbox/políticas). citeturn12search14turn25view1turn16view1turn21search0 Tabela de mitigação (mapeando risco → prevenção → detecção): | Risco | Prevenção recomendada (OpenClaw/config) | Controles externos úteis | Sinais/detecção prática | |---|---|---|---| | Exposição indevida do Gateway | `bind: "loopback"`, auth por token/senha, DM policy conservadora | Firewall/VPN/tailnet | Verificar sockets/portas; usar `openclaw status --deep` e `health`. citeturn20view3turn19search2turn10search3 | | Execução perigosa via ferramentas | Sandbox `mode: "all"`, `workspaceAccess: "none/ro"`, denylist de `exec/write/browser` em agentes não confiáveis | Contêiner restrito (cap-drop/read-only), AppArmor/SELinux (não documentado no projeto) | Revisar logs de tool calls; auditoria `security audit`. citeturn20view3turn10search1turn10search5turn19search0 | | Vazamento por logs/transcrições | `logging.redactSensitive`, reduzir retenção, preferir `status --all` ao compartilhar | SIEM/DLP (fora do escopo do projeto) | Inspecionar log JSONL; alertar para strings/padrões de secrets. citeturn19search0turn19search17turn19search1 | | Supply-chain via skills | Preferir skills escaneadas/pinadas; evitar instruções “copie e cole comando” | Mirror interno/allowlist; verificação de hash/reputação | Monitorar installs/updates; revisar skills em `~/.openclaw/skills` e workspace. citeturn9search2turn12search14turn25view1turn16view1 | | Token theft / UI abuse | Atualizar para versões corrigidas; hardening de UI/origin/allowedOrigins; rotacionar tokens | Treinamento anti-phishing; browser isolation | Monitorar acessos anômalos e eventos de config.apply; responder com “kill switch” (parar gateway, rotacionar secrets). citeturn22view4turn24search0turn10search21turn13search8 | ## Avaliação prática para substituir funções de conteúdo ### Premissa e limites técnicos (antes de testar) Como o OpenClaw é um orquestrador de **modelo + ferramentas + skills**, a capacidade de “substituir” papéis como designer gráfico ou social media manager depende mais do **toolchain/integrations** instalados do que do core em si. A documentação indica que integrações que não existem “nativamente” podem ser feitas via skill/plugin (mais confiável) ou via automação de browser (mais frágil e lenta). citeturn18view1turn20view3 O Canvas host fornece HTML/A2UI editável pelo agente, o que abre um caminho para protótipos e geração de assets simples (ex.: páginas, layouts, cards em HTML/SVG), mas “design gráfico completo” (ex.: arquivos nativos do Adobe/Figma, tipografia/kerning avançado, produção pronta para impressão) não aparece como garantia do core nas fontes analisadas. (Logo: tratar como **não garantido** e avaliar empiricamente.) citeturn20view2turn20view0 ### Plano de experimentos e métricas O objetivo dos testes abaixo é responder: “com o meu stack de modelo + skills + políticas de segurança, o OpenClaw entrega qualidade, consistência e velocidade suficientes para substituir/automatizar parte relevante do trabalho?” Métricas sugeridas (mensuráveis, com baixa ambiguidade): - **Tempo até primeiro rascunho útil** (minutos) e **tempo até versão “publicável”** (minutos). - **Taxa de retrabalho**: número de ciclos de revisão até aprovação. - **Consistência de marca**: checklist (tom, paleta, tipografia, CTA, compliance). - **Confiabilidade operacional**: erros por tarefa (falhas de tool, timeouts, ações indevidas). - **Custo e pressão de tokens**: usar tracking do próprio OpenClaw para tokens/custos (quando disponível) e observar efeitos de compaction. citeturn19search16turn9search19turn20view1 - **Risco residual**: quantas tarefas exigiram elevar permissões (`exec`, browser, escrita) e quantas foram bloqueadas por políticas/sandbox. citeturn20view3turn10search1 ### Cenários práticos com prompts e outputs esperados **Designer gráfico (conteúdo estático e variações)** Objetivo: produzir um kit básico de assets de social (padrões, templates e variações), usando Canvas/HTML/SVG e/ou integrações externas (se instaladas). Prompt exemplo (instrução operacional, para sessão privada): - “Crie um mini brand kit (cores, fontes alternativas web-safe, tom) para uma marca X. Depois gere 6 variações de um card (1080×1080) em SVG e em HTML/CSS para Canvas, com placeholders de imagem e texto. Salve tudo no workspace e entregue um índice com caminhos.” Outputs esperados: - Documentos no workspace (ex.: `brand/`, `assets/`) e cards renderizáveis no Canvas. citeturn20view2turn9search19 Falhas prováveis: - inconsistência visual ao longo de variações; - dependência de execução local (renderização) e limitações de tipografia; - risco de “alucinar” guidelines de marca sem validação; - aumento de custo/token por drafts grandes e iteração. citeturn9search19turn20view1 **Social media manager (calendário editorial + posts + publicação)** Objetivo: criar calendário, drafts e workflows de publicação, com ênfase em governança. Prompt exemplo: - “Planeje um calendário de 2 semanas (LinkedIn + Instagram) com 1 post por dia, com tema, hook, CTA e hashtags. Gere também um ‘brief de criativos’ por post. Não publique nada; apenas salve os drafts no workspace e gere um checklist de revisão.” Outputs esperados: - Uma estrutura organizada no workspace e um checklist de revisão; opcionalmente, cron jobs para lembretes (não publicação automática) se o usuário desejar. citeturn18view1turn18view1 Falhas prováveis: - halucinação de métricas, tendências e hashtags se não houver ferramenta confiável; - risco de publicar/mandar mensagens indevidas se permissões de outbound estiverem abertas; - necessidade de integração específica (API) para publicação real, que pode não existir sem skill/plugin. citeturn18view1turn20view3turn13search8 **Outros papéis de conteúdo (copywriter, suporte/CM, roteirista)** Para copywriting e community management, o core tende a ser mais viável porque exige menos “ação privilegiada” e mais produção textual — mas ainda assim é necessário medir: consistência, factualidade, alinhamento de tom e riscos de vazamento (memória/logs). citeturn20view1turn19search17turn25view0 ### Recomendação de execução segura dos testes Para evitar que o experimento de “substituição de papéis” aumente risco, a recomendação prática é: - Rodar testes em um agente dedicado “conteúdo” com **tool allowlist** restrita (idealmente sem `exec` e com workspace `ro` quando a tarefa não exige escrita). citeturn20view3turn10search23 - Manter publicação automática desabilitada; usar “drafts + checklist” e revisão humana como checkpoint. citeturn20view3turn13search8 - Log/retention mínimos para conteúdo sensível e uso de redaction. citeturn19search17turn19search0 - Repetir as mesmas tarefas com (a) modelos diferentes e (b) configurações de memória diferentes, para isolar o impacto de contexto/compaction. citeturn18view1turn20view1turn9search19 ## Fontes primárias recomendadas Os itens abaixo são os “primeiros lugares para olhar” antes de confiar em qualquer tutorial, vídeo ou post: Repositório oficial na entity["company","GitHub","code hosting platform"] (core, releases, issues, security advisories). citeturn20view0turn11search32turn22view4 Documentação oficial (arquitetura, instalação, configuração, segurança, troubleshooting, comandos). citeturn20view4turn20view2turn20view3turn19search23turn19search18 Repositório e site de trust/threat model (inclui `threats.yaml` e escopo do programa). citeturn13search8turn16view1 Repositório/serviço do ClawHub (formato de skills, e issues do registry). citeturn11search1turn11search5turn9search2 Base de CVEs e estudos de vulnerabilidade: entity["organization","National Vulnerability Database","nist vulnerability database"]/entity["organization","NIST","us standards agency"] e advisories do GitHub (para versões atingidas/corrigidas). citeturn22view0turn22view1turn24search0turn23search0 Frameworks e taxonomias citadas pelo projeto: entity["organization","MITRE","us nonprofit security org"] ATLAS (referenciado no threat model). citeturn16view1turn13search8 Relatos oficiais do projeto sobre segurança do marketplace (parceria com VirusTotal) e postura de segurança. citeturn12search14turn6view0turn13search8 Fontes em pt-BR para contexto e incidentes recentes: matéria técnica da Trend Micro Brasil e reportagem do TecMundo sobre campanhas via skills. citeturn25view0turn25view1 **Nota metodológica:** detalhes não documentados nas fontes acima foram tratados como “não verificados/não especificados”, conforme solicitado.