O Deno acaba de abrir o código de seu Firewall de Agentes (Claw Patrol)

BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00Este é o Claw Patrol, um firewall de segurança de código aberto construído pela equipe Dino que fica entre
00:00:04seus agentes de IA e a internet, e resolve três problemas fundamentais de segurança com agentes de IA.
00:00:09Acesso não é controle real, seu agente não deveria ver segredos e você não pode ver o que seu agente
00:00:14fez. Tenho testado muitas ferramentas de segurança para agentes de IA recentemente e realmente gosto da abordagem
00:00:19que o Claw Patrol adotou aqui, mas ainda não é perfeita. Então, o funcionamento do Claw Patrol é: você tem
00:00:28um servidor chamado gateway, que guarda suas regras, credenciais, logs e o painel do Claw Patrol,
00:00:32e então você tem qualquer número de máquinas que rodam agentes, e elas podem se juntar
00:00:36a esse gateway e rotear o tráfego dos agentes através dele. Na verdade, você pode optar por rodar comandos individuais
00:00:40através do gateway, ou pode adicionar sua máquina inteira. No meu caso, meu gateway é simplesmente um servidor
00:00:45Ubuntu, ao qual me conecto com Tailscale, que o Claw Patrol suporta nativamente, bem como
00:00:50WireGuard ou ambos, e meus agentes são meu Mac e meu servidor OpenClaw. Estou rodando o gateway OpenClaw
00:00:55através do Claw Patrol, e no meu Mac eu apenas uso o comando de execução única com Clawd quando preciso.
00:01:00Com esse contexto, vamos analisar os três principais problemas que o Claw Patrol resolve, e vou
00:01:04começar pelo número dois, que é: seus agentes não deveriam ver segredos, pois isso leva bem aos
00:01:09outros problemas. No gateway do Claw Patrol, você pode configurar suas credenciais, como usuários Postgres,
00:01:14assinaturas Clawd, contas do GitHub e quaisquer tokens de portador ou cabeçalhos personalizados, como tenho aqui para meu
00:01:19servidor de API de produção. Com isso, quando rodamos nossos agentes pelo gateway usando esse comando
00:01:25Claw Patrol run, eles não precisam de nenhuma dessas credenciais para que as requisições funcionem. Elas simplesmente
00:01:30serão injetadas quando a requisição passar pelo gateway. Então, se eu pedir ao Claw para usar minha API e meu
00:01:35banco de dados para me dar uma visão geral de ambos, ele consegue fazer isso sem problemas, e posso ver nos
00:01:41comandos que ele está executando que ele não está incluindo nenhuma chave de API para essas requisições curl,
00:01:46mas ele precisa de uma, e no Postgres, ele está usando apenas uma senha falsa “X”, que definitivamente não é a senha
00:01:51real, mas ele ainda se conecta e obtém as informações relevantes, já que o gateway
00:01:56detectou essas requisições e anexou as credenciais reais. Isso significa que o agente nunca
00:02:00tem acesso aos valores reais, então se alguém visse os logs do meu agente ou tentasse uma injeção de prompt,
00:02:06nunca conseguiria essas credenciais, pois elas vivem em um servidor completamente separado, e o agente não tem
00:02:10como acessá-las. Para mostrar esse processo de injeção de forma ainda mais clara, se eu executar esta requisição curl no meu
00:02:15terminal, você pode ver que ela é rejeitada porque não passei uma chave de API, mas se eu executar o exato
00:02:20mesmo comando através do “claw patrol run”, os dados retornam normalmente, pois a chave de API está sendo injetada.
00:02:26O próximo problema que o Claw Patrol pretende resolver é que acesso não é controle de ação. O Claw Patrol te dá
00:02:31um controle muito refinado sobre o que um agente pode fazer com uma requisição. Por exemplo, se eu usar aquela habilidade
00:02:36do Postgres novamente, mas desta vez pedir para deletar uma tabela e criar uma nova, quando ele roda, imediatamente
00:02:41retorna uma mensagem de erro personalizada que configurei, dizendo que mudanças de esquema só são permitidas via PRs de migração,
00:02:46não via agente. O gateway examinou a requisição Postgres que meu agente fez,
00:02:51e a verificou contra um conjunto de regras que defini, e graças a uma das minhas regras, ele negou
00:02:56a requisição de deleção de tabela. Outra maneira de lidar com isso é com um humano no circuito, para que eu possa
00:03:00fazer com que essa regra entre em contato comigo para aprovar a ação. No momento, ela só suporta
00:03:04Slack, mas mais opções virão em breve. Existe até uma opção de usar uma LLM como juiz,
00:03:09e as regras são incrivelmente personalizáveis e flexíveis, então você pode até ter regras como verificar
00:03:13seu endpoint de API de suporte ao cliente que envia respostas, e você pode ver se há algum conteúdo ofensivo,
00:03:18saudações faltando, ou simplesmente qualquer coisa que você não queira que vaze nessa requisição. E novamente,
00:03:22tudo isso sendo feito na requisição no gateway significa que, teoricamente, tudo isso está protegido contra
00:03:27injeções de prompt e praticamente todos os outros tipos de ataques de IA. O terceiro problema que o Claw Patrol
00:03:31resolve é: você não pode ver o que o agente fez, mas com o Claw Patrol, cada requisição é visível
00:03:37no painel aqui, e você pode até ver sessões ativas, bem como os tokens usados, e se clicar
00:03:42em uma requisição, pode ver os detalhes relevantes, como o comando Postgres que foi executado,
00:03:46ou, no caso de uma chamada de API, você pode ver a requisição de API, bem como a resposta recebida.
00:03:51Dessa forma, você não precisa perder tempo procurando em todos os logs dos serviços individuais
00:03:55que o agente tocou para tentar entender o que ele fez; em vez disso, você pode ver o que ele fez
00:03:59no ponto da requisição, então você deve ver praticamente tudo o que o agente faz.
00:04:03Esses são os três problemas que o Claw Patrol pretende resolver, mas como tudo isso é configurado? Bem,
00:04:07uma vez que você tem o Claw Patrol instalado, o gateway é configurado com um único arquivo HCL.
00:04:12Nele, você define os vários endpoints para os quais terá regras e credenciais,
00:04:16então tenho vários, como OpenAI, Slack, SSH, Postgres e assim por diante. Se qualquer requisição passar
00:04:22pelo gateway e corresponder a um deles, ele saberá verificar as regras e credenciais.
00:04:26Quanto às credenciais em si, a configuração é bem direta também.
00:04:30Você diz qual é o tipo de credencial e qual endpoint ela deve corresponder.
00:04:34Há suporte para muitos tipos de credenciais, como assinaturas Anthropic, Codex,
00:04:39ClickHouse, Postgres e também o básico, como tokens de portador e cabeçalhos personalizados,
00:04:43então você deve encontrar suporte para quase todos os tipos que precisa,
00:04:46e mesmo que não haja, você pode programar plugins para adicionar seu próprio tipo.
00:04:50Uma vez definida uma credencial, basta ir ao painel para preencher o
00:04:54valor real. Configurar regras também é bem fácil.
00:04:56Você simplesmente diz o endpoint ao qual a regra se aplicará e escreve a regra
00:05:00usando a Common Expression Language, então isso pode cobrir uma ampla gama de coisas, como HTTP,
00:05:05Postgres, Kubernetes e assim por diante. Depois disso, você diz o veredito para a regra que
00:05:09acabou de definir, se aprova ou nega com base nela. Você usaria “aprovar” aqui se estivesse criando
00:05:14uma abordagem baseada em lista de permissões em vez de uma lista de bloqueios; assim, você bloquearia tudo por padrão e
00:05:18só permitiria certas coisas. No meu caso, no entanto, usei simplesmente o método de lista de bloqueios.
00:05:22Finalmente, outro recurso muito útil aqui são os perfis. Você pode agrupar suas credenciais
00:05:26em múltiplos perfis, o que significa que quaisquer regras e endpoints anexados a essas credenciais
00:05:31também são agrupados junto com elas, e isso permite que você configure um tipo de controle baseado em função para seus
00:05:35agentes e suas equipes, de modo que os desenvolvedores possam ter certo acesso a credenciais e diferentes regras para
00:05:40eles, e talvez outra equipe, como uma equipe de suporte, tenha credenciais diferentes e regras diferentes
00:05:45também. Para ajudar você ao fazer mudanças nas regras, há um comando de teste onde você pode
00:05:49baixar ações de regra do painel e então reexecutá-las contra suas mudanças locais de regra para ver se
00:05:54alguma delas mudou o resultado, para que você possa identificar se haverá algum vazamento acidental.
00:05:59Devo admitir que achei esse processo de configuração um pouco entediante, e tenho certeza de que será
00:06:02melhorado em breve, pois isso é muito inicial no ciclo de vida do projeto, mas se houvesse apenas uma maneira simples de adicionar
00:06:07credenciais e regras a partir do painel, isso seria absolutamente incrível. Talvez algo semelhante a
00:06:11como o AdGuard funciona, onde você pode apenas ver uma requisição passando e clicar para adicionar uma regra ou
00:06:15credencial para essa requisição. Também tive muitos problemas ao tentar adicionar endpoints
00:06:19que eram apenas endereços IP ao meu servidor Proxmox local. Por algum motivo, ele simplesmente não queria
00:06:24interceptar essas requisições, e eu não conseguia ver nenhuma delas passando no painel, e isso apenas
00:06:28me deu uma dor de cabeça. Então definitivamente há alguns reparos necessários, ou talvez eu estivesse apenas usando incorretamente,
00:06:33mas de qualquer forma, sim, vai dar trabalho para chegar a um ponto de usabilidade que não interrompa
00:06:38seu fluxo, mas isso faz sentido, já que é tudo sobre segurança e não apenas enviar um agente
00:06:43em modo “YOLO”. Então me deixem saber nos comentários abaixo o que acham do Claw Patrol, e se
00:06:47têm alguma ferramenta de segurança que usam para seus agentes. Enquanto estiverem aí, inscrevam-se e, como
00:06:51sempre, nos vemos na próxima.

