Model Context Protocol (MCP) em produção: como operar servidores MCP com segurança

O que é o MCP e para que serve

O MCP é um padrão aberto que funciona como conector universal entre agentes de IA e os sistemas e dados da empresa. Ele resolve um problema concreto: sem um padrão, cada ligação entre um modelo e um sistema exige uma integração própria, e o número dessas integrações explode conforme crescem os agentes e as fontes. O MCP substitui esse emaranhado ponto a ponto por um contrato comum de como o agente encontra e usa ferramentas.

O que o protocolo padroniza

O MCP padroniza a descoberta e a chamada de ferramentas, recursos e prompts que um sistema oferece a um agente. Em vez de o desenvolvedor programar, caso a caso, como o agente conversa com o ERP, com o CRM e com o ITSM, cada um desses sistemas expõe suas capacidades por um servidor MCP que fala a mesma língua. O agente, do outro lado, descobre o que está disponível e chama o que precisa. Segundo a especificação oficial do protocolo, é essa padronização da conexão agente-sistema que o MCP entrega, e a spec evolui em versões atribuídas à sua fonte^[1].

Como funciona a arquitetura cliente-servidor

O MCP separa dois papéis: o cliente, que vive dentro do agente ou host, e o servidor, que expõe as capacidades de um sistema. O cliente descobre quais ferramentas existem e as chama; o servidor MCP publica ferramentas (ações que o agente pode executar), recursos (dados que pode ler) e prompts (modelos de instrução), fazendo a ponte com o sistema real por trás. Essa divisão é o que permite trocar de agente sem reescrever a integração e vice-versa — cada lado só precisa respeitar o protocolo.

O fluxo de uma chamada de ferramenta

Na prática, uma chamada segue sempre a mesma sequência. O cliente pergunta ao servidor quais ferramentas estão disponíveis; o servidor responde com a lista e a descrição de cada uma; o agente decide qual ferramenta usar para a tarefa; o cliente invoca a ferramenta escolhida, com parâmetros; o servidor executa a ação no sistema real e devolve o resultado. Entender esse fluxo é o que permite ver onde entram os controles — autenticação na conexão, autorização por ferramenta na invocação, log em cada chamada.

Consumir um servidor pronto ou expor um próprio

A primeira decisão prática ao operar MCP é entre consumir servidores prontos de fornecedores e expor um servidor próprio sobre sistemas internos. Consumir é conectar-se a um servidor que já existe; expor é publicar um servidor seu sobre ERP, CRM ou ITSM interno. Os critérios de escolha são a sensibilidade dos dados, a necessidade de lógica de negócio própria e o grau de controle que você precisa ter sobre as permissões.

Quando basta consumir um servidor pronto

Consumir é o suficiente quando o sistema-alvo já oferece um servidor MCP confiável e você não precisa de lógica própria sobre ele. É o caso típico de ferramentas SaaS que expõem suas próprias capacidades por MCP: você conecta o agente, concede o escopo mínimo e usa. A responsabilidade de operar o servidor fica com o fornecedor; a sua é revisar o que a conexão permite e não conceder mais acesso do que a tarefa exige. Para portes menores, consumir cobre a maioria dos casos.

Quando vale expor um servidor próprio

Expor um servidor próprio faz sentido quando o agente precisa acessar um sistema interno sem servidor pronto, ou quando há lógica de negócio e regras de permissão específicas que só você pode aplicar. Um servidor MCP sobre o ERP interno, por exemplo, permite controlar exatamente quais operações o agente pode fazer e sob quais regras. O custo é que você passa a operar essa superfície — com toda a disciplina de segurança que expor uma API crítica exige. Expor sem necessidade real amplia a superfície de ataque sem retorno.

Critérios para decidir

Autorização e menor privilégio

