Anthropic elimina a burocracia do OAuth para conectores MCP do Claude

A Anthropic tornou geralmente disponível a Enterprise-Managed Authorization (EMA) para os conectores do Model Context Protocol (MCP) do Claude, segundo informações divulgadas em 24 de agosto de 2026. A mudança transfere a autorização de cada funcionário, repetida integração por integração, para o sistema corporativo já usado pela organização para gerenciar identidades e acessos. 3943

O MCP é um padrão aberto para conectar assistentes de IA a ferramentas externas, aplicativos de negócios, repositórios de dados e ambientes de desenvolvimento. 12 A EMA foi criada para facilitar o provisionamento e a governança dessas conexões por administradores, mantendo as políticas centrais de acesso da empresa.

O que muda para funcionários e administradores

Antes, o processo normalmente tinha duas etapas:

1. O administrador habilitava ou aprovava um conector para a organização.
2. Cada funcionário entrava separadamente no serviço conectado e concluía o fluxo de consentimento OAuth daquele serviço.

Com a EMA, o administrador configura o conector e a política de acesso no provedor de identidade da empresa. Funcionários autorizados por grupos, funções ou políticas existentes podem usar o conector durante a sessão de login único (SSO), sem um novo redirecionamento para o navegador ou uma tela de consentimento específica para cada integração. 4962

Isso não significa que o acesso fique sem controle. O provedor de identidade continua sendo a fonte da decisão de autorização da organização. Os administradores podem definir quais usuários ou grupos terão acesso e revogar essa permissão no mesmo sistema centralizado. 4142

Como funciona o fluxo baseado no provedor de identidade

A implementação usa a extensão MCP Enterprise-Managed Authorization e o perfil Identity Assertion JWT Authorization Grant — uma concessão de autorização baseada em uma asserção de identidade.

Em termos simplificados:

1. O funcionário entra no sistema de SSO da organização.
2. O provedor de identidade emite uma asserção de identidade assinada, na forma de um JSON Web Token (JWT).
3. O Claude apresenta essa asserção ao servidor de autorização do conector MCP.
4. O servidor valida a asserção e, se a política da organização permitir o acesso, emite o token de acesso normal do conector.
5. O Claude usa esse token para acessar o servidor MCP aprovado.

O funcionário não precisa repetir o consentimento OAuth do próprio conector porque o servidor recebe uma asserção verificável sobre sua identidade corporativa e seu contexto de autorização. 4963

A Okta implementa esse modelo por meio do Cross App Access (XAA). O XAA é o nome dado pela Okta à sua implementação da abordagem mediada pelo provedor de identidade; a extensão do MCP busca oferecer uma camada de protocolo aberta, sem exigir que todas as organizações usem um mecanismo proprietário da Okta. 3538

Compatibilidade com Claude, Claude Code e Cowork

O anúncio do projeto MCP informa que a Anthropic implementou a extensão em sua camada compartilhada do MCP. Assim, administradores podem autorizar servidores MCP para usuários do Claude, do Claude Code e do Cowork. 62

Na prática, isso cria um modelo de autorização consistente para diferentes cenários: uso conversacional do Claude, fluxos de desenvolvimento e experiências de desktop ou orientadas a agentes.

O Claude Code também oferece controles empresariais separados para a configuração de servidores MCP. Segundo a Anthropic, políticas gerenciadas podem impor permissões de ferramentas, restrições de acesso a arquivos e configurações de servidores MCP, incluindo listas de servidores controladas pela organização. 13 Portanto, a EMA cuida da transferência de identidade e autorização, enquanto as configurações gerenciadas do Claude Code podem limitar quais servidores MCP os usuários estão autorizados a configurar.

A documentação da plataforma da Anthropic também descreve credenciais OIDC de curta duração, emitidas pelo provedor de identidade da organização, para autenticar cargas de trabalho sem depender de chaves de API estáticas e duradouras. Esse é um movimento relacionado em direção à identidade corporativa, mas não deve ser confundido com o fluxo específico de EMA para conectores. 18

Quais conectores e provedores são compatíveis?

O material disponível confirma um grupo inicial de provedores MCP associado ao programa da Okta: Asana, Atlassian, Canva, Figma, Granola, Linear e Supabase. 3856

No entanto, as evidências fornecidas não estabelecem uma lista definitiva de todos os conectores compatíveis com o lançamento de disponibilidade geral de 24 de agosto. Também não é possível distinguir com segurança quais integrações já estão disponíveis e quais foram apenas planejadas. Da mesma forma, o material não apresenta uma relação completa de provedores de identidade além da implementação XAA da Okta.

Por isso, as organizações devem confirmar a disponibilidade de cada conector e a compatibilidade com seu provedor de identidade antes de considerar a EMA universalmente suportada.

O modelo de adoção não se limita à Okta. Os provedores de identidade precisam emitir as asserções exigidas, enquanto os desenvolvedores dos conectores MCP devem operar servidores de autorização capazes de aceitá-las e validá-las. A documentação da Anthropic descreve os requisitos para desenvolvedores que desejam permitir que seus servidores MCP recebam asserções corporativas e retornem tokens de acesso sem uma etapa separada de consentimento do usuário. 49

Qual foi o papel da Ramp?

A Okta citou a Ramp, a Webflow, a HubSpot e outros clientes em comum como participantes do programa inicial para governar o acesso ao Claude e a aplicativos de provedores MCP participantes. 38

As fontes fornecidas, porém, não trazem detalhes suficientes sobre a implantação específica da Ramp — como tamanho do rollout, combinação de conectores ou resultados medidos. Portanto, essas informações não devem ser deduzidas a partir do anúncio.

Por que a mudança importa para as empresas

A EMA ataca um gargalo prático na implementação de ferramentas conectadas à IA em escala. Prompts de OAuth individuais aumentam o trabalho de integração, dificultam a padronização do acesso e deixam os administradores dependentes de que cada funcionário conclua corretamente a configuração.

Com um fluxo centralizado no provedor de identidade, as permissões podem acompanhar os papéis e grupos que a organização já utiliza. O desligamento de um funcionário ou a mudança de função também pode ser refletido pela política corporativa central, em vez de exigir a revogação manual de cada conexão.

A fronteira de segurança também fica mais clara: o provedor de identidade decide se o usuário tem direito de acessar o conector, e o servidor de autorização do MCP valida a asserção antes de emitir seu próprio token de acesso. Ainda assim, as empresas precisam avaliar cada servidor MCP, aplicar políticas de menor privilégio e controlar quais servidores os usuários podem adicionar. A documentação do Claude Code recomenda o uso de servidores MCP confiáveis e permite restringir sua configuração por meio de definições gerenciadas ou mantidas no controle de código-fonte. 13

A principal mudança, portanto, não é que o OAuth simplesmente desapareceu. O que deixa de existir é o ciclo de consentimento repetido na interface do funcionário. No lugar dele entra uma troca de autorização gerenciada pela empresa, conectando a política do SSO ao acesso aos conectores MCP.

Para organizações que distribuem o Claude entre várias equipes, isso pode tornar o provisionamento mais uniforme no Claude, no Claude Code e no Cowork, preservando o controle administrativo centralizado. 4962