Neste artigo do Blog Dolutech, vamos explicar uma mudança de paradigma que já domina os laboratórios de Inteligência Artificial em 2026: a corrida deixou de ser apenas sobre quem tem o modelo com mais “conhecimento” armazenado nos parâmetros, e passou a ser sobre IA Agêntica e quem constrói o melhor harness (o arcabouço de execução que envolve o modelo) e a chamada de ferramentas (tool calling) mais eficiente. Para profissionais de cibersegurança, essa virada não é um detalhe acadêmico: ela redefine a superfície de ataque de praticamente todo sistema corporativo que hoje conecta um LLM a e-mails, bancos de dados, terminais e pipelines de CI/CD.
O que é conhecimento parametrico e por que ele já não é o fator decisivo
Durante anos, a métrica que definia o “melhor modelo” era o quanto ele sabia de cor. Benchmarks como o MMLU mediam conhecimento enciclopédico congelado no momento do treinamento. O problema é que esse conhecimento é estático, envelhece rápido e não resolve o problema real das empresas: executar tarefas no mundo real, com dados atualizados, dentro de sistemas vivos.
Um relatório recente do BenchLM.ai já reflete essa virada de prioridade: a capacidade agêntica hoje carrega uma fatia enorme da pontuação geral dos benchmarks, justamente porque a habilidade de usar ferramentas, navegar e completar tarefas em múltiplas etapas é o diferencial mais forte entre modelos em uso de produção. Na prática, um modelo que pontua bem em conhecimento mas não consegue chamar funções de forma confiável ou navegar em software tem utilidade real limitada para fluxos de trabalho agênticos.
Esse é o ponto central que a Dolutech quer destacar: conhecimento sem execução é uma enciclopédia parada na estante. Ferramenta com execução confiável é um funcionário digital que resolve o problema.
O que é o “Harness” e por que ele importa mais que o tamanho do modelo
O termo harness, no contexto de agentes de IA, descreve o ambiente de execução que fica entre o modelo e o mundo real. Como bem definido em pesquisa acadêmica recente, um agente de LLM opera em um ciclo de raciocínio e ação: ele recebe uma tarefa, raciocina sobre o que fazer, emite uma chamada de ferramenta (ler um arquivo, executar um comando, fazer uma requisição de API), observa o resultado e raciocina novamente. O agente não interage diretamente com o mundo externo: ele roda dentro de um harness, um framework de runtime que fica entre o modelo e o ambiente operacional. Esse harness gerencia a conexão com a API do LLM, registra as ferramentas que o agente pode chamar, despacha essas chamadas e controla quanto do histórico da conversa cabe na janela de contexto.
Ou seja: o harness é o “corpo” que dá ao modelo mãos, olhos e memória de curto prazo dentro de um sistema real. Ferramentas como Claude Code e outros ambientes agênticos são exemplos práticos disso, e harnesses diferentes variam muito no conjunto de ferramentas que expõem, desde acesso rico a sistema de arquivos e busca na web até apenas operações básicas de leitura, escrita e execução de shell.
Essa diferença explica por que dois LLMs com a mesma “inteligência” bruta podem ter desempenhos radicalmente diferentes em produção: o resultado final depende tanto do modelo quanto da qualidade do harness que o envolve.
Exemplo técnico: o ciclo ReAct simplificado
Para tornar isso concreto, veja como funciona, na prática, o loop que sustenta a maioria dos agentes atuais:
1. TAREFA: "Verifique se há vulnerabilidades críticas não corrigidas no servidor X"
2. RACIOCÍNIO (modelo): "Preciso consultar o inventário de CVEs e o status de patch"
3. AÇÃO (tool call): scan_vulnerabilities(host="servidor-x", severity="critical")
4. OBSERVAÇÃO: resultado JSON retornado pela ferramenta
5. RACIOCÍNIO: "Encontrei CVE-2026-XXXXX sem patch. Preciso verificar CISA KEV"
6. AÇÃO (tool call): check_cisa_kev(cve="CVE-2026-XXXXX")
7. OBSERVAÇÃO: confirmação de exploração ativa
8. RESPOSTA FINAL: relatório consolidado de riscoNote que o “saber” do modelo (o que é uma CVE, o que é o CISA KEV) é irrelevante se ele não conseguir, de fato, chamar a ferramenta certa, com os parâmetros certos, na ordem certa. É exatamente aí que a maioria dos agentes falha hoje.
Por que a eficiência do tool calling se tornou prioridade estratégica
Segundo análises recentes de engenharia de harness, a diferença de desempenho entre agentes não vem mais só da inteligência bruta do modelo, e sim de decisões de arquitetura muito específicas. Um exemplo documentado mostra que a execução concorrente de ferramentas, em vez do tradicional ciclo sequencial de observar e depois agir, é o principal fator de eficiência para harnesses de pesquisa profunda, permitindo que um mesmo passo dispare busca, navegação e computação simultaneamente.
Outro estudo, focado em técnicas de compressão de contexto, mostrou que uma abordagem que deixa o próprio agente decidir o que vale a pena preservar na memória, em vez de um corte mecânico por limite de tokens, produz uma redução de 22,7% no consumo de tokens sem perda de precisão em tarefas de longo horizonte. Isso importa muito na prática: menos tokens processados significa menor custo, menor latência e, para quem opera SOCs e SIEMs, resposta mais rápida em investigações automatizadas.
Existe até uma linha de pesquisa que ataca o problema pela raiz: em vez de tentar prever todo tipo de chamada de ferramenta possível, o modelo aprende a gerar código que gerencia o próprio fluxo de execução. Um exemplo é o AutoHarness, do Google DeepMind, uma técnica que usa síntese de código para gerar automaticamente arcabouços de restrição de runtime a partir de esquemas de ferramentas e especificações de tarefa. O resultado prático foi notável: um modelo menor combinado com AutoHarness superou modelos muito maiores em jogos de teste, eliminando jogadas ilegais através de políticas de harness aprendidas.
Isso confirma o argumento central deste artigo: o modelo mais “sabido” não ganha se o harness que o cerca for mal desenhado. A vantagem competitiva migrou do treinamento para a engenharia de orquestração.
MCP: o padrão que virou espinha dorsal, e o novo vetor de ataque
Nenhuma discussão sobre tool calling em 2026 está completa sem falar do Model Context Protocol (MCP), lançado pela Anthropic no final de 2024 e hoje adotado em escala por praticamente todo o ecossistema de IA agêntica, incluindo OpenAI, Google, Meta e Microsoft. O MCP funciona como uma espécie de “USB-C para agentes de IA”, padronizando como um LLM se conecta a ferramentas, bancos de dados e sistemas corporativos.
O problema, do ponto de vista de segurança, é que essa adoção avançou mais rápido do que a maturidade do modelo de segurança do protocolo. Como aponta uma publicação técnica recente, o MCP introduz um modelo de ameaças inédito, no qual a IA atua como intermediária decisória, criando oportunidades de manipulação através de técnicas de prompt injection, e a análise identificou o tool poisoning, isto é, instruções maliciosas embutidas nos metadados das próprias ferramentas, como a vulnerabilidade do lado cliente mais prevalente e impactante.
Um documento de orientação de segurança de referência reforça o alerta: a proliferação rápida do MCP superou o desenvolvimento do seu modelo de segurança, e, assim como aconteceu com protocolos web no início da internet, o design flexível e pouco especificado abriu margem para ambiguidade no uso seguro. O mesmo relatório destaca que o protocolo inverte um padrão familiar de interação: em vez de clientes solicitarem dados a servidores, o MCP frequentemente espera que servidores consultem e, às vezes, executem ações em nome dos clientes conectados, criando caminhos de ataque novos e ainda pouco mapeados.
Essa não é uma preocupação teórica. Uma linha do tempo recente de incidentes reais confirma o padrão: uma falha crítica de injeção de comando (CVE-2026-0755, CVSS 9.8) foi encontrada em uma ferramenta MCP não oficial de integração com Gemini, e a vulnerabilidade permite que um atacante remoto e não autenticado execute código arbitrário com os privilégios da conta de serviço, decorrente da passagem direta de entrada fornecida pelo usuário para uma chamada de sistema sem validação ou sanitização adequada. Outro caso documentado envolveu uma falha de injeção de comando na integração MCP do nginx-ui, na qual o endpoint de mensagens MCP falhou em autenticar requisições de execução de comando, permitindo que atacantes reiniciassem o servidor ou modificassem arquivos de configuração, alcançando controle total do serviço em mais de 2.600 instâncias expostas publicamente.
Mitigação: boas práticas para times de segurança que operam agentes com MCP
Para quem administra ambientes que já usam MCP ou tool calling em produção, a Dolutech recomenda, com base nas diretrizes técnicas atuais do setor:
- Validação rigorosa de esquema em cada chamada de ferramenta: verificar campos obrigatórios, tamanhos excessivos e tipos de dados antes de qualquer execução, tratando toda entrada como potencialmente hostil.
- Segmentação por classificação de dados: separar ferramentas que tocam dados públicos das que acessam informação sensível ou regulada, seguindo o princípio de zonas de confiança distintas.
- Humano no loop para ações de alto impacto: como recomenda a própria especificação do protocolo, toda ação irreversível ou sensível deveria exigir confirmação humana explícita, não apenas um “SHOULD” no papel.
- Observabilidade completa do tool calling: registrar toda invocação, com parâmetros exatos e identidade envolvida, integrando esses logs ao SIEM corporativo para detecção de padrões anômalos.
- Monitoramento de mudanças em definições de ferramentas: alertar sempre que a descrição de uma ferramenta MCP já aprovada for alterada, prevenindo os chamados ataques de “rug pull”.
- Princípio do menor privilégio para credenciais de MCP servers: já que esses servidores concentram credenciais de múltiplos serviços, um único ponto comprometido pode expor toda a cadeia de integrações conectadas.
O impacto direto para equipes de segurança e SOC
Para o público da Dolutech, o recado prático é direto: a corrida por eficiência em tool calling está reformulando o perímetro de defesa das empresas. Não basta mais avaliar “o que o modelo de IA sabe” em um teste de phishing ou em uma simulação de resposta a incidente. É preciso avaliar o que o agente pode fazer, quais ferramentas ele tem permissão de invocar, com quais credenciais, e sob qual grau de supervisão humana.
Isso muda inclusive a forma como equipes de segurança devem testar esses sistemas. Um pentest tradicional avalia código e configuração estática. Um “red team” para agentes de IA precisa avaliar cadeias de decisão dinâmicas: será que um prompt malicioso escondido em um e-mail, em uma página web ou em um ticket de suporte consegue induzir o agente a chamar uma ferramenta fora do escopo pretendido? Esse é, hoje, o novo campo de batalha da segurança ofensiva e defensiva em IA.
O olhar regulatório: Europa, Portugal e Brasil
A adoção acelerada de agentes com tool calling também acende sinais amarelos regulatórios em ambos os lados do Atlântico.
Na União Europeia, o NIS2 já exige que operadores de infraestrutura crítica tratem cadeias de fornecimento digitais, incluindo integrações de IA agêntica, dentro do seu programa de gestão de risco. O DORA, focado no setor financeiro, impõe testes de resiliência operacional que passam a incluir, cada vez mais, cenários de terceiros de IA e automações conectadas a sistemas críticos. O GDPR/RGPD entra em cena sempre que um agente com tool calling acessa dados pessoais através de uma ferramenta conectada, exigindo base legal, minimização de dados e auditoria do fluxo completo, do prompt até a chamada de função. Em Portugal, o CNCS e o CERT.PT têm reforçado alertas sobre a superfície de ataque criada por integrações de IA em ambientes corporativos e públicos.
No Brasil, a LGPD e a fiscalização da ANPD seguem a mesma lógica: um agente de IA que usa tool calling para consultar ou modificar dados pessoais é, para todos os efeitos, um agente de tratamento de dados, sujeito às mesmas obrigações de qualquer sistema automatizado de decisão. Empresas brasileiras que adotam agentes conectados a CRMs, ERPs ou bancos de dados de clientes precisam, desde já, mapear esses fluxos como parte do seu registro de operações de tratamento.
O que vem a seguir: modelos menores, harnesses mais inteligentes
A tendência que a Dolutech observa com atenção é a de sistemas multiagentes especializados, substituindo o paradigma do “modelo generalista gigante que resolve tudo”. Nós já vemos evidências claras disso: modelos menores, quando operam dentro de um harness bem projetado, com revisão automática de seus próprios resultados, vêm superando modelos muito maiores em tarefas complexas. A inteligência deixou de estar concentrada apenas nos parâmetros do modelo e passou a estar distribuída entre modelo, harness, ferramentas disponíveis e qualidade da orquestração entre eles.
Para o mercado de cibersegurança, isso significa uma coisa muito concreta: a defesa também precisa evoluir na mesma direção. Não é mais suficiente proteger “o modelo”. É preciso proteger toda a cadeia, o harness, as ferramentas conectadas, o protocolo MCP e os dados que fluem entre cada etapa desse ciclo de raciocínio e ação.
A Dolutech continuará acompanhando de perto essa transição, trazendo para nossos leitores portugueses e brasileiros as implicações técnicas e regulatórias de cada nova onda de adoção de IA agêntica.
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.
