Sistemas multiagentes para segurança e revisão de código

Quando sistemas multiagentes melhoram segurança e revisão de código

Sistemas multiagentes para segurança e revisão de código ajudam quando aumentam independência, cobertura e evidência. Eles falham quando apenas colocam vários agentes correndo em paralelo sobre o mesmo contexto, com as mesmas ferramentas e a mesma conclusão esperada. A pergunta inicial deve ser simples: cada agente tem um papel claro, uma fronteira de autoridade e uma forma própria de provar o que encontrou?

O melhor uso aparece em tarefas que se beneficiam de perspectivas separadas. Um agente pode implementar uma correção pequena. Outro pode procurar regressões. Um terceiro pode revisar permissões, dependências, segredos, pontos de entrada, logs e efeitos externos. Um coordenador pode manter escopo e sequência. A revisão fica mais forte quando o revisor não herda o raciocínio do implementador como verdade, e sim reconstrói o risco a partir do diff, dos testes, do modelo de ameaça e das políticas do projeto.

A pesquisa da Anthropic sobre sistemas multiagentes reforça uma ideia que também vemos em produto: desempenho depende de coordenação, e coordenação precisa de desenho. Mais agentes não criam segurança por si. O valor vem de papéis separados, evidência verificável, limites de ferramenta, parada clara e decisão humana quando a mudança tem impacto real. Para aprofundar a camada de identidade e prova de ação, mantemos o guia Identidade de agentes de IA: permissões, aprovação por ferramenta e auditoria no Android, que aplica a mesma disciplina de autoria, permissão e trilha de auditoria a agentes em ambientes com efeitos concretos.

Escolha a topologia: coordenador, workers, revisor e merge humano

A topologia mais confiável separa quatro responsabilidades. O coordenador define objetivo, escopo, arquivos permitidos, critérios de aceite, orçamento e condição de parada. Os workers executam partes limitadas do trabalho: correção, teste, documentação, migração pequena, atualização de dependência ou análise de superfície. O revisor independente recebe o diff e o modelo de ameaça com liberdade para discordar. A autoridade de merge fica com uma pessoa ou com um processo humano governado, porque consenso de agentes não equivale a responsabilidade de release.

Há três padrões comuns. No modelo coordenador-worker, um agente central distribui tarefas e consolida resultados. Ele é bom para reduzir colisões, mas pode concentrar vieses se filtrar demais as evidências. No modelo peer-to-peer, agentes conversam entre si e refinam a solução. Ele pode acelerar descoberta, mas tende a convergir cedo quando todos compartilham o mesmo contexto. No modelo implementador-revisor, um agente escreve e outro examina com separação forte. Para segurança de código, esse terceiro padrão costuma ser o mais importante, mesmo quando os outros dois existem ao redor.

O agente revisor deve ser independente porque segurança nasce da possibilidade de desacordo. Ele precisa poder dizer que o patch resolve o bug funcional, mas abre exposição de segredo; que os testes passam, mas não cobrem o caminho de autorização; ou que a mudança reduz erro de UI e aumenta privilégio de ferramenta. Se o revisor compartilha cada hipótese intermediária com o implementador, a revisão pode perder variação útil e virar confirmação.

Para equipes que constroem agentes com ciclos de avaliação, a governança também precisa de harness, versão de cenário, repetição e reversão. O guia Phone agent autoaprimorável: versões, testes e reversão ajuda a pensar essa disciplina em um domínio diferente: agentes que melhoram por avaliação precisam preservar evidência, não apenas parecer mais fluentes.

Falhas de coordenação, recursos compartilhados, conformidade e conluio

A pesquisa atual da Anthropic destaca riscos que se traduzem diretamente para revisão de código. O primeiro é falha de coordenação. Dois agentes podem resolver partes diferentes do problema e ainda assim quebrar o sistema quando as mudanças se encontram. Um altera uma API, outro atualiza testes contra a assinatura antiga, e um terceiro documenta um comportamento que nenhum dos dois preservou. Coordenação útil exige dono de interface, contrato de mudança e ponto de integração.

