An agentic AI governance plan for the first MCP server that can change who has access to everything else.

Okta has made its open-source MCP server generally available. It lets LLMs and AI agents run Okta management operations in natural language, through Okta’s Admin Management APIs. That makes agentic AI governance a practical question for every Okta admin this week. Agentic AI governance is the set of policies, runtime controls and audit records that decide what an autonomous AI agent may do, on which systems, with whose approval, and how every action is traced back to a person. An identity provider is the hardest test of it, because the IdP decides who can reach every other system you run.

This post works through one real server: which Okta tools to allow, which to hold for human approval, which to deny, and what to log for each call.

What Okta’s MCP server does

According to the okta/okta-mcp-server repository, the server offers create, read, update and delete operations for users, groups, applications, policies, device assurance policies, brands, themes, custom pages, email templates, custom domains, email domains and system logs. The README’s own examples set the tone: “Create a new user and add them to the Engineering group” and “Show me all failed login attempts from the last 24 hours.”

Three design choices matter for MCP server security:

  • Scope-based tool loading. Each tool maps to a minimum OAuth 2.0 scope. At startup the server compares those against the scopes you configure in OKTA_SCOPES and silently removes any tool you haven’t granted. If you only grant okta.users.read and okta.groups.read, the agent never sees create_user or delete_group. A decorator checks scopes again at call time.
  • Confirmation for destructive operations. Deletes and deactivations ask the user to confirm through the MCP Elicitation API. Clients without elicitation support get a JSON payload describing the pending action, for the LLM to relay.
  • Two authentication modes. Device Authorization Grant for interactive use, and Private Key JWT for server-to-server runs.

Scope-based loading gives you a native read-only mode: grant only .read scopes. It works per scope, not per tool. okta.groups.manage unlocks create_group, update_group, delete_group, add_user_to_group and remove_user_from_group together. You can’t grant membership changes without also granting group deletion.

That is the gap. OAuth scopes limit which API the agent can call. They don’t describe intent. A token with okta.policies.manage can tidy up a stale rule or switch off the sign-on policy that enforces MFA; the API sees the same call. Elicitation helps, but it covers destructive operations only, and it trusts whoever is sitting at the client. An unattended agent running on Private Key JWT has nobody at the client.

What the README doesn’t list is just as useful: no tools for admin role assignment, factor resets or API token creation. That may change as the server grows, and other Okta MCP servers may expose them, so your policy should cover them anyway.

Your IdP and over-permissioned agents

Most agent mistakes are contained. A bad CRM update hurts one record. A bad IdP change spreads, for three reasons.

Privilege escalation. If an agent can add a user to a group, it can add any user, including itself or the account behind a prompt injection, to a group that is assigned to production apps. Group membership is the access model in most Okta orgs.

Persistence. Attackers who reach an IdP make changes that survive a password reset: a new user, a new app integration, a weakened sign-on policy rule, a new custom domain. Every one of those is a tool call on this server once the matching .manage scope is granted.

Accountability diffusion. When an agent acts with a shared service app’s credentials, the Okta System Log records the client, not the person who asked or the prompt that drove the action. In an incident review, “the agent did it” is not an answer anyone accepts.

These are the same risks the leading frameworks put at the top of their lists: excessive agency, tool misuse and identity abuse (OWASP GenAI Security Project). The IdP is where all three meet.

Allow, hold, deny: a gating plan for Okta tools

A good AI agent governance policy sorts every tool into one of three buckets before the first agent connects. Here is how we’d sort the Okta server’s tools.

Allow: read-only lookups (users, groups, apps, logs)

list_users, get_user, list_groups, list_group_users, list_applications, get_policy and get_logs cover most help-desk and access-review questions: who is in this group, which apps does this contractor have, what failed logins happened overnight. Allow them, log them, and keep an eye on volume. Read access to user profiles is still personal data, so redact sensitive attributes before they reach the model.

Hold for human approval: lifecycle and group-membership changes, app assignments

create_user, update_user, deactivate_user, add_user_to_group, remove_user_from_group, activate_application and update_application are the actions teams actually want agents to do. They are also how access gets granted. Let the agent prepare the change, then hold it until a named person approves. This is the core of human approval for AI agents: the agent does the work, a human owns the decision. Hold group changes for any group assigned to sensitive apps, at least.

Deny by default: admin role grants, MFA/factor resets, policy and authorization-server edits, API token creation

Deny every policy write (create_policy, update_policy, deactivate_policy, update_policy_rule and the rest), device assurance writes, custom domain and email domain changes, and deletes of users, groups or apps. Admin role grants, factor resets, authorization server edits and API token creation aren’t tools on this server today; deny them by name so a future release or another server doesn’t silently add them. An agent should never be able to change the rules that govern agents.

