Riscos de Segurança e Melhores Práticas do MCP em 2026

Quando a Anthropic lançou o Protocolo de Contexto do Modelo no final de 2024, ele abordou um problema real. Em vez de escrever código de integração personalizado para cada ferramenta que um agente de IA precisava usar, as equipes podiam conectar agentes a bancos de dados, APIs e sistemas internos por meio de uma interface padronizada. A adoção foi rápida. Até 2025, dezenas de milhares de servidores MCP haviam sido implantados em ambientes empresariais.

Mas a velocidade da adoção expôs uma lacuna para a qual a maioria das organizações não estava preparada: . O MCP foi projetado para tornar os agentes de IA mais capazes. Ele não foi projetado com a segurança empresarial como um princípio fundamental. A especificação original foi lançada sem uma estrutura de autenticação obrigatória. O modelo de confiança implícita assumia que os servidores MCP eram benignos. E as ferramentas que esses servidores expunham eram tratadas como saídas de sistemas bem-comportados, e não como uma nova superfície de ataque.

Pesquisadores de segurança documentaram as consequências rapidamente. CVE-2025-49596, com uma pontuação CVSS de 9.4, mostrou que instâncias não autenticadas do MCP Inspector poderiam ser exploradas para executar comandos arbitrários. A Invariant Labs demonstrou que um servidor MCP malicioso poderia exfiltrar silenciosamente todo o histórico de mensagens do WhatsApp. O incidente do agente Supabase Cursor em junho de 2025 mostrou como um agente privilegiado processando tickets de suporte fornecidos pelo usuário poderia ser enganado para vazar tokens de integração por meio de injeção de prompt.

Estes não são casos extremos de experimentos mal construídos. Eles aconteceram em sistemas de produção reais porque a arquitetura do MCP cria superfícies de ataque que as ferramentas de segurança tradicionais não foram projetadas para ver. 

Este artigo aborda os riscos de segurança específicos do MCP que as empresas enfrentam, os controles que os abordam e por que a abordagem que você usa para aplicar esses controles é tão importante quanto os próprios controles.

Your AI Agents Have Access to Everything, Does Your Security?

TrueFoundry enforces identity-aware execution and granular RBAC inside your private cloud environment.

Book Demo

Os 5 Principais Riscos de Segurança do MCP Enfrentados pelas Empresas

Estes são os cinco riscos de segurança do MCP mais comumente encontrados em implantações de MCP.

Acesso Excessivamente Privilegiado do Agente

Quando um desenvolvedor conecta um agente de IA pela primeira vez a sistemas empresariais, ele geralmente busca as credenciais às quais já tem acesso, muitas vezes chaves de API de nível de administrador ou contas de serviço com permissões amplas. Isso ocorre porque eles querem que o agente funcione sem encontrar erros de autorização durante o desenvolvimento. O problema é que essas permissões amplas raramente são reduzidas antes que o agente entre em produção.

O projeto OWASP MCP Top 10, lançado especificamente para rastrear vulnerabilidades do MCP, identifica o acesso excessivamente privilegiado como um risco fundamental. Quando um agente de suporte ao cliente possui as mesmas credenciais que um administrador de banco de dados, um único ataque bem-sucedido contra esse agente não expõe uma fila de suporte. Ele expõe o banco de dados. O raio de impacto de qualquer comprometimento escala diretamente com a quantidade de acesso concedida ao agente.

Esta não é uma preocupação teórica. O incidente do Supabase envolveu um agente executando com acesso privilegiado de função de serviço, processando entradas que continham conteúdo controlado por invasores. O nível de privilégio foi o que tornou o ataque possível. Um agente com acesso somente leitura a dados de suporte não teria tido as credenciais para exfiltrar tokens de integração.

Injeção de Prompt Através de Conteúdo Externo

