As equipes de segurança continuam me perguntando o que MCP security realmente significa. Não no sentido de "por favor, defina a sigla". No sentido de "encontramos três servidores MCP rodando nos laptops de desenvolvedores e ninguém sabe quem é responsável por eles". Essa é a pergunta real. E é uma pergunta diferente daquelas que a maioria dos guias de segurança de API foi criada para responder.
MCP security não é segurança de API com um novo nome. O protocolo cria uma relação de confiança entre agentes de IA e sistemas de produção que a maioria dos controles existentes nunca foi projetada para inspecionar. Um gateway de API padrão monitora o perímetro. O MCP entrega a um agente de IA as chaves do que está dentro e depois pede que você resolva a governança mais tarde.
Esta é a parte que as equipes aprendem tarde demais.
A superfície de ataque para a qual ninguém reservou orçamento
- O MCP cria um caminho de confiança bidirecional entre agentes de IA e sistemas internos que os gateways de API padrão não inspecionam.
- 53% dos servidores MCP usam segredos estáticos de longa duração — exatamente o padrão de credencial que facilita o comprometimento da cadeia de suprimentos.
- O sequestro no nível do registro é possível sem nenhuma vulnerabilidade no código; apenas os metadados são suficientes.
- Um LLM protegido e sistemas subjacentes protegidos ainda deixam você exposto se a camada de servidores MCP estiver sem controle.
- Vulnerabilidades clássicas se aplicam em escala: 43% de injeção de comandos e 22% de travessia de caminho nas implementações testadas.
O Que MCP Security Realmente Significa
MCP security abrange os controles, mecanismos de proteção e monitoramento aplicados a hosts, servidores e registros MCP para evitar exposição de dados, execução não autorizada de ferramentas e abusos no nível do protocolo. Essa definição parece administrável até você observar o que ela precisa cobrir na prática.
A segurança de API padrão protege uma fronteira de solicitação/resposta. Você autentica na borda, valida entradas e registra o que cruza a linha. O MCP faz algo estruturalmente diferente. Ele cria uma relação de confiança bidirecional entre um agente de IA e os sistemas aos quais ele se conecta, o que significa que o agente não apenas consulta um recurso: ele pode invocar ferramentas, ler arquivos, executar comandos e encadear essas ações em vários sistemas conectados. O agente de IA está dentro do perímetro. O servidor atua como ponte.
Essa ponte é o que a maioria dos gateways de API não foi criada para inspecionar. Eles conseguem ver que uma solicitação aconteceu. Em geral, não conseguem ver o que foi informado ao agente de IA, qual ferramenta ele decidiu chamar ou se a descrição da ferramenta na qual ele confiou foi adulterada antes disso. A superfície de ataque se estende à camada de protocolo, ao registro onde os servidores são descobertos e ao ambiente de host onde o agente é executado. Nenhuma dessas camadas existe em uma integração de API convencional.
Essa distinção importa porque equipes que tratam o MCP como "apenas mais uma integração" aplicam os controles errados, auditam os logs errados e deixam passar as falhas erradas — geralmente até que algo já tenha movido dados que não deveria.
Como o MCP Funciona e Onde Está a Fronteira de Confiança
O Model Context Protocol tem três componentes, e cada um traz um problema distinto de fronteira de confiança. Entendê-los separadamente não é algo acadêmico. É a diferença entre saber onde colocar os controles e instalá-los no lugar errado.
O host é o ambiente onde o agente de IA realmente é executado. Uma IDE como Claude Desktop ou Cursor é um host. Uma plataforma de orquestração, um executor de pipelines agênticos ou uma aplicação personalizada que incorpora um modelo de IA também são hosts. O host decide quais servidores o agente pode alcançar, gerencia como o contexto do agente é construído e, em última instância, determina o raio de impacto caso algo dê errado. Um host comprometido ou configurado incorretamente não expõe apenas uma ferramenta. Ele expõe tudo o que o agente consegue ver naquele ambiente.
O cliente é o conector no nível do protocolo. Ele gerencia a comunicação efetiva entre o host e um servidor MCP específico: inicia sessões, envia solicitações e recebe respostas de ferramentas. O cliente é o que traduz a intenção de um agente em uma chamada de rede concreta.
O servidor é o que expõe ferramentas, recursos e prompts ao agente. É o componente mais próximo dos seus sistemas reais — seus bancos de dados, repositórios de código-fonte e APIs em nuvem. Quando o agente chama uma ferramenta, o servidor a executa. Essa execução pode ler arquivos, acionar pipelines de CI/CD, executar consultas ou chamar APIs downstream, dependendo do que o servidor expõe.
O importante aqui é que esses componentes formam uma cadeia de confiança delegada. O host confia no cliente. O cliente confia no servidor. O servidor confia nas definições das ferramentas que expõe. Um invasor que consegue influenciar qualquer elo dessa cadeia pode influenciar o comportamento do agente — não atacando diretamente o LLM, mas manipulando o ambiente no qual o LLM opera.
Host MCP e Cliente MCP: O Que Cada Componente Controla
As equipes confundem esses dois o tempo todo. Já vi arquitetos de segurança definirem controles para a camada de cliente porque é nela que a atividade de rede ocorre, ignorando completamente que é no host que as permissões do agente são de fato definidas.
O host MCP controla o ambiente de execução mais amplo. Ele define a quais servidores o agente pode se conectar, gerencia a configuração local do servidor MCP e determina qual contexto o agente recebe. O host é onde o perímetro de segurança deve ser estabelecido primeiro, porque ele governa todo o espaço de ação do agente. Um host configurado incorretamente representa um raio de impacto configurado incorretamente.
O cliente MCP envia solicitações no nível do protocolo para um servidor específico. Ele é um conector, não um controlador. O cliente não decide o que o agente tem permissão para fazer — esse é o trabalho do host. Mas o cliente estabelece a sessão, gerencia a autenticação e opera a camada de transporte para cada conexão com o servidor. É um ponto de controle mais restrito do que a maioria das equipes imagina quando ouve a palavra "cliente".
O MCP opera com esses dois componentes funcionando em sequência. O host define o ambiente; o cliente executa dentro dele. Não distingui-los faz com que você coloque controles de acesso no local errado — e é exatamente aí que a maioria das configurações incorretas começa.
Onde o Servidor MCP se Encaixa em um Pipeline de IA Agêntica
O servidor MCP é o alvo de maior valor no pipeline. Tudo o que o agente de IA consegue realmente fazer passa por ele. Um ou mais servidores MCP expõem as ferramentas, os recursos e os prompts que o agente pode invocar — e "ferramentas", neste contexto, significa acesso real a sistemas: ler um arquivo, consultar um banco de dados, enviar código, chamar uma API externa, mandar uma notificação.
Quando um agente de IA faz uma chamada ao servidor MCP, ele não está fazendo uma pergunta. Ele está solicitando uma ação. A resposta do servidor molda o que o agente fará em seguida. As ferramentas disponíveis estão listadas no manifesto do servidor, e o agente seleciona entre elas com base em suas instruções e contexto. É por isso que a segurança do servidor MCP importa mais do que pode parecer de fora: controle o servidor, controle as ações do agente. Comprometa o servidor, e o pipeline de IA agêntica se torna um mecanismo de entrega para qualquer coisa que o invasor queira executar.
É aqui que o chamado geralmente começa.
Riscos de MCP Security que Você Realmente Encontrará
Os riscos em uma implantação de MCP não são casos extremos hipotéticos descritos por pesquisadores que querem palestrar em conferências. Eles são mensuráveis, reproduzíveis, e vários deles estão presentes na maioria das implementações do mundo real. O cenário de ameaças se divide em algumas categorias distintas, e elas exigem defesas diferentes.
Envenenamento de Contexto e Injeção Indireta de Prompt via MCP
Isso pega as equipes de surpresa porque não parece uma vulnerabilidade vista de fora. Um agente malicioso não precisa atacar o modelo de IA nem o banco de dados subjacente. Basta inserir conteúdo malicioso na janela de contexto do modelo via MCP — por meio de um documento que o agente lê, uma resposta de API que ele recebe ou uma saída de ferramenta que ele processa.
Assim que esse conteúdo entra no contexto, ele pode emitir instruções para o modelo que substituem ou redirecionam seu comportamento. O usuário não vê isso. A interface visível parece normal. Mas o agente pode então estar exfiltrando credenciais, enviando dados para um endpoint controlado por invasores ou realizando ações que o usuário nunca autorizou — tudo porque uma entrada externa no ambiente MCP disse para ele fazer isso. A Invariant Labs demonstrou essa classe de ataque com exemplos funcionais contra implantações MCP reais. A defesa não é confiar mais no modelo. É segregar o conteúdo externo não confiável para que ele nunca alcance o contexto do modelo como uma entrada que carrega instruções.
Injeção de Comandos, Travessia de Caminho e SSRF: Vulnerabilidades Clássicas que Ainda se Aplicam
Um equívoco recorrente é que a história de segurança do MCP se resume principalmente à injeção de prompt — um problema de IA que exige defesas de IA. Os dados dizem o contrário.
Um estudo empírico de implementações MCP constatou que 43% dos servidores testados tinham falhas de injeção de comandos, 22% permitiam travessia de caminho ou leituras arbitrárias de arquivos, e 30% tinham vulnerabilidades de SSRF. São fraquezas tradicionais de aplicações web surgindo em ferramentas de IA em taxas que seriam alarmantes em qualquer outro contexto. Elas se aplicam aqui porque os servidores MCP aceitam entradas, as passam a comandos de sistema e operações de arquivo e fazem solicitações de rede de saída — todos os mesmos padrões que geram essas vulnerabilidades em aplicações convencionais.
A abordagem MCP não muda a mecânica subjacente. Um servidor que passa uma entrada não sanitizada para um comando de shell é vulnerável à injeção de comandos, quer um LLM tenha gerado essa entrada ou um humano a tenha digitado. O que muda com MCP é o alcance do invasor: ele pode influenciar a entrada sem tocar diretamente no servidor, manipulando o que foi dito ao agente de IA para enviar.
📊 Em números:
Nas implementações MCP testadas, quase metade tinha falhas exploráveis de injeção de comandos e quase um terço tinha vulnerabilidades de SSRF. Não são casos extremos nem exposições teóricas — são as mesmas classes de vulnerabilidade que causaram grandes violações em infraestrutura web convencional, agora surgindo na camada que dá a agentes de IA acesso direto a sistemas internos.
Sequestro de Servidor no Nível do Registro e Risco na Cadeia de Suprimentos
Este é o que refuta mais diretamente o argumento de que "se protegermos o LLM e os sistemas subjacentes, o MCP será apenas infraestrutura básica".
Um estudo de medição de 67.057 servidores MCP em seis registros públicos encontrou 833 servidores vulneráveis e 18 com descrições suspeitas que permitiam manipulação de invocação e sequestro no nível do registro. O ataque não exige uma vulnerabilidade no código. Verificações fracas de propriedade e metadados não confiáveis no registro são suficientes. Um invasor que consegue inserir no registro um servidor malicioso ou modificado, descoberto por um agente ou desenvolvedor, pode moldar o raciocínio do modelo e o comportamento do agente em escala antes que o agente alcance o LLM ou o banco de dados protegidos.
Servidores MCP de terceiros obtidos de registros públicos trazem um risco de cadeia de suprimentos comparável ao de pacotes npm não avaliados — e, no ecossistema MCP, a infraestrutura de avaliação é muito menos madura. Pesquisadores de segurança demonstraram ataques de envenenamento de ferramentas nos quais descrições de servidor aparentemente inofensivas continham instruções ocultas que levavam agentes a exfiltrar dados ou redirecionar ações sem qualquer indicação visível ao usuário final. A camada de descoberta do ecossistema MCP é uma superfície de ataque. Equipes que não a tratam como tal estão fazendo uma suposição que os dados não sustentam.
Controles de Segurança que Realmente Transformam o Risco de MCP de Teórico em Gerenciável
A teoria termina aqui. Os controles a seguir abordam os modos específicos de falha acima, e não a categoria genérica de "proteger sistemas de IA". Eles vêm do guia prático de MCP da Coalition for Secure AI e da pesquisa da Astrix Security sobre práticas de credenciais no MCP.
Autenticação, Autorização e Acesso a Ferramentas com Privilégio Mínimo
Comece pela identidade. Toda conexão com servidor MCP deve exigir autenticação forte. TLS no mínimo; TLS mútuo para conexões servidor a servidor nas quais você controla as duas pontas. As credenciais devem ter curta duração e escopo definido — não chaves de API armazenadas em variáveis de ambiente, que o relatório "State of MCP Server Security 2025" da Astrix Security encontrou em 79% das implementações e que são exatamente o tipo de segredo estático que torna o roubo de credenciais simples.
A autorização MCP deve ter escopo exatamente para o que o agente de IA precisa na tarefa que está realizando — e não para o que é conveniente expor. Uma ferramenta que o agente precisa para ler registros de CRM não deveria também ter acesso de escrita, a menos que o fluxo exija isso explicitamente. Tratar ferramentas MCP como uma fronteira de confiança, como recomenda a comunidade de segurança, significa restringir o acesso a diretórios e APIs específicos em vez de conceder permissões amplas e confiar que o modelo permanecerá dentro dos limites.
Uma lista de verificação prática para começar:
- Substitua chaves de API estáticas por OAuth ou tokens de curta duração Apenas 8,5% dos servidores MCP usam OAuth atualmente. Esse número precisa ser muito maior em qualquer implantação que você controla.
- Defina o escopo das credenciais por ferramenta, não por servidor Um servidor que expõe dez ferramentas não deve usar um único conjunto de credenciais com acesso a tudo de que as dez ferramentas poderiam teoricamente precisar.
- Faça a rotação de segredos conforme uma agenda, não após uma violação Se a rotação de credenciais exigir etapas manuais, ela não acontecerá de forma consistente. Automatize-a ou aceite que ela não acontecerá.
- Audite trimestralmente o escopo das permissões das ferramentas As ferramentas disponíveis acumulam escopo ao longo do tempo. O que começou como acesso somente leitura tende a se expandir. Revise isso.
Validação de Entrada, Execução em Sandbox e o Que Não Registrar em Logs
Dadas as taxas de injeção de comandos e travessia de caminho em implantações reais, tratar todas as entradas externas como não confiáveis não é opcional. Valide e sanitize tudo antes que alcance uma ferramenta que execute comandos, leia arquivos ou faça solicitações de saída. Isso não é específico do MCP — é uma prática padrão de desenvolvimento seguro que a abordagem de IA às vezes leva equipes a ignorar porque pensam que o modelo é a camada de validação. Ele não é.
A execução em sandbox limita o raio de impacto quando algo passa pelos controles. Um servidor MCP que inicia processos filhos ou acessa o sistema de arquivos local deve ser executado em um ambiente onde essas capacidades sejam explicitamente limitadas — diretórios específicos, destinos de rede específicos, sem acesso a segredos de produção dentro do sandbox. Limites rigorosos de sistema de arquivos e rede são uma boa prática reconhecida por um motivo: um servidor MCP local com acesso irrestrito ao sistema de arquivos é uma vulnerabilidade de travessia de caminho esperando que alguém encontre a entrada certa.
Sobre logs: audite cada invocação de ferramenta. Registre o que foi chamado, com quais argumentos e o que foi retornado. Mas um servidor MCP malicioso pode tentar extrair tokens sensíveis dos logs se esses logs forem acessíveis. Não registre valores brutos de credenciais, tokens de autenticação ou segredos que apareçam nas cargas úteis. Registre o suficiente para reconstruir o que aconteceu; não o suficiente para entregar a um invasor o que ele precisa caso o log seja comprometido. Esta é a recomendação da Black Hills Information Security que as equipes consistentemente ignoram.
Monitoramento de Interações MCP e Manutenção de Visibilidade em Todo o Grafo
Um servidor MCP não faz uma única chamada de API. Ele pode acionar cadeias de chamadas de ferramentas em vários sistemas, e essas cadeias podem se ramificar. Uma única interação comprometida pode se propagar por um fluxo de maneiras invisíveis nos logs de qualquer sistema isolado, mas claramente visíveis em uma visão no nível do grafo da sequência de interações.
O monitoramento contínuo de implantações MCP significa acompanhar não apenas se uma ferramenta foi chamada, mas também o que ela chamou downstream. Monitore: chamadas de ferramenta a recursos fora do escopo esperado, padrões incomuns de argumentos — strings longas em caminhos de sistema de arquivos, endereços de rede inesperados —, falhas de autenticação nas invocações de ferramentas e qualquer ferramenta que subitamente comece a ser executada com mais frequência do que sua linha de base. Arquivos antigos de configuração de servidores MCP também são um sinal — um servidor que não foi alterado em seis meses pode ter se desviado de sua postura de segurança original sem que ninguém perceba.
As equipes que desenvolvem isso na Latenode têm uma vantagem: o AI Agent Builder permite orquestração em várias etapas, na qual cada ação do agente é uma etapa discreta do fluxo com seu próprio log de execução. Isso significa que as cadeias de chamadas de ferramentas se tornam visíveis como sequências de execução estruturadas, em vez de rastros opacos de inferência — uma forma prática de obter a visibilidade no nível do grafo que o monitoramento MCP exige, sem criar uma stack personalizada de observabilidade do zero.
Quem Realmente Precisa de Controles de MCP Security e o Que Está Tentando Evitar
Três equipes estão lidando com versões diferentes desse problema agora. Cada uma está tentando evitar uma falha específica, e não uma categoria genérica de "risco de segurança de IA".
Equipes de segurança e engenharia de plataforma que expõem dados de observabilidade e CI/CD a agentes de IA
Essas equipes estão conectando agentes de IA a pipelines de implantação, sistemas de monitoramento e APIs de infraestrutura para que desenvolvedores possam consultar o status de builds, acionar reversões ou investigar incidentes por uma interface conversacional. O que elas tentam evitar é um caminho de produção descontrolado: um agente que pode ler logs de implantação também pode, nas condições erradas, acionar implantações. O modelo de ameaça é um escopo de ferramenta configurado incorretamente somado a uma injeção de prompt suficientemente persuasiva em um relatório de incidente ou entrada de log. O controle que mais frequentemente falta é o acesso a ferramentas com privilégio mínimo — acesso de leitura e escrita separados claramente na camada de servidor MCP. A adoção de IA nesse contexto avança rápido o bastante para que controles de segurança sejam adicionados depois, que é exatamente quando a exposição já ocorreu.
Equipes de experiência do desenvolvedor e ferramentas de IA que criam integrações de IDE e fluxos de assistentes de código
Essas equipes conectam servidores MCP a repositórios de código-fonte, rastreadores de problemas e sistemas de revisão de código para que assistentes de IA possam ajudar desenvolvedores a encontrar contexto, sugerir correções e entender bases de código. O que elas tentam evitar são alterações não autorizadas de código e exfiltração de credenciais por envenenamento de ferramentas — um servidor MCP de terceiros que parece uma ferramenta útil de busca de código, mas contém instruções ocultas em sua descrição de ferramenta que redirecionam o agente para exfiltrar chaves de API de arquivos .env. Profissionais de segurança nesse espaço estão tratando cada vez mais cada entrada de registro MCP de terceiros da mesma forma que equipes de segurança de aplicações tratam pacotes npm não avaliados: como um artefato não confiável que exige revisão antes de ser usado em produção. Assistentes de IA com acesso a repositórios de código são alvos de alto valor, e o vetor da cadeia de suprimentos do registro é aquele que a maioria das equipes de ferramentas para desenvolvedores ainda não considerou totalmente.
Equipes de AppSec e DevSecOps que tentam se antecipar a uma nova superfície de segurança de IA
Essas equipes lidam com MCP como TI paralela: novas ferramentas de IA continuam aparecendo em ambientes de produção, cada uma com sua própria configuração de servidor MCP, sem inventário central e com escopos de acesso pouco claros. O que elas tentam evitar é o sequestro de registros e caminhos de acesso não contabilizados — situações em que a um agente foi concedido acesso a um sistema que a conformidade exige auditar, mas ninguém adicionou o servidor MCP ao inventário de ativos porque ele foi instalado por um desenvolvedor em uma tarde de sexta-feira. O novo desafio de IA aqui não é técnico. É de governança. Os próprios agentes estão cada vez mais bem governados; os servidores aos quais eles se conectam não.
Três Equívocos sobre MCP Security que Criam Lacunas Reais
Esses três equívocos surgem repetidamente antes dos incidentes. Não na fase teórica, em que seriam fáceis de corrigir. Na fase de design, em que moldam a arquitetura.
Equívoco um: MCP é apenas mais um sistema de plugins, então os controles de segurança de API o cobrem. Isso parece razoável até você analisar o modelo de confiança. Uma integração de API convencional tem um cliente definido, um endpoint definido e um conjunto fixo de operações que o cliente pode solicitar. O MCP permite que um agente de IA descubra e invoque ferramentas dinamicamente com base em seu contexto e instruções de execução. As decisões do agente são moldadas por entradas que a stack de segurança muitas vezes nunca toca — descrições de ferramentas, contexto injetado por documentos externos, metadados de registro. Os controles de API padrão não conseguem auditar o que foi informado ao agente para que ele decidisse; eles só podem observar o que ele solicitou posteriormente. Essa lacuna é a superfície de ataque específica do MCP.
Equívoco dois: se o LLM e os sistemas subjacentes estiverem protegidos, MCP é uma preocupação secundária no nível de middleware. Esse é o enquadramento no qual equipes conscientes de segurança caem com mais frequência, e também é por isso que é o mais perigoso. Equipes que investiram fortemente em segurança de LLM e proteção de infraestrutura tendem a tratar o MCP como encanamento — o tubo entre duas coisas seguras. Mas esse tubo é exatamente o caminho de ataque identificado pela pesquisa em escala de registros. O estudo da arXiv sobre 67.057 servidores encontrou condições para sequestro no nível do registro em registros públicos sem qualquer vulnerabilidade no código dos sistemas subjacentes. O agente só consegue agir por meio de ferramentas MCP. Controle as ferramentas e você controla o agente — independentemente de quão protegido esteja o modelo ou o banco de dados por trás dele.
🤔 Espera.
Se um agente de IA só consegue agir por meio de ferramentas MCP, então um servidor MCP comprometido tem acesso direto a tudo aquilo que o agente recebeu permissão para tocar. O treinamento de segurança do LLM não ajuda aqui — o treinamento de segurança trata do que o modelo se recusa a gerar, não do que uma instrução de ferramenta manipulada diz para ele executar. O raio de impacto de um servidor comprometido é exatamente igual ao escopo de permissões do servidor. Você revisou esse escopo recentemente?
Equívoco três: injeção de prompt é o único problema real de MCP security, então, se você cuidar disso, estará protegido. As estatísticas de injeção e SSRF da Equixly refutam isso diretamente. 43% de injeção de comandos, 30% de SSRF, 22% de travessia de caminho — são vulnerabilidades clássicas de infraestrutura aparecendo em ferramentas de IA em taxas que acionariam programas de remediação em qualquer contexto convencional. A injeção de prompt é uma classe de ameaça real e importante. Ela não é a única. Servidores MCP aceitam entradas de agentes de IA e executam operações reais em sistemas reais. São serviços acessíveis pela web. Devem ser tratados com as mesmas práticas de desenvolvimento seguro de qualquer outro serviço acessível pela web.
Continuo vendo equipes pularem o trabalho relacionado a vulnerabilidades clássicas porque a conversa sobre MCP security foi dominada pelos vetores de ataque específicos de IA. Esse enquadramento é preciso até certo ponto. Mas não vai longe o bastante.
Como Será o Futuro de MCP Security à Medida que o Ecossistema Amadurece
Algumas coisas estão claramente em andamento. Outras são problemas realmente em aberto que nenhum fornecedor ou órgão de padronização resolveu.
A governança de registros é a lacuna mais óbvia. A conversa sobre a checklist de MCP security amadureceu rapidamente no último ano, mas ainda não há um processo padronizado de verificação de servidores para registros públicos. Qualquer pessoa pode publicar um servidor MCP. A adoção de MCP nas ferramentas para desenvolvedores superou a capacidade do ecossistema de avaliar o que está sendo adotado. Servidores MCP remotos descobertos por registros públicos trazem o mesmo risco de cadeia de suprimentos que pacotes open source não revisados, sem sequer os sinais de governança social que as comunidades NPM e PyPI usam para identificar pacotes suspeitos.
A assinatura padronizada de servidores é a resposta técnica, mas oferecer suporte à assinatura no nível do ecossistema MCP exige coordenação entre vários operadores de registros e fornecedores de toolchains. Essa coordenação está em estágio inicial. A constatação da pesquisa da Astrix de que 88% dos servidores exigem credenciais, enquanto a maioria usa segredos estáticos, sugere que a camada de identidade precisa de trabalho de padronização antes que a camada de assinatura faça diferença.
O abuso de contexto entre agentes é um modelo emergente de ameaça que ainda não está bem definido. À medida que implantações com múltiplos MCP se tornam comuns — um agente invocando ferramentas de vários servidores e compartilhando contexto entre eles — a superfície de interação para envenenamento de contexto e escalonamento de privilégios cresce de formas que os modelos de segurança de servidor único não abordam. Quem é responsável por auditar uma cadeia de contexto que cruza três servidores pertencentes a três equipes? Essa pergunta não tem uma resposta clara hoje, e espero que ela gere a primeira onda de incidentes sérios de IA agêntica quando alguém descobrir isso da pior maneira.
