MCP servers for IAM: which can create users and which can only read

A routine request to an administrator: “Create a user, add them to the Engineering group and revoke access in a week.” For an AI agent, that is one sentence. For IAM, it is several administrative operations, each of which could trigger an incident. The author of an article on Habr compared what vendors already offer through Model Context Protocol, and the findings were mixed.

Who can do what as of November 9, 2026

The author checked official documentation and tool lists. He did not put tenants under load, so this is a comparison of advertised capabilities, not an independent audit.

Okta: a self-hosted, open-source server, generally available since February 2026, that can create and modify users and groups. It provides OAuth scopes, tool filtering and approval of destructive actions through MCP Elicitation. The hosted version is still in Early Access.

Microsoft MCP Server for Enterprise: public preview and read-only, with three tools for Graph GET requests and schema access.

PingOne Remote MCP Server: Early Access, with support for creating, modifying and deleting users, although the vendor itself advises against enabling this in production. Enabling it for an environment exposes every tool permitted by the role.

JumpCloud: user creation, suspension and deletion, group changes, OAuth session revocation and events in Directory Insights.

Auth0: the server automates applications, APIs, Actions and logs, but its reference documentation lists no user or group management capabilities. For the task of onboarding an employee, that is a fundamental distinction.

In official materials, Keycloak acts as an authorization server for other MCP servers, rather than as the system being administered. Administering the directory requires a community server and a separate assessment of its access model.

Five checks instead of counting tools

1. What is enabled by default. Ideally, the server is disabled or read-only until an administrator explicitly allows more. The granularity of controls after enabling it also matters.
2. Whose identity the agent uses. An administrator’s OAuth identity, with their assigned roles, is easier to audit than a shared API key in environment variables.
3. Permission checks on every call. Hiding unnecessary tools in tools/list is useful, but it is not authorization. Checks are also needed at tools/call: the list may be outdated, and a call can be constructed manually.
4. Exactly what the human approves. With Okta, if the client cannot display an Elicitation dialog, the server returns JSON for the model to interpret. That creates a different trust boundary from an approval page generated by the IAM system itself from a stored operation.
5. Identifying the agent in the logs. You need to establish which client initiated a change and who approved it. Ping records both the administrator’s user_id and the MCP server’s client_id in its audit log.

Prompt injection remains a separate concern: a group name or user attribute could contain an instruction for the model. Tool results must not be treated as trusted commands; the server must enforce permission limits.

One approval, one operation

The author develops issuerd and explicitly discloses that fact. In his project, the server stores the canonical tool and arguments, while the human authenticates again and sees a page assembled from server-side data. After CIBA approval, the client receives a short-lived DPoP token without a refresh token. Changes to the id, arguments or realm are rejected, while repeating the same call returns the stored result without performing a second deletion.

This is not an MCP standard. It requires a client with DPoP and CIBA support, and issuerd offers neither cross-realm administration nor unattended M2M.

What to do in practice

The MCP Authorization 2026-07-28 specification, with OAuth 2.1 and Resource Indicators, addresses how a client obtains access to an MCP server. It does not define how a human approves the deletion of a specific user.

The author’s checklist: start with a test tenant and read-only mode; compare the actual tools/list with the task; assign a least-privilege role; prefer a delegated identity over a shared secret; require fresh approval for deletions and privileged roles; filter MCP actions in the audit logs; and rehearse revoking the agent’s access in advance. Early Access and “not for production” are architectural considerations, not fine print.

Checks need to live where the model cannot rewrite them: in roles, scopes, the token audience, a server-generated approval page and audit logs. The old confused deputy problem has not gone away; the intermediary can now simply explain its actions eloquently.