← Todos os insights

Análise de tendênciaRecorte: Brasil5 min de leitura

MCP é fácil na demo. Em produção, toda chamada de ferramenta precisa de um nome por trás

Uma arquitetura de referência da AWS põe SSO corporativo, OAuth e checagem de token antes de uma ferramenta MCP; os agentes da Ping agem com a autoridade do usuário. É aí que começa o MCP enterprise.

Ouça este artigo · 6 min

Narração completa do artigo, gerada por IA.

Um espelho de fechadura de bronze ornamentado sobre fundo escuro, em duotone La Madre, ao lado das palavras Em nome de quem?
Foto: The Cleveland Museum of Art (rawpixel, CC0)

As demos de Model Context Protocol costumam mostrar como é fácil um agente ganhar uma ferramenta nova: aponte para um servidor e a ferramenta aparece. Nas empresas, a pergunta é a oposta. Quem está chamando essa ferramenta, com autoridade de quem, e como cada chamada é verificada? Dois anúncios da última semana respondem por lados diferentes.

AWS: a ferramenta fica atrás da identidade corporativa

Em 2 de outubro, o arquiteto de soluções da AWS Jishnu Dasgupta publicou uma arquitetura de referência para dar busca na web ao Claude Desktop pelo Amazon Bedrock AgentCore Gateway. O ponto do desenho é o que o desktop não guarda: nenhuma chave de API de busca na máquina do usuário.

A cadeia funciona assim. O usuário entra pelo AWS IAM Identity Center, o SSO da organização. O Amazon Cognito federa essa identidade e emite um JWT por um fluxo OAuth 2.0 de código de autorização. O AgentCore Gateway valida o token a cada requisição e expõe a ferramenta gerenciada de busca como endpoint compatível com MCP, via HTTP com streaming. O Claude Desktop descobre a ferramenta com a chamada padrão tools/list do MCP e a usa quando precisa de informação atual. A AWS diz que o tráfego das consultas fica dentro da infraestrutura dela.

Dois limites para registrar. É uma arquitetura de tutorial, não uma afirmação de que todo deploy de MCP precisa exatamente desse stack. E a busca gerenciada está disponível hoje em US East (Norte da Virgínia), Europa (Irlanda) e Ásia-Pacífico (Tóquio), não em São Paulo; a configuração do Identity Center exige a conta de gerenciamento do AWS Organizations.

Ping: o agente empresta a autoridade do usuário

Em 29 de setembro, a Ping Identity lançou três agentes de identidade para o Gemini Enterprise, disponíveis no Google Cloud Marketplace e construídos com o Agent Development Kit do Google. Funcionários podem gerenciar seus dispositivos de autenticação conversando; o help desk e os administradores de identidade cuidam de usuários, sessões, acessos e cadastro de MFA.

O detalhe de desenho que importa: a Ping diz que o agente de dispositivos segue o modelo de menor privilégio, não guarda credenciais permanentes e não age sem a orientação do usuário autenticado. As ações passam pelas APIs da Ping, dentro da autoridade atribuída à pessoa, e mudanças administrativas no Advanced Identity Cloud exigem confirmação explícita. O CEO Andre Durand resumiu como manter “cada ação ligada à autoridade da pessoa por trás dela”.

Cinco identidades em cada chamada de ferramenta

Juntando as duas coisas, uma chamada MCP em produção envolve mais identidades do que a demo admite:

  • a pessoa que pediu o trabalho;
  • o agente que decidiu chamar a ferramenta;
  • a credencial que a chamada carrega, de preferência curta e com escopo para aquela chamada;
  • a identidade da ferramenta ou do servidor, em que o gateway confia;
  • o responsável pelo agente e pela ferramenta.
