O 'harness' dos agentes de IA vira a nova superfície de ataque

Ao perguntar a um responsável por segurança onde está o risco de um agente de IA, a resposta quase sempre começa pelo modelo: se dá para burlar com jailbreak, se dá para confiar nos seus pesos. Esse reflexo está cada vez mais defasado. Um número crescente de demonstrações de exploração, testes de red team independentes e avaliações de pesquisadores aponta, em vez disso, para o código que fica entre o modelo e o mundo exterior. Esse código é chamado de harness: ele equipa o modelo com ferramentas e transforma sua saída de texto em ações reais — um comando de shell, uma escrita de arquivo, uma chamada de API. Em muitas empresas, essa camada não está totalmente inventariada, nem testada, nem claramente sob responsabilidade de algum time.

O que é, na prática, um harness de IA

Ao pedir uma definição, os profissionais convergem para metáforas diferentes. Michael Bargury, cofundador e diretor de tecnologia da empresa de segurança em IA Zenity, chama o harness de 'mãos, pernas e olhos' do modelo: o modelo só produz tokens de texto, e é o harness que os transforma em um comando de shell, uma escrita de arquivo ou uma chamada de API. Rob T. Lee, diretor de IA e pesquisa do SANS Institute, compara o modelo a um motor e o harness ao chassi. Michael Sromin, engenheiro sênior de aprendizado de máquina na Lasso Security, o descreve como o sistema operacional que controla todo o loop de uma aplicação agêntica, conectando modelo, ferramentas e usuário. Omar Santos, engenheiro distinto da Cisco, dá a definição mais formal: a camada que envolve um modelo e o torna utilizável — orquestração, uso de ferramentas, prompts, contexto, papéis, avaliações e proteções incluídos. As quatro definições apontam para o mesmo problema: é no harness que a autoridade de um agente é de fato exercida. Ele fica entre o raciocínio do modelo e um sistema de arquivos real, uma chave de API ou um banco de dados de produção. Um modelo perfeitamente alinhado serve de pouco se o código ao redor confia em um padrão de shell genérico ou reutiliza um espaço de trabalho com conteúdo não confiável em várias execuções.

Três formas de um harness falhar

Elad Meged, engenheiro fundador e pesquisador de segurança na Novee Security, mostrou na conferência Black Hat USA como conseguiu acessar os repositórios oficiais de automação da Anthropic, do Google e da OpenAI usando apenas issues do GitHub. As falhas específicas variavam conforme o fornecedor — execução de código, credenciais expostas, instruções injetadas que um componente mais poderoso, mais adiante, aceitava sem revalidar. O erro arquitetural de fundo, porém, era surpreendentemente igual nos três casos: um componente tomava uma decisão de segurança que outro componente mais poderoso, mais à frente na cadeia, confiava sem verificar de novo. 'Não é uma falha do modelo, é uma falha de fronteira de confiança', resume Meged.

A segunda fonte de falhas está no próprio design do harness, sem que nenhum erro de código seja necessário. Pesquisadores da Lasso Security simplesmente trocaram o harness de um mesmo modelo aberto, mantendo modelo, prompt e ferramentas idênticos. A taxa de sucesso dos ataques subiu de 1% para 24%, e o resultado se inverteu completamente em 43 das 100 combinações de modelo e tarefa testadas. 'Trocar de harness é, na prática, obter um agente completamente diferente', afirma Sromin, que recomenda avaliar harness e modelo juntos em vez de adotar uma configuração padrão sem testá-la.

A terceira vulnerabilidade percorre a cadeia de suprimentos do harness. A equipe de Michael Bargury na Zenity examinou 'skills' — arquivos que ensinam uma nova tarefa a um agente — e encontrou malware ladrão de credenciais escondido em alguns que haviam passado por todos os scanners do mercado, incluindo os da própria Anthropic e da Cisco. Um skill malicioso se escrevia no arquivo de memória que um agente recarrega a cada reinicialização: apagar o skill não bastava, porque a instrução de reinstalação permanecia ativa e o malware retornava na próxima execução. Outro se passava por uma ferramenta oficial da Anthropic, apagava a ferramenta legítima após ser executado e a substituía pela versão do atacante, sem mudança visível para o usuário. O caso mais marcante foi uma campanha de ferramentas de código aberto clonadas e secretamente modificadas para roubar credenciais, que acumularam cerca de 1,7 milhão de downloads antes de serem detectadas e interrompidas.

• Inventário: catalogar cada harness em produção, mesmo os chamados internamente de 'copiloto', 'assistente de fluxo de trabalho' ou 'plugin'
• Mapa de acessos: identificar quais ferramentas e dados cada harness pode alcançar, e reduzir essas permissões ao mínimo necessário
• Teste independente: avaliar harness e modelo juntos em vez de confiar em uma configuração padrão sem verificá-la

As equipes pensam em termos de aplicativos, serviços, pipelines ou bots. Os harnesses desaparecem em repositórios de código, produtos SaaS e telas de configuração de fornecedores, em vez de aparecer como ativos próprios no inventário de segurança.

O que isso muda para empresas brasileiras

Para uma empresa no Brasil que implanta agentes de IA internamente — como extensão de ferramentas tipo Copilot, automação própria ou um framework de agentes —, o harness quase nunca aparece hoje como um item separado no inventário de segurança. Santos recomenda não esperar por visibilidade total: de 60% a 70% de cobertura é alcançável com relativa rapidez ao começar pelos sistemas em produção, deixando protótipos e IA invisível para uma segunda etapa. Essa lógica também vale para empresas sujeitas à LGPD, que já exige demonstrar como sistemas automatizados tratam dados pessoais: a ferramenta que executa as ações do agente precisa constar do mesmo inventário que o modelo. Na prática, isso significa tratar o harness como um componente próprio nos processos de compra e auditoria — com sua própria avaliação de risco, seu próprio ciclo de correções e um princípio de privilégio mínimo nos acessos, qualquer que seja o modelo por trás dele.