The situation
Your IT team lives in Cursor. They are already asking the agent about tickets and repositories. The next question is the obvious one. Can it look up who is in the Finance group, or whether a new hire landed in the right app? Okta is right there behind an API. The reason you hesitate is simple. The same API that lists a user can deactivate one. The same credential that reads group membership can add somebody to a group that grants production access.
That is the shape of Okta MCP access for IT team rollouts. Reads are useful every day. Writes are rare, consequential and hard to undo. The answer is not to pick one. Let the reads through and stop the writes before they leave Elaichi. MCP, the Model Context Protocol, is the standard an AI client uses to list and call tools. Elaichi serves it at one address for the whole organization. Every call is checked against the caller's role before the credential is used.
This post is about the governance shape, not about typing a URL into Cursor. For the connection steps, read the walkthrough on connecting Elaichi to Cursor for a whole team.
How do you set up Okta MCP access for IT team members?
Write block rules on the IT role naming every Okta tool that is not a read. Then have each IT member connect Cursor once with their own sign-in. Elaichi enforces the rule on every call, whatever client sent it. Cursor supports OAuth for MCP servers that require it, and reads a remote server from a url entry in its own mcp.json (Cursor's MCP docs, checked October 2026).
The order matters. Restrictions first, connection second. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. An IT persona role is where the rule belongs, and an unconfigured role is an open role.
Block rules alone have a gap. A layer with only block rules has no allowlist, so everything it does not block passes it. Block three obvious write tools on the Okta connector and every write tool you did not name stays reachable. Two ways out:
- Allow rules naming the read tools. Once a role carries any allow rule, every connector and tool that none of its allow rules names is blocked for that role. That holds across the whole catalog. So if you allow eight Okta read tools, add whole-connector allow rules for every other app that role uses. Otherwise you have cut IT off from Jira and Slack by accident.
- Block rules naming every tool that is not a read. More typing up front, no collateral damage elsewhere.
For a team that already reaches several apps through one endpoint, the block list is usually the smaller change. For the reasoning behind picking one or the other, see restrict one AI tool or the whole app. The Okta connector page lists the tools you will be naming.
Which Okta tools should IT not reach from an AI client?
Anything that deactivates a user, changes group membership, or assigns or unassigns an application. Those are the shapes that turn a lookup question into an access change.
When you save a rule, Elaichi looks each named connector and tool up in the organization's catalog. A name it cannot find is refused. Each tool's operation is stored beside its name. A block rule then matches by name or by operation, so renaming a tool cannot slip it past a block. An allow rule matches only by the stored operation, never the name, because a tool's name is set by whoever edits the connector. That asymmetry is deliberate; why blocks match tool names but allows do not covers it properly.
A block rule reaches one more thing. A block on a connector also blocks every fork that declares descent from it. Elaichi walks the lineage toward its root for up to eight hops. A chain that is longer, loops or is broken is refused outright rather than checked partially. So somebody forking the Okta connector to make a tidier version does not escape the block.
Why is connector:create high trust for this team?
Because a restriction binds a connector's identity: its slug and its declared fork lineage. It deliberately does not bind the host the connector calls. A member with connector:create can build a new connector aimed at the same API. Your block on the old connector will not catch it.
This is the one permission Elaichi flags as high trust. The role editor shows a "High trust" tag on it. Its description warns that connector governance binds the connector, not the host it calls. Elaichi checks a custom connector's config for shape, not for where it points, and the permission text says a connector can be pointed at any destination.
For an IT team this cuts closer than for most. IT is the group that knows the Okta API and holds the credentials. It would reasonably want a connector that does the one thing the catalog connector does not. Among the system roles, connector:create and connector:manage sit only with Org Owner and Org Admin. If you are authoring a custom IT role, leave both out. Route the genuine need through whoever holds them.
One related limit on custom roles catches people. A custom role may include only permissions its author currently holds. So an Org Admin cannot grant a role something they do not hold. Editing or deleting a custom role also requires holding every permission that role currently has.
What does the IT role actually look like?
One role, not two. A member holds exactly one role in an organization, and role writes refuse zero roles or more than one. Each role is meant to be a complete persona. To combine two personas you author a custom role rather than stacking them.
For a help desk persona that reads Okta from Cursor, three permissions matter:
- tool:execute. Without it the member's tool list over MCP is empty. Every call is refused in-band, with a message saying re-authorizing cannot help.
- connection:create, so each person connects their own Okta account rather than inheriting somebody else's.
- connector:view, to browse the catalog.
Leave out connector:create, connector:manage, restriction:manage and restriction:override. A member who can edit restrictions can edit their own way out of them. Elaichi enforces one exception here. An admin cannot create, edit or delete a restriction aimed at themselves while someone else's rule restricts them. They also cannot write one aimed at a role whose permissions exactly match their own. Both are refused, with a message asking another admin to make the change.
If you are designing this role from scratch, designing roles for AI agents walks the one-role-each constraint in more detail.
How does a member see that a tool is blocked?
They see the tool's name, flagged as restricted, with no description, no input schema and no way to call it. Elaichi does not hide a restricted tool. It names it and refuses it.
When somebody searches for a tool, Elaichi searches the tools they may run. It then ranks their restricted tools separately against the same query and returns those matches by name, flagged restricted, with a count. A connector blocked whole shows as one row for the connector. Calling a restricted tool's exact name returns a restriction refusal rather than "Unknown tool". The refusal says whether the block comes from their role or from their own account, and that an admin can lift it through an access request. It does not name the rule, who wrote it, why, or what else it covers.
That design decision keeps the help desk from filing a ticket about a broken AI. They can see that the deactivation tool exists and is not theirs, which is the correct mental model.
From the client, a member can file their own access request. Any member can file one, filing needs no permission, and a request is always for the caller themselves. An admin resolves it in the console under Governance, then Access requests. That needs member:manage and a step-up confirmation. No AI surface can approve or deny a request, denials included.
Connecting the account: whose Okta sign-in?
Each IT member's own, not one shared service account, where Okta supports per-person sign-in. Every call through a connection fetches credentials from that one connection's bound account. The caller's own identity plays no part in whose credential is used.
That last sentence is the one people misread. A shared connection runs every caller's call as its owner. Say one person connects Okta with a broad admin account and shares the connection with the team at use level. Every member then reaches Okta as that admin, and only Elaichi's restrictions hold them back. The restrictions do hold, on every call, for the person calling rather than the connection's owner. But you have removed a layer you did not need to remove.
Where per-person connections are possible, have each member connect their own. Restrictions in Elaichi then narrow what each of them can do through it. Where only one credential exists, connect it with the narrowest account that covers the reads, and lean on the block rules. Either way, the credential never reaches the AI client. Elaichi's credential service holds every connected account's secrets encrypted, and fetches them into memory only for the call that needs them.
When you do not need any of this
If one IT person wants Okta lookups in their own Cursor and nobody else is asking, a narrow read-only credential against Okta's own API is a smaller thing to maintain. You get no shared audit trail and no role rules, and you do the offboarding by hand. For one person that may be the honest trade. When you do not need an MCP gateway yet argues the threshold.
The case for routing it through Elaichi starts when there are several IT people, several apps, and somebody who will eventually leave. Then one address, one set of role rules and one audit log across apps is worth the setup. The audit log records each connected-tool call with the acting person, the connector, the connection the call reached, the tool's classification and the surface it came from. Over MCP it also records the client's id. Elaichi keeps 90 days of audit history.
When someone leaves, removing the member revokes every live MCP grant they hold in that organization. That happens inside the same call that deletes the membership, so their clients fail on the next request rather than after a cache window. Role and restriction changes are slower. They take about two minutes, because resolved permissions and restrictions are cached per point of presence.
The order to do it in
Restrictions, then connections, then clients. If you connect first, there is a window where the role has no rules and therefore no limits.
Distribution is the client's business, not Elaichi's. On Enterprise, Cursor's MCP Allowlist is configured in the team dashboard under MCP Configuration, and adding a server there approves a configuration rather than pushing it to anyone's machine (Cursor's model and integration management docs, checked October 2026). Local servers are a separate inventory: the MCP project's own guide has each person list them in a config file on their own machine (Connect to local MCP servers, checked October 2026). One hosted endpoint spares you both.
For the whole-company view, MCP governance is the pillar. To compare this against an app vendor's own MCP server, vendor MCP servers through Elaichi sets out the difference, and the connector catalog shows what is already there.
