A segurança em servidores MCP passou a ser uma preocupação importante à medida que empresas conectam agentes de inteligência artificial a bancos de dados, APIs, repositórios de código e serviços em nuvem. O ganho de produtividade é evidente, mas também aumenta a quantidade de sistemas que um agente pode consultar ou controlar.
O Model Context Protocol (MCP) funciona como uma camada padronizada para conectar aplicações de IA a dados, ferramentas e fluxos de trabalho externos. Isso transforma o agente em algo muito mais poderoso do que um simples chatbot, mas também cria novos caminhos para vazamento de credenciais, execução indevida de comandos e acesso não autorizado a informações corporativas.
Neste cenário, proteger apenas o modelo de IA não é suficiente. É necessário proteger toda a cadeia formada por cliente MCP, servidor MCP, identidade utilizada pelo agente, ferramentas conectadas e sistemas de destino. A seguir, veja os cinco principais caminhos pelos quais segredos podem ser expostos e quais controles devem fazer parte de uma arquitetura segura.
O que é o Model Context Protocol e como ele funciona
Criado originalmente pela Anthropic e apresentado como um padrão aberto em novembro de 2024, o Model Context Protocol foi projetado para simplificar a conexão entre aplicações de IA e sistemas externos. Em vez de cada aplicação precisar desenvolver uma integração diferente para cada serviço, o MCP estabelece uma interface padronizada.
A arquitetura utiliza uma relação entre host, cliente e servidor. O host coordena a aplicação de IA, enquanto os clientes estabelecem conexões individuais com servidores MCP. Esses servidores podem disponibilizar recursos, prompts e ferramentas, permitindo que o agente consulte informações ou execute determinadas operações.
Na prática, um servidor MCP pode funcionar como uma ponte entre o agente e um banco de dados corporativo. Outro pode fornecer acesso ao Git, a sistemas de observabilidade, armazenamento em nuvem ou plataformas de desenvolvimento.
Os tools são especialmente importantes para a segurança. Eles permitem que modelos invoquem funções capazes de consultar bancos de dados, chamar APIs ou executar outras operações. A própria especificação atual recomenda mecanismos de confirmação humana para ações sensíveis.
As identidades não humanas na era da inteligência artificial
Esse novo modelo também muda a maneira como as empresas precisam pensar sobre identidades.
Tradicionalmente, uma aplicação utilizava uma conta de serviço ou uma chave de API para acessar determinado recurso. Com agentes de IA, essas credenciais passam a ser utilizadas por sistemas capazes de interpretar linguagem natural, tomar decisões intermediárias e encadear múltiplas ações.
São as chamadas Identidades Não Humanas (NHIs). Elas incluem chaves de API, tokens OAuth, contas de serviço, certificados e credenciais de aplicações.
O problema surge quando uma única identidade recebe permissões muito amplas. Se um agente puder consultar o banco financeiro, acessar documentos internos e enviar informações para serviços externos usando a mesma credencial, o comprometimento de apenas uma integração poderá transformar um incidente localizado em uma violação muito maior.
Como a segurança em servidores MCP pode ser comprometida
A exposição de segredos não depende necessariamente de uma falha no protocolo. Muitas vezes, o problema está na forma como o servidor é implantado, configurado e autorizado.
Um servidor MCP que possui acesso legítimo a informações sensíveis já representa um ativo crítico. Se suas credenciais forem armazenadas incorretamente ou suas ferramentas receberem permissões excessivas, o agente conectado poderá se tornar um caminho para atingir sistemas que antes estavam isolados.
Credenciais em texto simples e a proliferação não governada
Um dos erros mais básicos continua sendo um dos mais perigosos: armazenar segredos diretamente em arquivos de configuração, scripts ou variáveis expostas.
Em ambientes MCP locais, uma configuração pode conter tokens necessários para autenticar uma integração. Quando esses arquivos são copiados para notebooks, máquinas de desenvolvedores, backups ou repositórios Git, a quantidade de pontos onde a credencial existe aumenta rapidamente.
O problema também aparece quando equipes diferentes criam servidores MCP sem uma política centralizada. Cada projeto pode adotar seu próprio método de armazenamento, criando uma verdadeira proliferação não governada de segredos.
Mesmo quando uma chave não está publicamente disponível, ela pode permanecer esquecida durante meses em um repositório privado ou em uma máquina que já não deveria ter acesso ao sistema.
A resposta não é simplesmente criptografar arquivos de configuração. O ideal é eliminar a necessidade de manter credenciais estáticas nesses locais e utilizar mecanismos centralizados capazes de controlar acesso, expiração e revogação.
Injeção de prompt e permissões excessivas
Outro risco surge quando o agente consegue interpretar conteúdo externo como se fossem instruções confiáveis.
A injeção de prompt ocorre quando dados controlados por um atacante conseguem alterar o comportamento esperado do modelo. Isso pode acontecer diretamente por meio de uma entrada maliciosa ou indiretamente através de páginas, documentos, e-mails e outros conteúdos processados pelo agente. A OWASP classifica Prompt Injection como LLM01:2025 e destaca consequências como divulgação de informações, acesso não autorizado e execução de comandos em sistemas conectados.
Imagine um agente conectado a um servidor MCP capaz de consultar um banco interno e enviar mensagens. Um documento aparentemente legítimo pode conter instruções maliciosas direcionadas ao modelo. Se o agente interpretar essas instruções como comandos válidos e possuir permissões excessivas, o ataque poderá sair do ambiente de IA e atingir sistemas reais.
É justamente por isso que injeção de prompt e controle de privilégios precisam ser tratados conjuntamente. Uma defesa baseada apenas em instruções no prompt não é suficiente.
O perigo dos servidores não confiáveis e vulnerabilidades na cadeia de suprimentos
A facilidade para criar e compartilhar servidores MCP também cria um problema de cadeia de suprimentos.
Instalar um servidor de terceiros significa confiar no código responsável por intermediar o acesso do agente a recursos corporativos. Uma vulnerabilidade nesse componente pode permitir que uma entrada controlada externamente alcance funções privilegiadas.
Um exemplo importante é a CVE-2025-6514, relacionada ao pacote mcp-remote. Segundo o NVD, versões afetadas podiam sofrer injeção de comandos no sistema operacional ao conectar-se a servidores MCP não confiáveis, devido ao processamento de uma URL de autorização manipulada. A vulnerabilidade recebeu avaliação crítica de 9,6 pela JFrog e afetava versões até 0.1.15.
O caso demonstra por que a segurança de servidores MCP não deve terminar na configuração do modelo. Dependências, pacotes, servidores externos e componentes de conexão também precisam entrar no inventário de segurança da organização.
Boas práticas para proteger servidores MCP
A melhor estratégia é assumir que agentes de IA podem cometer erros e que conteúdos externos podem ser manipulados. A arquitetura precisa limitar o impacto quando isso acontecer.
Centralização de segredos e uso de credenciais efêmeras
Empresas devem evitar espalhar chaves estáticas pelos servidores MCP. Em seu lugar, o acesso deve passar por uma solução especializada de gestão de segredos.
Ferramentas como o HashiCorp Vault permitem centralizar credenciais, controlar acesso e administrar diferentes tipos de segredos. O Vault também oferece mecanismos para geração dinâmica de credenciais, reduzindo a dependência de chaves permanentes.
Sempre que possível, prefira credenciais efêmeras, com escopo limitado e tempo de vida curto. Se um token for roubado, sua janela de utilização será menor.
A rotação automática também deve fazer parte da estratégia. Segredos que nunca expiram transformam pequenos incidentes em comprometimentos persistentes.
Princípio do menor privilégio, human-in-the-loop e criptografia zero-trust
O princípio do menor privilégio deve determinar exatamente o que cada servidor MCP e cada identidade não humana podem fazer.
Um agente responsável por consultar métricas não precisa de permissão para excluir máquinas. Um servidor que consulta um banco não deveria automaticamente possuir autorização para alterar registros.
As permissões também devem ser divididas por função. Em vez de entregar acesso administrativo completo, disponibilize ferramentas específicas com operações limitadas.
O segundo controle é o human-in-the-loop. Ações destrutivas ou de alto impacto, como excluir dados, alterar infraestrutura, publicar código ou transferir informações sensíveis, devem exigir aprovação humana.
A própria especificação do MCP recomenda que aplicações forneçam ao usuário capacidade de negar chamadas de ferramentas e apresentem confirmações para operações relevantes.
Por fim, a arquitetura deve adotar uma abordagem zero-trust: nenhuma conexão deve ser considerada confiável simplesmente porque está dentro da rede corporativa.
Isso significa autenticação forte, autorização granular, criptografia durante o transporte, segmentação de rede, registro das chamadas e monitoramento contínuo.
Também é importante validar entradas e saídas. Servidores MCP devem verificar parâmetros recebidos, restringir recursos sensíveis e evitar retornar mais informações do que o necessário. A própria especificação estabelece considerações de segurança para recursos, incluindo validação de URIs e controles de acesso.
Monitore chamadas e trate servidores MCP como ativos críticos
Logs devem registrar quem iniciou a ação, qual agente participou, qual servidor MCP foi utilizado, qual ferramenta foi chamada, quais permissões estavam disponíveis e qual foi o resultado.
Esse nível de observabilidade permite identificar padrões anormais, como um agente realizando centenas de consultas em poucos minutos ou acessando recursos que normalmente não utiliza.
Também é recomendável manter um inventário de todos os servidores MCP, suas versões, dependências, proprietários e sistemas acessíveis.
Antes de colocar um novo servidor em produção, faça análise de código, verificação de dependências, testes de segurança e avaliação das permissões solicitadas.
O futuro da gestão de segredos na era dos agentes autônomos
O MCP não é, por si só, uma vulnerabilidade. Seu valor está justamente em fornecer uma maneira padronizada de conectar agentes a ferramentas e informações. O risco aparece quando essa capacidade é implantada sem os mesmos controles aplicados a sistemas críticos tradicionais.
À medida que agentes autônomos ganham acesso a mais sistemas corporativos, identidade, autorização e gestão de segredos deixam de ser detalhes de infraestrutura e passam a fazer parte da própria arquitetura de inteligência artificial.
A empresa que adota MCP precisa pensar além do chatbot. Um agente com acesso a APIs, bancos de dados, Git e infraestrutura possui capacidade operacional real. Portanto, cada servidor MCP deve ser tratado como um componente crítico de produção, com inventário, controle de acesso, atualizações, auditoria e resposta a incidentes.
