Three high-priority IAM actions you can automate with natural language using the Okta MCP Server

As the Okta admin for your org, you’re probably still clicking through the console to accomplish your daily identity security tasks.

That is not a criticism. For most of the time identity platforms have existed, clicking was the only option: navigate, select, submit, confirm. The console was the interface. Now it does not have to be.

What does the Okta MCP Server do?

The Okta MCP Server lets AI agents interact with your Okta org through natural language. The Okta MCP Server implements the Model Context Protocol (MCP), an open standard for connecting AI agents to external tools. Your agents can query users, manage groups, create and update applications, read and apply policies, pull System Log data, and much more—all through natural language prompts.

You tell the agent what you want. The Okta MCP Server translates that prompt into structured Okta API calls, runs them, and returns a result. Every action carries a full audit trail, attributed the same way a human admin action would be. AI clients include Claude, GitHub Copilot, and any other MCP-compatible clients with protocol version compatibility.

More than 200 organizations are already running it. Here is how some of them are using it.

Use case 1: Continuous automated Okta System Log monitoring

A global customer relationship management platform provider uses Claude and the Okta MCP Server on Azure to monitor its Okta logs every five minutes. 

The implementation

At the center of the setup is a Claude skill that scans the Okta System Log on that schedule and flags problems such as lockouts and users who sign in from prohibited geographic zones. A second Claude tool, connected through the same server, can block a user, such as someone who signs in from another country.

Tasks that are too repetitive to do manually at the required frequency, too sensitive to skip, and well-defined enough that an agent can run them reliably are tailor-made for automation. The organization turned Okta log monitoring from a periodic manual review into a continuous automated control.

The Okta MCP Server runs on a virtual server in Azure, with each user connecting from their own Claude instance. About 10 admins on the IT security team use the setup every day for distinct tasks. IT support handles onboarding, offboarding, and user management. IT security monitors logs. Two people build and operate the system, and everyone else uses the skills.

Essential guardrails

Three guardrails limit what the AI can change, who it acts as, and what reaches production:

• Role restriction: The team gives new staff log admin or org admin roles, never super admin. Claude authenticates as the person using it, so access stays per person.
• Scope and change governance: The team reviews API scopes and gets Director or CTO approval before anything goes to production.
• Sandbox verification: The team tests any new MCP server in a sandbox first.

Scaling the tool

The team plans to extend the setup to include: 

• Full automation of onboarding, offboarding, and user management 
• Chaining Okta with other connectors, such as Google Workspace, in a single Claude request

Use case 2: A multi-agent pipeline with human-in-the-loop approval

An instructional technology and textbook publishing company built a multi-system pipeline where agents do the preparation work and a human authorizes the final action. The pipeline runs entirely in the cloud.

The implementation

Each request moves through a five-stage automated pipeline:

1. An employee submits a Jira ticket.
2. Atlassian Rovo classifies the request.
3. A GitHub Copilot cloud agent formats it and opens a GitHub issue.
4. A human reviews and approves.
5. The Okta MCP Server executes.

The company uses the pipeline for three jobs:

• SAML and OpenID Connect (OIDC) app onboarding
• Monthly vendor and app-usage reporting
• ThreatInsight monitoring

The human-in-the-loop design is deliberate: agents handle the coordination work, but no identity change executes without a human sign-off.

Best practices for building a managed pipeline

Teams with a similar pipeline to manage who want less overhead managing and servicing the MCP Server can use the Okta Managed MCP Server instead. Here’s how:

• Give the pipeline only the tools it needs. The server loads a tool only when the connection holds its OAuth scope, so tools the workflow never uses never load.
• Start with reporting. Best practices say to begin with read-only work. 
• Keep a person in the approval step. Deactivating or deleting an app already requires an explicit confirmation through the elicitation feature. 

To build a similar workflow, an admin can:

1. Create an OIDC app integration with Proof Key for Code Exchange (PKCE), and assign it only to the people or groups who need it.
2. Grant only the scopes the workflow needs, such as okta.apps.read, okta.apps.manage, and okta.logs.read.
3. Create a separate app for each role so least privilege can be effectively implemented. 
4. Connect an MCP client to the Okta Managed MCP Server, and confirm it with a low-risk question, such as "What is the current account status for user alice@example.com?"
5. Review the scopes regularly, and remove any you no longer use.

Use case 3: Rapid legacy configuration cleanup using natural language 

A large online catering marketplace wanted Claude to query their Okta org. The goal was a natural-language interface for auditing and cleaning up years of accumulated configuration. Questions like "What applications has this user signed in to since 2024?" now take seconds instead of requiring manual log searches.

The implementation

Organizations that want to clean up legacy configuration data in a similar way, but with less effort, can use the Okta Managed MCP Server. As in the use cases above, an admin connects the Managed MCP Server to an AI client such as VS Code with GitHub Copilot. The same approach should work with other clients, such as Claude Desktop.

A cleanup comes down to four checks:

• List groups with member counts, and flag the empty ones: "List my groups and show the member count for each, then flag any group that has zero members so I can decide whether to delete it." Built-in groups, such as Everyone, cannot be deleted.
• Check an app's assignments before deactivating it: "Show me App A's group and user assignments. If no active users are assigned, deactivate it after I confirm."
• Review where a user has signed in with the System Log tool, filtered by user and date range, instead of searching logs by hand.
• Remove leftovers, such as test policies and test accounts. Permanent user deletion works only on accounts that are already deactivated.

Best-practice safety rules

Three habits keep a large cleanup safe:

• Narrow each prompt to one group, app, or date range, and state concrete rules, such as "90+ days inactive." Broad prompts pull large datasets and slow responses.
• Start with read-only audits. Confirm the results are accurate before you allow deactivations and deletions, because some cannot be undone.
• Spot-check a sample by hand for high-stakes checks.

Bringing identity security into the AI era with the Okta MCP Server

Identity operations have lagged behind the rest of IT automation for a long time. But now, whether you choose the open-source version or the Okta Managed MCP Server, you can connect to the AI clients identity administrators already run to manage their existing identity platform.

The Okta MCP Server gives those connections structure: defined tools, enforced authorization, and an audit trail on every action. If your team is already running AI agents elsewhere in the business, your identity org does not have to be the exception.

Open-source or Okta-managed: Which should you choose?

You can implement the Okta MCP Server in two ways depending on your architecture: 

• Self-hosted (open source): Best for running locally over standard input/output (STDIO) with client and server on the same machine. Free, flexible, and completely under your control. 
• Okta Managed MCP Server: Best for teams that want HTTPS connectivity and an Okta-managed deployment without managing infrastructure. 

Compare the two options and choose the one that fits your environment

How to get started with the Okta Open Source MCP Server

The fastest path to first value is read-only log queries and user lookups. Start there, understand what your agents can do with your specific Okta configuration, then expand to write operations once you are confident in the setup.

Full setup instructions: Configure, start, and test the Okta Open Source MCP Server

Not ready to self-host?

If your team doesn't want to manage an infrastructure, needs HTTPS connectivity, or prefers a deployment that Okta patches and scales for you, the Okta Managed MCP Server delivers the same natural-language-to-Okta capability as a cloud-hosted service. No local installation required.

The Okta Managed MCP Server is currently in Early Access, with General Availability planned for early 2027. Connect it to your agent of choice and let us know what you build.