MCP virou infraestrutura. Agora vem a parte perigosa da segurança de agentes LLM.

TL;DR

A Model Context Protocol deixou de ser curiosidade técnica e virou padrão de fato para integrar LLMs a sistemas externos — e o que isso muda não é a UX, é a superfície de ataque, o modelo de identidade e o escopo de confiança. Tratar segurança de agentes LLM como refinamento de prompt é o mesmo erro de 2014 que tratava autenticação como detalhe de feature: funciona até alguém executar a primeira ação real que não deveria.

• A segurança de agentes LLM vive em três lugares que tutorial de MCP não cobre: identidade do chamador, escopo de cada tool, e blast radius do que o agente consegue encadear.
• Tool poisoning é prompt injection que não passa pelo prompt: o veneno está na descrição da tool, no JSON de retorno, ou no servidor MCP que serviu a chamada.
• Permissão por tool é a granularidade errada. O que importa é o grafo de ações encadeadas que o agente consegue construir em N passos.
• Blast radius precisa ser medido antes de liberar a primeira ação de produção, não depois do primeiro incidente.
• Quatro controles pagam o ROI no primeiro trimestre: inventário de tools + identidade curta + escopo por capability + kill switch observável.

~ 13 min de leitura · 2261 palavras

O que mudou: MCP não é mais “spec”, é superfície de execução

A Model Context Protocol foi anunciada em 2024 como forma padronizada de LLMs consumirem ferramentas externas. Em 2026, é a forma dominante — Anthropic, OpenAI, Google e a maior parte dos provedores sérios tratam MCP como camada default. Servidores comunitários, gateways e SDKs em Python, TypeScript e Go amadureceram rápido. Rodar MCP em produção deixou de ser exceção em seis meses.

O que a conversa pública ainda não internalizou é o que isso significa para segurança. Quando um LLM responde em texto, o blast radius é o leitor humano. Quando invoca uma tool, é o sistema do outro lado: banco, cluster Kubernetes, bucket S3, sistema de pagamento. A diferença não é de grau — é de classe.

A primeira geração de conteúdo sobre MCP tratou o protocolo como detalhe de implementação: como conectar, como declarar tools, como debugar JSON-RPC. Esse conteúdo envelheceu em seis meses. O que ficou foi o problema que o protocolo expôs — o modelo virou um ator com capacidade de execução real, e o software corporativo não foi desenhado para um ator assim.

Tratar o agente como usuário autenticado é o piso. Tratar como identidade com escopo próprio, revogável e auditável, é o teto realista para 2026.

Os três problemas que tutorial de MCP não resolve para segurança de agentes LLM

Um tutorial de MCP mostra como registrar uma tool e como ela é chamada. Um diagnóstico de segurança mostra onde o tutorial parou cedo demais.

Identidade do chamador. Quem é o “user” do agente? Em arquitetura tradicional, é a pessoa sentada na frente do teclado. Em arquitetura agentic, é o resultado de uma cadeia: o humano delegou a um agente, o agente invocou outro agente, esse agente chamou uma tool. O JWT que chega na tool representa o humano ou o agente intermediário? Se carrega o escopo do humano, está exagerado. Se carrega o do agente, perdeu-se a rastreabilidade do humano. É exatamente essa zona cinzenta que atacante explora.

Escopo de cada tool. A documentação de MCP diz que cada tool declara seu input schema. O que ela não diz é como limitar o que a tool pode fazer quando chamada por um agente com autonomia de encadear. Se a tool `query_database` aceita SQL arbitrário, o escopo é “qualquer SELECT que o agente inventar”. Pode ser o que se quer — ou um desastre esperando o primeiro prompt que peça `DROP TABLE`.

Blast radius. O pior caso não é o agente executar uma tool perigosa. É o agente encadear três tools benignas em uma sequência cujo efeito combinado é catastrófico. Tool 1 lê lista de e-mails. Tool 2 envia e-mail para destinatário arbitrário. Tool 3 lê o calendário. Isoladas, três tools de escritório. Combinadas em três chamadas, exfiltração com agendamento automático. Permissão por tool não captura isso. Permissão por capability, sobre grafo de execução, captura.

A literatura recente — em particular o “lethal trifecta” de Simon Willison — resume o ataque canônico: três capabilities (acesso a dados privados, exposição a conteúdo não-confiável, capacidade de exfiltração) que, combinadas em um único agente, produzem vazamento inevitável. A defesa não é “tomar uma das três” — é tornar a combinação estruturalmente cara.

Tool poisoning: o prompt injection que não passa pelo prompt

O modelo tradicional de prompt injection assume que o atacante controla parte do input do modelo. Em 2024, isso significava colar instrução maliciosa em um documento. Em 2026, com MCP, o vetor se multiplicou.

