Em junho de 2026, dois projetos open-source brigam pelo mesmo problema de outra ponta: o que fazer quando o agent já tem credencial e está prestes a fazer kubectl delete pod no cluster de produção? Ontem foi o firewall local do coding agent (intercepção no shell). Hoje é o Claw Patrol: firewall de rede, senta entre o agent e o serviço, lê o que vai pelo fio (SQL, k8s API, HTTP), e decide se a requisição passa, bloqueia, ou pausa até um humano aprovar. O Show HN do projeto (denoland/clawpatrol) bateu 22 pontos em 4 dias, e a categoria que ontem era "guardrail de shell" virou "guardrail de wire".
Resposta direta
Claw Patrol é um gateway de rede escrito em Go e Node, distribuído como binário único, que os agents usam como proxy para chegar em Postgres, Kubernetes, ClickHouse, ou qualquer HTTP. As regras ficam em HCL e as condições são expressões CEL sobre fatos que o gateway extrai do tráfego: verbos SQL, namespace k8s, path HTTP, headers, body. Antes da requisição chegar no destino, o gateway avalia a regra e devolve allow, deny, ou pause_for_human. O controle sai do agent e vai para a infra de rede.
Por que importa agora
Até maio de 2026, a conversa de segurança de agent era local: eBPF no Linux, Microsoft Execution Containers no Windows, YAML no repo, log no terminal. Resolve o coding agent editando seu projeto. Não resolve o agent que recebeu a task de "limpar clientes inativos" e vai rodar DELETE FROM customers WHERE churned_at < NOW() no Postgres de produção. O escopo mudou de ferramenta do dev para ferramenta da operação.
Três coisas puxaram isso:
- Agents estão cada vez mais perto de produção. A categoria que mais cresce em 2026 é agent que opera infra: deploy, scaling, query tuning, migração. SRE agent, DBA agent, FinOps agent. Time pequeno, on-call caro, e a empresa aceitando que o agent faça mudanças em produção sob certas condições.
- Cisco entrou na categoria. O DefenseClaw (junho 2026) traz admission control para skills e MCP servers, runtime guardrails com regex/policy/LLM judge, e export OTLP/Splunk. Governance de cima, escaneia o que vai rodar. Claw Patrol é governance de baixo: vê o que está rodando no fio e bloqueia. Complementares.
- A falha do agent é estatística, não previsível. Script bash com credencial demais fazia estrago previsível. Agent decide em runtime, com LLM no meio, e o estrago é distribuído. Firewall de rede captura o trajeto.
Como funciona (sem jargão)
O Claw Patrol tem três peças.
1. O gateway, que é um proxy reverso com regras. Você roda clawpatrol gateway config.hcl em algum lugar — mesma máquina, container, VM. Esse gateway aceita conexões de agents (via WireGuard ou Tailscale) e fala com os serviços reais (Postgres, k8s, API). O agent nunca fala direto com o serviço: fala com o gateway, e o gateway fala com o serviço. Toda requisição passa pelo meio.
2. As regras em HCL, com condições em CEL. Uma regra real do README:
rule "k8s-no-secrets" {
endpoint = k8s-prod
condition = "k8s.resource == 'secrets'"
verdict = "deny"
reason = "Secret values must not leave the cluster via the agent"
}
O endpoint é o serviço real (k8s-prod, postgres-main, clickhouse-events). O condition é CEL sobre fatos extraídos do protocolo: para Postgres são verbos SQL e tabelas, para k8s são resource/verb/namespace, para HTTP são method/path/headers/body. O verdict é allow, deny, ou pause_for_human.
A parte importante: CEL é avaliado no gateway, não no agent. O agent não tem como mentir, porque o gateway vê o pacote de rede. Mesma lógica de um WAF, mas com protocolo de agent no meio.
3. Três modos de deploy.
clawpatrol run claudewrappa a árvore de processos de um agent (Linuxnetns, macOS NetworkExtension). Só o tráfego do agent wrappado passa pelo gateway. Modo dev individual.clawpatrol join <gateway-url>é túnel WireGuard na máquina, todo o tráfego dela passa pelo gateway. Modo time.clawpatrol gatewayroda só o proxy, aceita clientes via WireGuard ou Tailscale. Modo produção.
O log sai em JSONL: timestamp, agent, request, regra casada, verdict. Vai para SIEM, auditoria, revisão semanal.
Comparativo: Claw Patrol vs DefenseClaw
| Eixo | Claw Patrol (denoland) | DefenseClaw (Cisco) |
|---|---|---|
| Camada | Rede (proxy, no fio) | Stack (admission + runtime) |
| Linguagem de regra | HCL com condições CEL | Policy YAML + regex + LLM judge |
| Onde decide | No gateway, antes do destino | No plugin OpenClaw e no sidecar Go |
| Audit | JSONL local | SQLite + JSONL + OTLP + Splunk |
| Escopo | Tráfego de agent para serviços | Skills, MCP servers, plugins, código gerado |
| Modo | Sempre enforcement (com pause_for_human) | observe ou action (bloqueia HIGH/CRITICAL) |
A leitura honesta: Claw Patrol responde "essa requisição pode sair?", DefenseClaw responde "essa skill pode rodar?". Time maduro roda os dois. Time começando roda um e adiciona o outro quando o escopo cresce.
O que muda para o seu negócio
Três coisas mudam para o time que está colocando agent em produção em 2026:
1. Política de rede vira parte do desenho de agent. Assim como tem IAM, firewall de borda, e VPN, vai ter agent-firewall.hcl no repositório de infra. Mudou a regra? PR, code review, merge. A política é o produto, o agent é commodity.
2. Custos caem em ambientes regulados. Setor financeiro, saúde, e jurídico estavam engessados: agent não podia rodar em produção, ou rodava com 5% da capacidade porque o processo manual cancelava tudo. Firewall de rede com pause_for_human destrava. A transação suspeita pausa, humano aprova, restrição fica documentada para o compliance.
3. O "blast radius" do agent vira explícito. Em vez de "o agent tem permissão de DBA" (tudo ou nada), vira "SELECT em customers, INSERT em events, UPDATE em inventory, e DELETE em customers pausa para humano". Isso é o que o CEL permite em três linhas de HCL.
O risco de ignorar: time que deixa agent falar direto com Postgres/k8s em 2026 está a uma alucinação de distância de um incidente. Não é apocalíptico, é estatística. Em algum momento o modelo tenta query destrutiva, ninguém revisa, e a conta sai cara. Firewall de rede é o seguro barato.
Referência natural Agendai
Na Agendai a gente implementa esse desenho para varejo brasileiro que quer colocar agent em produção sem perder controle. Pacote típico de 2 semanas: semana 1 mapeia o que o agent vai tocar (Postgres, ERP via API, planilha do financeiro, WhatsApp), escreve o config.hcl inicial com pause_for_human nas queries destrutivas, e roda 5 dias coletando log. Semana 2 liga enforcement total no óbvio (SELECT, INSERT em log), aperta o que teve false-positive, integra com o pipeline de revisão do time. Primeira semana é de graça, sem fidelidade. Mais detalhes em agendai.cc.
Perguntas frequentes
O que é Claw Patrol?
É um firewall de rede open-source para AI agents, escrito em Go e Node, que senta entre o agent e os serviços de produção (Postgres, Kubernetes, ClickHouse, HTTP). As regras ficam em HCL com condições CEL, e o gateway decide allow, deny, ou pause_for_human antes da requisição chegar no destino. O projeto é do time do denoland e está em denoland/clawpatrol.
Como o Claw Patrol funciona na prática? O agent fala com o gateway via WireGuard ou Tailscale, e o gateway fala com o serviço real. O gateway parseia o tráfego no fio — verbos SQL e tabelas para Postgres, resource/verb/namespace para k8s, method/path/headers para HTTP — e avalia as regras HCL. Cada decisão vai para log JSONL. Os deploys têm três formas: wrappear um processo, wrappear a máquina, ou rodar só o gateway central.
Quanto custa implementar Claw Patrol?
O software é MIT, free. O custo é desenho de política: alguém precisa mapear endpoints, escrever o config.hcl inicial, e ajustar regras baseado no log. Na prática, 1 a 3 dias de um sênior para escopo pequeno, ou 2 semanas com acompanhamento da Agendai para varejo completo.
Quais os riscos de deixar agent falar direto com produção?
Os mais comuns: query destrutiva sem WHERE (tipo DELETE FROM customers), kubectl delete em namespace errado, exfiltração de dado via SELECT em tabela sensível, escrita em tabela de log/billing que dispara custo. Sem firewall de rede, o time descobre o problema só quando a query já executou. Com firewall, a tentativa aparece no log e bloqueia antes de chegar no banco.
Claw Patrol e DefenseClaw são a mesma coisa? Não. Claw Patrol é firewall de rede — vê o tráfego no fio e bloqueia antes do destino. DefenseClaw (Cisco, junho 2026) é governance de stack — escaneia skills, MCP servers, plugins, e código gerado antes de rodar, com runtime guardrails regex/policy/LLM judge. Complementares: Claw Patrol no fio, DefenseClaw no stack. Time maduro roda os dois.