O núcleo de segurança do MCP é conceder a cada agente só as ferramentas de que ele precisa — nunca acesso amplo. Um servidor MCP sem controle de acesso dá, se comprometido, acesso a todo banco, sistema e serviço que ele conecta. Por isso autenticação, autorização por escopo e menor privilégio não são opcionais: são a diferença entre um conector e um portão aberto.

OAuth e escopo mínimo de ferramentas

O servidor MCP deve exigir autenticação e conceder escopos por ferramenta, não acesso amplo. O padrão de autorização adotado pela especificação é baseado em OAuth com PKCE, conforme atribuído à fonte^[3]. Na prática, cada agente autentica e recebe autorização apenas para o conjunto de ferramentas que sua tarefa exige — um agente de suporte que só precisa ler chamados não deve receber a ferramenta que altera pedidos no ERP. Escopo por ferramenta é o que impede que uma credencial vire uma chave-mestra.

O princípio do menor privilégio

Cada servidor e cada agente deve operar com o mínimo de acesso necessário — esse é o principal mecanismo de contenção. Um escopo estreito significa que, mesmo que um agente seja manipulado ou uma credencial vaze, o estrago fica limitado ao pouco que aquele escopo permite. Segundo análises de segurança do protocolo, a consequência de ignorar isso é direta: um servidor MCP com acesso excessivo transforma qualquer comprometimento em acesso a tudo que ele conecta^[4]. Menor privilégio não é rigor burocrático; é o que dimensiona o raio de um incidente.

Defesa contra tool poisoning e superfície de ataque

Um servidor MCP é uma superfície de ataque e deve ser tratado com a mesma disciplina de qualquer API exposta — autenticação, isolamento, transporte seguro e observabilidade. Entre os riscos específicos do protocolo, o tool poisoning é o mais característico: instruções maliciosas embutidas nos metadados de uma ferramenta que influenciam a decisão do agente antes de qualquer ação do usuário.

O que é tool poisoning

Tool poisoning é a contaminação dos metadados de uma ferramenta com instruções maliciosas que o agente lê e obedece. Como o agente decide qual ferramenta usar a partir da descrição que o servidor fornece, um servidor malicioso — ou comprometido — pode embutir nessas descrições comandos que desviam o comportamento do agente, sem que o usuário perceba. O risco não está em uma ação visível, e sim na informação que o agente consome para decidir. É por isso que confiar cegamente em servidor de terceiro é perigoso: você está deixando o agente ler instruções que não controla.

Como conter o risco

A contenção é de governança, não de sorte. As práticas centrais são: usar apenas servidores de origem confiável, validar e revisar os metadados das ferramentas antes de habilitá-las, restringir quais servidores podem ser registrados e não confiar automaticamente em servidor de terceiro. Restringir o registro de servidores a uma lista aprovada evita que qualquer servidor entre na malha sem verificação. Em portes maiores, isso vira um pipeline formal de verificação de servidores e monitoramento de comportamento; em portes menores, começa por escolher fornecedores confiáveis e revisar cada conexão.

Transporte e isolamento

O servidor MCP deve operar sobre TLS e ficar isolado da rede interna sensível, como qualquer API crítica exposta. Cifrar o transporte protege as chamadas em trânsito; isolar o servidor limita o que ele alcança caso seja comprometido. Tratar o servidor como parte da superfície de ataque — e não como um componente interno confiável por padrão — é o que orienta essas escolhas. O foco é sempre a contenção: reduzir o que um servidor comprometido consegue tocar, em vez de supor que ele nunca será comprometido^[6].

Operar em escala com modelo stateless

Operar o servidor MCP de forma stateless é o que permite escalá-lo horizontalmente sem depender de sticky session. Um servidor que guarda estado na sessão prende cada agente a uma instância específica; um servidor stateless pode ser replicado atrás de um load balancer, e qualquer instância atende qualquer chamada. Essa é a decisão de arquitetura que separa um servidor que escala de um que trava sob carga.

Por que operar stateless

