A engenharia de harnesses consiste na prática de construir a camada — incluindo o código — que transforma um modelo de IA, de um simples gerador de texto, num agente capaz de realizar ações. Em suma, um agente de IA é um modelo acompanhado de um harness. O modelo decide o que fazer a seguir e o harness concretiza essa ação, ligando o modelo a ferramentas, contexto, sistemas externos e validação. Em muitos trabalhos práticos, e especialmente no âmbito da segurança, o «harness» determina a qualidade do resultado final mais do que a escolha do modelo.
O que é um arnês?
Um «harness» é a camada de orquestração em torno de um modelo, ou de vários modelos em simultâneo. Trata-se de código, lógica de fluxo de trabalho, conceção de prompts e validação a funcionar em conjunto, sendo que o modelo se insere nesse conjunto como um componente entre vários outros. O «harness» contém a lógica que determina qual o modelo que é executado e quando, qual o contexto a que cada um tem acesso, como os resultados são verificados e quando se deve recorrer a um modelo mais avançado.
Na sua forma mais simples, um «harness» é um pequeno trecho de código:
- Chamar o modelo
- O modelo solicita uma ferramenta
- O Harness executa a ferramenta e devolve o resultado
- Repita até obter os resultados finais
À medida que os chicotes se tornam mais complexos, recorrem frequentemente a alguns dos seguintes padrões:
- Encadeamento de instruções: Passos sequenciais com verificações entre eles, para uma tarefa que se decompõe numa ordem fixa.
- Encaminhamento: Um classificador encaminha cada entrada para um processador especializado e encaminha as consultas simples para um modelo mais económico, reservando as mais complexas para um modelo mais potente.
- Paralelização: Consiste em dividir uma tarefa em partes independentes ou em executar a mesma tarefa várias vezes e agregar os resultados.
- Orchestrator-workers: Um modelo central divide a tarefa em tempo real e delega as sub-tarefas, para trabalhos em que não é possível prever antecipadamente quais serão essas sub-tarefas.
- Avaliador-otimizador: Um modelo gera resultados enquanto outro os avalia, num ciclo contínuo até que o resultado seja aprovado.
O «harness» também é frequentemente responsável pela compactação, que é o processo que condensa longos históricos de conversas ou transcrições, resumindo as mensagens mais antigas num bloco denso de texto. A gestão correta da janela de contexto de um LLM também tem um impacto significativo na qualidade e segurança da saída, o que deu origem ao novo tema em voga da engenharia de contexto (que deixaremos para outra ocasião).
Por que é que é mesmo necessário usar um arnês?
Se estiver a escolher entre modelos, está a ajustar apenas uma variável. Os modelos Frontier convergiram a tal ponto que a diferença entre os melhores, em benchmarks de codificação padrão, é relativamente pequena. No entanto, se aplicar esse mesmo modelo num «harness» fraco em vez de um forte, a diferença no que ele consegue realmente descobrir é grande. Em muitos casos, o design do «harness» terá um impacto maior na qualidade dos resultados do que o próprio modelo.
Depender menos de um modelo específico permite-lhe adaptar-se às mudanças dos tempos. Os modelos de vanguarda têm vindo a ser alvo de um escrutínio acrescido ultimamente e estão a perder popularidade junto de alguns. Com o incidente entre a Hugging Face e a OpenAI, em julho de 2026, um modelo de vanguarda atacou uma empresa, mas esta não conseguiu utilizar um modelo de vanguarda para se defender, uma vez que esses modelos bloqueiam regularmente tarefas relacionadas com a cibersegurança. A Hugging Face teve de recorrer a um modelo chinês de pesos abertos para a sua resposta ao incidente (felizmente,os modelos de pesos abertos têm tido um desempenho bastante bom nos últimos tempos). Ficar à mercê da recusa dos modelos não é um plano sustentável para o futuro.
Um modelo competente também não consegue executar a tarefa sozinho. Se pedires até mesmo ao «melhor» modelo numa janela de chat para encontrar as vulnerabilidades num repositório, vais deparar-te com limites muito rapidamente. Por um lado, a base de código não cabe no seu contexto e, mesmo nas partes que consegue ver, não consegue realmente estabelecer ligações entre ideias ao longo dos ficheiros. E, claro, os resultados serão diferentes de cada vez, porque são não determinísticos. Para detetar vulnerabilidades de forma eficaz, um sistema de teste precisa de manter um ciclo em execução e verificar os resultados obtidos. Nos nossos testes de desempenho dos modelos de IA mais recentes, mostramos por que razão o sistema de teste é tão importante na deteção de vulnerabilidades no código e como uma verificação de acessibilidade e uma fase de validação são o que distingue uma pilha de possibilidades de uma lista sobre a qual se pode agir.
Há também a questão do custo. Os modelos maiores custam mais por execução, e o desempenho não varia proporcionalmente ao preço. Executar vários agentes mais baratos pode ser mais eficaz do que um único agente caro com o mesmo investimento, uma vez que é possível transformar o número de agentes em cobertura. Um modelo mais barato (geralmente) produz mais falsos positivos, pelo que um sistema de controlo pode gerir as várias execuções e filtrar o ruído, com agentes separados a validar os resultados e a eliminar os dados irrelevantes.
E quando o trabalho envolve assuntos sensíveis, o arnês é o único lugar onde a segurança pode estar garantida. Não basta apenas pedir a um modelo para se sentir seguro (falaremos sobre isto mais tarde).
Quais são alguns exemplos de aplicações da IA?
Praticamente qualquer LLM utilizado como produto está integrado numa estrutura de suporte. Um exemplo simples: todos os agentes de programação que se impuseram nos fluxos de trabalho dos programadores nos últimos dois anos são estruturas de suporte que envolvem um modelo de vanguarda.
O Claude Code é o agente de terminal da Anthropic. Lê e escreve código ao longo do mesmo ciclo «chamar-modelo-executar-ferramenta» descrito acima. O ciclo de agente subjacente seleciona ferramentas, acumula contexto e gere sessões prolongadas através da compactação, com os modos de permissão e o ambiente de sandbox a definirem os limites de segurança. O modo de agente do Cursor baseia-se no mesmo princípio, mas dentro de um editor que prioriza a IA, construído sobre o VS Code, onde o sistema de controlo permite a edição de vários ficheiros a partir do IDE, em vez de a partir do terminal.
O «harness» mais famoso poderá ser o OpenClaw, embora se possa argumentar que já se expandiu para além de ser apenas um «harness». Na sua essência, trata-se de um serviço Node.js em execução contínua que liga um LLM ao seu Mac Mini e às aplicações de mensagens. Fornece o gateway, os canais, a organização do contexto, a memória persistente, as funcionalidades e o ciclo que os une. O OpenClaw é também um exemplo que serve de alerta para a fragilidade da segurança quando o sistema de controlo é pouco rigoroso e a sandbox é, na prática, inexistente (voltaremos a este assunto daqui a pouco).
Para um exemplo detalhado e prático, o siteCloudflare publicou, fase a fase, o seu conjunto de ferramentas de deteção de vulnerabilidades, desenvolvido ao aplicar modelos de segurança a dezenas dos seus próprios repositórios. Essas fases dão uma boa ideia de tudo o que um conjunto de ferramentas maduro faz, especialmente num contexto de segurança. O nosso próprio conjunto de ferramentas, disponível em Aikido , é semelhante a um nível geral — analisa uma base de código à procura de pontos de entrada potenciais, classifica os fluxos suspeitos a explorar, investiga cada um deles em profundidade e, por fim, classifica os resultados obtidos.
O papel do «harness» na segurança e proteção da IA
No contexto da segurança, o «harness» também é parcialmente responsável por conter o modelo, mantendo-o dentro dos limites que definiu quando este se desvia da tarefa ou é desviado por algum elemento da sua entrada. Ele mantém os limites flexíveis, e estes mantêm-se enquanto a sua orquestração se comportar da forma como a concebeu.
Mecanismos de proteção, como o âmbito e o registo, têm de fazer parte da camada de ferramentas controlada pelo código. Como os LLMs são não determinísticos e, por isso, imprevisíveis, mesmo as tentativas mais ousadas de os controlar apenas com prompts não conseguem garantir a segurança. A injeção de prompts é um dos maiores problemas quando se tenta controlar os LLMs apenas com prompts, porque qualquer entrada controlada por um atacante que consiga entrar no contexto pode corromper o LLM se for suficientemente convincente.
Os controlos de segurança abrangidos pelo conjunto de cabos incluem:
- Controlo do âmbito: Regras sobre o que está permitido, como os domínios, hosts ou repositórios a que um agente pode aceder, e a recusa de agir fora desses limites. Num «harness», isto traduz-se numa lista de permissões que verifica o código executado antes de uma ferramenta ser acionada, bem como em instruções relativas ao âmbito apresentadas no prompt.
- Mediação de ferramentas: O harness determina quais as ferramentas existentes, quais os argumentos permitidos e se uma determinada chamada pode ser executada. O modelo apenas pode solicitar uma ferramenta, cabendo ao código do harness decidir se a executa ou não
- Contexto e tratamento de entradas: Controlos contra a injeção de prompts e conteúdos não confiáveis, tais como a remoção ou colocação em quarentena de dados externos, a limitação do que o modelo lê e a não alimentação do modelo com conteúdos da Internet aberta dos quais ele possa obter instruções.
- Validação e verificação: verificações independentes dos resultados produzidos pelo modelo, como um segundo agente que tenta refutar uma conclusão, uma verificação de acessibilidade ou a validação do esquema nos resultados. Isto permite detetar ruído e alucinações.
- Lógica de escalonamento e encaminhamento: regras que determinam quando passar uma tarefa para um modelo mais avançado, quando recorrer a um ser humano e quando interromper o processo. Os «circuit-breakers» e as condições de interrupção também se enquadram aqui.
- Registo e observabilidade: Registo de todos os pedidos e ações, para que uma execução possa ser acompanhada em tempo real, pausada ou auditada. Este controlo permite-lhe intervir quando necessário.
- Gestão de taxas e recursos ao nível da aplicação: limitação de taxas e deteção da carga, para que os agentes não sobrecarreguem um alvo nem gerem custos excessivos.
Em alguns casos, os agentes estarão numa sandbox, geralmente quando o agente interage com sistemas ativos ou tem permissão para executar comandos de shell. A sandbox é o « container » em que todo o conjunto de testes é executado e onde é aplicada a segurança rigorosa, o que inclui o isolamento do sistema operativo, as restrições de rede, os limites de recursos e a separação da infraestrutura interna. Como esses limites são impostos pelo ambiente, o modelo não pode ultrapassá-los, independentemente do que decida fazer.
Curiosidade: também é possível aninhar sandboxes dentro do harness. Se o harness fornecer ao modelo uma ferramenta que execute comandos, esses comandos podem ser executados na sua própria sandbox separada, de modo que uma funcionalidade de risco tenha o seu próprio limite rígido sem comprometer o resto do sistema.
A IA promove a segurança no mundo real
Dois casos recentes mostram o que acontece quando estas fronteiras falham, de formas diferentes. O OpenClaw mostra o que acontece quando a fronteira rígida simplesmente não existe. O incidente entre a Hugging Face e a OpenAI mostra o que acontece quando essa fronteira existe, mas é violada.
O OpenClaw mostra como isto funciona quando as camadas são deixadas ao critério do utilizador. É fornecido com os controlos de harness, mas trata a sandbox como uma opção opcional e, por predefinição, a sessão principal é executada diretamente na máquina anfitriã, com acesso total às suas credenciais e ficheiros. A sandbox abrange apenas as sessões para as quais está configurada e, mesmo assim, algumas ferramentas estão marcadas para serem executadas na máquina anfitriã de qualquer forma. Assim, a forma mais comum de executar o OpenClaw é através de um harness capaz, com barreiras de proteção flexíveis e sem limites rígidos subjacentes, o que constitui a configuração subjacente aos seus piores incidentes. Um harness sem sandbox só é tão contido quanto os seus controlos flexíveis permitirem, e face a um modelo não determinístico, estes nem sempre se mantêm.
O incidente entre a Hugging Face e a OpenAI que mencionei anteriormente é um excelente (ou não tão excelente) exemplo de como a infraestrutura em torno de um modelo poderoso pode falhar na garantia da segurança. A OpenAI revelou que, durante a execução interna de um teste de desempenho, os seus próprios modelos escaparam do ambiente de teste e acederam aos sistemas de produção da Hugging Face para obter as respostas do teste.
O incidente mostra o que acontece quando tanto o próprio julgamento do modelo como o sistema que o rodeia são comprometidos ao mesmo tempo. O modelo da OpenAI estava a funcionar com as «recusas cibernéticas» desativadas, o que significa que o modelo ou os agentes se recusam a fazer algo que lhes foi pedido, operando com base no seu treino em vez de quaisquer regras externas. Isto faz sentido para os testes que a OpenAI estava a tentar realizar, mas também cria graves riscos de segurança. Neste incidente, a responsabilidade pela contenção destes agentes recaiu inteiramente sobre o sistema circundante, em vez de sobre um prompt, nomeadamente o «harness» e a «sandbox», e ambos falharam.
Até mesmo a OpenAI, que tentou implementar uma sandbox segura, foi comprometida devido a um sistema de registo de pacotes vulnerável e acessível. Trata-se, evidentemente, de um exemplo extremo, mas os modelos vão tornar-se cada vez mais inteligentes, e na vossa sandbox terão de ter isso em conta.
A solução de conceção tem de ser arquitetónica e multifacetada. É necessário avaliar o risco de tudo o que está acessível ao agente. Foi assim que criámos o nosso «harness» para os nossos agentes « pentest de IA ». O sistema separa a parte que planeia, raciocina e armazena dados sensíveis (o plano de controlo) de um ambiente isolado («sandbox») que executa ferramentas, controla navegadores e interage com a rede (o plano de execução), através de políticas de rede e software robustos.
O lado da execução não tem acesso à orquestração secrets nem à infraestrutura interna, pois parte-se do princípio de que a execução pode apresentar comportamentos indesejados e que o ambiente de teste não consegue conter tudo. É aqui que entra a sandbox. A aplicação rigorosa bloqueia qualquer domínio que não conste da lista de domínios autorizados ao nível da rede, para que o agente não consiga aceder ao mesmo, independentemente do que decida fazer.
Aproveitamento da IA, agora e no futuro
O modelo chama a atenção, mas é o «harness» que faz grande parte do trabalho. É ele que transforma o potencial em resultados de excelência, além de gerir vários controlos de segurança. As grandes organizações tecnológicas estão a apostar nos «harnesses», tanto para uso interno como na modalidade de serviço. A Microsoft lançou recentemente uma estrutura de «harness» como produto. Enquanto tivermos LLMs, iremos mantê-los contidos em «harnesses», pelo que esta disciplina está apenas a dar os primeiros passos. Neste artigo, abordámos apenas a superfície do tema, mas também pode continuar a aprender sobre IA nesta fantástica página sobre engenharia de harnesses.
Escolhe bem o teu modelo, mas depois dedica todo o teu esforço ao arnês. É por isso que fabricamos as nossas próprias ferramentas, incluindo as da Aikidoanálise de código com IA e pentest de IA, como arneses em primeiro lugar.
FAQ
O que é um arnês?
Um «harness» é a camada de orquestração em torno de um ou mais modelos. É o código, a lógica do fluxo de trabalho, a conceção dos prompts e a validação que transformam um modelo num agente capaz de agir, decidindo qual o agente que é executado e quando, qual o contexto que cada um percebe, quando se deve escalar e como é verificado o resultado.
Qual é a diferença entre o arnês e o modelo?
O modelo fornece o raciocínio e a linguagem. O harness fornece tudo o resto: as ferramentas, a memória, o ciclo, a validação e alguns controlos de âmbito. Se trocar o modelo, o harness permanece. É por isso que um harness robusto permite atualizar modelos sem ter de reconstruir o sistema.
A engenharia de arneses é uma disciplina a sério?
Tornou-se uma coisa só. À medida que os modelos de vanguarda convergem em termos de capacidades, é na orquestração em torno deles que reside agora a maior parte da diferença prática nos resultados, razão pela qual as equipas estão a investir na conceção de «harness» como um domínio de trabalho específico.
De que forma a engenharia de arneses se aplica à segurança?
No âmbito da segurança, o «harness» desempenha duas funções. Aumenta a qualidade dos resultados através de um âmbito de análise restrito e de uma validação independente entre agentes paralelos, e controla o agente através do isolamento arquitetónico e da imposição do âmbito ao nível da rede, de modo a que um agente não possa aceder ao ambiente de produção nem provocar fugas de dados.
O que são as medidas de proteção para agentes de IA?
As barreiras de proteção são as restrições que mantêm um agente dentro do âmbito pretendido, tais como o sandboxing, os domínios incluídos na lista de permissões, os limites de taxa e uma separação rígida entre a camada de planeamento e a camada de execução. As mais fiáveis são aplicadas no código e na infraestrutura, em vez de serem solicitadas num prompt, pelo que o modelo não as pode ignorar nem contornar.
