Servidores MCP para IAM: quais podem criar usuários e quais só podem ler

Um pedido comum a um administrador: “Crie um usuário, adicione-o ao grupo Engineering e revogue o acesso daqui a uma semana”. Para um agente de IA, isso é uma frase. Para IAM, são várias operações administrativas, e cada uma pode acabar em um incidente. O autor de um artigo no Habr comparou o que os fornecedores já oferecem por meio do Model Context Protocol, e encontrou um cenário desigual.

O que cada um pode fazer em 9 de novembro de 2026

O autor consultou a documentação oficial e as listas de ferramentas. Não submeteu os tenants a testes de carga, portanto esta é uma comparação das capacidades anunciadas, não uma auditoria independente.

Okta: servidor auto-hospedado e de código aberto, em disponibilidade geral desde fevereiro de 2026, capaz de criar e modificar usuários e grupos. Oferece escopos OAuth, filtragem de ferramentas e aprovação de ações destrutivas por meio do MCP Elicitation. A versão hospedada ainda está em Early Access.

Microsoft MCP Server for Enterprise: em prévia pública e somente leitura, com três ferramentas para solicitações GET do Graph e acesso ao esquema.

PingOne Remote MCP Server: em Early Access, permite criar, modificar e excluir usuários, mas o próprio fornecedor desaconselha habilitar essas funções em produção. A ativação em um ambiente expõe todas as ferramentas permitidas pela função.

JumpCloud: criação, suspensão e exclusão de usuários, alteração de grupos, revogação de sessões OAuth e eventos no Directory Insights.

Auth0: o servidor automatiza aplicações, APIs, Actions e logs, mas a documentação de referência não inclui gerenciamento de usuários e grupos. Para a tarefa de cadastrar um funcionário, essa é uma diferença fundamental.

Nos materiais oficiais, o Keycloak aparece como servidor de autorização para outros servidores MCP, e não como o sistema administrado. Para administrar o diretório, é necessário usar um servidor da comunidade e avaliar separadamente seu modelo de acesso.

Cinco verificações em vez de contar ferramentas

1. O que vem habilitado por padrão. O ideal é que o servidor esteja desativado ou opere em modo somente leitura até que um administrador autorize mais capacidades. A granularidade dos controles após a ativação também importa.
2. Em nome de quem o agente atua. A identidade OAuth de um administrador, com suas funções atribuídas, facilita a auditoria mais do que uma chave de API compartilhada em variáveis de ambiente.
3. Verificação de permissões em cada chamada. Ocultar ferramentas desnecessárias em tools/list é útil, mas isso não é autorização. A verificação também é necessária em tools/call: a lista pode estar desatualizada, e uma chamada pode ser montada manualmente.
4. O que exatamente a pessoa aprova. Na Okta, se o cliente não consegue exibir um diálogo de Elicitation, o servidor retorna um JSON para o modelo interpretar. O limite de confiança é diferente daquele de uma página de aprovação gerada pelo próprio sistema IAM a partir de uma operação armazenada.
5. Como identificar o agente nos logs. É preciso saber qual cliente iniciou a alteração e quem a aprovou. A Ping registra na auditoria tanto o user_id do administrador quanto o client_id do servidor MCP.

A injeção de prompt representa um risco adicional: o nome de um grupo ou um atributo de usuário pode conter uma instrução para o modelo. Os resultados das ferramentas não devem ser tratados como comandos confiáveis; cabe ao servidor impor os limites de permissão.

Uma aprovação, uma operação

O autor desenvolve o issuerd e declara isso expressamente. Em seu projeto, o servidor armazena os valores canônicos de tool e arguments; a pessoa se autentica novamente e vê uma página montada com dados do servidor. Após a aprovação via CIBA, o cliente recebe um token DPoP de curta duração, sem refresh token. Alterações no id, nos argumentos ou no realm são rejeitadas, e a repetição da mesma chamada retorna o resultado armazenado sem executar uma segunda exclusão.

Isso não é um padrão do MCP. Exige um cliente com suporte a DPoP e CIBA, e o issuerd não oferece administração entre realms nem M2M sem intervenção humana.

O que fazer na prática

A especificação MCP Authorization 2026-07-28, com OAuth 2.1 e Resource Indicators, trata de como um cliente obtém acesso a um servidor MCP. Ela não define como uma pessoa aprova a exclusão de um usuário específico.

O checklist do autor: começar com um tenant de testes e modo somente leitura; comparar o tools/list real com a tarefa; atribuir uma função com o mínimo de permissões; preferir uma identidade delegada a um segredo compartilhado; exigir uma nova aprovação para exclusões e funções privilegiadas; filtrar as ações MCP nos logs de auditoria; e ensaiar antecipadamente a revogação do acesso do agente. Os status Early Access e “não recomendado para produção” fazem parte da decisão de arquitetura, não são letras miúdas.

As verificações precisam estar onde o modelo não possa reescrevê-las: nas funções, nos escopos, na audiência do token, na página de aprovação gerada pelo servidor e nos logs de auditoria. O velho problema do confused deputy continua existindo; agora o intermediário simplesmente explica suas ações com eloquência.