Okta tool category Risk Recommended action What to log
Users, groups, apps: read (list_*, get_*) Low; personal data exposure Allow, with redaction of sensitive attributes Agent, tool, query, result count
System Log (get_logs) Low to medium; reveals security events Allow for security agents only Agent, time range, filter
User lifecycle (create_user, update_user, deactivate_user) High; grants or removes access Hold for human approval Agent, args, approver, decision
Group membership (add_user_to_group, remove_user_from_group) High; privilege escalation Hold for human approval Agent, user, group, approver
App changes (update_application, activate_application, install_oin_app) High; new access paths, persistence Hold, or deny for production apps Agent, app, diff, approver
Deletes (users, groups, apps) High; destructive Deny by default Attempt, agent, args
Policies and policy rules (*_policy, *_policy_rule writes) Critical; can switch off MFA enforcement Deny Attempt, agent, args, alert
Device assurance, custom domains, email domains Critical; trust and phishing surface Deny Attempt, agent, alert
Admin roles, factor resets, API tokens (not on this server today) Critical Deny by name Attempt, alert

Give the agent its own identity, not a borrowed admin token

The fastest way to connect an agent is to paste in a super admin’s token. Don’t. Create a dedicated service app for each agent, with only the scopes its job needs. Least privilege for AI agents starts there, and Okta’s scope-based loading makes it easy to check: if a tool doesn’t appear in tools/list, the agent can’t call it.

Agents aren’t people with a login, and treating them as users breaks your access model; we’ve covered why in agents are not users. Each agent needs a unique record of its own, tied to the person or team accountable for it. Scope that record from the IdP roles you already maintain, so an agent acting for the help desk never gets more than the help desk has.

Identity is necessary, not sufficient. Your IdP still matters for AI governance (we argued that here), but an identity tells you who. It doesn’t say which tool, with which arguments, under which policy. Pair the agent’s identity with tool-level scope and per-call policy.

Log every call: what an audit trail for agent actions needs

The Okta System Log will record the API calls the server makes. It won’t record the prompt that triggered them, the agent’s reasoning, or the policy decision that let them through. An AI agent audit trail needs, for every call:

  • Who: the agent, and the person or team it acts for
  • What: the MCP server, the tool and the full arguments
  • Decision: allowed, held or denied, and the policy that decided
  • Approver: who approved a held action, and when
  • Outcome: the result or error returned

Stream it to your SIEM next to the Okta System Log, so security monitoring can join the two by time and client. Then alert on denied attempts. A spike of denied policy writes is an incident signal, whether it comes from a buggy prompt or a prompt injection.

How to implement agentic AI governance for any MCP server (the Okta pattern, generalized)

Okta is the high-stakes example, but the steps work for any MCP server. Here is how to implement agentic AI governance in five steps:

  1. Inventory. List every MCP server your teams connect and every tool each exposes. Shadow servers are the first gap.
  2. Scope. Give each agent its own identity and the narrowest scopes and tools its job needs. Default to read-only.
  3. Hold. Mark every tool that grants access, moves money or deletes data as approval-required, with a named approver.
  4. Log. Record every call with agent, tool, arguments, decision and approver, and send it to your SIEM.
  5. Review drift. Servers add tools in new releases, as Okta’s will. Review your allow, hold and deny lists on every upgrade and each quarter, and remove scopes nobody used.

This is the agent lifecycle in practice: approve, scope, run, monitor, retire. Treat it as a framework you run continuously, not a one-time project.

Where Barndoor fits

Barndoor is the AI Gateway for enterprises. Put Barndoor MCP Governance in front of the Okta MCP server and the plan above becomes policy enforced on every request:

  • Tool-level least privilege. Allow add_user_to_group while denying delete_group, even though Okta grants both through one scope.
  • Runtime enforcement. Unauthorized actions are stopped before they execute.
  • Human approval. Hold sensitive actions until a person approves them.
  • A record for every agent. Each agent gets its own delegated, unique record, and people are scoped from your existing IdP roles.
  • A complete audit trail of every agent action and the policy that governed it, streamed to your SIEM.
  • Barndoor data protection redacts, tokenizes or blocks sensitive data inline before it reaches a model.
  • A governed catalog so teams only use the MCP servers they’re approved for.

See how the MCP gateway works.

Frequently asked questions

What is agentic AI governance?

Agentic AI governance is the policies, runtime controls and audit records that decide what autonomous AI agents may do, on which systems, with whose approval, and how each action is traced to an accountable person.

Is it safe to connect AI agents to Okta through MCP?

It can be, if you start read-only, give each agent its own service app with minimal scopes, hold access changes for human approval, deny policy and domain writes, and log every call. Connecting with a super admin token is not safe.

Which Okta actions should require human approval?

User creation, updates and deactivation; adding or removing group members; and application changes. Policy edits, deletes and domain changes should be denied outright rather than held.

How do you implement agentic AI governance?

Inventory your MCP servers and tools, scope each agent to the minimum, hold high-risk tools for approval, log every call to your SIEM, and review for drift whenever a server adds tools.

How is agentic AI governance different from traditional AI governance?

Traditional AI governance focuses on models: training data, bias, accuracy and documentation. Agentic AI governance adds actions. It controls what an agent can do in real systems at runtime, and who is accountable for each action.

What is the best agentic AI governance solution?

Look for tool-level policy (not just server-level), enforcement at runtime on every call, human approval for chosen actions, a separate identity per agent, and an audit trail you can send to your SIEM. Test it against a high-stakes server like Okta’s before you trust it.

Put the policy in front of the server

Okta’s server gives you scopes and confirmation prompts. Your security team still needs tool-level rules, approvals and a full audit trail before agents touch the IdP. Start a free trial of Barndoor and put your allow, hold and deny list in front of the Okta MCP server today.