Key Takeaway

O Claw Patrol aumenta a segurança no uso de agentes de IA ao interceptar requisições em um gateway central, injetando credenciais sensíveis em tempo de execução e aplicando políticas de controle refinadas contra ações indesejadas.

Highlights

  • O Claw Patrol atua como um gateway centralizado entre agentes de IA e a internet para mitigar riscos de segurança.

  • O sistema injeta automaticamente credenciais reais em requisições de agentes, evitando que chaves de API e senhas fiquem expostas no ambiente de execução do agente.

  • Regras de firewall configuradas via Common Expression Language (CEL) permitem bloquear ações específicas, como modificações de esquema em bancos de dados Postgres.

  • O painel do Claw Patrol centraliza o monitoramento, permitindo a visualização detalhada de requisições, comandos executados e respostas recebidas em tempo real.

  • A configuração do gateway utiliza um arquivo HCL, suportando integração nativa com Tailscale e WireGuard para conectividade segura.

Timeline

Arquitetura e problemas de segurança em agentes

  • O Claw Patrol posiciona um servidor gateway entre agentes de IA e a internet.
  • O sistema resolve problemas de exposição de credenciais, falta de controle sobre ações e invisibilidade das atividades do agente.

O gateway centraliza regras, logs e credenciais, permitindo que múltiplos agentes roteiem o tráfego através dele. A infraestrutura suporta conexões via Tailscale ou WireGuard. É possível integrar máquinas inteiras ou rodar comandos únicos de execução via Clawd.

