Okta for AI Agents + ACP — composition guide

Okta launched Okta for AI Agents to GA on April 30, 2026, bringing identity-perimeter governance to AI agents — Agent Identity, MCP Bridge, “discover, onboard, protect, govern” tooling, and the five-question framing (who is the agent, what’s it allowed to do, on whose behalf, against which resource, with what approval).

For customers with Okta in their stack, this is real: agents can be onboarded and governed using the same identity primitives that already protect human and machine workloads. For Fortune 500 enterprises, Okta is the path of least resistance.

This page is the honest read on how Okta for AI Agents and ACP compose. Both products are designed for the same end goal — bringing AI agents inside an enterprise’s control surface — but they intercept at different architectural points and solve overlapping but distinct scopes.

TL;DR. Okta for AI Agents covers identity-perimeter governance: who the agent is, what credentials it carries, what scopes it has against which resources. ACP covers tool-call-level governance: what each tool call does, what its inputs and outputs contain, and per-call policy + audit + redaction across every framework and runtime. Most enterprises with serious AI deployments will use both.

What Okta for AI Agents covers

From the launch and adjacent material:

• Agent Identity. A first-class identity primitive for AI agents — distinct from human users and traditional service accounts. Integrates with existing Okta directories, RBAC, Conditional Access.
• MCP Bridge. Brings agents and the MCP tools they call inside the identity perimeter without code changes. Acts as an identity-aware proxy for MCP traffic.
• Discover / onboard / protect / govern. Tooling for finding agents in your environment, registering them, applying policy, and producing audit.
• Five-question framing. Who is the agent, what’s it allowed to do, on whose behalf, against which resource, with what approval. The right framing for the category.
• Distribution. Already deployed in nearly every Fortune 500. For customers who already trust Okta as their IdP, adoption is incremental, not new.

The launch announcement explicitly positions Okta for AI Agents to govern across “any dev framework, agentic runtime, hyperscaler, SaaS environment, or local machine.” The MCP Bridge in particular is the technical claim worth understanding: it brings MCP-mediated agent traffic inside Okta’s identity perimeter so existing identity controls apply.

What’s outside the identity-perimeter scope

The MCP Bridge intercepts MCP-mediated tool calls. AI agents — particularly the most autonomous ones — make calls that don’t route through MCP:

• Coding-agent native tools. Claude Code’s PreToolUse hook fires for Bash, Edit, Read, Write, file globs, and MCP tools alike. Cursor’s hook surface is similar. Codex CLI’s hooks fire on every tool dispatch. These tool calls happen on developer machines, outside the identity perimeter, against local file systems and shells.
• Framework-internal dispatch. When a CrewAI agent hands off to another CrewAI agent, when a LangGraph supervisor routes to a worker, when an Anthropic Agent SDK loop dispatches a tool — these are in-process Python or TypeScript calls that don’t cross any network boundary the perimeter can see.
• Direct LLM API calls. When the agent decides what to do, it calls the model. Bedrock, Vertex, Anthropic API, OpenAI API. These calls carry the prompt, the tool declarations, the conversation context — content that’s relevant to governance but doesn’t fit cleanly inside an identity-flow model.
• Sub-agent and delegation chains. Multi-agent systems compose multiple agents, each with potentially different scopes. Tracking that compositional semantics — the delegation chain — needs governance in the call path, not just at the perimeter.

These aren’t gaps in Okta’s product. They’re the boundary of what an identity-perimeter architecture is designed to govern. A different architectural intercept is needed for each — and that’s where ACP fits.

Three composition patterns

Pattern 1 — Okta for identity, ACP for tool-call governance (most common)

Best for customers who have Okta in their stack and want full governance:

• Okta for AI Agents handles agent identity, perimeter onboarding, and the MCP Bridge for MCP-mediated traffic.
• ACP runs at the tool dispatch layer in agent code and the hook layer in coding agents. Every tool call — MCP or not — goes through ACP for per-call policy, identity-attributed audit, output redaction, and tier-aware rules.
• Identity flow: Okta-issued JWTs propagate to ACP via standard OIDC trusted-issuer setup. Agent identity flows from Okta into ACP’s audit row.

Same identity story, broader coverage. The two layers don’t fight each other; they intercept at different points.

Pattern 2 — Okta for managed agents, ACP for self-built agents

Best when an enterprise has a mix:

• Workloads using Okta’s discover-and-onboard flow (managed agents in known runtimes) get governed by Okta natively.
• Self-built agents (Anthropic Agent SDK, OpenAI Agents SDK, CrewAI, LangGraph, Vercel AI SDK, Mastra, etc.) get governed by ACP at the tool-decorator layer.
• Single audit destination collects from both for unified compliance review.

Pattern 3 — Okta as MCP server source, ACP as MCP server target

Less common, useful in specific cases:

• ACP exposes a hosted MCP endpoint at mcp.agenticcontrolplane.com/mcp. It can serve governed tools to any MCP client, including agents identified through Okta’s MCP Bridge.
• Okta’s identity propagates to ACP’s MCP endpoint via standard OAuth/OIDC; ACP enforces policy and writes audit downstream.

Honest comparison

When Okta alone is sufficient

If all of these are true:

• All your agents run in environments Okta can discover and onboard
• All tool calls of interest go through MCP (or you accept that non-MCP calls are governed elsewhere — application code, downstream-API auth, etc.)
• You’re already an Okta-deep enterprise and want a single-vendor identity story
• You don’t have developer-laptop coding agents in scope (or you treat them as out-of-perimeter by policy)

For shops that fit that profile, Okta for AI Agents alone is genuinely sufficient.

When ACP composes with Okta

If any of these apply:

• Coding agents on developer machines (Claude Code, Cursor, Codex CLI) are in scope
• Self-built agents using framework SDKs (CrewAI, LangGraph, Anthropic Agent SDK, OpenAI Agents SDK, Vercel AI SDK, Mastra, Pydantic AI, AutoGen, Google ADK) need per-tool-call governance
• Output redaction (PII, secrets) on tool returns is a requirement
• You need delegation-chain audit when agents call agents
• You operate across multiple clouds and want unified runtime audit

Install

Okta for AI Agents setup is documented at okta.com (configured per your Okta tenant).

For ACP composition (Pattern 1):

pip install acp-governance        # Python
npm install @agenticcontrolplane/governance  # TypeScript

For coding agents:

curl -sf https://agenticcontrolplane.com/install.sh | bash

Both flow into the same ACP workspace at cloud.agenticcontrolplane.com.

Related

• AWS Bedrock integration — equivalent composition guide for AWS
• Microsoft Foundry integration — equivalent for Azure
• Vertex AI Agent Builder integration — equivalent for Google Cloud
• Reference architecture — how ACP composes with cloud-native and identity-native governance layers