O segundo risco vem de recursos compartilhados. Worktree, fila de tarefas, cache, credencial, ambiente de teste, banco de dados temporário e quota de ferramenta são recursos mutáveis. Quando vários agentes escrevem ou consomem os mesmos recursos sem bloqueio, o resultado pode ser interferência invisível. Um teste pode passar porque outro agente preparou estado local. Um segredo pode vazar porque um worker recebeu credencial ampla para uma tarefa curta. Um comando de limpeza pode apagar evidência que o revisor precisava examinar.

O terceiro risco é conformidade. Comunicação entre agentes ajuda a coordenar, mas também pode reduzir diversidade. Se o primeiro agente declara cedo que a correção é segura, os demais podem alinhar a leitura em torno dessa conclusão. Em revisão de segurança, variação é uma ferramenta: um agente deve procurar abuso de permissão, outro deve procurar exposição de dados, outro deve testar rollback, e o revisor deve preservar a capacidade de chegar a uma conclusão desconfortável.

O quarto risco é conluio ou alinhamento estratégico indesejado. Em pesquisa, comunicação pode melhorar desempenho e também abrir espaço para agentes coordenarem respostas de forma que contorne uma avaliação. Em produção, a leitura prática não é tratar toda comunicação como perigosa. A leitura correta é registrar canais, limitar o que cada agente vê, separar evidência bruta de conclusão, e exigir que achados independentes permaneçam visíveis no momento do merge.

Contenção não é apenas sandbox. Sandbox limita ambiente, mas não resolve por si só identidade, escopo, estado compartilhado e efeitos externos. Para a camada de limites entre ambiente isolado e permissão real, o guia Sandbox de agentes de IA e permissões do telefone: por que limites ainda importam aprofunda por que autorização e efeito precisam ser tratados separadamente.

Fluxo independente para revisão de segurança de código

Um fluxo operacional começa antes do primeiro patch. Fixe o escopo em uma frase: que bug, recurso ou risco será tratado. Em seguida, escreva um mini modelo de ameaça: quais dados podem ser expostos, quais permissões mudam, quais entradas são não confiáveis, quais dependências entram no caminho e que efeito externo pode ocorrer. O coordenador deve transformar isso em tarefas pequenas e critérios de aceite verificáveis.

Depois, separe implementador e revisor. O implementador recebe o menor contexto suficiente para editar. Ele deve produzir diff, testes relevantes e notas sobre suposições. O revisor recebe o diff final, os critérios, a saída de testes, a lista de arquivos alterados e o modelo de ameaça. Ele não precisa aceitar a narrativa do implementador. Ele precisa reconstruir a pergunta: esta mudança reduz o risco original sem criar outro maior?

O revisor deve examinar pelo menos seis áreas: autenticação e autorização, validação de entrada, tratamento de segredo, dependências novas ou alteradas, permissões de ferramenta, e caminhos de erro. Testes passando são evidência funcional, não prova de segurança. Uma cobertura boa ajuda, mas o revisor ainda deve perguntar se existe caminho não testado com privilégios diferentes, se logs incluem dados sensíveis, se uma exceção revela detalhe interno, e se a reversão deixa estado inconsistente.

O merge precisa de decisão humana ou de gate humano definido. O papel humano não é repetir cada linha lida pelo agente; é assumir responsabilidade por escopo, risco aceito e timing de release. Quando o revisor bloqueia, o implementador corrige ou apresenta evidência adicional. Quando o risco permanece, o merge aguarda. Quando a mudança entra, o plano de rollback deve estar pronto antes do deploy, não depois do incidente.

Contenha ferramentas, credenciais, worktrees, filas e orçamentos

Contenção começa com snapshot de capacidade. Antes da execução, registre quais ferramentas cada agente pode usar, quais arquivos pode tocar, quais comandos pode rodar, quais credenciais ficam fora de alcance e qual orçamento de tempo ou tokens se aplica. Essa lista precisa ser específica o suficiente para bloquear expansão acidental. Um agente que revisa dependências não precisa de segredo de produção. Um agente que edita documentação não precisa escrever em código de autenticação.