A tool em si é um vetor. O nome, a descrição, o JSON Schema de input e o output retornado são texto que entra no contexto do modelo. Um atacante que registra uma tool maliciosa em um servidor MCP — comprometido, mirror malicioso, dependência de terceiro na supply chain — injeta instrução direto no system prompt equivalente do agente. O modelo não vê a diferença entre “instrução do operador” e “descrição da tool” — vê uma string de texto que informa o que a tool faz.

O caso documentado mais sério envolveu um servidor MCP não-oficial oferecendo uma tool de “busca em repositórios de código”. A descrição, em texto natural, instruía o modelo a incluir um trecho adicional nas respostas — trecho que, em cadeias mais complexas, era tratado como instrução por modelos downstream. Resultado: prompt injection atravessando fronteiras de processo sem que nenhum processo individual tivesse sido “phishingado”.

A defesa não é “validar descrição de tool” — é ingênuo. É tratar toda tool como código não-confiável por padrão. Servidores MCP catalogados, versionados, com provenance auditável. Tools em sandboxes com escopo mínimo. Outputs parseados como dados, não como instruções.

A OWASP já catalogou o vetor em LLM01 (Prompt Injection) e LLM10 (Model Theft). A Cloud Security Alliance publicou MAESTRO para threat modeling de agentes. A MITRE mantém o ATLAS para adversarial ML. O problema não é falta de taxonomia — é que a maioria das organizações em produção não leu nenhuma das três.

Identidade e segredos: o que acontece quando o “user” do agente não é uma pessoa

Em arquitetura tradicional, o “user” de uma chamada de API é uma pessoa física autenticada por SSO, com grupos e policies atreladas. Em arquitetura agentic, o “user” pode ser um agente que recebeu delegação de outro agente que recebeu delegação de um humano. A cadeia de identidade vira cadeia de ambiguidade.

O caso prático mais comum: o agente precisa acessar um sistema que não fala MCP. Então usa um secret. Esse secret está em algum lugar — variável de ambiente, vault, arquivo de credenciais, gerenciador de secrets. Onde quer que esteja, o agente lê. E agora o secret vazou: está no log do LLM, no contexto da próxima chamada, em qualquer cache de tool que persista output por mais de cinco minutos.

A resposta convencional — “use short-lived tokens” — resolve parte. A operacional é mais feia: para sistemas que o agente acessa com frequência, a credencial tem que ser do agente, não do humano. Precisa ser revogável, escopada, registrada com a identidade do agente — não da pessoa que delegou.

OAuth 2.0 com token exchange dá o vocabulário (RFC 8693 define como trocar um token por outro com escopo diferente). A maioria das organizações não implementou — o motivo usual é “complexidade”, traduzido por “não sabemos o escopo certo do agente, então demos o do humano”. O escopo do humano é grande demais. O do agente vai precisar ser construído do zero, capability por capability, com auditoria de cada capability delegada.

Três perguntas separam uma implementação segura de um desastre esperando:

• O secret que o agente usa é único para esse agente, ou compartilhado entre agentes?
• O secret pode ser revogado sem invalidar o usuário humano original?
• O log de uso do secret identifica o agente que o usou, ou apenas o humano que delegou?

Se a resposta a qualquer uma for “não” ou “não sei”, o segredo está em zona de risco.

Escopo de ações: por que “permissão por tool” é a granularidade errada

A primeira onda de servidores MCP implementou controle de acesso por tool. Lista de tools que o agente pode invocar. A ferramenta está autorizada ou não. É um bom começo, mas ingênuo.

O problema é o que a permissão por tool não captura: a composição. Um agente com três tools benignas pode encadear uma sequência cujo efeito é uma quarta ação que nenhuma das três tools isoladamente permitiria. Ler lista de e-mails, criar rascunho, enviar rascunho — isoladamente, três capabilities de produtividade. Combinadas, um vetor de phishing automatizado a partir da caixa do próprio usuário.

O controle que importa é o de capability sobre grafo. Capability, não tool: “o agente pode ler e-mails” é uma capability. “O agente pode enviar e-mail para fora do domínio” é outra. A primeira pode ser autorizada; a segunda, não. O grafo captura o que cada capability permite em sequência, e a autorização é negada por padrão quando a sequência produz um efeito que nenhuma capability individual autorizaria.

A implementação concreta varia. OpenAI function calling com structured outputs, Anthropic tool use com permission tokens, Vertex AI com function calling restrictions — todos oferecem variantes desse controle. A maioria dos servidores MCP comunitários não oferece. Quando o servidor não oferece, a policy precisa ser imposta no cliente: um gateway que intercepta todas as chamadas, valida o grafo de capabilities, e nega sequências proibidas antes que cheguem à tool.

