Quatro em cada dez empresas somam falhas mais rápido do que corrigem. CodeMender aposta em aprovação humana

O número na atualização de segurança da Google que merece mais atenção não é da Google. Ele vem de Katie Norton, da IDC, citada no post: quase 40% das empresas adicionam vulnerabilidades mais rápido do que conseguem corrigi-las.

Se esse é o seu cenário, um scanner melhor só piora a situação. Cada novo achado cai numa fila que já estava crescendo. Os produtos que a Google anunciou no Cloud Security Summit em 4 de novembro são interessantes principalmente como tentativas de esvaziar essa fila.

Corrigir, não encontrar

CodeMender, o agente autônomo de segurança de código da Google, está em preview desde julho, e a Google diz que centenas de clientes o usaram. A atualização adiciona remediação autônoma que roda dentro de um sandbox no nível do sistema operacional ou de uma VM isolada, com verificações human-in-the-loop (aprovação humana) antes de uma correção ser aceita. Ele pode varrer uma pasta específica, um repositório inteiro ou apenas os arquivos alterados desde a última varredura, e funciona com vários modelos, incluindo o Gemini 4 Argon.

A Thales, que o avaliou cedo, diz que o CodeMender poderia reduzir o tempo de descoberta de vulnerabilidades em mais de 95%. Essa é uma estimativa inicial de um cliente sobre descoberta, citada pela Google, não um resultado medido em remediação.

As escolhas de design são as certas. Uma correção gerada em um sandbox pode ser construída e testada antes de qualquer pessoa vê-la, e o humano revisa um patch funcional em vez de um achado. É aí que a automação mais ajuda: ela transforma o trabalho de quem revisa de escrever uma correção em julgar uma.

Isso também move o gargalo, como argumentamos no nosso texto sobre capacidade de verificação. Se o CodeMender produz cinquenta patches por dia, alguém ainda precisa aprovar cinquenta patches por dia. Times que já têm dificuldade para revisar pull requests humanos deveriam decidir de antemão quais classes de correção podem ser mescladas com uma revisão mais leve: atualizações de dependência com testes passando, por exemplo, mas não mudanças em código de autenticação.

Agentes recebem tokens em vez de chaves

As mudanças de identidade são mais silenciosas e podem importar mais daqui a um ano.

O Auth Manager do Agent Identity agora está em disponibilidade geral (GA). Ele executa fluxos OAuth 2.0 e PKCE para agentes e renova os tokens que os usuários delegam a eles. Um preview adiciona suporte a JWT: agentes recebem tokens OIDC padrão e podem se autenticar na AWS, no Azure, em sistemas on-premises e em servidores MCP sem chaves de API estáticas e de longa duração.

Chaves estáticas são como a maioria dos agentes acessa outros sistemas hoje, e uma chave vazada funciona até alguém notar. Tokens de curta duração e verificáveis são a mesma melhoria que a IBM fez com credenciais de agente que expiram, agora oferecida entre nuvens. O VPC Service Controls baseado em identidade também aceita papéis do IAM (em disponibilidade geral (GA)) e Workload Identity Federation for GKE (preview), então perímetros de rede podem seguir a identidade do agente em vez do endereço dele.

Regras de tópico para chat regulado

O Model Armor adiciona um detector de tópico personalizado em preview: regras baseadas em prompt que mantêm um assistente dentro ou fora de tópicos definidos. A Google o direciona para saúde, seguros e varejo. Ele é útil para impedir que um assistente de sinistros dê conselhos médicos. Não é um controle de autorização; um modelo que se mantém no tópico ainda pode agir no registro errado.

O que fazer com isso

Meça a fila antes de adicionar ferramentas. Se os achados já superam as correções, priorize a automação de remediação com testes em sandbox em vez de nova detecção. Substitua chaves estáticas de agentes por tokens de curta duração onde o sistema de destino aceitar OIDC. E trate filtros de tópico como política de conteúdo, mantidos separados das verificações de permissão que decidem o que um agente pode alterar.