Last updated: September 2026
Okta’s Managed MCP Server, announced in September 2026 and currently in Early Access, is a hosted Model Context Protocol endpoint that lets an AI client such as Claude Code or Cursor manage Okta users, groups, apps, policies, system logs and governance workflows in natural language, with tool exposure gated by OAuth scopes and the signed-in admin’s privileges. It is worth being precise about what is new: Okta shipped an open-source MCP server for Okta administration in September 2025, and the 2026 release is the hosted version of that idea, with nothing to run locally. On Keycloak the equivalent is not a product you buy but an assembly: the Admin REST API, a service-account client scoped with realm-management roles, and an MCP server you own that wraps the calls you’re willing to expose.
The tradeoff is the usual one and it is worth stating plainly rather than pretending otherwise. Okta’s version works this afternoon and Keycloak’s version does not. What you get in exchange is control over exactly which administrative verbs an AI client can reach, and an audit trail in a system you already operate.
Is conversational IAM the same thing as MCP authorization?
No, and the two get conflated constantly because both involve MCP and an identity provider. They sit on opposite sides of the connection.
Conversational IAM means administering the identity provider itself by talking to it. The IdP is the resource being managed, the MCP server exposes admin operations as tools, and the human in the loop is an identity administrator. That is what Okta’s Managed MCP Server does.
MCP authorization means the identity provider issues tokens so that agents can call somebody else’s tools. The IdP is the authorization server, the MCP server is some unrelated application, and the human is an end user delegating access. That is what we covered in Keycloak as an MCP authorization server and in the CIMD client registration walkthrough.
You can need both, and the security reasoning for each is different. The first question is which administrative actions an AI assistant may perform against your directory. The second is which user resources an agent may reach on someone’s behalf. Getting the answer to one does not give you the other.
What does the Okta Managed MCP Server actually ship?
According to Okta’s product announcement, “Introducing the Okta Managed MCP Server: Manage your Okta org with natural language,” published in September 2026, the server is a turnkey hosted endpoint that AI clients connect to directly, with no local process to install or credentials to distribute to laptops. It covers users, groups, applications, policies, system logs and governance workflows through Okta’s admin management APIs.
Three design choices in it are worth borrowing regardless of which IdP you run:
- Tool access follows scopes. Okta says the server enforces your existing OAuth scopes and least-privilege boundaries, so what the AI client can actually do is bounded by the grant and by the signed-in admin’s privileges rather than by the model’s judgement.
- Hosted means no credential sprawl. The usual failure mode of a local MCP server is an admin API token sitting in a config file on a developer laptop, syncing to a dotfiles repo. A hosted endpoint with a per-admin OAuth session eliminates that.
- Server-side input handling and a confirmation gate. Okta describes schema validation and a request sanitizer on the server rather than trusting whatever JSON the model produced, and its 2026 release notes describe using the MCP Elicitation API so destructive actions such as deleting an app or deactivating a user require explicit confirmation. Anyone building this themselves should copy both instincts.
How do you build the same thing on Keycloak?
You build it out of three parts, and none of them are exotic. The Admin REST API is the tool surface, a service-account client is the identity the tools act as, and realm-management client roles are the blast radius.
1. Create a confidential client with service accounts enabled. Use grant_type=client_credentials. Do not reach for the password grant against admin-cli, which plenty of Keycloak tutorials still use, including parts of our own Admin REST API guide: Keycloak 26.2 disabled Direct Access Grants by default for new clients and flagged the grant as deprecated by reference to the OAuth security best current practice, and RFC 9700 says it must not be used. The same guide covers the service-account setup and the 403 you get when the roles are wrong.
2. Scope the service account narrowly. Assign only the realm-management client roles the tools actually need. A read-mostly assistant wants view-users, query-users, view-clients and view-events. It does not want realm-admin, which is the composite that contains everything and the default many teams reach for because it makes the 403s stop.
# Grant only the roles the tools need, never the realm-admin composite.
# The service account username is service-account-<clientId>.
kcadm.sh add-roles -r your-realm
--uusername service-account-mcp-admin
--cclientid realm-management
--rolename view-users
--rolename query-users
--rolename view-clients
--rolename view-events3. Wrap the calls in an MCP server you control. This is where the design work is. The temptation is to expose the Admin API generically, one tool per endpoint, and let the model figure it out. That produces exactly the blast radius you were trying to avoid. The better shape is a small number of task-level tools that map to things you would actually authorize: “find users who have not logged in since date,” “list clients missing an audience mapper,” “show admin events for this realm in the last hour.”
Two Keycloak specifics make this materially safer than a generic API wrapper:
- Short access-token lifespans. Set the access token lifespan on the service-account client to minutes. The client credentials grant re-mints cheaply, and a leaked token expires before it is useful.
- Sender-constrained tokens. Keycloak supports DPoP, which binds the token to a key the client holds, so a stolen bearer token cannot be replayed from elsewhere. We walked through the mechanics in DPoP with the Keycloak Admin API.
If your tools need to page through large realms, the bulk pagination notes will save you the first round of timeouts.
Should an AI assistant be allowed to write to your directory at all?
Start read-only, and make the write path a separate decision with a separate approval. To be fair to Okta, it does not ignore this: the Managed MCP Server gates destructive operations behind an explicit confirmation step. Read-only-first is the stricter position beyond that gate, and it’s worth taking deliberately rather than discovering later, because the demo that sells the feature is always a write.
The reasoning is not that models are unreliable in general. It is that the consequences are asymmetric and the rollback story is poor. A misread query returns wrong data to a human who will notice. A misapplied group membership grants standing access that nobody notices until an audit, and Keycloak has no undo for an admin operation any more than Okta does.
What we’d actually ship first: an assistant with
view-users,query-usersandview-events, and no write tools whatsoever. That covers the genuinely common asks, which are investigative rather than mutative: why did this login fail, who is in this group, which clients have not been used this quarter. Teams that start there tend to find read access carries most of the value on its own, and then add writes deliberately for the two or three workflows that justify them.
When you do add writes, scope each one to a task rather than to an endpoint, require a confirmation step in the tool contract as Okta’s server does, and log the resulting admin event with the human’s identity attached rather than only the service account’s.
Which one should you pick?
The honest answer depends on a question that has nothing to do with MCP: whose identity provider is already the system of record.
| Okta Managed MCP Server | Keycloak plus your own MCP server | |
|---|---|---|
| Time to first working tool | Immediate, hosted | Days, you build it |
| What it can reach | Okta’s admin API surface | Exactly what you expose |
| Where credentials live | Okta’s hosted session | Your service-account client |
| Audit trail | Okta System Log | Keycloak admin events, your pipeline |
| Availability | Early Access as of September 2026 | Generally available components |
| Cost model | Part of the Okta relationship | Infrastructure you already run |
If Okta is your workforce IdP and you want conversational administration of it, use the Okta product rather than rebuilding a narrower version of something your existing relationship already covers.
The case for the Keycloak path is different. It applies when the directory you want an assistant to reason about is your customer identity system rather than your employee directory, when you need the tool surface to be narrower than a vendor’s default, or when the same realm is already doing double duty as your MCP authorization server for agent workloads. In that last case the two stories converge usefully: one Keycloak realm is both the thing administered conversationally and the authorization server issuing agent tokens, and there is exactly one audit log to read afterwards.
Hybrid arrangements are common and entirely reasonable. Keeping Okta for workforce while running Managed Keycloak for customer identity and agent authorization is a normal shape, and we covered the boundaries in the Keycloak and Okta comparison. Teams going further in one direction can read the Okta to Keycloak migration guide, and the wider agentic identity picture is in Agentic IAM in 2026.
Frequently asked questions
What is the Okta Managed MCP Server?
It is a hosted Model Context Protocol endpoint, announced in September 2026 and in Early Access, that lets AI clients including Claude Desktop, Claude Code, Cursor and VS Code manage an Okta org in natural language. It covers users, groups, apps, policies, system logs and governance workflows, with access bounded by OAuth scopes and the signed-in admin’s privileges.
How is it different from Okta’s open-source MCP server?
Okta released an open-source MCP server for Okta administration in September 2025, which you run yourself and configure with credentials locally. The 2026 Managed MCP Server is hosted by Okta, so there is no local process and no admin token distributed to developer machines. The capabilities overlap substantially, but the operational model is the thing that changed.
Does Keycloak have an official MCP server for administration?
Not for administration. Keycloak documents itself as an MCP authorization server, which is the other side of the problem: issuing tokens so agents can call other tools. For conversational administration you wrap the Admin REST API in an MCP server you build and operate, using a service-account client scoped with realm-management roles.
What Keycloak permissions does an admin assistant need?
Only the realm-management client roles matching the tools you expose. A read-oriented assistant typically needs view-users, query-users, view-clients and view-events. Avoid the realm-admin composite, which grants the full administrative surface and makes least privilege impossible to reason about afterwards.
Can I audit what an AI client did to my realm?
Yes. Keycloak records admin events and login events, and both can be exported to your existing log pipeline. The useful refinement is carrying the human operator’s identity into the tool call rather than logging only the service account, so the trail shows who asked rather than only which client acted.
Is this the same as securing an MCP server with Keycloak?
No. Securing an MCP server means Keycloak issues access tokens that let agents call that server’s tools, which is a delegation problem. Conversational IAM means an MCP server exposes Keycloak’s own administration as tools, which is a privileged-access problem. The configurations, the threat models and the people who sign off on them are different.
Sources
- Okta, “Introducing the Okta Managed MCP Server: Manage your Okta org with natural language,” September 2026, retrieved 2026-09-15, https://www.okta.com/blog/product-innovation/okta-managed-mcp-server-ai-agents/
- Okta Developer, “Okta MCP Server API release notes 2026,” MCP Elicitation API confirmation for destructive actions, retrieved 2026-09-15, https://developer.okta.com/docs/release-notes/2026-okta-mcp-server/
- Okta Developer, “Introducing the Okta Open Source MCP Server,” September 2025, retrieved 2026-09-15, https://developer.okta.com/blog/2025/09/22/okta-mcp-server
- Keycloak, “Integrating with Model Context Protocol (MCP),” retrieved 2026-09-15, https://www.keycloak.org/securing-apps/mcp-authz-server
- IETF, “RFC 9700, Best Current Practice for OAuth 2.0 Security,” retrieved 2026-09-15, https://www.rfc-editor.org/rfc/rfc9700