OAuth sem toque zero para MCP

Escopo e Objetivos do OAuth Sem Toque / EMA

• Transfere o consentimento OAuth de usuários finais individuais para o IdP corporativo/admin de TI da empresa.
• Destinado principalmente a contas de funcionários, não a contas pessoais.
• Benefícios prometidos:
  • Controle centralizado sobre quais servidores MCP e apps podem acessar dados corporativos.
  • UX de “simplesmente funciona”: quando os funcionários entram em um LLM via SSO, todas as conexões MCP pré-aprovadas já estão ativas.
  • Melhor auditabilidade e conformidade, especialmente em ambientes regulados.
  • Ajuda a impedir que dados fluam para contas SaaS pessoais quando existem contas corporativas.

Debates sobre Segurança, Atrito e Consentimento

• Alguns argumentam que o “atrito” atual do OAuth (prompts, consentimento por app) é uma característica, não um bug.
• Preocupação: agentes poderiam ser enganados via prompt injection para usar MCPs poderosos (por exemplo, banco) sem opt-in explícito por conversa.
• Outros respondem que:
  • Controle refinado e autorização por ferramenta/tarefa devem ser aplicados pelo cliente/harness, não apenas pelo provedor do LLM.
  • O EMA não muda fundamentalmente o fato de que a autenticação MCP é por usuário, não por conversa.
• Há receio de os funcionários perderem visibilidade e responsabilidade sobre o que está conectado em seu nome.

Identidade Empresarial vs. do Consumidor

• O EMA é visto como bem alinhado à realidade empresarial:
  • A empresa efetivamente “possui” a identidade e pode revogar ou reestruturar o acesso centralmente.
  • Encaixa-se em ambientes onde as afirmações do IdP são a principal âncora de confiança.
• Vários comentaristas argumentam que esse modelo é problemático para identidade de consumidor, onde:
  • Cada aplicação possui diretamente a conta do usuário.
  • Nenhum IdP único pode agir com segurança como uma autoridade universal de delegação.

MCP vs Skills / Outros Padrões de Integração

• O debate continua sobre MCP vs ferramentas baseadas em “skills”/CLI:
  • Pontos pró-MCP: descrições semânticas dos servidores, busca de ferramentas, melhores trilhas de auditoria, implantação padronizada, sem necessidade de execução arbitrária de código.
  • Críticos observam riscos de exposição de tokens e argumentam que objetivos semelhantes podem ser alcançados com ferramentas/skills mais proxies ou gateways.
• Alguns veem o MCP cada vez mais como uma “framework de apps” com autenticação compartilhada, e não apenas um protocolo.

Questões de Implementação e Padrões

• O mecanismo subjacente (ID-JAG) não é específico do MCP e poderia ser usado para CLIs ou outros clientes OAuth.
• O registro dinâmico de clientes é um ponto problemático; muitos IdPs (por exemplo, alguns diretórios corporativos) não têm bom suporte, forçando soluções alternativas como proxies ou clientes pré-registrados.
• O trabalho continua em autorização no nível de tarefa, delegação em múltiplos saltos e atenuação de tokens estilo capability, mas os detalhes ainda estão evoluindo e são um pouco अस्प claros.