Injeção de credenciais e controle de acesso

  • Credenciais reais não são armazenadas no ambiente do agente, sendo injetadas apenas durante a passagem pelo gateway.
  • O firewall permite definir permissões granulares, como impedir alterações de esquema em bancos de dados por agentes.
  • Regras podem ser configuradas para exigir aprovação humana via Slack ou utilizar uma LLM como juiz para validar requisições.

O agente utiliza senhas fictícias ou omite chaves de API durante o processamento, mantendo a segurança caso ocorra uma injeção de prompt ou vazamento de logs. O gateway valida cada ação contra um conjunto de regras, bloqueando ou permitindo o tráfego conforme o endpoint e a intenção da operação.

Monitoramento e configuração de regras

  • O painel do gateway oferece visibilidade total de sessões, tokens utilizados e detalhes de cada comando ou chamada de API.
  • A configuração é feita via arquivo HCL, utilizando Common Expression Language (CEL) para definir regras de negação ou permissão.
  • O sistema permite criar perfis que agrupam credenciais e regras, facilitando o controle baseado em funções para diferentes equipes.

A depuração de regras é facilitada por um comando de teste que compara mudanças locais com ações reais do histórico. Embora funcional, o processo de configuração inicial ainda é considerado complexo e apresenta limitações técnicas ocasionais com o uso de endereços IP diretos.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video