Quando o servidor MCP guarda suas credenciais: o vetor de ataque silencioso da IA em produção

A incorporação de agentes de IA em processos empresariais abriu uma via prática para que sistemas e dados em produção sejam acessíveis a partir dos modelos: chama-se Model Context Protocol (MCP) e, segundo sua especificação original, foi promovido por Anthropic para que assistentes e agentes possam chamar a ferramentas e dados ao vivo. O que começou a ser notado em auditorias e relatórios técnicos é que o servidor MCP —se intermediário que liga o agente com APIs, arquivos e bases de dados — geralmente se tornar o depósito das credenciais necessárias para agir. Quando essas credenciais estão mal protegidas, a capacidade de um atacante para ler dados se transforma em capacidade para agir em nome do agente.

Tecnicamente, um servidor MCP expõe um conjunto de ações que o agente pode invocar e, para executar essas ações, necessita de credenciais: chaves de serviço, tokens OAuth, variáveis de ambiente com segredos ou cadeias de configuração. Em muitas implementações práticas, essas credenciais acabam em arquivos de configuração locais ou em variáveis de ambiente em texto plano; em outras, são replicadas entre ambientes (desenvolvimento, staging, produção) porque não existe um armazém centralizado ou processos de rotação automática. Além disso, o agente opera com identidades não humanas (NHIs) que permitem não apenas ler, mas modificar e executar mudanças. Por isso, roubar um token do servidor MCP não é simplesmente filtrar dados: é obter uma chave com a qual realizar operações nos sistemas que o agente tinha acesso para gerenciar.

Os vetores de exposição confirmados por múltiplas análises e incidentes públicos incluem, entre outros: arquivos de configuração em texto plano ou variáveis de ambiente contendo tokens; proliferação e duplicação de credenciais sem rotação; prompt injection, onde conteúdo malicioso em um documento ou em uma web induz o agente a expor segredos ou executar ações indevidas; licenças excessivas atribuídas por conforto durante o desenvolvimento que depois chegam à produção; e riscos de cadeia de fornecimento ao conectar servidores MCP não confiáveis. Um exemplo público citado em relatórios técnicos é a vulnerabilidade atribuída como CVE-2025-6514 em mcp-remote - um proxy OAuth utilizado em clientes e com mais de 400.000 downloads - onde um servidor malicioso pode desencadear injeção de comandos do sistema operacional e execução remota de código, permitindo assim o roubo de credenciais na máquina cliente. Para mais informações técnicas sobre MCP e seu desenho, você pode consultar o repositório público da especificação no GitHub: https://github.com/anthropic/mcp, e o registo público da vulnerabilidade no MITRE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-6514.

Quem está em risco é uma pergunta prática: qualquer organização que integre agentes de IA com acesso a sistemas internos e que dependa de servidores MCP para delegar ações está potencialmente afetada. Isso inclui equipamentos de desenvolvimento que exibem agentes em pipelines, equipamentos de suporte que usam assistentes para operar sobre tickets e dados, e arquiteturas cloud que expõem APIs que os agentes devem invocar. Também estão em risco os supply chains que confiam em componentes de terceiros (por exemplo, proxies ou utilitários como mcp-remote) sem controles de integridade e atualização.

As consequências reais que podem ser derivadas são variadas e de gravidade prática: desde vazamento de documentação interna e segredos de API até ações maliciosas realizadas com os NHIs roubados (borrado de registros, escalado de privilégios, movimento lateral em nuvem). Além disso, a natureza autónoma dos agentes faz com que o tempo entre compromisso e dano possa ser muito curto, e que a evidência de um abuso dispersível entre logs de diferentes sistemas se não houver rastreabilidade centralizada.

Devemos distinguir: os factos acima descritos são confirmados pela especificação técnica de MCP e por incidentes públicos relatados; as afirmações sobre frequência (por exemplo, que o armazenamento em texto plano é “rutinario”) são estimativas baseadas em auditorias e práticas observadas em implantaçãos rápidos de projetos de IA; e ainda há incerteza sobre o alcance agregado do problema a nível de todas as organizações que têm desenvolvido MCP internamente (não há ainda um inventário público global).

Diante desse panorama, as medidas concretas que equipes de segurança e desenvolvedores devem aplicar imediatamente são claras e aplicáveis:

1) Remover segredos em texto plano e centralizá-los em um vault gerido. Mover chaves e tokens fora de arquivos de configuração e variáveis de ambiente para um gestor de segredos com controle de acesso e registro de acesso. Se se procura uma solução comercial com funções de mascaramento e verificação por confirmação, existem ferramentas no mercado que implementam estas ideias; por exemplo, o Keeper Secrets Manager oferece fluxos de uso para agentes e controles de revelado com confirmação: https://www.keepersecurity.com/secrets-manager/.

2) Usar credenciais de curta duração e rotação automática. Evitar chaves estáticas. Gerar tokens efêmeros com caducidade e renovação automática reduz significativamente a janela de exposição se houver fuga.

3) Forçar o princípio de menor privilégio. Atribuir a cada agente apenas as permissões mínimas necessárias para a sua tarefa e verificar através de revisões e regras automáticas que essas permissões não sejam aumentadas por conforto de desenvolvimento. Para definições e guias de controle de acesso, convém enviar-se às guias de boas práticas de controle de acessos e lerst privilege: https://csrc.nist.gov/Glossary/term/least_privilege.

4) Manter um humano no ciclo para operações sensíveis. Acções como revelar um segredo sem mastigar, remover dados de produção ou executar alterações em infra-estruturas críticas devem exigir confirmação humana autenticada e registo da aprovação.

5) Instrumentar logging, auditoria e detecção específica para agentes. Registar cada pedido do agente, a identidade NHI utilizada e o recurso em causa; habilitar alertas de comportamento anormais (por exemplo, pedidos fora de horário ou de recursos invulgares) e conservar logs suficientes para auditoria forense.

6) Inventariar e controlar todos os servidores MCP e proxies de cliente. Atuar contra “shadow MCP”: digitalizar repositórios, máquinas de desenvolvimento e ambientes cloud para localizar instâncias, aplicar adesivos e revogar tokens se for detectado software vulnerável (por exemplo, atualizar ou retirar mcp-remote afetado por CVE-2025-6514).

7) Proteger contra prompt injection e conteúdo adverso. Filtrar, sanear e verificar a proveniência do conteúdo que os agentes processam; manter mecanismos de validação e, quando necessário, limitar o acesso dos agentes a documentos externos não confiáveis.

Em suma, MCP introduz uma camada operacional que facilita a utilidade dos agentes da IA, mas também concentra risco: o servidor MCP acaba muitas vezes como suporte de credenciais com capacidade de atuar em sistemas críticos. As defesas não são exóticas: centralizar segredos, usar credenciais efímeras, aplicar leiast privilege, adicionar revisões humanas em pontos críticos, auditar ações e manter um inventário completo são passos técnicos e organizacionais que devem ser aplicados agora para mitigar um risco que, de outro modo, pode passar despercebido até que o dano seja irreversível.