A IA da Chainguard ataca seu app em execução para provar a falha. Avalie o sandbox antes do modelo.

Um scanner estático lê o código e faz suposições. Um serviço de vulnerabilidade que executa o código e tenta quebrá-lo pode provar. O segundo tipo é muito mais útil para um time de segurança afogado em incertezas, e muda o que você está comprando: não mais um gerador de relatórios, mas um ambiente onde um modelo de fronteira executa ataques contra o seu software.

O Chainguard Harness, anunciado em 14 de outubro, é esse tipo de serviço. A Chainguard compila a aplicação do cliente a partir do código-fonte, como ela seria enviada para produção, a inicializa em uma microVM isolada e deixa o Claude Mythos 5.1 sondar a instância em execução em busca de falhas exploráveis: erros de lógica, injeção, esgotamento de recursos. A saída é um relatório com severidade e impacto, passos para confirmar cada descoberta e uma correção recomendada escrita para o código do cliente. Ele descreve problemas e como confirmá-los, não um ataque funcional.

O Harness está em beta, com uma lista de espera e acesso inicialmente limitado a um pequeno grupo de organizações. Ele também será vendido por meio do Claude Marketplace, onde os clientes podem aplicar parte de um compromisso existente com a Anthropic.

A contenção é a arquitetura

Quando um modelo executa comandos contra uma aplicação em execução, o design do sandbox importa mais do que a habilidade do modelo. O anúncio da Chainguard é específico sobre isso, e os detalhes são o que um comprador deve verificar:

Onde o modelo atacante pode e não pode chegar

Operações da Chainguard

• Um engenheiro nomeado revisa cada correção e relatório

Loop do agente

• Executa fora do sandbox
• Cada chamada de ferramenta e comando registrado em log

microVM de caça

• Sem saída de rede
• Sem credenciais
• Apenas shell e pacotes construídos pela Chainguard

Aplicação sob teste

• Compilada a partir do código-fonte
• Tratada como dado não confiável

• Configuração e caça são fases separadas. Um modelo de configuração compila o app e busca dependências; então a microVM é suspensa. A caça a retoma sem saída de rede e sem credenciais.
• O loop do agente executa fora do sandbox, e cada chamada de ferramenta e comando é registrado em log.
• O código sob teste é tratado como dado não confiável, uma defesa contra injeção de prompt escondida em comentários ou strings.
• O acesso ao repositório é somente leitura, por meio de um GitHub App ou de um arquivo-fonte enviado.

Essa lista é um bom modelo para avaliar qualquer sistema de IA que executa código, de testadores de segurança a agentes de codificação. É o mesmo raciocínio por trás da contenção como a verdadeira fronteira de segurança para agentes: assuma que o modelo pode ser persuadido, e decida de antemão o que um modelo persuadido pode alcançar.

Reproduzível, ou não conta

A segunda escolha de design aborda a principal reclamação sobre descobertas de segurança de IA: elas são barulhentas. A Chainguard reproduz cada exploit em uma microVM nova, e descobertas que não se reproduzem todas as vezes são excluídas. Cada correção recomendada deve fazer o exploit falhar contra o código corrigido.

Isso é o oposto de um scanner que lista tudo o que pode estar errado. Ele troca recall por evidência. A troca faz sentido para descobertas que chegam aos desenvolvedores, porque um exploit reproduzível é difícil de descartar, e se encaixa no padrão da semana: a frase da Snyk de que o gerador não pode ser o validador, e o GitHub mantendo seu aviso de descobertas de IA.

A Chainguard não publica números de precisão, falsos positivos ou falsos negativos, nem preços, nem linguagens suportadas e nem tempos de execução. Um relatório limpo diz o que o Harness provou, não o que ele deixou passar.

Perguntas antes de entregar o código-fonte

1. Onde a compilação acontece, e em qual jurisdição? Seu código-fonte e dependências saem do seu ambiente para o da Chainguard.
2. O que acontece com a microVM, seus logs e as anotações de trabalho do modelo após a execução? A custódia dos artefatos importa tanto quanto a custódia do código.
3. Quem vê a saída bruta do modelo? Apenas a equipe da Chainguard opera o modelo; os clientes não podem instruí-lo nem ver sua saída bruta. Isso limita o uso indevido, e também limita sua própria auditoria.
4. A que uma recomendação de correção compromete você? Nada é implantado automaticamente. A correção é uma proposta que passa pela sua revisão como qualquer outra mudança.
5. Como falhas upstream são tratadas? A Chainguard diz que coordena a divulgação com mantenedores de código aberto e envia builds corrigidos por meio de seu repositório; combine de antemão como você será informado.

Os testes de segurança de IA estão migrando de ler código para executá-lo. Compre como você compraria um teste de penetração com um testador muito rápido: verifique as regras de engajamento primeiro.