Porque estado na sessão impede a distribuição de carga. Se o servidor mantém o contexto de uma conversa na memória local, o load balancer precisa mandar sempre o mesmo agente para a mesma instância — a chamada sticky session —, o que cria pontos de falha e limita a escala. Um servidor stateless não tem esse acoplamento: pode-se adicionar ou remover instâncias livremente, e a operação continua. É o mesmo princípio que rege qualquer serviço web pensado para escalar.

Onde vai o estado que precisa persistir

O estado que precisa sobreviver a uma chamada vai para fora do servidor, em armazenamento externo, não na sessão. Quando há contexto que deve persistir entre chamadas, ele é gravado em um repositório compartilhado que todas as instâncias enxergam — banco, cache distribuído ou serviço equivalente. Assim, o servidor em si permanece sem estado e descartável, enquanto o dado persistente fica em uma camada projetada para isso. Colocar o servidor atrás de load balancer com escala horizontal deixa de ser um problema quando o estado já mora fora dele.

Observabilidade, inventário e governança de servidores

Sem observabilidade e inventário, a malha de servidores MCP vira acesso não mapeado — ninguém sabe quais servidores existem, o que expõem e quem os usa. Registrar as chamadas e manter um catálogo de servidores é o que transforma uma coleção de conexões em algo governável e auditável.

Log e auditoria de chamadas

Toda chamada de ferramenta deve ser registrada: qual ferramenta foi chamada, por qual agente, com quais parâmetros e com qual resultado. Esse log é o que permite auditar comportamento e detectar uso fora do escopo — um agente chamando ferramentas que não deveria, um volume anômalo de chamadas, um parâmetro suspeito. A observabilidade das chamadas MCP conecta-se diretamente à observabilidade dos agentes: é pela trilha das chamadas que se reconstrói o que um agente fez e por quê.

Inventário de servidores

Manter um registro de quais servidores MCP existem, o que cada um expõe, quem os opera e com quais escopos é pré-requisito de governança. Sem esse inventário, a malha cresce por adição informal e ninguém consegue responder perguntas básicas de segurança — quantos servidores tocam o ERP, quais expõem dado sensível, qual agente acessa o quê. O inventário é para os servidores MCP o que o catálogo é para qualquer ativo de TI: o que não está no inventário não é governado.

Relação com governança e segurança de agentes

O MCP é a camada de integração que os agentes usam — e se encaixa ao lado, não no lugar, da governança e da segurança de agentes. A governança de agentes de IA cuida de dono, catálogo, escopo e ciclo de vida do agente; a segurança de agentes de IA em produção cuida de prompt injection, identidade e menor privilégio do agente. Aqui o foco é o protocolo e a operação dos servidores: o que o MCP expõe, com qual autorização e sob qual observabilidade. As três camadas se complementam — operar servidores MCP com disciplina é parte de governar a frota de agentes, não um assunto à parte.

Roteiro operacional para MCP em produção

O roteiro é sempre o mesmo — decidir consumir ou expor, definir escopo mínimo, configurar autenticação, operar stateless, ligar observabilidade e inventariar — dimensionado ao mínimo viável de cada porte. A lógica é tratar cada servidor MCP como uma API crítica desde o primeiro dia.

Os passos, em ordem

1. Decidir consumir ou expor: avalie sensibilidade dos dados, lógica de negócio e controle de permissão necessários.
2. Definir o escopo mínimo de ferramentas: cada agente recebe só as ferramentas de que precisa.
3. Configurar autenticação e autorização: OAuth com escopo por ferramenta e menor privilégio.
4. Operar stateless atrás de load balancer: estado que persiste vai para armazenamento externo.
5. Ligar log e observabilidade: registre cada chamada — ferramenta, agente, parâmetros, resultado.
6. Inventariar e revisar: mantenha o catálogo de servidores, escopos e donos, e revise periodicamente.

Como o roteiro muda conforme o porte