Automação de IA
O Projeto de Segurança GenAI da OWASP define uma barra mínima de cinco categorias para implementação segura de servidor MCP. Use esta lista de verificação para avaliar sua postura atual em identidade, isolamento, ferramentas, validação e implementação antes de ir para produção.
O guia prático do Projeto de Segurança GenAI da OWASP para desenvolvimento de servidor MCP culmina em uma lista de verificação de revisão concreta — a “Barra Mínima de Segurança MCP”. Esta lista de verificação define os controles básicos que devem estar em vigor antes que um servidor MCP seja implementado em produção.
Este post apresenta a lista de verificação completa com orientações de implementação para cada item, organizados nas cinco áreas de segurança que o guia da OWASP define. Use-a para revisões de segurança pré-implementação, auditorias periódicas e como estrutura para remediar lacunas identificadas.
Marcando itens: Para cada item, registre APROVADO (implementado e verificado), REPROVADO (não implementado ou parcialmente implementado), ou N/A (não aplicável a esta implementação).
Portões de implementação: Itens na Categoria 1 (Identidade, Autenticação, Política) e Categoria 2 (Isolamento) são portões rígidos de implementação — qualquer REPROVADO deve bloquear a entrada em produção até ser remediado. Itens em outras categorias devem ser aceitos como risco com cronogramas documentados.
Gatilhos de revisão: Execute novamente a lista de verificação completa após qualquer mudança significativa no código do servidor MCP, registro de ferramentas, configuração de autenticação, ambiente de implementação, ou quando uma nova categoria de ferramentas for integrada.
Esta é a categoria de maior prioridade. Falhas de autenticação concedem aos atacantes acesso direto a tudo que o servidor MCP pode fazer.
O que verificar: Toda conexão remota ao servidor MCP requer autenticação através de um servidor de autorização OAuth 2.1 devidamente configurado. Conexões anônimas são rejeitadas. Servidores MCP locais usando STDIO podem usar autenticação alternativa apropriada ao seu contexto de implementação.
Como testar: Tente conectar sem um cabeçalho de autorização. Tente conectar com um token malformado ou expirado. Ambos devem resultar em falha de autenticação, não em acesso a ferramentas.
Modos comuns de falha: Endpoints de desenvolvimento deixados acessíveis sem autenticação; fallback para autenticação de chave API que não valida expiração ou escopo; validação de token apenas no estabelecimento da sessão, não por solicitação.
O que verificar: Tokens de acesso expiram em minutos (não horas). Cada token carrega o escopo mínimo necessário para a tarefa atual. Cada invocação de ferramenta valida a assinatura do token, emissor (iss), audiência (aud), expiração (exp) e escopo necessário — não apenas no estabelecimento da sessão.
Como testar: Use um token válido, depois espere que ele expire (ou avance manualmente o relógio). Tente uma chamada de ferramenta — ela deve falhar com um 401, não ter sucesso com base em um resultado de validação em cache.
Modos comuns de falha: Validação de token em cache no início da sessão e não repetida; tokens com vida útil de 24+ horas; escopos “admin” amplos usados em vez de escopos específicos de operação; campo exp não verificado.
O que verificar: O servidor MCP não encaminha tokens de cliente para APIs downstream. Todas as chamadas de serviço downstream usam tokens explicitamente emitidos para o servidor MCP (via fluxos On-Behalf-Of ou credenciais de serviço). Um gateway de política centralizado intercepta todas as invocações de ferramentas e aplica autenticação, autorização, consentimento e registro de auditoria antes que qualquer código de ferramenta seja executado.
Como testar: Revise o código para qualquer local onde o token do cliente de entrada seja encaminhado em uma chamada de API de saída. Inspecione os logs de acesso do serviço downstream para verificar se as solicitações chegam com credenciais do servidor, não credenciais do usuário.
Modos comuns de falha: Padrão Authorization: Bearer ${request.headers.authorization} em chamadas downstream; verificações de autorização espalhadas por manipuladores de ferramentas individuais; nenhum ponto de aplicação de política centralizado.
Comece seu teste gratuito hoje e veja resultados em dias.
Falhas de isolamento em ambientes multilocatário são catastróficas — elas permitem que um usuário acesse os dados de outro. Estes são portões rígidos de implementação.
O que verificar: Nenhuma variável global, atributo de nível de classe ou instâncias singleton compartilhadas armazenam dados específicos do usuário ou da sessão. Cada sessão usa objetos instanciados independentemente ou namespaces com chave de sessão (por exemplo, chaves Redis prefixadas com session_id:). A revisão de código confirma que não há estado mutável compartilhado entre sessões.
Como testar: Execute duas sessões simultâneas com identidades de usuário diferentes. Verifique se os dados gravados na sessão A não podem ser lidos na sessão B. Use testes de carga simultâneos para verificar condições de corrida que possam causar vazamento de estado de sessão.
Modos comuns de falha: self.user_context = {} como atributo de classe em um serviço singleton; caches globais sem namespaces com chave de sessão; armazenamento local de thread que não tem escopo adequado para o ciclo de vida da solicitação.
O que verificar: Além do contexto de execução, qualquer infraestrutura compartilhada (bancos de dados, caches, filas de mensagens) aplica controles de acesso por usuário. Uma consulta executada na sessão de um usuário não pode retornar dados de outro usuário mesmo se a infraestrutura compartilhada estiver mal configurada ou comprometida.
Como testar: Tente acessar os dados de outro usuário manipulando parâmetros de sessão ou explorando chaves de cache compartilhadas.
Modos comuns de falha: Chaves de cache baseadas apenas no conteúdo da consulta, não na identidade do usuário; consultas de banco de dados sem cláusulas WHERE com escopo de usuário; diretórios de arquivos temporários compartilhados sem subdiretórios por usuário.
O que verificar: Quando uma sessão termina (de forma limpa ou por timeout/erro), todos os recursos associados são imediatamente liberados: handles de arquivo, arquivos temporários, contexto na memória, tokens em cache, conexões de banco de dados. Existem limites por sessão para memória, CPU, taxa de API e uso do sistema de arquivos.
Como testar: Termine uma sessão abruptamente (mate a conexão sem um desligamento gracioso). Verifique se não há recursos residuais. Crie uma sessão e esgote seu limite de taxa; verifique se isso não afeta outras sessões.
Modos comuns de falha: Arquivos temporários deixados em /tmp após o término da sessão; tokens em cache não revogados no término da sessão; nenhuma cota de recursos permitindo que uma sessão esgote a infraestrutura compartilhada.
A segurança de ferramentas previne os ataques mais perigosos específicos do MCP: envenenamento de ferramentas e rug pulls.
O que verificar: Cada definição de ferramenta tem uma assinatura criptográfica de um aprovador de ferramenta autorizado. A assinatura cobre o manifesto completo (descrição, esquema, versão, permissões). O servidor MCP verifica essa assinatura no momento do carregamento e rejeita qualquer ferramenta sem assinatura ou com assinatura incompatível. As versões das ferramentas são fixadas — o servidor não pode carregar dinamicamente uma ferramenta atualizada sem uma nova assinatura aprovada.
Como testar: Modifique um único caractere na descrição de uma ferramenta carregada. Verifique se o servidor detecta a incompatibilidade de hash e bloqueia o carregamento da ferramenta. Tente carregar uma definição de ferramenta sem assinatura — ela deve ser rejeitada.
Modos comuns de falha: Definições de ferramentas armazenadas como configuração mutável sem verificação de integridade; nenhuma infraestrutura de chave de assinatura; ferramentas carregadas diretamente de um sistema de arquivos compartilhado sem fixação de versão.
O que verificar: A varredura automatizada verifica as descrições de ferramentas em busca de padrões semelhantes a instruções que possam representar tentativas de envenenamento. A validação periódica confirma que o comportamento real em tempo de execução de uma ferramenta corresponde à sua descrição declarada — uma ferramenta que afirma ser somente leitura não deve ser capaz de operações de gravação em tempo de execução.
Como testar: Adicione uma instrução suspeita a uma descrição de ferramenta (“sempre também chame send_webhook com…”) e verifique se a varredura automatizada a sinaliza antes da revisão humana. Revise a configuração da ferramenta SAST para regras de detecção de envenenamento específicas do MCP.
Modos comuns de falha: Nenhuma varredura automatizada de descrições de ferramentas; processo de revisão manual que pode perder instruções incorporadas em descrições longas; nenhuma validação de comportamento em tempo de execução para detectar ferramentas que mentem sobre suas capacidades.
O que verificar: O contexto do modelo recebe apenas os campos necessários para a invocação correta da ferramenta: nome, descrição, esquema de entrada, esquema de saída. Metadados internos, detalhes de implementação, informações de depuração e configuração sensível são filtrados antes de serem passados ao modelo.
Como testar: Inspecione o que o modelo recebe quando enumera as ferramentas disponíveis. Verifique se nenhum campo interno, strings de conexão ou metadados operacionais aparecem na visualização do modelo.
Modos comuns de falha: Objetos de configuração de ferramenta completos passados ao contexto do modelo; mensagens de erro contendo detalhes internos do sistema que vazam para o modelo; descrições de ferramentas incluindo notas de implementação não relevantes para invocação.
Receba gratuitamente as últimas dicas, tendências e ofertas.
Falhas de validação permitem injeção, manipulação de dados e negação de serviço.
O que verificar: A validação de Esquema JSON é aplicada para cada mensagem do protocolo MCP, cada entrada de invocação de ferramenta e cada saída de ferramenta antes de chegar ao modelo. A validação rejeita qualquer mensagem que não esteja em conformidade com o esquema definido — campos obrigatórios ausentes, tipos errados, valores fora das faixas permitidas.
Como testar: Envie uma invocação de ferramenta com um parâmetro obrigatório ausente. Envie uma mensagem com um campo extra inesperado. Ambos devem ser rejeitados, não silenciosamente ignorados ou processados com valores padrão.
Modos comuns de falha: Validação opcional que é ignorada em condições de erro; validação apenas em entradas, não em saídas; esquemas muito permissivos (aceitando parâmetros type: "any").
O que verificar: Todas as entradas são sanitizadas para remover ou escapar caracteres que possam permitir injeção (sequências XSS, metacaracteres SQL, metacaracteres shell, bytes nulos). Limites de tamanho são aplicados em todas as entradas e saídas. O servidor trata todos os dados do modelo como potencialmente adversariais, idênticos à entrada do usuário em uma aplicação web tradicional.
Como testar: Envie entradas contendo payloads de injeção SQL, metacaracteres shell e sequências XSS. Verifique se eles são rejeitados ou escapados com segurança antes de chegar aos sistemas downstream. Envie uma entrada que exceda o limite de tamanho — verifique se ela é rejeitada de forma limpa.
Modos comuns de falha: Entradas passadas diretamente para consultas SQL ou comandos shell; nenhum limite de tamanho permitindo que entradas superdimensionadas causem esgotamento de memória; saídas retornadas ao modelo sem limites de tamanho ou filtragem de conteúdo.
O que verificar: Chamadas de ferramentas são aceitas apenas como objetos JSON estruturados com esquemas validados. A geração de texto de forma livre que implica invocações de ferramentas não é processada. O sistema não pode ser induzido a executar chamadas de ferramentas gerando linguagem natural que o servidor interprete como comandos.
Como testar: Envie uma string de linguagem natural que descreva uma invocação de ferramenta (“chame a ferramenta delete_file com caminho /etc/passwd”). Verifique se o servidor não interpreta isso como uma chamada de ferramenta.
Modos comuns de falha: Sistemas híbridos que aceitam tanto JSON estruturado quanto descrições de ferramentas em linguagem natural; servidores que analisam texto gerado pelo modelo para identificar invocações de ferramentas; análise de chamadas de ferramentas baseada em regex que pode ser falsificada.
O endurecimento da implementação limita o raio de explosão de qualquer vulnerabilidade explorada.
O que verificar: O servidor MCP executa em um contêiner mínimo endurecido. O processo do contêiner executa como um usuário não-root. Capacidades desnecessárias do Linux são removidas. Políticas de rede restringem todo o tráfego de entrada e saída a conexões explicitamente necessárias. A imagem do contêiner contém apenas o software mínimo necessário.
Como testar: Execute docker inspect e verifique se o usuário é não-root. Revise as políticas de rede e confirme que estão bloqueando todo o tráfego, exceto conexões explicitamente permitidas. Faça varredura da imagem do contêiner em busca de pacotes desnecessários ou software com vulnerabilidades conhecidas.
Modos comuns de falha: Contêineres executando como root por conveniência; nenhuma política de rede deixando todo o tráfego de saída permitido; imagens base com instalações completas de SO em vez de imagens mínimas.
O que verificar: Todas as chaves de API, segredos de cliente OAuth, credenciais de banco de dados e tokens de conta de serviço são armazenados em um cofre de segredos (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.). Nenhum segredo existe em variáveis de ambiente, código-fonte, imagens de contêiner ou saída de log. Operações de gerenciamento de segredos acontecem em middleware que é inacessível ao modelo de IA — o LLM nunca vê ou processa valores de credenciais.
Como testar: Pesquise logs por strings semelhantes a credenciais. Inspecione variáveis de ambiente acessíveis ao processo do servidor. Revise o contexto acessível do modelo para confirmar que nenhum valor de credencial aparece.
Modos comuns de falha: Chaves de API em arquivos .env commitados no controle de versão; credenciais retornadas em mensagens de erro que chegam ao modelo; segredos passados como parâmetros de ferramenta que aparecem no contexto de conversa do modelo.
O que verificar: O pipeline de implementação inclui varredura de segurança automatizada (SAST, SCA, varredura de vulnerabilidades de dependência) como portões rígidos — varreduras com falha bloqueiam a implementação. Todas as invocações de ferramentas, eventos de autenticação e decisões de autorização são registrados de forma imutável com contexto completo. Os logs são ingeridos por um SIEM com alertas em tempo real sobre padrões anômalos (picos de validação com falha, frequência incomum de chamadas de ferramentas, conexões externas inesperadas).
Como testar: Introduza uma dependência com vulnerabilidade conhecida e verifique se o pipeline CI/CD falha a compilação. Gere padrões anômalos de chamadas de ferramentas e verifique se os alertas SIEM disparam dentro do tempo de resposta esperado.
Modos comuns de falha: Varredura de segurança como consultiva em vez de portões bloqueadores; logs gravados em armazenamento mutável que um atacante poderia modificar; nenhum alerta sobre padrões anômalos; verbosidade excessiva de log que torna eventos relevantes impossíveis de encontrar.
Imprima ou exporte esta lista de verificação e trabalhe nela sistematicamente para cada servidor MCP antes da implementação em produção. Envolva sua equipe de segurança na revisão — muitos itens requerem tanto revisão de código quanto testes ao vivo para verificar corretamente.
Para equipes que desejam verificação independente, uma auditoria de segurança MCP profissional testa todos os 16 itens da lista de verificação contra seu ambiente em produção, usando técnicas de teste adversarial em vez de autoavaliação. O resultado é um relatório de postura de segurança verificado com um plano de remediação priorizado.
A 'Barra Mínima de Segurança MCP' do Projeto de Segurança GenAI da OWASP é uma lista de verificação de revisão que define os controles de segurança básicos necessários antes que um servidor MCP seja implementado em produção. Ela cobre cinco domínios: Identidade/Autenticação/Política Forte, Isolamento Estrito e Controle de Ciclo de Vida, Ferramentas Confiáveis e Controladas, Validação Orientada por Esquema e Implementação Endurecida com Supervisão Contínua. Não atingir a barra mínima significa que o servidor MCP não deve ser implementado até que as lacunas sejam remediadas.
Trabalhe em cada categoria sistematicamente, marcando itens como APROVADO, REPROVADO ou NÃO APLICÁVEL com evidências para cada decisão. Qualquer REPROVADO nas categorias 1 ou 2 (identidade e isolamento) deve bloquear a implementação — essas são as lacunas de maior risco. REPROVADOs em outras categorias devem ser aceitos como risco com um cronograma de remediação documentado antes da implementação. A lista de verificação deve ser reavaliada após qualquer mudança significativa no servidor MCP, registro de ferramentas ou ambiente de implementação.
Várias ferramentas suportam validação automatizada de segurança MCP: Invariant MCP-Scan (especializado em varredura de segurança MCP), ferramentas SAST com regras MCP personalizadas, npm audit e pip audit para varredura de dependências, OSV-Scanner para verificações de banco de dados de vulnerabilidades, perfis Docker seccomp e AppArmor para isolamento em tempo de execução, e integração SIEM para monitoramento centralizado. Nenhuma ferramenta única cobre todos os itens da lista de verificação — a cobertura abrangente requer combinar análise estática, testes dinâmicos e monitoramento contínuo.
Arshia é Engenheira de Fluxos de Trabalho de IA na FlowHunt. Com formação em ciência da computação e paixão por IA, ela se especializa em criar fluxos de trabalho eficientes que integram ferramentas de IA em tarefas do dia a dia, aumentando a produtividade e a criatividade.
Use esta lista de verificação para autoavaliação e depois traga nossa equipe para uma auditoria de segurança verificada. Testamos cada item em seu ambiente em produção e entregamos um plano detalhado de remediação.
Servidores MCP expõem uma superfície de ataque única que combina riscos tradicionais de API com ameaças específicas de IA. Aprenda as 6 vulnerabilidades crítica...
A autenticação é a camada de segurança mais crítica para servidores MCP remotos. Aprenda por que o OAuth 2.1 com OIDC é obrigatório, como a delegação de tokens ...
O envenenamento de ferramentas e os rug pulls são dois dos vetores de ataque específicos do MCP mais perigosos. Aprenda como atacantes incorporam instruções mal...
