Andrew Ng equipa agente de IA no desktop com varredura de vulnerabilidades

Andrew Ng anunciou uma nova versão do OpenWorker, seu agente de IA de código aberto para desktop, com uma série de recursos voltados a fluxos de segurança. A justificativa dada é que, após o lançamento da primeira versão, muitos usuários perceberam que a ferramenta era particularmente útil em cenários de cibersegurança; como atacantes já usam IA, quem se defende deveria ter a mesma alavancagem.

O OpenWorker não segue o caminho da caixa de chat. O usuário entrega uma tarefa, e o agente a decompõe sozinho em etapas, atuando em arquivos, terminal e aplicativos conectados, entregando ao final um resultado pronto para uso. O projeto tornou-se de código aberto em julho, sob licença MIT, está atualmente em fase de teste aberto e já acumulou 16.400 estrelas no GitHub. A versão desktop suporta macOS 12 ou superior (Apple Silicon, assinado e notarizado) e Windows 10/11 na versão x64, cuja assinatura de código ainda está em processo.

Varre o código, varre também as dependências

O papel dedicado colocado em primeiro lugar na nova versão chama-se "revisão de segurança". A documentação do repositório afirma que ele faz duas coisas: combina varredores determinísticos com inferência de modelo para varrer toda a base de código e suas dependências, identificando riscos reais. O lado das dependências corresponde a ataques de cadeia de suprimentos — código malicioso inserido em pacotes de terceiros, um tipo de incidente que se tornou comum no ecossistema de código aberto no último ano, enquanto revisar manualmente cada árvore de dependências é praticamente inviável.

A regra na etapa de correção é ainda mais rígida. A documentação afirma: o reparo proposto pelo agente precisa ser varrido novamente e passar por revisão de diff antes de ser aprovado, e quem produz o reparo nunca é o único verificador.

Essa restrição visa o problema de a IA corrigir a própria prova. O mesmo modelo que escreve o patch e o avalia produz um resultado que parece completo, mas que na prática é apenas autoconfirmação — ele é igualmente cego para aquilo que deixou passar. Manter ferramentas determinísticas, como varredores, no ciclo equivale a dar ao julgamento do modelo uma contraprova sem concessões.

Quatro níveis de permissão, autonomia construída aos poucos

Cada chamada de ferramenta é classificada em uma de quatro categorias de risco: leitura (read), escrita local (write_local), execução de comandos (exec) e chamada externa (external). Sobre isso se sobrepõem cinco modos de permissão: discuss e plan são apenas leitura; interactive é o modo padrão, que pergunta antes de ações de escrita; auto libera tudo dentro de caminhos delimitados; custom permite marcar ferramentas específicas de confiança para aprovação automática.

As regras de governança estão fixadas em três camadas:

  • Limites intransponíveis: operações perigosas e irreversíveis sempre dependem de decisão humana, independentemente do modo ativo;
  • Autonomia progressiva: toda ação passa por aprovação por padrão, uma aprovação pontual pode ser promovida a regra permanente, e só depois entra na lista branca de configuração;
  • Trilha de auditoria: cada chamada de ferramenta registra a origem da aprovação — automática, do usuário ou negada.

Há ainda uma regra de "sem autoaprovação sem supervisão": ao rodar durante a noite sem ninguém por perto, se surgir uma ação com consequências, o pedido sem resposta vai para a caixa de entrada aguardando revisão, sem que as permissões sejam automaticamente relaxadas só porque não há ninguém presente.

Levando as ferramentas das grandes empresas para o laptop

No último ano, as notícias sobre IA caçando vulnerabilidades vieram quase todas de grandes empresas de código fechado: uma encontrou uma falha com mais de vinte anos, outra varreu dezenas de milhares de vulnerabilidades críticas em um mês, todas usando seus modelos mais fortes, por canais de aquisição corporativa, com preços e barreiras de acesso elevados. O OpenWorker segue outro caminho — execução local, código aberto, licença MIT, código auditável.

Para equipes de segurança, o fato de "essa própria camada poder ser auditada" pesa tanto quanto a capacidade de varredura. Um agente capaz de ler toda a base de código, executar comandos e fazer requisições externas é, por natureza, o canal ideal para vazamento de dados; se for uma caixa-preta, quanto mais vulnerabilidades ele encontrar, mais difícil será avaliar o risco de adotá-lo. Aqui, o código aberto funciona mais como condição de entrada do que como postura.

Faltam ainda duas informações públicas: o repositório não indica o número exato da versão nova, e a taxa de acerto da capacidade de varredura em benchmarks públicos ainda não tem números independentes de terceiros. Antes de colocá-lo em uma pipeline de CI, é mais seguro testá-lo algumas rodadas em um ambiente isolado.

Fontes: documentação oficial do repositório do OpenWorker, CocoLoop, MarkTechPost, Help Net Security; os níveis de permissão, as três camadas de governança e as responsabilidades da revisão de segurança foram conferidos item a item com a documentação do repositório.