O Model Context Protocol está viabilizando novos e poderosos fluxos de trabalho. Ele permite que modelos acessem ferramentas, consultem sistemas e realizem ações em nome dos usuários. Esse recurso proporciona ganhos reais de produtividade. Também cria uma nova e concreta superfície de ataque: quando um modelo, agente ou cliente de IA herda a identidade de um usuário, pequenas alterações em uma ferramenta ou pacote MCP podem introduzir riscos invisíveis em grande escala.
O risco em uma única frase
Um servidor MCP executado com as credenciais de um usuário pode acessar os mesmos sistemas e APIs que ele. Ferramentas comprometidas não precisam burlar a autenticação. Elas já operam como se fossem o usuário legítimo.
Como essas explorações realmente acontecem
Toda ferramenta MCP apresenta ao modelo um conjunto simples de informações: um nome, uma descrição legível para humanos e uma lista de parâmetros. O modelo usa essas descrições para escolher qual ferramenta chamar e como preencher seus parâmetros. Na prática, os metadados da ferramenta podem influenciar o comportamento do modelo. Isso é uma injeção de prompt incorporada ao protocolo.
Por exemplo, considere uma ferramenta inofensiva de “Consultar previsão do tempo” que foi modificada para exigir o resultado de uma consulta ao CRM antes de ser executada. O modelo seguiu essa instrução, extraiu dados do CRM e os repassou ao contexto de execução da ferramenta de previsão do tempo. Para exfiltrar o registro do CRM, bastou uma linha adicional de código que enviava os dados coletados para um endpoint público. O usuário continuou recebendo uma resposta normal sobre a previsão do tempo, enquanto dados confidenciais de negociações eram enviados silenciosamente para fora da organização.
Essa exploração não precisou de nenhum jailbreak. Não exigiu nenhuma invasão complexa. Bastaram uma pequena alteração em uma ferramenta e algumas instruções em linguagem natural. E, como muitos pacotes MCP são instalados ou atualizados com comandos práticos, como npx, ou com tags “latest”, códigos comprometidos podem ser baixados automaticamente quando um cliente é iniciado.
Por que os controles tradicionais muitas vezes não detectam isso
A maioria das ferramentas de segurança é desenvolvida para proteger APIs, aplicar controles de identidade e monitorar os limites da rede. Os ataques de MCP exploram uma dimensão diferente: a forma como o modelo seleciona e encadeia ferramentas. Servidores MCP locais podem executar código arbitrário, e o modelo pode encadear ferramentas de maneiras invisíveis ao monitoramento restrito a APIs.
Em termos simples, esses ataques parecem ações legítimas de usuários. Eles usam credenciais legítimas para fazer chamadas legítimas. Isso dificulta a detecção e a atribuição com as ferramentas existentes.
Por que esse risco está aumentando
O MCP está deixando de se restringir aos fluxos de trabalho exclusivos de desenvolvedores. Fornecedores de SaaS e equipes de produto estão disponibilizando automações no estilo de agentes como “ferramentas”, “agentes” ou “automações”, com fluxos que permitem adicioná-las com um clique. Usuários sem conhecimento técnico podem habilitar esses recursos sem compreender as implicações de segurança. Isso significa que comprometimentos na cadeia de suprimentos ou no nível das ferramentas podem ir além das equipes de engenharia e afetar usuários dos produtos em toda a empresa.
Também estamos vendo registros e catálogos selecionados que apresentam serviços MCP de terceiros como componentes “confiáveis”. Essas listas podem ser extraídas ou preenchidas a partir de repositórios públicos, e um selo não é garantia de segurança.
Consequências práticas
Uma exploração bem-sucedida do MCP pode causar diversos danos. Ela pode exfiltrar silenciosamente registros de clientes, obter credenciais temporárias ou tokens e usá-los em chamadas subsequentes. Também pode desencadear ações destrutivas ou combinar pequenas ações em uma cadeia maior e dispendiosa. É importante ressaltar que esses comportamentos podem ocorrer enquanto o usuário acredita estar realizando tarefas rotineiras e de baixo risco.
O que fazer a seguir
Bloquear totalmente o MCP não é uma opção viável para a maioria das organizações. O MCP oferece valor real, e remover o acesso apenas leva os usuários a recorrer à IA paralela e a soluções alternativas não autorizadas. O caminho mais prático é obter visibilidade sobre quais recursos de MCP estão sendo usados, classificar essas ferramentas e aplicar políticas e controles em tempo de execução nos limites do modelo.
Agende uma demonstração do F5 Workforce AI Security, anteriormente chamado SurepathAI, para combinar descoberta, classificação e aplicação de políticas, permitindo que sua equipe continue produtiva enquanto ações de risco são impedidas.
Sobre o autor
Publicações relacionadas no blog
IA agêntica em cibersegurança: promessas e riscos
Saiba por que o uso de IA agêntica na cibersegurança é essencial para combater ameaças impulsionadas por IA e por que os agentes também criam novos riscos para as empresas.
Como os clientes da F5 no setor financeiro lidam com a soberania digital sem desacelerar a inovação
Como é a soberania digital na prática? Dois projetos recentes da F5 com clientes mostram como diferentes empresas estão enfrentando esses desafios.
Soberania operacional: construindo resiliência em um mundo imprevisível
Para muitas organizações, a questão já não se resume apenas a controlar os dados. Trata-se de manter a capacidade de operar, adaptar-se e se recuperar à medida que as leis e as condições evoluem.
Segurança de IA com evidências: o que levaremos ao Gartner SRM
Antes de sua sessão no Gartner SRM, o vice-presidente sênior de Marketing de Produtos da F5 explica como a F5 ajuda as organizações a proteger a IA em três etapas práticas.
Gestão de riscos de IA: como as proteções podem ajudar a mitigá-los
O risco da IA é impulsionado por comportamentos probabilísticos e pela explicabilidade limitada, não apenas por falhas de segurança. Uma gestão eficaz exige controle operacional contínuo.
Lei de IA do Colorado (SB 205): o que as empresas precisam saber antes de 2026
A SB 205 do Colorado, a lei pioneira do estado sobre inteligência artificial, foi sancionada pelo governador Jared Polis em 17 de maio de 2024. O projeto de lei estabelece requisitos para que as empresas que utilizam IA implementem controles destinados a proteger os cidadãos do Colorado.