A injeção de prompt é classificada como a vulnerabilidade número um no OWASP Top 10 para Aplicações LLM 2025, e assume um caráter diferente em ambientes MCP do que em implantações simples de chatbots. Quando um agente tem a capacidade de executar ações, uma injeção bem-sucedida não produz apenas uma saída ruim. Ela pode desencadear operações reais: envio de e-mails, chamadas de API, modificação de registros ou encaminhamento de dados para endereços externos.

O padrão de ataque é indireto. O invasor não precisa de acesso aos seus sistemas. Eles incorporam instruções maliciosas dentro do conteúdo que o agente processará como parte de seu trabalho normal: um PDF que lhe é pedido para resumir, um e-mail de cliente que está roteando, uma página da web que está lendo para pesquisa. O agente lê o conteúdo, encontra as instruções incorporadas e, como não há uma fronteira rígida entre dados e instruções na forma como os modelos de linguagem processam o contexto, ele interpreta essas instruções como legítimas e age de acordo com elas.

O pesquisador de segurança Simon Willison, que acompanha este problema desde 2022, escreveu: ""A maldição da injeção de prompt continua sendo que sabemos sobre o problema há mais de dois anos e meio e ainda não temos mitigações convincentes.""

A própria especificação do MCP reconhece o risco, observando que sempre deve haver um humano no ciclo.

Envenenamento de Ferramentas e o Ataque Rug Pull

Os agentes MCP confiam nos metadados das ferramentas. Quando um agente se conecta a um servidor MCP e solicita a lista de ferramentas disponíveis, o servidor responde com nomes de ferramentas, descrições e esquemas de parâmetros. O agente usa esses metadados para decidir quais ferramentas chamar e como chamá-las. O envenenamento de ferramentas explora essa relação de confiança.

Num ataque de envenenamento de ferramentas, um atacante cria ou compromete os metadados de uma ferramenta para que contenham instruções ocultas. A descrição da ferramenta parece normal numa inspeção visual, mas contém diretivas incorporadas que fazem com que o agente execute ações prejudiciais, exfiltre dados ou eleve as suas próprias permissões. Como o conteúdo malicioso está dentro da definição da ferramenta e não na entrada do usuário, ele contorna as camadas de validação de entrada que verificam apenas o conteúdo visível para o usuário.

A Invariant Labs demonstrou uma variante disso em 2025, mostrando como um servidor MCP malicioso no mesmo contexto de agente que um servidor MCP legítimo do WhatsApp poderia usar o envenenamento de ferramentas para ler e exportar silenciosamente todo o histórico de mensagens de um usuário. O ataque não exigiu erro do usuário nem exploração em nível de rede.

Um ataque relacionado é o rug pull, onde uma ferramenta se comporta legitimamente na instalação e depois altera silenciosamente o seu comportamento depois que o usuário lhe concedeu permissões. Os servidores MCP podem atualizar as definições das ferramentas sem notificar o cliente, e a maioria dos clientes não sinaliza nem detecta essas alterações. 

Proliferação de Credenciais em Servidores MCP Não Gerenciados

Em ambientes sem gerenciamento centralizado de credenciais, cada servidor MCP mantém sua própria configuração de autenticação. Os desenvolvedores armazenam chaves de API em variáveis de ambiente, codificam OAuth tokens em arquivos de configuração e usam credenciais de conta de serviço de longa duração porque são mais fáceis de gerenciar do que tokens de escopo de curta duração. Pesquisas que rastreiam implantações de MCP encontraram 492 servidores MCP expostos publicamente que careciam de autenticação básica ou criptografia.

A CVE-2025-6514, uma vulnerabilidade crítica de injeção de comando de SO no mcp-remote, um proxy OAuth com mais de 437.000 downloads usado em integrações da Cloudflare, Hugging Face e Auth0, demonstrou a dimensão da cadeia de suprimentos desse risco. 

Um endpoint MCP malicioso poderia enviar uma URL de autorização criada que o mcp-remote passaria diretamente para o shell do sistema, alcançando a execução remota de código na máquina cliente e fornecendo acesso a chaves de API, credenciais de nuvem, arquivos locais e chaves SSH armazenadas nessa máquina.

