O MCP torna os agentes mais seguros ou menos seguros?

Mais seguros por integração, mais arriscados no agregado. Um único protocolo significa um único lugar para revisar e revogar — mas também barateia conectar um agente a outro sistema, e cada conexão é uma decisão de confiança nova que alguém precisa tomar.

Preciso de autenticação em um servidor somente leitura?

Não necessariamente, se os dados forem genuinamente públicos. Você ainda precisa de limite de taxa e trilha de auditoria: público não significa gratuito, e um endpoint público sem limites é um amplificador apontado para a sua própria infraestrutura.

Por que verificar o cabeçalho Origin se os agentes não o enviam?

Justamente porque não enviam. O tráfego sem cabeçalho é o público legítimo; uma requisição que traz um Origin alheio é um navegador agindo em nome de outra pessoa, que é exatamente o caso que vale a pena rejeitar.

O que é um rug pull de ferramentas e como me defendo?

Um servidor que apresenta descrições inofensivas quando o usuário o aprova e as altera depois. As defesas são fixar a versão do servidor, revalidar as descrições quando elas mudam e não conceder a um servidor remoto capacidades que você não concederia a uma dependência de código.

GovernançaAtualizado 2026-08-22 · Versão 1.0

O que é Segurança em MCP?

Segurança em MCP é o que impede que um servidor de Model Context Protocol se torne o caminho mais fácil para dentro de um sistema. O protocolo padroniza como agentes descobrem e invocam ferramentas; ele não decide quem pode invocá-las, o que elas alcançam, nem o que acontece quando a descrição de uma ferramenta fica hostil. Essas decisões vivem no servidor: autenticação, validação de origem e transporte, ferramentas de escopo estreito, limites de taxa e trilha de auditoria.

Evidência: ProduçãoConfiança: AltaFonte: Sistema em produçãoFonte: Experiência pessoalFonte: Observação do setor

Legível por máquina: JSON

Definição

Segurança em MCP é o conjunto de controles aplicados a um servidor de Model Context Protocol e a seus clientes — autenticação e autorização, validação de origem e transporte, escopo de ferramentas, tratamento de entradas e saídas, limitação de taxa e auditoria — para que expor capacidades a um agente de IA não signifique expor os sistemas por trás delas.

Pontos-chave

MCP padroniza o encanamento, não a confiança: cada servidor decide sua própria postura.
A descrição de uma ferramenta é entrada não confiável para o modelo: ela pode instruir e pode mudar depois de aprovada.
Servidores locais por stdio e remotos por HTTP têm modelos de ameaça diferentes; os erros perigosos são outros.
Verificações de origem e limites de taxa ficam no servidor, porque os clientes não estão sob o seu controle.
«Somente leitura» é uma propriedade da implementação, nunca do nome da ferramenta.

Contexto

O MCP dá ao agente uma forma uniforme de descobrir e invocar capacidades. Essa uniformidade é ao mesmo tempo o valor e o risco: um mesmo cliente pode apontar para muitos servidores, e cada servidor é uma decisão de confiança nova, tomada na prática por quem colou uma URL num arquivo de configuração.

Duas formas de implantação dominam. Um servidor local por stdio roda com os privilégios do próprio usuário na máquina dele: não há fronteira de rede, então as perguntas são o que ele pode ler e se ele liga para casa. Um servidor remoto por HTTP é um endpoint público: as perguntas passam a ser quem chama, de onde, com que frequência e se um navegador pode ser enganado para chamar em nome de um usuário.

Para esta base de conhecimento operamos uma de cada forma — um endpoint HTTP público e um pacote stdio publicado —, então os controles a seguir são descritos como estão implementados, e não como uma lista genérica.

Arquitetura

Decida primeiro a exposição: capacidade pública somente leitura, capacidade autenticada ou apenas local. Todo o resto decorre dessa resposta, e a maioria dos incidentes vem de um servidor que nunca a tomou.

Valide o transporte antes de fazer trabalho. Em servidores HTTP, verifique o cabeçalho Origin contra uma lista de permitidos e rejeite chamadas cross-site iniciadas por navegador antes de qualquer handler rodar: DNS rebinding e abuso no estilo CSRF chegam por aí.

Mantenha o servidor sem estado sempre que o protocolo permitir. Sem armazenamento de sessão não há fixação de sessão, nem contaminação entre requisições, nem estado a vazar entre chamadores.

Restrinja o escopo das ferramentas. Uma ferramenta, uma capacidade, sem verbos que mudam conforme um argumento: uma ferramenta de «consulta» que também escreve é uma escalada de privilégio esperando o parâmetro certo.

Limite a taxa por chamador e responda com um 429 real e Retry-After. Um agente que tenta de novo é tráfego normal; um agente que tenta sem limite é uma ferramenta de negação de serviço apontada para o seu próprio backend.

Registre cada chamada com forma suficiente para reconstruir um abuso — ferramenta, resultado, latência, identidade do chamador — e nada que transforme o próprio log na brecha.

Trate todo resultado de ferramenta como conteúdo não confiável no caminho de volta. Um servidor que faz proxy de dados externos é, por construção, um canal de injeção indireta.

Componentes

