Os agentes de IA estão saindo dos experimentos para fluxos de trabalho em produção, e o Model Context Protocol (MCP) está se tornando a camada de conexão que permite que esses agentes acessem dados corporativos, aplicações, APIs, repositórios e ferramentas de automação. Isso torna o MCP poderoso, mas também crítico para a segurança. À medida que as organizações adotam a IA agentica, elas precisam entender não apenas como o MCP melhora a conectividade, mas também como ele cria novos desafios de visibilidade, governança e superfície de ataque.
O que é o MCP e por que ele é importante para a IA corporativa?
O Model Context Protocol é um padrão aberto que oferece aos sistemas de IA uma maneira consistente de descobrir e interagir com ferramentas externas, fontes de dados e sistemas de negócios. Uma forma concisa de defini-lo é: o MCP é um plano de controle padronizado para conectar agentes de IA ao contexto e às ações corporativas.
Isso é importante porque a IA corporativa só se torna útil quando consegue alcançar os sistemas onde o trabalho acontece. Um agente de suporte pode precisar consultar uma plataforma de chamados. Um assistente de codificação pode precisar inspecionar um repositório de código-fonte. Um assistente financeiro pode precisar recuperar registros de banco de dados. Um agente de operações pode precisar invocar uma API interna ou iniciar um fluxo de trabalho.
O MCP funciona como uma camada de abstração um-para-muitos. Em vez de criar integrações separadas para cada aplicação e sistema de IA, as organizações podem expor ferramentas, recursos e prompts por meio de servidores MCP. Os clientes de IA podem então chamar APIs, consultar bancos de dados, ler arquivos, recuperar contexto e acionar fluxos de trabalho por meio de um protocolo compartilhado.
A adoção foi rápida. A Anthropic introduziu o MCP em novembro de 2024 como um padrão aberto para conectar assistentes de IA aos sistemas onde os dados residem. Em 2025, OpenAI, Microsoft e Google já haviam anunciado ou documentado suporte ao MCP em seus produtos e serviços.
Em dezembro de 2025, a Anthropic doou o MCP para a Agentic AI Foundation, um fundo dirigido pela Linux Foundation e cofundado pela Anthropic, Block e OpenAI, com o apoio de Google, Microsoft, AWS, Cloudflare, Bloomberg e outros. O MCP é agora amplamente tratado como o padrão emergente para a conectividade de IA agentica.
Como a arquitetura do MCP cria exposição de segurança
O MCP utiliza uma arquitetura cliente-servidor. Uma aplicação de IA atua como host e executa um ou mais clientes MCP. Esses clientes se conectam a servidores MCP, que expõem ferramentas, recursos e prompts. Um servidor pode fornecer acesso a um repositório Git, um banco de dados, uma aplicação SaaS, uma conta em nuvem ou uma API interna.
Isso se assemelha a um modelo de API tradicional, mas o MCP altera o padrão de interação. Os servidores MCP não retornam apenas dados estáticos. Eles descrevem as ferramentas disponíveis para os sistemas de IA, influenciam o contexto do agente e executam ações em nome dos clientes conectados. Em fluxos de trabalho agenticos, o modelo pode decidir quando e como invocar essas ferramentas com base em instruções e contexto.
Isso cria caminhos de ataque que diferem dos riscos de APIs tradicionais. Um usuário dá uma instrução, um agente de IA a interpreta, um cliente MCP seleciona uma ferramenta, um servidor MCP executa uma ação e os sistemas downstream respondem. Cada transferência pode introduzir uma lacuna de política, validação ou visibilidade.
Os servidores MCP também são, frequentemente, intermediários privilegiados. Um único servidor pode ficar entre um agente de IA e gerenciadores de código-fonte, bancos de dados, serviços em nuvem, APIs internas, sistemas de arquivos ou ferramentas de observabilidade. Se esse servidor tiver permissões excessivas ou for mal protegido, ele se torna um alvo de alto valor.
O protocolo foi projetado para ser flexível, e essa flexibilidade ajudou na adoção. Mas isso também significa que muitos controles ficam a cargo de quem implementa. Autenticação, autorização, validação de entrada, aprovação de ferramentas, gerenciamento de sessão, registro de logs e aplicação de políticas não são impostos uniformemente no nível do protocolo. Portanto, dois servidores MCP que realizam funções semelhantes podem ter posturas de segurança completamente diferentes.
Principais riscos de segurança do MCP que as organizações enfrentam hoje
O risco de segurança do MCP abrange identidade, autorização, integridade de prompts, gerenciamento de sessão, gestão de contexto e exposição da cadeia de suprimentos de software. Quatro áreas merecem atenção imediata.
A primeira é o controle de acesso. O MCP não exige autenticação ou controle de acesso baseado em funções no nível do protocolo. Implantações robustas podem adicionar esses controles, mas implementações iniciais podem depender de suposições de confiança local, credenciais compartilhadas ou acesso excessivamente permissivo a ferramentas. Se um servidor MCP puder ler repositórios, consultar bancos de dados ou chamar APIs internas, um controle de acesso fraco na camada MCP pode se tornar um controle de acesso fraco em todo sistema conectado.
A segunda é o envenenamento de ferramentas e injeção de prompt. Em um ataque de envenenamento de ferramenta, um servidor MCP mal-intencionado ou comprometido insere instruções ocultas em descrições de ferramentas, metadados, prompts ou saídas. Um agente de IA pode tratar essas instruções como contexto legítimo e realizar ações não intencionais, como vazar dados, ignorar instruções de segurança ou passar segredos para outra ferramenta. A injeção de prompt cria um risco relacionado quando agentes processam conteúdo não confiável de tickets, documentos, repositórios, páginas da web ou saídas de ferramentas.
O terceiro é a fragilidade de tokens e sessões. Muitas implementações de MCP dependem de tokens de portador (bearer tokens), permissões delegadas, fluxos OAuth ou padrões de passagem de token. Tokens de longa duração, escopos amplos, revogação deficiente e gerenciamento fraco do ciclo de vida da sessão podem permitir que invasores se movam da camada MCP para sistemas downstream. O MCP também cria oportunidades para ataques de "deputado confuso" (confused deputy), onde um componente confiável é enganado para usar sua autoridade de uma forma que o usuário não pretendia.
O quarto é a serialização de contexto insegura. O MCP troca objetos estruturados via JSON-RPC com frequência. Sem uma aplicação rigorosa de esquema e isolamento, riscos de payloads malformados, desserialização insegura, path traversal, injeção e execução de comandos podem atingir ferramentas privilegiadas ou ambientes de execução.
O Problema de Descoberta e Inventário de Servidores MCP
Servidores MCP estão se tornando uma nova forma de shadow IT. Eles são fáceis de implantar pelos desenvolvedores, frequentemente criados com frameworks de código aberto e podem ser executados em estações de trabalho, contêineres, sistemas de CI/CD ou ambientes de nuvem. Um desenvolvedor pode conectar rapidamente um assistente de IA a arquivos, repositórios, credenciais, logs, bancos de dados ou APIs internas sem criar um processo formal de revisão de segurança.
Isso cria um problema de visibilidade. Sem descoberta contínua de servidores MCP, as equipes de segurança não conseguem responder a perguntas básicas como: Quais servidores existem? Onde eles estão sendo executados? Quem é o proprietário? Quais ferramentas eles expõem? Quais agentes os utilizam? A quais dados eles podem acessar? Eles estão autenticados? Eles são sancionados? As permissões foram alteradas?
Uma auditoria única não será suficiente. Ambientes MCP mudam à medida que os desenvolvedores testam frameworks, adicionam ferramentas, atualizam credenciais ou expandem permissões. As equipes de segurança precisam de um inventário em tempo real que capture localização, proprietário, exposição de ferramentas, status de autenticação, escopo de acesso, comportamento em tempo de execução e status de sanção em endpoints e ambientes de nuvem.
Isso deve parecer familiar para equipes que lidaram com APIs "shadow": endpoints desconhecidos, propriedade pouco clara, exposição de dados não documentada e controles inconsistentes. Servidores MCP criam um desafio semelhante, mas com uma complicação adicional. Eles não expõem apenas dados a aplicativos. Eles expõem capacidades a agentes de IA que podem raciocinar, escolher ferramentas e iniciar ações.
Incidentes Reais de Segurança em MCP que Ilustram o Risco
O MCP ainda é relativamente novo, mas pesquisas documentadas já mostram por que as equipes de segurança precisam de controles antes de uma implantação ampla.
Pesquisadores demonstraram ataques de injeção de parâmetros de ferramentas contra agentes MCP de código aberto, mostrando como entradas não higienizadas podem expor dados confidenciais do servidor ou influenciar a execução da ferramenta. Esses casos destacam dois modos de falha comuns: as entradas são consideradas confiáveis cedo demais e o registro (logging) é insuficiente para reconstruir o que aconteceu após o fato.
Cenários de MCP relacionados ao GitHub também mostraram o perigo de permissões excessivas em repositórios. Em uma classe de ataques, uma ferramenta conectada ao MCP com amplo acesso ao repositório poderia ler conteúdo de um repositório privado e gravá-lo em um repositório público sem que o usuário compreendesse totalmente o caminho da ação. O problema é a fronteira tênue entre a intenção do usuário, as permissões da ferramenta e as ações da API downstream.
A vulnerabilidade no Anthropic MCP Inspector ofereceu outro alerta. O MCP Inspector é uma ferramenta de desenvolvedor para testar e depurar servidores MCP. Em 2025, pesquisadores relataram a CVE-2025-49596, uma vulnerabilidade crítica de execução remota de código envolvendo ataques baseados em navegador contra ambientes locais de desenvolvedores. Relatórios descreveram como um site malicioso poderia acionar comandos em uma máquina de desenvolvedor sob certas condições, levando a um patch na versão 0.14.1. A lição para as empresas é direta: até mesmo ferramentas MCP fornecidas por fornecedores exigem revisão de segurança, gerenciamento de versão e uso controlado.
Melhores Práticas de Segurança MCP para Implantação Corporativa
As organizações devem tratar o MCP como infraestrutura de conectividade de produção, não como uma conveniência para o desenvolvedor. O primeiro requisito é autenticação e autorização para cada interação MCP. Servidores MCP não autenticados não devem ter acesso a ferramentas, dados ou fluxos de trabalho confidenciais. Onde o OAuth for usado, siga as diretrizes do OAuth 2.1, aplique consentimento explícito por cliente, restrinja escopos, vincule tokens aos públicos pretendidos e evite a passagem desnecessária de tokens.
O princípio do privilégio mínimo deve ser aplicado em todas as camadas: usuário, agente, cliente, servidor, ferramenta e sistema downstream. Um servidor criado para ler documentação não deve ter acesso de escrita a repositórios de código-fonte. Um servidor usado para análise de dados não deve ser capaz de modificar a infraestrutura em nuvem. As permissões das ferramentas devem ser revisadas sempre que servidores forem atualizados ou novas funcionalidades forem adicionadas.
Utilize sandboxes para servidores MCP a fim de reduzir o impacto de path traversal, injeção de comandos, execução arbitrária de código, escalonamento de privilégios e esgotamento de recursos. Limites de sistema de arquivos, isolamento de contêineres, restrições de tempo de execução e controles de saída de rede podem reduzir o raio de alcance de possíveis incidentes.
A validação rigorosa do esquema JSON-RPC deve ser aplicada antes que as solicitações cheguem aos ambientes de execução. Os parâmetros das ferramentas devem ser higienizados, as saídas devem ser tratadas como não confiáveis e a desserialização deve ocorrer apenas em contextos controlados.
Logs de auditoria abrangentes também são essenciais. As equipes de segurança precisam de uma sequência rastreável de atividades entre as sessões, incluindo quem iniciou a solicitação, quais agentes e clientes estavam envolvidos, qual servidor recebeu a chamada, qual ferramenta foi invocada, qual decisão de autorização foi tomada, qual sistema downstream foi acessado e se ocorreu alguma violação de RBAC. Logs úteis devem incluir dados relevantes de cabeçalho HTTP, eventos de autorização, registros de execução de ferramentas, identificadores de sessão e resultados anômalos.
Por fim, avalie servidores MCP de terceiros antes do uso em produção. Servidores da comunidade devem ser avaliados como pacotes de terceiros, imagens de contêiner ou dependências de código aberto. Revise o código-fonte sempre que possível, verifique a existência de comportamento malicioso, entenda as permissões necessárias, valide o comportamento de autenticação e teste em um ambiente que não seja de produção antes de conectá-los a sistemas sensíveis.
Construindo um Programa de Governança MCP do Zero
A segurança do MCP não pode depender da disciplina individual dos desenvolvedores. As empresas precisam de uma governança que torne a adoção segura o padrão.
Comece com descoberta. As equipes de segurança precisam de um inventário completo de servidores MCP em endpoints, estações de trabalho de desenvolvedores, instâncias em nuvem, contêineres, sistemas de CI/CD e infraestrutura de produção. Uma vez descobertos, classifique cada servidor por risco com base na sensibilidade dos dados, ferramentas expostas, postura de autenticação, escopo de acesso, exposição externa, criticidade para o negócio e status de aprovação.
Os controles devem ser aplicados de acordo com o risco. Servidores experimentais de baixo risco podem precisar apenas de proteções básicas e políticas de expiração. Servidores de alto risco podem exigir autenticação forte, autorização rigorosa, sandboxing, fluxos de aprovação, monitoramento contínuo e gestão formal de mudanças.
O monitoramento contínuo mantém o programa atualizado. O monitoramento deve detectar novos servidores MCP quase em tempo real, distinguir implantações aprovadas de não aprovadas, identificar mudanças na exposição de ferramentas e sinalizar comportamentos que sugiram uso indevido ou comprometimento.
A governança de MCP também deve se conectar aos programas de segurança corporativa existentes. As equipes de IAM precisam entender como usuários, agentes, clientes e servidores são autorizados. As equipes de EDR devem visualizar as ferramentas MCP nos endpoints. As equipes de segurança em nuvem devem rastrear servidores MCP em ambientes de nuvem. As equipes de segurança de API devem monitorar as APIs downstream que os agentes chamam via MCP. As equipes de SIEM e resposta a incidentes precisam de telemetria suficiente para reconstruir a atividade conduzida por agentes.
É aqui que a segurança do MCP se conecta diretamente à segurança de APIs. Agentes de IA geram impacto nos negócios ao chamar ferramentas, APIs, bancos de dados e fluxos de trabalho. O MCP atua no meio desse caminho. Protegê-lo exige visibilidade tanto na camada MCP quanto nas APIs e sistemas que ele alcança.
A Segurança do MCP Começa com Visibilidade
Toda grande mudança tecnológica cria uma nova infraestrutura que as equipes de segurança eventualmente precisam governar. Na adoção da nuvem, foram as contas de nuvem não gerenciadas. Nas APIs, foram as APIs sombra. Para agentes de IA, os servidores MCP estão rapidamente se tornando o próximo desafio de visibilidade.
O risco não é o MCP em si. O protocolo resolve um problema real ao fornecer aos sistemas de IA uma maneira padronizada de interagir com aplicativos corporativos, fontes de dados e fluxos de trabalho. O desafio é que as organizações estão implantando servidores MCP muito mais rápido do que estabelecendo controles ao redor deles.
As equipes de segurança não podem proteger o que não conseguem ver. Antes de avaliar modelos de autenticação, revisar permissões ou detectar tentativas de envenenamento de ferramentas, elas precisam saber quais servidores MCP existem, quais sistemas esses servidores podem acessar e quais agentes de IA os estão utilizando.
À medida que os agentes de IA se integram aos processos de negócio, os servidores MCP passarão a se assemelhar cada vez mais às APIs: uma infraestrutura de conectividade crítica que exige descoberta, monitoramento e governança contínuos. As organizações que estabelecerem visibilidade agora estarão em uma posição muito mais forte do que aquelas que tentarem proteger um ecossistema MCP cuja existência desconheciam. Obtenha uma Avaliação de Superfície para encontrar todos os servidores MCP em sua infraestrutura de IA.
Perguntas frequentes sobre segurança em MCP
O que torna a segurança em MCP diferente da segurança de API padrão?
A segurança de API tradicional foca em interações previsíveis entre cliente e servidor. O MCP adiciona uma camada de decisão de IA, descoberta dinâmica de ferramentas, autoridade delegada e contexto que pode influenciar o comportamento do agente. Isso introduz riscos como envenenamento de ferramentas, injeção de prompt, ataques de "confused deputy" e ações não intencionais do agente.
Como encontro todos os servidores MCP em execução na minha organização?
Utilize a descoberta contínua em endpoints, ambientes de nuvem, estações de trabalho de desenvolvedores, containers, sistemas de CI/CD e infraestrutura de produção. O inventário deve registrar localização, proprietário, ferramentas expostas, status de autenticação, sistemas conectados, escopo de acesso e status de aprovação.
O que é envenenamento de ferramentas no MCP e como ele funciona?
O envenenamento de ferramentas ocorre quando um servidor MCP malicioso ou comprometido oculta instruções em descrições de ferramentas, metadados, prompts ou saídas. Um agente de IA pode tratar essas instruções como contexto legítimo e realizar ações não intencionais.
O MCP exige autenticação por padrão?
Não. O MCP não exige autenticação ou RBAC no nível do protocolo. As organizações precisam implementar controles de identidade, autorização, consentimento, tokens e políticas para qualquer servidor MCP conectado a dados ou ações sensíveis.
O que é o ataque de "confused deputy" no MCP e como posso evitá-lo?
Um ataque de "confused deputy" acontece quando um componente MCP confiável usa sua autoridade de uma forma que o usuário não pretendia. Previna-o com consentimento explícito, escopos OAuth restritos, tokens vinculados ao público, verificações de autorização por ferramenta e decisões de política que considerem o usuário, o agente, o cliente, o servidor, a ferramenta e a ação solicitada.
Como devo avaliar um servidor MCP de terceiros antes de usá-lo em produção?
Avalie-o como faria com um pacote de terceiros, uma imagem de container ou uma dependência de código aberto. Revise o código-fonte sempre que possível, verifique a existência de código malicioso, entenda as permissões necessárias, valide o comportamento de autenticação, teste em um ambiente que não seja de produção e monitore o comportamento antes de conectá-lo a sistemas sensíveis.