Pontos Cegos de Auditoria que Comprometem a Conformidade

Servidores MCP padrão não registram o contexto de execução em um formato estruturado e pronto para conformidade. Eles podem registrar que uma ferramenta foi chamada. Eles geralmente não registram de qual usuário humano a solicitação se originou, qual foi o raciocínio do agente no momento da chamada, quais dados foram retornados ou se uma política de acesso foi consultada antes que a operação fosse permitida.

Para empresas que operam sob SOC 2, HIPAA ou GDPR, esta não é uma lacuna menor. O SOC 2 exige evidências de controles de gerenciamento e processamento de dados. O HIPAA exige trilhas de auditoria de cada acesso ao sistema que toque em informações de saúde protegidas, atribuídas a um usuário ou serviço identificável. O GDPR exige a capacidade de demonstrar quais dados foram processados, quando e por quem. Uma implantação de MCP sem registro de auditoria estruturado falha em todos esses requisitos simultaneamente.

Uma pesquisa de 2025 sobre o uso de sistemas de IA em ambientes empresariais descobriu que menos de 30% dos sistemas de IA tinham trilhas de auditoria estruturadas de acesso a ferramentas de agente. Menos de 15% conseguiam reconstruir todo o caminho de decisão para uma ação de agente.

Quando um incidente de segurança ocorre nesse ambiente, a investigação depende da reconstrução forense a partir de logs incompletos, adicionando semanas ao tempo de resposta a incidentes e tornando quase impossível produzir evidências prontas para auditoria.

Melhores Práticas Essenciais de Segurança MCP

Os riscos de segurança MCP acima compartilham um fio condutor comum: todos eles resultam da ausência de um limite controlado entre os agentes de IA e os sistemas a que acessam. Cada melhor prática abaixo é projetada para estabelecer e impor esse limite na camada onde o ataque ocorre, e não depois do fato.

Impor Execução com Consciência de Identidade

A decisão arquitetônica mais importante em qualquer implantação de MCP é como a identidade do agente de IA é gerenciada. Contas de serviço compartilhadas criam lacunas de responsabilidade que nenhuma quantidade de registro pode preencher. Se cinco agentes compartilham um conjunto de credenciais, não há como atribuir uma ação específica a um agente específico, muito menos ao usuário humano que a acionou.

A abordagem correta é a autenticação Em Nome De (OBO), onde cada solicitação de agente de IA carrega e exerce as permissões exatas do usuário humano que a iniciou. Quando um desenvolvedor consulta fontes de dados através de um agente conectado ao MCP, a operação ocorre com o nível de acesso do desenvolvedor, e não com credenciais de nível de administrador que por acaso estão configuradas no servidor. O acesso é limitado pelo que essa pessoa está autorizada a fazer em qualquer outro lugar da organização.

Isso exige integração com seu provedor de identidade corporativo, seja Okta, Azure AD ou uma configuração SSO personalizada. Significa registro dinâmico de cliente e fluxos de código de autorização onde os tokens têm escopo de usuário, são de curta duração e são automaticamente atualizados, em vez de chaves estáticas de longa duração que persistem até que alguém as revogue manualmente.

Aplicar Controle de Acesso Baseado em Funções Granular no Nível da Ferramenta

O controle de acesso em nível de servidor é demasiado genérico para implantações de MCP em produção. Controlar se um usuário ou agente pode acessar um servidor MCP é um ponto de partida. O que você realmente precisa é a capacidade de controlar quais ferramentas específicas dentro desse servidor cada função pode invocar.

O requisito prático é este: um agente de suporte ao cliente deve ser capaz de invocar operações de leitura em um servidor CRM, mas não operações de exclusão. Um agente financeiro deve ser capaz de consultar registros de pagamento, mas não acionar transferências de saída. Essas distinções não podem ser expressas por meio de políticas de acesso em nível de servidor. Elas exigem RBAC em nível de ferramenta, onde cada ferramenta dentro de um servidor possui seus próprios requisitos de autorização e esses requisitos são avaliados a cada invocação.

