Your Okta Controls Who Logs In, Not What AI Agents Do Next.

If your organisation runs Okta, you've already done the hard work of centralising identity. Every employee authenticates through a single point. Application access follows group membership. Provisioning and deprovisioning are automated through SCIM. You can answer "who has access to what" in minutes rather than days.

That infrastructure is real, and it matters. But as AI agents become a standard part of how your engineering, sales, and operations teams work, a gap is opening up that Okta was never designed to cover — and that many IT teams are only starting to understand.

This piece explains what that gap is, how an MCP gateway bridges it, and what the Okta integration actually looks like in practice.

What Okta Covers — and Where It Stops

Okta's role in an AI agent deployment is the same role it plays everywhere: managing the human identity that the agent acts on behalf of.

Here's the sequence when an employee uses an AI tool like Claude Code or GitHub Copilot Agent Mode:

1. The employee authenticates to their AI tool (or the AI tool connects to a backend service)

2. Okta confirms identity, checks group membership, validates entitlements

3. The employee's credentials are used to authorise MCP connections to internal systems

4. The agent begins calling tools inside those systems

Okta controls steps 1 and 2 cleanly. After that, it has no visibility.

Once an agent is inside Salesforce, or GitHub, or your internal ticketing system, the actions it takes are governed by that application's own permission model — not by anything Okta configured. Okta knows that the employee has access to Salesforce. It has no mechanism to distinguish between an agent reading a single customer record and an agent running a bulk export of the entire CRM. From the identity layer's perspective, those operations look identical.

For human users, this limitation is acceptable because humans are naturally self-limiting. A sales rep with read-and-update access doesn't accidentally bulk-export 50,000 records. They make deliberate choices about what they do.

AI agents don't have that self-limiting behaviour. They execute workflows. They call whatever tools are available to complete the task. An agent preparing a territory report might query far more records than the task required — not maliciously, but because "gather relevant context" means something different at machine speed. Okta never sees any of this, and cannot intervene.

Recommended Reading: How 5 Enterprise Teams are deploying Remote MCP Servers

The Specific Gap: Action-Level Access

Consider what a senior developer's access looks like today.

Their Okta profile says: access to GitHub. That assertion is correct — they can create pull requests, manage branches, push commits, access repository secrets. The SAML token reflects this. The developer can do all of it.

Now that developer connects Claude Code to the GitHub MCP server. The agent inherits those credentials. The GitHub MCP server exposes these tools:

The engineer wants the agent to help review their PR, pull context from related tickets, and suggest improvements. A reasonable, well-scoped task.

But the agent, in trying to be thorough, has access to every tool in that list. It can delete branches — including others' branches, not just the engineer's own. It can access secrets. If the model reasons that "cleaning up the branch structure" requires deleting old branches, it will attempt to do that, because nothing told it not to.

Okta's verdict was: "this user has access to GitHub." It has nothing more to say about which of those eight tools an agent should or shouldn't call.

How the MCP Gateway + Okta Integration Works

The MCP gateway is the layer between employees' AI tools and the systems they connect to. It's the control point that makes action-level governance possible — and it integrates with Okta natively, in both directions.

Okta → Gateway: Group-Based Access Policy

Employee group membership in Okta drives access policy in the gateway. You define which Okta groups get access to which tool sets:

When the engineer's group membership changes in Okta — say, they're promoted to a senior role — their gateway tool access updates automatically on their next session. No manual reconfiguration. No ticket to IT. No stale permissions from their previous role lingering in a config file.

Gateway → Okta: SCIM Lifecycle Events

This is where the integration really matters for IT operations. Okta pushes lifecycle events to the gateway the same way it pushes them to any other SCIM-connected application:

• New hire: Employee is added to the "Junior Engineers" Okta group. SCIM provisions their gateway access with the Junior Engineers tool set. When they open Claude Code and add the gateway URL, they immediately have the right tool access for their role.

• Promotion: Employee moves from "Junior Engineers" to "Senior Engineers" in Okta. SCIM updates their gateway profile. Their next agent session reflects the new tool access.

• Offboarding: IT disables the employee's Okta account. SCIM propagates that event to the gateway. Gateway access is revoked. Every downstream MCP connection that flowed through the gateway stops — GitHub, Jira, Salesforce, whatever they had access to. One event, complete effect.

This is the behaviour IT teams expect from centralised identity. And it only works if agent credentials live in the gateway — not on individual laptops.

Authentication Flows: How Credentials Actually Work

When an agent makes a tool call through the gateway, authentication to the downstream system can work a few different ways:

• OAuth (preferred): The gateway manages the OAuth flow using the employee's Okta identity as the authorising principal. The downstream system sees an agent acting on behalf of a specific, authenticated user. Clean token lifecycle. Revocable.

• API keys (centralised): For systems that use API keys, the credentials live in the gateway — not on the employee's device. When credentials need to be rotated or revoked, it's a gateway-level operation. No hunting down local config files.

• Token pass-through: For systems that expect to receive the employee's own token directly, the gateway handles the pass-through, but the token itself still traces to the employee's Okta-authenticated session.

In all cases, the key principle: credentials are centralised at the gateway, not distributed across employee devices. This is what makes Okta's lifecycle events meaningful — when Okta says an employee is offboarded, the gateway has the actual authority to act on it.

Why Direct SCIM-to-MCP-Server Integrations Don't Hold Up

Some teams try the alternative: configure SCIM provisioning directly to each individual MCP server, one Okta integration per system. GitHub gets its own SCIM connection. Jira gets its own SCIM connection. The internal data warehouse gets its own.

This approach works for two or three systems. At scale, it fails in familiar ways:

