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

Ao perguntar a um responsável de segurança onde está o risco de um agente de IA, a resposta quase sempre começa pelo modelo: se pode ser contornado por jailbreak, se se pode confiar nos seus pesos. Esse reflexo está cada vez mais ultrapassado. Um número crescente de demonstrações de exploração, testes de red team independentes e avaliações de investigadores aponta, em vez disso, para o código que fica entre o modelo e o mundo exterior. Esse código chama-se harness: equipa o modelo com ferramentas e transforma a sua produção de texto em ações reais — um comando de shell, uma escrita de ficheiro, uma chamada a uma API. Em muitas empresas, esta camada não está totalmente inventariada, nem testada, nem claramente atribuída a uma equipa.

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-lhe as 'mãos, pernas e olhos' do modelo: este só produz tokens de texto, e é o harness que os transforma num comando de shell, numa escrita de ficheiro ou numa chamada de API. Rob T. Lee, diretor de IA e investigação do SANS Institute, compara o modelo a um motor e o harness ao chassis. Michael Sromin, engenheiro sénior de aprendizagem automática na Lasso Security, descreve-o como o sistema operativo que controla todo o ciclo de uma aplicação agêntica, ligando modelo, ferramentas e utilizador. 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 salvaguardas incluídos. As quatro definições apontam para o mesmo problema: é no harness que a autoridade de um agente é efetivamente exercida. Situa-se entre o raciocínio do modelo e um sistema de ficheiros real, uma chave de API ou uma base de dados de produção. Um modelo perfeitamente alinhado serve de pouco se o código à sua volta confiar num padrão de shell genérico ou reutilizar um espaço de trabalho com conteúdo não fiável em várias execuções.

Três formas de um harness falhar

Elad Meged, engenheiro fundador e investigador de segurança na Novee Security, mostrou na conferência Black Hat USA como conseguiu aceder aos repositórios oficiais de automação da Anthropic, da Google e da OpenAI usando apenas issues do GitHub. As falhas concretas variavam consoante o fornecedor — execução de código, credenciais expostas, instruções injetadas que um componente mais poderoso, mais adiante, aceitava sem as revalidar. O erro arquitetural subjacente era, porém, 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 voltar a verificá-la. 'Não é uma falha do modelo, é uma falha de fronteira de confiança', resume Meged.

A segunda fonte de falhas está no próprio desenho do harness, sem que seja necessário qualquer erro de código. Investigadores da Lasso Security limitaram-se a trocar 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 inverteu-se por completo 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 em conjunto em vez de adotar uma configuração pré-definida sem a testar.

A terceira vulnerabilidade percorre a cadeia de fornecimento do harness. A equipa de Michael Bargury na Zenity examinou 'skills' — ficheiros que ensinam uma nova tarefa a um agente — e encontrou malware ladrão de credenciais escondido em alguns que tinham passado por todos os scanners do mercado, incluindo os da própria Anthropic e da Cisco. Um skill malicioso escrevia-se no ficheiro de memória que um agente recarrega a cada reinício: apagar o skill não bastava, porque a instrução de reinstalação permanecia ativa e o malware regressava no arranque seguinte. Outro fazia-se passar por uma ferramenta oficial da Anthropic, apagava a ferramenta legítima depois de executado e substituía-a pela versão do atacante, sem qualquer mudança visível para o utilizador. 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ões de downloads antes de serem detetadas e travadas.

• Inventário: catalogar cada harness em produção, mesmo os designados internamente como 'copiloto', 'assistente de workflow' ou 'plugin'
• Mapa de acessos: identificar que ferramentas e dados cada harness pode alcançar, e reduzir essas permissões ao mínimo necessário
• Teste independente: avaliar harness e modelo em conjunto em vez de confiar numa configuração pré-definida sem a verificar

As equipas pensam em termos de aplicações, serviços, pipelines ou bots. Os harnesses desaparecem em repositórios de código, produtos SaaS e ecrãs de configuração de fornecedores, em vez de aparecerem como ativos próprios no inventário de segurança.

O que isto muda para as empresas portuguesas

Para uma empresa em Portugal que implementa agentes de IA internamente — como extensão de ferramentas do tipo Copilot, automação própria ou uma framework de agentes —, o harness quase nunca surge hoje como uma linha separada no inventário de segurança. Santos recomenda não esperar por visibilidade total: entre 60% e 70% de cobertura é alcançável com relativa rapidez começando pelos sistemas em produção, deixando protótipos e IA não autorizada para uma segunda fase. Esta lógica cruza-se com a obrigação já em vigor no Regulamento europeu da IA de documentar os casos de uso de alto risco: a ferramenta que executa as ações do agente deve constar do mesmo inventário que o modelo. Na prática, isto significa tratar o harness como um componente próprio nos processos de compra e auditoria — com a sua própria avaliação de risco, o seu próprio ciclo de correções e um princípio de privilégio mínimo nos acessos, seja qual for o modelo que funciona por trás.