A atualização de 2026 da especificação MCP introduziu o consentimento de escopo incremental, permitindo que os clientes solicitem apenas o acesso mínimo necessário para cada operação, em vez de solicitar todas as permissões antecipadamente. A implementação disso requer uma camada de autorização que compreenda a semântica em nível de ferramenta, e não apenas o roteamento em nível de rede.

Exigir Aprovação Humana para Ações Irreversíveis

Os agentes não devem ser capazes de executar operações destrutivas ou de alto risco sem um ponto de verificação humano. Exclusões de banco de dados, transferências de dados externos, transações financeiras, modificações em massa de registros e comunicações de saída são todas operações onde uma instrução equivocada ou injetada pode causar danos difíceis ou impossíveis de reverter.

A especificação MCP reconhece isso explicitamente: deve haver sempre um humano no ciclo com a capacidade de negar invocações de ferramentas. Implementar isso na prática significa anotar ferramentas MCP com classificações de risco e impor fluxos de aprovação para operações marcadas como destrutivas ou irreversíveis. O agente apresenta a ação pretendida com seus argumentos antes de executar e aguarda autorização humana explícita.

Este não é apenas um mecanismo de segurança. É também uma mitigação de injeção de prompt. Uma instrução injetada que não pode ser executada sem aprovação humana não pode exfiltrar dados silenciosamente. A etapa de aprovação quebra a cadeia de ataque na camada de execução, mesmo quando a detecção na camada de entrada falha.

Consolidar Conexões de Ferramentas em um Único Registro Governado

As conexões ponto a ponto entre agentes individuais e servidores MCP individuais são o que criam as lacunas de visibilidade e as falhas de governança descritas na seção de riscos. Quando cada equipe gerencia suas próprias conexões de servidor, não há um lugar central para ver quais ferramentas existem, quem tem acesso a elas ou o que está sendo chamado em produção no momento.

Um registro central governado muda isso. As ferramentas são registradas uma vez. As políticas de acesso são definidas uma vez e aplicadas de forma consistente. Quando uma ferramenta é atualizada ou desativada, essa mudança é refletida em um único lugar e os agentes a captam automaticamente, em vez de continuar a chamar endpoints obsoletos ou falhar porque não foram informados sobre a mudança. As equipes de segurança obtêm um inventário único em vez de uma planilha que está sempre desatualizada.

O registro também mitiga o risco de fraude. Quando as definições das ferramentas são gerenciadas centralmente, as alterações nos metadados das ferramentas são versionadas e auditáveis. Uma ferramenta que altera silenciosamente sua própria descrição após a instalação é detectável porque o registro mantém um histórico de como cada ferramenta era no momento do registro versus como ela é agora.

Manter Registros de Auditoria Abrangentes e Estruturados

Cada evento de autenticação, emissão de token, invocação de ferramenta e decisão de política deve ser registrado com metadados estruturados que incluam quem fez a solicitação, qual agente a executou, qual ferramenta foi chamada, quais argumentos foram passados, o que foi retornado e se alguma política foi aplicada ou substituída.

A distinção entre ter logs e ter logs prontos para conformidade é significativa. Registros de auditoria que registram nomes de ferramentas e carimbos de data/hora satisfazem um requisito técnico restrito. Registros que documentam a identidade do usuário, a identidade do agente, o contexto completo da solicitação, as políticas aplicadas e o conteúdo de saída em um formato estruturado que pode ser consultado e exportado sob demanda satisfazem os requisitos SOC 2, HIPAA e GDPR. Estas são coisas diferentes, e a lacuna entre elas é onde a maioria das falhas de auditoria ocorre.

Os registros devem ser retidos dentro do seu próprio ambiente. Registros que residem em um sistema SaaS de terceiros não estão totalmente sob seu controle, não podem ser produzidos sob demanda com total certeza e podem estar sujeitos a restrições de tratamento de dados que conflitam com o que sua estrutura de conformidade exige.

