O Problema do Escopo Wildcard: Por que as Configurações MCP Default para admin:* em vez de Menor Privilégio

Se você grep seus próprios mcp.json agora, há uma boa chance de que você encontre uma string de escopo que se pareça com "admin:*" ou "full_access" em algum lugar. Não porque alguém se sentou e decidiu que uma ferramenta precisava de direitos administrativos abrangentes, mas porque quando o README de um servidor diz "conceda este escopo para fazê-lo funcionar" e a versão enumerada não está documentada em lugar nenhum, o curinga é apenas mais rápido de copiar e colar.

Eu voltei através do lado de configuração das heurísticas do sentinel-scan-cli (as verificações estáticas apenas do manifesto, sem sondagem ao vivo) e a verificação de escopo curinga é uma das mais simples, e também uma das mais consistentemente úteis uma vez que você começa a procurá-la.

O que realmente sinaliza

A regra é estreita de propósito: uma ferramenta ou entrada de servidor declara um campo de escopo/permissão que é um curinga ou um termo abrangente não limitado em vez de uma lista enumerada. Concretamente, coisas como:

{
  "mcpServers": {
    "internal-crm": {
      "command": "npx",
      "args": ["-y", "@example/crm-mcp"],
      "scopes": ["admin:*"]
    }
  }
}

versus a versão que realmente diz o que a ferramenta toca:

{
  "mcpServers": {
    "internal-crm": {
      "command": "npx",
      "args": ["-y", "@example/crm-mcp"],
      "scopes": ["contacts:read", "contacts:write", "notes:read"]
    }
  }
}

Ambas as configurações podem acabar concedendo à mesma ferramenta o mesmo acesso efetivo se o servidor chamar apenas três endpoints de CRM internamente. A diferença é que a segunda diz a você, e a qualquer um que revisar a configuração depois, exatamente quais são esses três endpoints. A primeira não diz nada até que você leia o código-fonte do servidor ou espere que algo dê errado.

Por que isso vale a pena verificar, mesmo que seja "apenas texto de configuração"

Esta é uma verificação de manifesto estático, não uma auditoria de capacidade em tempo de execução, então tem uma limitação honesta: não pode dizer o que um escopo curinga realmente resolve no nível da API, e não pode pegar um servidor que declara seu escopo de forma insuficiente, mas que ultrapassa em código de qualquer maneira. O que ela captura é a falha muito mais comum, que é ninguém se importando em enumerar escopos porque o curinga já "funciona".

O lugar onde isso dói geralmente é meses depois, quando um segundo servidor MCP não relacionado é adicionado à mesma sessão do agente e agora você tem uma ferramenta de CRM com escopo curinga ao lado de uma ferramenta que lê conteúdo da web arbitrário. Revisar "essa combinação faz sentido" é muito mais difícil quando um lado é admin:* em vez de uma lista curta e concreta. Auditar o aumento de escopo é basicamente impossível retroativamente se nada foi registrado de forma restrita desde o início.

A correção está quase sempre disponível, apenas não é o caminho padrão

A maioria dos servidores MCP que suportam permissões com escopo também suportam escopos enumerados, o curinga tende a ser o primeiro exemplo no README porque é mais curto de escrever. Enumerar leva cinco minutos a mais de leitura da lista de ferramentas do servidor e mapeamento das ferramentas que você realmente vai chamar, e se paga na primeira vez que alguém precisa revisar a configuração sem explorar o código-fonte do servidor.

Se você quiser verificar seus próprios arquivos mcp.json para esse padrão (e uma mão cheia de problemas estáticos relacionados: transportes remotos em texto simples, credenciais codificadas em args, falta de metadados de proveniência em servidores de origem remota) sentinel-scan-cli faz isso como uma verificação estática pura, sem chamadas de rede, sem execução de servidor. Mapeado contra as categorias do OWASP MCP Top 10 em um relatório de amostra se você quiser ver a forma completa da saída antes de executá-lo.

Como está a granularidade do seu escopo real em configurações de produção, enumerada por padrão ou curinga até quebrar?