Maintenance multiplies. Each SCIM integration is its own surface. Different MCP servers implement SCIM differently — or not at all. When a sync fails (they fail), debugging which integration has the problem, and what access state it left behind, requires investigation per connection. Across thirty systems, this is an operational burden that compounds quarterly.

Policy doesn't transfer. Even if provisioning works cleanly, SCIM tells each system "this user has access." It doesn't tell any system "this user's agent can create PRs but not delete branches." The action-level governance problem isn't solved by direct provisioning. You've handled access; you haven't handled what that access allows an agent to do.

New systems require new integrations. Every time IT wants to make a new internal tool available through AI tools, it requires a new Okta integration, new SCIM configuration, new testing. The work multiplies with every addition. The gateway model collapses this: one SCIM integration between Okta and the gateway. Adding a new MCP-connected system means adding a connector in the gateway — which automatically inherits the Okta-driven access policy. No new Okta integration required.

The Day-to-Day Operational Picture

For IT teams already running Okta, the operational reality of managing MCP access through a gateway looks like this:

Scenario: New internal tool goes live on MCP. The data engineering team finishes building an MCP server for the internal analytics platform. IT adds a connector in the gateway, configures which Okta groups get access to which query tools (read-only for analysts, read-write for data engineers), and it's available to the right employees on their next agent session. No per-user configuration. No API key distribution. No Okta integration work beyond the existing gateway SCIM connection.

Scenario: Engineer changes teams. A developer moves from the infrastructure team to the product team. Their Okta group membership updates — infrastructure team out, product team in. SCIM propagates the change to the gateway. Their AI tool's available tools update on the next session. No manual permission adjustment, no IT ticket, no gap where they have access they shouldn't.

Scenario: Vendor acquisition forces system retirement. The company retires a project management tool following a switch to a new platform. IT removes the connector from the gateway. Every agent connection to that system stops — for every employee, immediately. No hunting down individually-configured MCP server URLs on laptops.

Scenario: Security incident requires investigation. A security event suggests unusual agent activity from a specific employee account. IT pulls the gateway audit log filtered by user identity. Every tool call is available: what tool was called, when, what parameters were passed, what the system returned. The investigation has a coherent starting point — not a fragmented search across five different system logs in different formats.

The Warning for Okta Admins: Pre-Gateway Connections

Here's the common pattern in organisations early in this transition: employees already have MCP connections running outside any centralised system. They connected their AI tools directly to individual MCP servers weeks or months ago, before any gateway existed. They generated API keys, stored them in local config files, and their agents have been connecting to GitHub and Jira and Confluence ever since.

These connections are invisible to Okta. They're not SCIM-provisioned. They don't reflect group membership. They're not affected when you offboard the employee.

The transition to a gateway model doesn't require immediate revocation and restart. The practical path:

1. Stand up the gateway and connect it to Okta via SCIM and SSO

2. Establish the gateway as the required path for all new MCP connections from that point forward

3. Communicate the gateway URL to the engineering team — their AI tool configuration becomes a one-field update

4. Migrate existing direct connections in waves, prioritised by risk (employees with the broadest system access first)

5. Close the historical gap by auditing and revoking orphaned API keys from the individual systems that had them

The critical question for any Okta admin being asked to govern AI agent access: where do the credentials live? If the answer is "on individual employee devices," the Okta integration you build won't give you the control you need. The credential has to live in the centralised layer for the centralised identity system to have meaningful authority over it.

Recommended: Delegated Access & Token Management for Your AI Agents

FAQs

Does setting up the MCP gateway require changes to our existing Okta configuration?

Minimal. The gateway connects to Okta the same way any SCIM-enabled SaaS application does — you add it as an application in the Okta admin console, configure the SCIM endpoint and credentials, and set up group assignments. If you've connected other applications to Okta via SCIM, the process is identical. No changes to existing Okta integrations, policies, or group structures required.

Can we use existing Okta groups for MCP gateway access, or do we need new ones?

Existing groups work. The gateway maps your current Okta groups to tool access policies — whatever group structure you already maintain for application access can drive AI agent access policy in the gateway. Most IT teams find their existing engineering, sales, and operations group structure translates cleanly without new groups.

What happens to gateway access during Okta downtime?

If Okta is unavailable, authentication to the gateway fails — employees can't establish new agent sessions. Existing sessions may continue for the duration of their token lifetime, depending on gateway configuration. This is consistent with how SSO-dependent applications behave generally. Gateway downtime and Okta downtime are independent failure modes; the gateway remains available if Okta is available.

How do we handle employees who have MCP connections both through the gateway and directly to individual servers?

The parallel state is a transitional condition, not a stable one. IT should track which employees still have direct connections (via endpoint audit or developer survey), prioritise migrating the highest-risk users first, and communicate a deprecation timeline for direct connections. The gateway audit log will show you which employees are using the gateway — gaps indicate who still has direct connections outside IT's visibility.

Does the gateway respect Okta's conditional access policies — like requiring compliant device authentication?

Authentication to the gateway goes through Okta's standard OIDC flow, which means conditional access policies apply at login. An employee whose access requires a compliant device will need to satisfy that requirement to authenticate to the gateway. Post-authentication tool call traffic doesn't re-evaluate conditional access on every call — which is consistent with how Okta conditional access works for any application, not a gap specific to the gateway.

What if an employee generates their own API keys for systems and bypasses the gateway entirely?

This is the distributed credential problem the gateway is designed to prevent. The gateway doesn't block employees from generating API keys directly — that's a policy enforcement question for individual systems and IT policy. The practical approach is clear communication: AI tool MCP connections must use the gateway. Direct API key configurations for AI tools are out of policy. For high-sensitivity systems, IT can revoke broad-access API key generation permissions at the application level, forcing agent access through the gateway as the only viable path.