As Falhas nas Soluções Atuais do Mercado

Não faltam ferramentas comercializadas como soluções de segurança MCP. A questão é se elas abordam os problemas de segurança MCP na camada onde essas vulnerabilidades de segurança realmente ocorrem, ou se aplicam controles de uso geral a um problema que exige algo mais específico.

• Gateways de API legados não conseguem ler a intenção do agente. Gateways de API tradicionais foram construídos para tráfego HTTP entre serviços. Eles inspecionam cabeçalhos, impõem limites de taxa e aplicam autenticação MCP na camada de transporte. Uma tarefa de agente de IA que aciona chamadas de ferramentas para 20 ferramentas MCP diferentes gera tráfego que, no nível da rede, aparece como uma sequência de solicitações legítimas e autenticadas. Não há nada no envelope HTTP que revele se essas solicitações foram impulsionadas por uma ação do usuário ou por uma instrução injetada e oculta em um documento que o agente leu três etapas antes. Gateways que não conseguem analisar a semântica do protocolo MCP não podem detectar ou impedir vetores de ataque na camada semântica contra aplicações de IA.

• Plataformas SaaS gerenciadas direcionam seus dados através de infraestrutura que você não controla. Plataformas de IA hospedadas na nuvem resolvem o problema de implantação, mas criam um problema de residência de dados. Quando as solicitações de descoberta de ferramentas de um agente de IA e as interações MCP são roteadas através de uma nuvem de terceiros, informações sensíveis deixam o limite da sua rede a cada interação. Para organizações com obrigações de residência de dados HIPAA, GDPR ou de serviços financeiros, isso cria Conformidade de IA exposição que existe independentemente de a postura de segurança do próprio fornecedor SaaS ser adequada. Você não pode satisfazer um requisito de residência de dados confiando na infraestrutura de outra pessoa. Esta é uma preocupação de segurança aguda para equipes que executam servidores MCP remotos com acesso a dados do usuário.

• Configurações open-source DIY (faça você mesmo) falham em escala. Construir um proxy personalizado a partir de componentes de código aberto evita taxas de fornecedores e dá às equipes de engenharia controle máximo, mas cria obrigações de manutenção que crescem mais rápido do que as equipes que as gerenciam. O registro de ferramentas através de arquivos YAML ou JSON estáticos significa que cada nova integração requer uma edição manual, uma revisão de código e uma implantação. Políticas RBAC escritas em arquivos de configuração não podem ser alteradas em tempo real. O registro de auditoria requer instrumentação personalizada para cada servidor. Quando você está gerenciando um punhado de agentes, isso é gerenciável. Quando você está gerenciando dezenas, torna-se um problema de engenharia de plataforma em tempo integral.

Legacy Gateways Cannot Read Agent Intent, Your MCP Security Layer Must

Get semantic-aware governance, credential vaulting, and SOC 2 audit trails built in with TrueFoundry.

Book Demo

Protegendo Fluxos de Trabalho de Agentes com TrueFoundry

O Gateway MCP da TrueFoundry é construído com base na premissa de que os controles que as empresas precisam para executar o MCP com segurança em produção não podem ser simplesmente acoplados à infraestrutura existente. Eles precisam fazer parte da infraestrutura.

O gateway é implantado inteiramente dentro do ambiente AWS, GCP ou Azure do cliente. Cada solicitação de ferramenta, cada chamada de descoberta, cada par de prompt-resposta permanece dentro do limite da rede da organização. Não há camada de roteamento SaaS ou infraestrutura de terceiros no caminho dos dados. Nenhuma dependência externa que crie risco de saída de dados. Isso importa não apenas para a conformidade, mas para o modelo de ameaça: dados que nunca saem do seu ambiente não podem ser interceptados em trânsito.