Worktrees isoladas reduzem colisão. Cada worker deve operar em uma área separada, com integração explícita. Filas também importam: tarefas concorrentes precisam de estado claro, dono, prioridade e cancelamento. Quando dois agentes alteram o mesmo arquivo, um coordenador ou processo de merge deve resolver conflito com evidência, não com último escritor. Quando uma ferramenta externa é chamada, o log precisa mostrar quem chamou, com que argumento e qual resultado voltou.

Credenciais seguem privilégio mínimo e expiração curta. Ambientes de teste devem usar dados sintéticos ou contas de baixa consequência. Orçamentos limitam loops de tentativa, custo e ruído. Parar um agente interrompe novas ações, mas não desfaz automaticamente efeitos já concluídos. Se um script enviou uma notificação, apagou um recurso de teste ou abriu um ticket externo, a recuperação precisa de passo explícito.

Na FoneClaw, aprendemos a valorizar filas e estado de aprovação porque tarefas no telefone também podem se sobrepor. Uma solicitação pode estar aguardando permissão enquanto outra está em execução. O guia Fila de tarefas de IA no Android: sessões e aprovações mostra como isolamento de sessões e aprovações ajuda a manter autoria e controle quando várias conversas tentam produzir efeitos no mesmo dispositivo.

Como essas lições chegam aos phone agents Android

A analogia com phone agents é de governança. Em código, o efeito final é diff, teste, build, deploy ou mudança de dependência. No Android, o efeito pode ser enviar mensagem, alterar configuração, abrir navegação, ler tela, iniciar chamada ou preparar uma ação em outro app. A superfície muda, mas a pergunta permanece: quem tem permissão, que evidência aparece, onde a pessoa confirma e como o sistema recupera quando algo falha?

Na FoneClaw, construímos para tarefas Android suportadas com controle visível. O usuário mantém aprovações, ferramentas e recuperação no fluxo. Ações consequentes aparecem antes de avançar. Parar e tentar novamente fazem parte da experiência, assim como orientar a pessoa quando uma permissão falta ou quando o estado do app impede a conclusão. A informação atual de recursos fica na página de recursos da FoneClaw, e a instalação atual fica na página de download da FoneClaw.

Essa abordagem vem da mesma disciplina que torna revisão multiagente útil: separar intenção, autorização e efeito. Entender um pedido não é o mesmo que executar uma ação. Preparar uma mensagem não é o mesmo que enviá-la. Ler a tela atual não é o mesmo que controlar todos os apps. Quando uma tarefa sai do editor e chega ao telefone, a governança fica mais concreta porque o usuário vive com o resultado.

Também estamos construindo para recuperação honesta. Um agente deve explicar bloqueio de permissão, oferecer uma rota de correção e preservar a possibilidade de cancelar. Ele não deve prometer reversão total de efeitos que já aconteceram. Essa fronteira torna o produto mais confiável: o usuário vê o que está em curso, decide quando aprovar e entende o próximo passo quando o Android impõe limite.

Checklist de release para revisão multiagente de código

Antes da execução, confirme dono, escopo, arquivos permitidos, ferramentas disponíveis, credenciais bloqueadas, orçamento, critérios de aceite e condição de parada. Durante a execução, registre qual agente fez cada ação, preserve saídas de teste, bloqueie colisões em recursos compartilhados e mantenha achados independentes separados das conclusões do implementador.

Antes do merge, exija diff legível, testes relevantes, revisão de segurança independente, lista de permissões alteradas, dependências novas, exposição de segredo, plano de rollback e decisão humana. Se o revisor discordar, a discordância fica visível até ser resolvida. Consenso sem evidência não deve substituir prova.

Depois de um incidente, trate a falha como dado de governança. Atualize escopo de ferramenta, isolamento de worktree, orçamento, fila, logs e critérios de bloqueio. Sistemas multiagentes melhoram revisão quando transformam paralelismo em evidência independente. A meta não é ter mais agentes; é ter papéis que se corrigem, limites que seguram impacto e decisões que permanecem rastreáveis.