Esse gateway é o equivalente funcional do API gateway que toda arquitetura de microsserviços madura tem. A diferença é que o gateway tradicional protege o backend do frontend; o gateway de agentes protege o backend do modelo. O modelo não sabe negociar permissões — qualquer defesa tem que estar antes dele.

Blast radius: medir antes de permitir, não depois do incidente

O conceito de blast radius vem de segurança de infraestrutura: a magnitude do pior cenário quando um componente é comprometido. Em agentes, a definição é a mesma, mas a unidade muda. Não é “quantos servidores podem cair”; é “quantos sistemas podem ser modificados por um agente comprometido, e em que janela de tempo”.

A medição tem que acontecer antes de liberar a primeira ação em produção — não depois do primeiro incidente. Os números:

• Quantas tools o agente consegue invocar em sequência sem intervenção humana?
• Cada tool, qual o efeito colateral máximo (read-only, mutação, mutação irreversível)?
• O efeito combinado de duas tools está documentado em algum lugar?
• Existe kill switch que revoga todas as capabilities do agente em menos de 60 segundos?

Se essas perguntas não têm resposta em uma linha cada, o blast radius é desconhecido. Blast radius desconhecido é o pior cenário possível — a única defesa disponível é reação manual, e a velocidade de agentes é maior que a velocidade de qualquer humano olhando.

O kill switch observável é o controle que mais retorna por hora investida. Não é fancy: é um endpoint que revoga todas as capabilities de um agente, com efeito propagado em menos de 60 segundos, com alerta para o time de segurança. A maioria dos incidentes publicados em 2025-2026 teria sido contida em minutos se esse controle existisse. A maioria das organizações em 2026 ainda não tem.

A medição que se faz é simples: rodar o agente em staging com capabilities equivalentes às de produção, registrar o grafo completo de execução por uma semana, calcular o envelope máximo. Esse envelope é o blast radius declarado. Qualquer capability nova que expande o envelope precisa de autorização explícita, registrada, datada e revogável.

O que fazer agora: quatro controles que pagam o ROI no primeiro trimestre

A lista de controles de segurança para agentes é longa e mal calibrada. A diferença entre “controle” e “teatro de segurança” é se o controle barra um ataque real ou só aparece em relatório trimestral.

Quatro controles pagam o ROI no primeiro trimestre, sem dependência de vendor específico e sem retrabalho arquitetural grande:

Inventário de tools e servidores MCP. Toda tool que algum agente consome em qualquer ambiente é catalogada: servidor MCP, versão, mantenedor, data de atualização, escopo declarado, escopo efetivo medido. Esse inventário vira a verdade-base de qualquer auditoria de segurança de agentes LLM. Sem ele, o resto é chute.

Identidade curta e específica para cada agente. Cada agente em produção tem identidade própria, com credenciais curtas e escopadas. O segredo não é compartilhado entre agentes, é revogável sem invalidar o humano que delegou, e o log registra qual agente usou o quê e quando.

Escopo por capability, com gateway de validação. Permissão por tool é o piso. O controle real é o grafo de capabilities. Um gateway intercepta todas as chamadas, valida o grafo contra a policy declarada, nega sequências proibidas. A policy é auditável, versionada, revisada trimestralmente.

Kill switch observável com tempo de propagação medido. Endpoint que revoga todas as capabilities de um agente. Tempo de propagação medido e inferior a 60 segundos. Alerta para o time de segurança quando acionado. Testado em staging pelo menos uma vez por trimestre.

Esses quatro controles não substituem threat modeling, revisão de código ou auditoria. Mas elevam o piso de qualquer arquitetura agentic de “depende do desenvolvedor ter pensado nisso” para “está no caminho crítico de qualquer deploy”. O custo é da ordem de duas pessoas por duas semanas para implementar, e meio FTE para manter.

A conta de segurança de agentes LLM não fecha com quatro controles. Fecha com revisão contínua, threat modeling atualizado a cada release do modelo, e cultura de post-mortem que trate incidente de agente com a mesma seriedade de incidente de banco. Esses quatro controles garantem que, quando o incidente vier, a resposta não dependa de alguém ter lembrado de desabilitar uma capability às três da manhã.

Leitura relacionada

• Feature flag não é gambiarra. É seguro contra deploy irreversível. — mostra como o controle de feature flag se aplica a agentes que precisam ser desabilitados em segundos, não em horas, e por que o kill switch deste post é implementado exatamente como um toggle de produção.
• Você não tem atraso. Você tem expectativa errada. — desmonta a crença de que o problema é prazo quando o problema é escopo, e oferece o critério que se aplica igualmente a capability por capability no lugar de tool por tool.
• Responsabilidade do desenvolvedor com código gerado por IA — aprofunda a fronteira entre o que o modelo faz e o que o engenheiro responde, argumento que sustenta o ponto deste post sobre auditoria do agente ser responsabilidade da operação, não do prompt.