Uma chamada MCP com identidade na frenteQUEMO QUÊAPLICADO E REGISTRADO01Usuárioentra com oSSOcorporativo02Tokenemitidopara esseusuário ecliente03Agente pedeaferramentavia MCP04Gatewayvalidatoken epolítica05Ferramentaroda com aautoridadedo usuário06Chamadaregistradacomusuário,agente eferramentaIdentidade humanaIntenção do agente
  1. Usuário entra com o SSO corporativo
  2. Token emitido para esse usuário e cliente
  3. Agente pede a ferramenta via MCP
  4. Gateway valida token e política
  5. Ferramenta roda com a autoridade do usuário
  6. Chamada registrada com usuário, agente e ferramenta
  • Quem: Usuário entra com o SSO corporativo · Token emitido para esse usuário e cliente
  • O quê: Agente pede a ferramenta via MCP
  • Aplicado e registrado: Gateway valida token e política · Ferramenta roda com a autoridade do usuário · Chamada registrada com usuário, agente e ferramenta

Identidade humanaIntenção do agente

O agente decide chamar uma ferramenta. O gateway decide se esse usuário pode, por meio desse agente, agora.

O que os times enterprise devem levar disso

Pare de distribuir chaves de API estáticas para agentes. Uma chave num notebook ou na configuração de um agente é uma credencial sem usuário associado. Coloque as ferramentas atrás de um gateway que aceite tokens ligados a uma pessoa logada ou a uma identidade de agente.

Decida quando o agente age como o usuário e quando age como ele mesmo. Autoridade delegada (o modelo da Ping) é o certo quando a ação pertence ao usuário. Uma identidade própria do agente, com direitos estreitos, é o certo para trabalho em segundo plano. Misturar as duas, por exemplo um agente com todos os direitos de um usuário rodando sozinho, é onde os incidentes começam. Tratamos dessa distinção na análise sobre identidade de agentes como disciplina própria de IAM.

Faça do gateway o ponto de controle. Validação de token, lista de ferramentas permitidas e política por ferramenta devem ficar num único lugar que registra cada chamada. É o papel que descrevemos para o gateway de IA como ponto de aplicação de política.

Use o provedor de identidade que você já tem. Num ambiente Microsoft, as mesmas perguntas são respondidas com o Entra ID como provedor de identidade e um gateway como o Azure API Management na frente dos servidores MCP. O post da AWS não cobre essa configuração, e os detalhes mudam, mas as perguntas de auditoria são as mesmas.

Olhe para onde vão as consultas. Para uma empresa brasileira, uma ferramenta que roda na Virgínia ou na Irlanda significa que as consultas, e o que elas carregam, saem do país. Se um funcionário colar dados de clientes numa busca, isso é transferência internacional de dados pessoais, com as exigências que a ANPD regulamentou. Não é motivo para não usar; é motivo para decidir antes o que pode entrar numa consulta e registrar a base para a transferência.

Lembre por que isso é urgente. O novo relatório de ameaças da Microsoft, que analisamos em o texto sobre agentes e higiene de identidade, lista identidade do agente, autenticação entre agentes e revogação entre as perguntas que agora são do time de segurança.

O que fazer agora

  1. Inventarie os servidores e ferramentas MCP em uso, inclusive os que desenvolvedores conectaram por conta própria, e as credenciais de cada um.
  2. Tire chaves estáticas de desktops e configurações de agentes; troque por tokens validados no gateway.
  3. Classifique cada ferramenta: age como o usuário ou como o agente. Registre.
  4. Exija SSO em toda chamada de ferramenta disparada por pessoa, e registre usuário, agente e ferramenta juntos.
  5. Inclua confirmação em ações administrativas ou irreversíveis, como a Ping faz em mudanças de identidade.
  6. Verifique onde a ferramenta roda e para onde vai o tráfego antes de liberá-la para dados regulados.

Em resumo

O MCP resolveu como agentes encontram ferramentas. Não resolveu quem pode usá-las. As empresas que vão levar MCP para produção são as que tratam cada chamada de ferramenta como uma requisição autenticada, autorizada e registrada, com uma pessoa ou um agente nomeado por trás.

Tem um caso de uso de IA parado entre o protótipo e a produção?

Conte o que você quer colocar no ar. Respondemos com próximos passos honestos.

Converse sobre um caso de uso