A engenharia de "harness" é a prática de construir a camada, incluindo o código, que transforma um modelo de IA de um mero gerador de texto num agente capaz de executar ações. Em suma, um agente de IA é um modelo mais um "harness". O modelo decide o que fazer a seguir, e o "harness" concretiza-o, ligando o modelo a ferramentas, contexto, sistemas externos e validação. Em muitos trabalhos práticos, e especialmente no trabalho de segurança, o "harness" determina a qualidade do resultado mais do que a escolha do modelo.
O que é um "harness"?
Um "harness" é a camada de orquestração em redor de um modelo, ou de vários modelos em simultâneo. Consiste em código, lógica de fluxo de trabalho, conceção de "prompts" e validação a trabalhar em conjunto, com o modelo integrado como um componente entre vários. O "harness" contém a lógica que decide qual o modelo a executar e quando, que contexto cada um visualiza, como as conclusões são verificadas e quando se deve recorrer a um modelo mais poderoso.
No seu formato mais simples, um "harness" é um pequeno ciclo de código:
- Chamar o modelo
- O modelo solicita uma ferramenta
- O "harness" executa a ferramenta e devolve o resultado
- Repetir até obter os resultados finais
À medida que os "harnesses" se tornam mais complexos, utilizam frequentemente alguns dos seguintes padrões:
- Encadeamento de "prompts": Passos sequenciais com verificações entre eles, para uma tarefa que se decompõe numa ordem fixa.
- Encaminhamento ("routing"): Um classificador envia cada entrada para um gestor especializado, direcionando as consultas simples para um modelo mais económico, enquanto reserva as mais complexas para um modelo mais poderoso.
- Paralelização: Dividir uma tarefa em partes independentes ou executar a mesma tarefa várias vezes e agregar os votos.
- Orquestrador-trabalhadores: Um modelo central divide o trabalho em tempo real e delega-o, para situações em que não é possível prever as subtarefas com antecedência.
- Avaliador-otimizador: Um modelo gera enquanto outro critica num ciclo até que o resultado seja aprovado.
O "harness" também é frequentemente responsável pela compactação, o processo que condensa históricos de conversas longas ou transcrições, resumindo mensagens mais antigas num bloco denso de texto. Gerir corretamente a janela de contexto de um LLM também tem um impacto significativo na qualidade e segurança das respostas, o que deu origem ao novo tema em destaque da engenharia de contexto (que guardaremos para outra ocasião).
Porque é que precisa mesmo de um "harness"
Se estiver a escolher entre modelos, está apenas a afinar uma variável. Os modelos de ponta convergiram a um ponto em que a diferença entre os principais nos testes de código padrão é relativamente pequena. No entanto, se envolver esse mesmo modelo numa estrutura fraca em vez de numa forte, a diferença no que ele consegue realmente detetar é enorme. Em muitos casos, o design da estrutura terá mais impacto na qualidade do resultado do que o modelo.
Depender menos de um modelo específico permite-lhe adaptar-se a tempos de mudança. Os modelos de ponta têm enfrentado algum escrutínio extra ultimamente e estão a perder o favor de alguns. Com o incidente entre a Hugging Face e a OpenAI de julho de 2026, um modelo de ponta atacou uma empresa, mas não puderam usar um modelo de ponta para se defenderem, uma vez que os modelos de ponta bloqueiam regularmente tarefas relacionadas com cibersegurança. A Hugging Face teve de usar um modelo chinês de pesos abertos para a sua resposta a incidentes (felizmente, os modelos de pesos abertos estão a ter um desempenho muito bom atualmente). Estar à mercê das recusas dos modelos não é um plano sustentável para o futuro.
Um modelo capaz também não consegue executar o trabalho sozinho. Se pedir até ao "melhor" modelo numa janela de chat para encontrar as vulnerabilidades num repositório, vai deparar-se com limites muito rapidamente. Por um lado, a base de código não caberá no seu contexto e, mesmo nas partes que consegue ver, não consegue realmente ligar ideias entre ficheiros. E, claro, os resultados serão diferentes de cada vez porque são não determinísticos. Para encontrar vulnerabilidades de forma eficaz, uma estrutura precisa de manter um ciclo em execução e verificar o que é devolvido. Nos nossos testes dos modelos de IA mais recentes, mostramos porque é que a estrutura é tão importante ao detetar vulnerabilidades no código e como uma verificação de alcançabilidade e uma fase de validação separam um monte de dúvidas de uma lista sobre a qual pode agir.
Há também o argumento dos custos. Modelos maiores custam mais por execução, e a capacidade não escala de forma direta com o preço. Executar vários agentes mais baratos pode superar um agente caro pelo mesmo valor, uma vez que pode converter a contagem de agentes em cobertura. Um modelo mais barato produz (geralmente) mais falsos positivos, pelo que uma estrutura pode gerir as múltiplas execuções e filtrar o ruído, com agentes separados a validar as conclusões e a eliminar o lixo.
E quando o trabalho toca em algo sensível, a estrutura é o único local onde a segurança pode residir. Apenas pedir a um modelo para ser seguro não é suficiente (vamos abordar isto mais tarde).
Quais são alguns exemplos de estruturas de IA?
Praticamente qualquer LLM utilizado como produto está integrado numa estrutura. Exemplo simples: todos os agentes de código que dominaram os fluxos de trabalho dos programadores nos últimos dois anos são estruturas construídas em redor de um modelo de ponta.
O Claude Code é o agente de terminal da Anthropic. Lê e escreve código através do mesmo ciclo de chamada do modelo e execução de ferramentas mencionado acima. O ciclo agêntico subjacente escolhe ferramentas, acumula contexto e gere sessões longas através de compactação, com modos de permissão e sandboxing a definir os limites de segurança. O modo de agente do Cursor baseia-se na mesma ideia dentro de um editor centrado em IA construído sobre o VS Code, onde a estrutura comanda a edição de vários ficheiros a partir do IDE em vez do terminal.
A estrutura mais famosa poderá ser o OpenClaw, embora possa argumentar-se que já se expandiu para além de ser apenas uma estrutura. No fundo, é um serviço Node.js de longa duração que liga um LLM ao seu Mac Mini e a aplicações de mensagens. Fornece o gateway, os canais, a montagem de contexto, a memória persistente, as competências e o ciclo que os une. O OpenClaw é também um exemplo a ter em conta de como a segurança é fraca quando a estrutura é permissiva nesse aspeto e a sandbox é praticamente inexistente (vamos voltar a isto daqui a pouco).
Para um exemplo detalhado e do mundo real, a Cloudflare publicou a sua estrutura de descoberta de vulnerabilidades fase a fase, construída enquanto direcionava modelos de segurança para dezenas dos seus próprios repositórios. As fases dão uma boa ideia de tudo o que uma estrutura madura faz, particularmente num contexto de segurança. A nossa própria estrutura na Aikido tem um aspeto semelhante a um nível elevado — explorando uma base de código em busca de potenciais pontos de entrada, classificando os fluxos suspeitos a abrir, investigando cada um em profundidade e, em seguida, efetuando a triagem do que é devolvido.
O papel da estrutura na segurança da IA
No contexto da segurança, a estrutura também é parcialmente responsável por conter o modelo, mantendo-o dentro dos limites definidos quando este se desvia da tarefa ou é empurrado para fora dela por algo no seu input. Mantém os limites flexíveis, e estes resistem desde que a sua orquestração se comporte da forma como a construiu.
As barreiras de proteção como o âmbito e o registo (logging) precisam de ser parte da camada de ferramentas que o código controla. Como os LLMs são não determinísticos e, portanto, imprevisíveis, até as tentativas mais heroicas de os controlar apenas com instruções (prompts) não conseguem garantir a segurança. A injeção de instruções (prompt injection) é um dos maiores problemas ao tentar controlar LLMs com instruções, porque qualquer input controlado por um atacante que chegue ao contexto pode envenenar o LLM com argumentos convincentes.
Os controlos de segurança abrangidos pela estrutura incluem:
- Controlo de âmbito: Regras sobre o que está dentro dos limites, como quais os domínios, anfitriões ou repositórios que um agente pode aceder, e a recusa em agir fora disso. Numa estrutura, isto traduz-se numa lista de permissões que verifica as execuções de código antes de uma ferramenta ser acionada, bem como instruções de âmbito na instrução.
- Mediação de ferramentas: A estrutura decide que ferramentas existem, quais os argumentos permitidos e se uma determinada chamada tem permissão para ser executada. O modelo apenas pode solicitar uma ferramenta, e o código da estrutura escolhe se a executa ou não
- Gestão de contexto e de input: Controlos contra a injeção de instruções e conteúdos não fidedignos, como a remoção ou quarentena de dados externos, a limitação do que o modelo lê e a não alimentação de conteúdos da internet aberta dos quais possa retirar instruções.
- Validação e verificação: Verificações independentes sobre o que o modelo produz, como um segundo agente a tentar desmentir uma conclusão, uma verificação de alcançabilidade e validação de esquemas no output. Isto deteta ruído e alucinações.
- Lógica de escalamento e encaminhamento: Regras para saber quando entregar uma tarefa a um modelo mais forte, quando exigir intervenção humana e quando parar. Os mecanismos de interrupção (circuit-breakers) e as condições de paragem também se encontram aqui.
- Registo e observabilidade: O registo de cada pedido e ação para que uma execução possa ser vigiada em direto, 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 taxa (rate-limiting) e consciência de carga para que os agentes não sobrecarreguem um alvo nem disparem os custos.
Em alguns casos, os agentes estarão numa sandbox, geralmente quando o agente interage com sistemas em direto ou tem permissão para executar comandos de shell. A sandbox é o container onde toda a estrutura é executada e aplica o reforço de segurança rígido, que inclui o isolamento do SO, as restrições de rede, os limites de recursos e a separação da sua infraestrutura interna. Como esses limites são impostos pelo ambiente, o modelo não consegue cruzá-los, independentemente do que decida fazer.
Facto curioso: Também pode aninhar sandboxes dentro da estrutura. Se a estrutura fornecer ao modelo uma ferramenta que executa comandos, esses comandos podem ser executados na sua própria sandbox separada, para que uma capacidade de risco obtenha a sua própria barreira rígida sem enfraquecer o resto do sistema.
Segurança de estruturas de IA no mundo real
Dois casos recentes mostram o que acontece quando estes limites falham, de formas diferentes. O OpenClaw mostra o que acontece quando a barreira rígida simplesmente falta. O incidente entre a Hugging Face e a OpenAI mostra o que acontece quando está presente, mas é violada.
O OpenClaw demonstra o que acontece quando as camadas ficam ao encargo do utilizador. O software inclui controlos de enquadramento, mas trata a sandbox como opcional; por predefinição, a sessão principal é executada diretamente na máquina anfitriã com acesso total às respetivas credenciais e ficheiros. O isolamento em sandbox abrange apenas as sessões para as quais está configurado e, mesmo assim, algumas ferramentas estão definidas para ser executadas no anfitrião de qualquer forma. Assim, a forma mais comum de utilizar o OpenClaw é um sistema capaz com salvaguardas flexíveis e sem um limite rígido subjacente, sendo esta a configuração por trás dos seus incidentes mais graves. Um sistema sem uma sandbox é tão seguro quanto os seus controlos flexíveis permitirem e, perante 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 redor de um modelo poderoso falha na manutenção da segurança. A OpenAI revelou que, durante uma execução interna de um benchmark, os seus próprios modelos escaparam à sandbox de teste e acederam aos sistemas de produção da Hugging Face para obter as respostas do benchmark.
O incidente demonstra o que acontece quando o discernimento do próprio modelo e o sistema envolvente são comprometidos em simultâneo. O modelo da OpenAI estava a ser executado com as recusas de cibersegurança desativadas (momento em que o modelo ou os agentes recusam realizar uma tarefa solicitada), operando com base no seu treino em vez de regras externas. Isto faz sentido para os testes que a OpenAI pretendia realizar, mas também introduz riscos de segurança graves. Neste incidente, o sistema envolvente era inteiramente responsável por conter estes agentes em vez de um prompt (especificamente, o sistema de enquadramento e a sandbox), e ambos falharam.
Até a OpenAI, que tentou implementar uma sandbox segura, foi comprometida por um único sistema de registo de pacotes acessível e vulnerável. Trata-se, naturalmente, de um exemplo extremo, mas os modelos vão continuar a evoluir e a tornar-se mais inteligentes, pelo que terá de ter isto em conta na sua sandbox.
A resposta de conceção deve ser arquitetónica e em várias camadas. Avalie o risco de tudo o que seja acessível ao agente. Foi assim que construímos o nosso sistema para os nossos agentes de pentest de IA. O sistema separa a parte que planeia, raciocina e armazena dados confidenciais (o plano de controlo) de uma sandbox isolada que executa ferramentas, navega na web e interage com a rede (o plano de execução) através de políticas de rede e software robustos.
A vertente de execução não tem acesso a Secrets de orquestração nem à infraestrutura interna, partindo do princípio de que a execução pode comportar-se incorretamente e o sistema de enquadramento não consegue conter tudo. É aqui que entra a sandbox. A aplicação rigorosa bloqueia qualquer domínio que não esteja numa lista de permissões ao nível da rede, impedindo o agente de aceder ao mesmo, independentemente das ações que decida tomar.
Sistemas de IA, agora e no futuro
O modelo recebe toda a atenção, mas o sistema de enquadramento realiza um trabalho substancial. É o componente que transforma a capacidade nos melhores resultados obtidos, além de gerir vários controlos de segurança. As grandes organizações tecnológicas estão a concentrar-se em sistemas de enquadramento, tanto para uso interno como sob a forma de serviço. Recentemente, a Microsoft lançou uma framework de enquadramento como produto. Enquanto existirem LLMs, teremos de os conter em sistemas de enquadramento, pelo que esta disciplina está apenas a dar os primeiros passos. Apenas tocámos na superfície neste artigo, mas também pode continuar a sua aprendizagem sobre IA nesta fantástica página sobre engenharia de enquadramentos.
Escolha bem o seu modelo, mas concentre o seu esforço principal no sistema de enquadramento. É por isso que desenvolvemos as nossas próprias ferramentas, incluindo a análise de código com IA e o pentest de IA do Aikido, concebidos primeiro como sistemas de enquadramento.
FAQ
O que é um "harness"?
Um sistema de enquadramento é a camada de orquestração em redor de um ou mais modelos. Consiste no código, na lógica de fluxo de trabalho, na conceção de prompts e na validação que transformam um modelo num agente capaz de agir, decidindo qual o agente executado em cada momento, o contexto a que cada um acede, quando deve ocorrer uma escalada e a forma como o resultado é verificado.
Qual é a diferença entre o sistema de enquadramento e o modelo?
O modelo fornece o raciocínio e a linguagem. O sistema de enquadramento fornece todo o resto: as ferramentas, a memória, o ciclo, a validação e alguns controlos de âmbito. Se substituir o modelo, o sistema de enquadramento mantém-se. É por isso que um sistema de enquadramento robusto lhe permite atualizar os modelos sem necessidade de reconstruir o seu sistema.
A engenharia de enquadramentos é uma disciplina real?
Tornou-se numa. À medida que os modelos de ponta convergem em termos de capacidade, a orquestração em seu redor passou a ser responsável pela maior parte da diferença prática nos resultados, razão pela qual as equipas estão a investir na conceção de enquadramentos como uma área de trabalho autónoma.
Como se aplica a engenharia de enquadramentos à segurança?
Em segurança, o sistema de enquadramento desempenha duas funções. Ele aumenta a qualidade das conclusões através de uma delimitação restrita e de uma validação independente entre agentes paralelos, e contém o agente através de isolamento arquitetónico e imposição de âmbito ao nível da rede, impedindo que um agente aceda indevidamente à produção ou divulgue dados.
O que são salvaguardas de agentes de IA?
As salvaguardas são as restrições que mantêm um agente dentro do seu âmbito pretendido, tais como o isolamento em sandbox, domínios em listas de permissões, limites de taxa e uma separação estrita entre a camada de planeamento e a camada de execução. As soluções fiáveis são impostas ao nível do código e da infraestrutura, em vez de serem solicitadas num prompt, impedindo que o modelo as ignore ou contorne.
