Durante anos, a pergunta de segurança sobre um modelo de linguagem foi simples: o que é que ele responde? Hoje a pergunta mudou. Os modelos deixaram de só escrever texto e passaram a agir: leem ficheiros, executam código, enviam emails, chamam APIs. Para isso ligam-se a ferramentas externas através do Model Context Protocol (MCP), de plug-ins e de pacotes. E é exatamente aí, na cadeia que alimenta o agente, que se está a abrir a superfície de ataque mais negligenciada de 2026.
O caso que melhor ilustra isto é o postmark-mcp. Era um servidor MCP publicado no npm para permitir que assistentes de IA enviassem email. Funcionou de forma limpa durante quinze versões. Na versão 1.0.16, o autor acrescentou uma única linha: uma cópia oculta (BCC) de todas as mensagens para um domínio externo. Tinha cerca de 1500 descarregamentos por semana, e os investigadores estimam que perto de 300 organizações o terão usado em produção. Quem o fez esteve, sem saber, a reencaminhar correspondência sensível para um terceiro, sem um único alerta a disparar.
O problema não é um pacote isolado. É estrutural.
O agente confia em quem não devia
Um agente de IA lê a descrição de cada ferramenta para perceber como a usar, e trata essa descrição como instrução fiável. Basta esconder texto malicioso nessa descrição, a chamada tool poisoning, para que o modelo o execute como se viesse do utilizador. A injeção de prompts, instruções maliciosas disfarçadas de pedido legítimo, continua a ser a vulnerabilidade número um do OWASP para LLM em 2026, e há quem defenda que é um defeito permanente da tecnologia, não um bug que se corrige com um patch.
Some-se a isto a infraestrutura à volta. O CVE-2025-6514, com gravidade 9.6, era uma injeção de comandos no mcp-remote, o proxy que liga muitos clientes locais a servidores MCP remotos. E os registos públicos, npm e PyPI, continuam a ser inundados de pacotes maliciosos que roubam credenciais a partir das pipelines de quem os instala. O agente automatiza a confiança, e a automação da confiança é precisamente o que um atacante quer.
Pedir contas ao agente
A 22 de junho, os serviços das Five Eyes, a aliança de informações dos EUA, Reino Unido, Canadá, Austrália e Nova Zelândia, vieram avisar que a IA está a comprimir o tempo entre a descoberta de uma falha e a sua exploração, de anos para meses. A orientação que publicaram sobre IA agêntica é, no fundo, higiene clássica aplicada a um contexto novo: não dar acesso amplo, começar pelas tarefas de baixo risco, privilégio mínimo, autenticação forte, segmentação e registo de tudo.
É aqui que vale a pena olhar para um agente como se olha para um suspeito. Quem lhe deu a ordem? O que é que ele instalou? Que dados saíram, para onde, e quem aprovou? Se a resposta a estas perguntas não estiver nos registos, o incidente já aconteceu e ninguém o vai conseguir reconstruir.
Na prática, três decisões resolvem a maior parte do risco:
- Tratar cada servidor MCP, plug-in ou skill como uma dependência não confiável: fixar versões, rever o que muda a cada atualização e remover o que não se usa.
- Dar a cada agente o mínimo de permissões e isolar o que ele toca, para que uma instrução envenenada não chegue aos dados que importam.
- Registar e vigiar as ações do agente, não só as suas respostas, porque é nas ações que se vê o ataque.
A IA agêntica é uma das mudanças mais úteis dos últimos anos. Mas dar autonomia a um sistema sem lhe pedir contas é repetir, mais depressa, um erro que já conhecemos. Desta vez, com a diferença de que o agente abre a porta sozinho.
Fontes: Koi Security, JFrog, CISA / Five Eyes, OWASP.
#StaySafe
🙏🖖