• Injeção de identidade OAuth 2.0 com fluxos On-Behalf-Of: Os agentes atuam sob as permissões exatas do usuário solicitante, herdadas através do provedor de identidade existente da organização. Okta, Azure AD e configurações de SSO personalizadas são suportados de imediato. Não há contas de serviço compartilhadas. Cada chamada de ferramenta é atribuída a uma identidade humana específica, produzindo uma cadeia de responsabilidade que resiste a qualquer revisão de conformidade.

• RBAC em nível de ferramenta aplicado na camada do gateway: As políticas de acesso são aplicadas antes que as solicitações cheguem a qualquer modelo ou ferramenta. O registro expõe apenas as ferramentas que cada função ou equipe está autorizada a usar, e não a superfície completa de cada servidor conectado. Um agente de suporte vê ferramentas de consulta de CRM. Ele não vê comandos de administração de banco de dados. A distinção é imposta no nível da plataforma, e não por convenção do desenvolvedor.

• Abstração de Servidor MCP Virtual para proteção da cadeia de suprimentos: As implementações de ferramentas de backend ficam atrás de uma camada de abstração virtual no registro. Quando a implementação subjacente de uma ferramenta muda, ou quando uma ferramenta comprometida precisa ser substituída, a alteração ocorre no registro sem afetar nenhum dos agentes que dependem dela. Isso também isola os agentes de ataques de "rug pull": as definições das ferramentas são controladas por versão através do registro, e as alterações nos metadados das ferramentas são rastreadas e auditáveis.

• Fluxos de aprovação com intervenção humana para operações de alto risco: As ferramentas podem ser anotadas com classificações de risco. Operações marcadas como destrutivas ou irreversíveis exigem autorização humana explícita antes da execução. Isso é configurável por ferramenta e por função, para que as equipes possam exigir aprovação para exclusões de banco de dados, permitindo que as leituras prossigam sem interrupção.

• Logs de auditoria estruturados retidos dentro do seu próprio ambiente: Cada solicitação é registrada com metadados completos: identidade do usuário, identidade do agente, modelo, ferramenta, argumentos, resposta, políticas aplicadas, latência e custo. Os logs são retidos na própria infraestrutura do cliente e podem ser exportados em formato JSON estruturado para integração com Grafana, Splunk, Datadog ou qualquer pipeline de observabilidade existente. A Innovaccer, processando aproximadamente 17 milhões de solicitações de inferência de IA por mês sob HIPAA no AWS GovCloud, usa a telemetria estruturada da TrueFoundry através do OpenTelemetry e a visualiza no Grafana, sem que nenhum dado sensível saia de seu limite de nuvem.

Quer experimentar o AI Gateway da TrueFoundry? Agende uma demonstração hoje!

Conclusão: Tornando o MCP Seguro para Produção

O MCP resolveu o problema de integração. Não resolveu o problema de governança. As dezenas de milhares de servidores MCP implantados em ambientes corporativos em 2025 criaram uma enorme quantidade de novas capacidades e uma expansão igualmente significativa da superfície de ataque que a maioria das organizações não estava equipada para governar.

Os incidentes que já ocorreram, incluindo Supabase, Asana, Atlassian, o CVE mcp-remote, não foram causados por engenharia deficiente. Foram causados por uma arquitetura que não considerava os requisitos de segurança de ambientes de produção corporativos. O protocolo base não foi construído com esses requisitos em mente.

Abordar os riscos de segurança do MCP de uma forma que realmente funcione em produção significa impor controles na camada de infraestrutura: execução com reconhecimento de identidade, controle de acesso em nível de ferramenta, gerenciamento centralizado de credenciais, aprovação humana para operações destrutivas e logs de auditoria estruturados retidos em seu próprio ambiente. Estes não são recursos opcionais para indústrias regulamentadas. São os requisitos básicos para a execução de agentes de IA que interagem com sistemas críticos de negócios.

TrueFoundry implanta todos esses controles dentro da sua própria nuvem. Seus dados permanecem onde sua governança se aplica. Seus logs de auditoria são seus para produzir, consultar e exportar conforme sua programação.