Autenticação: nenhuma para dados de leitura genuinamente públicos, token ou OAuth para qualquer outra coisa, com a decisão documentada, porque «sem auth» precisa ser uma escolha e não um descuido.Validação de origem e host em servidores remotos, derivada de tráfego medido e não presumida a partir do padrão de uma aplicação web.Autorização por ferramenta: o que este chamador pode invocar, não apenas se ele pode se conectar.Validação de entrada na fronteira da ferramenta, com o mesmo rigor de uma API pública — porque é isso que ela é.Modelagem da saída: devolva o mínimo de que o chamador precisa; nunca repasse payloads crus de sistemas a montante.Limites de taxa e cotas, com cabeçalhos corretos o bastante para que clientes bem-educados recuem sozinhos.Logs de auditoria e métricas, retidos o suficiente para investigar e agregados o suficiente para serem seguros de guardar.Higiene de cadeia de suprimentos do próprio servidor: dependências fixadas, atualizações revisadas e publicação com procedência, para que o cliente saiba que está falando com o servidor que você construiu.

Benefícios

Um servidor MCP bem delimitado é uma superfície de ataque menor do que a integração ad hoc que substitui: um protocolo, um ponto de auditoria, um lugar para revogar.
A ausência de estado e as ferramentas estreitas tornam o servidor barato de raciocinar: a revisão de segurança cabe em uma página.
Erros padronizados e cabeçalhos de limite de taxa tornam o comportamento do cliente previsível, o que já é em si uma propriedade defensiva.
Como tudo cruza uma única fronteira, a medição sai de graça: abuso e uso aparecem nos mesmos logs e se distinguem.

Riscos

Rug pull de ferramentas: um servidor que se comporta no momento da aprovação e muda suas descrições depois, quando o cliente já parou de perguntar.
Servidores locais amplos demais: um servidor stdio com o sistema de arquivos e as credenciais do usuário é uma capacidade de agente completa, sem fronteira de rede para contê-la.
Deputado confuso: o servidor detém credenciais que o chamador não tem, então quem chegar até ele herda o alcance dele.
Exposição pública silenciosa: um servidor remoto implantado sem autenticação, sem verificação de origem e sem limite de taxa é descobrível e gratuito de abusar.
Relé de injeção: saída de ferramenta obtida de terceiros e entregue ao modelo como se fosse instrução confiável.

Ferramentas e tecnologias

A especificação do MCP e sua orientação de segurança de transporte: a linha de base que todo servidor deveria conseguir responder.Listas de origem permitida e configuração de CORS aplicadas antes de o código da aplicação rodar.Armazenamentos de limite de taxa (Redis ou equivalente) indexados por identidade de chamador com hash, em vez de IP em claro.Logs de requisição estruturados e métricas de latência, para ver abuso e custo na mesma visão.OWASP Top 10 para aplicações LLM, pelas classes de injeção e excesso de agência que um servidor MCP amplifica.Fichas em registries e publicações assinadas, para que o cliente verifique que o servidor instalado é o que você publicou.

Exemplos

Esta base de conhecimento expõe um endpoint MCP HTTP público e somente leitura. Ele é sem estado por design, então nenhuma sessão pode ser fixada ou reproduzida; as ferramentas devolvem apenas conteúdo publicado; e cada chamada é limitada por chamador com hash, com um 429 real e Retry-After.
Antes de escrever a regra de Origin desse endpoint, medimos o tráfego dele: quase nenhuma requisição trazia cabeçalho Origin, nenhuma trazia null e todas as que traziam vinham deste site. A regra publicada segue a medição — rejeitar chamadas com origem de navegador de qualquer outro lugar e permitir o tráfego de agentes sem cabeçalho, que é o público real — em vez de copiar a política padrão de uma aplicação web.
O pacote stdio publicado para esta mesma base roda localmente sem credenciais e sem acesso ao sistema de arquivos, porque tudo de que precisa é uma chamada de saída ao endpoint público. A um servidor local que não precisa de nada, não se dá nada.

FAQs

O MCP torna os agentes mais seguros ou menos seguros?: Mais seguros por integração, mais arriscados no agregado. Um único protocolo significa um único lugar para revisar e revogar — mas também barateia conectar um agente a outro sistema, e cada conexão é uma decisão de confiança nova que alguém precisa tomar.
Preciso de autenticação em um servidor somente leitura?: Não necessariamente, se os dados forem genuinamente públicos. Você ainda precisa de limite de taxa e trilha de auditoria: público não significa gratuito, e um endpoint público sem limites é um amplificador apontado para a sua própria infraestrutura.
Por que verificar o cabeçalho Origin se os agentes não o enviam?: Justamente porque não enviam. O tráfego sem cabeçalho é o público legítimo; uma requisição que traz um Origin alheio é um navegador agindo em nome de outra pessoa, que é exatamente o caso que vale a pena rejeitar.
O que é um rug pull de ferramentas e como me defendo?: Um servidor que apresenta descrições inofensivas quando o usuário o aprova e as altera depois. As defesas são fixar a versão do servidor, revalidar as descrições quando elas mudam e não conceder a um servidor remoto capacidades que você não concederia a uma dependência de código.