Okta AI Agent Security Takes Aim at Enterprise Confusion

Okta has identified an unusual opponent for its AI agent security push: customer confusion, not another security vendor. President and COO Eric Kelleher made that case at the Goldman Sachs Communacopia + Technology Conference on September 9, 2026.

The argument reflects a market where enterprises want autonomous software but struggle to define what must be secured. An agent might summarize email, update a sales record, approve a refund, or operate an entire financial workflow. Each role creates different permissions, risks, and accountability requirements.

Okta wants identity to become the organizing layer for that disorder. Its framework asks three questions: Where are the agents, what can they connect to, and what can they do? Microsoft is pursuing similar goals through Entra Agent ID and Agent 365, making enterprise distribution as important as security design.

That competition changes the meaning of Okta’s message. Confusion can open a market for an independent identity provider, but it can also slow purchases and favor bundled platforms. Okta must turn an urgent security narrative into repeatable deployment, measurable adoption, and standards that customers can use across vendors.

Okta AI Agent Security Starts With Three Questions

Okta’s immediate move is to reduce a sprawling security problem to agent discovery, connection control, and authorization.

During the September conference, Kelleher described customers asking Okta for help after encountering alarming reports about autonomous agents. These buyers understand that agents introduce risk, but they often lack a shared model for evaluating that risk.

Okta’s answer is its Blueprint for the Secure Agentic Enterprise. The company introduced the framework in March and made Okta for AI Agents generally available on April 30, 2026. The product extends familiar identity controls to autonomous and semi-autonomous software.

The first question, “Where are my agents?”, concerns inventory and ownership. Employees can activate tools without a formal deployment process, while developers can create agents across numerous cloud platforms. Security teams cannot govern an agent they cannot identify.

Okta’s Agent Discovery capability is designed to expose those hidden deployments. According to the company’s agent discovery details, it detects OAuth consent activity and identifies connections involving unsanctioned agent platforms.

OAuth consent grants an application permission to access another service without receiving the user’s password. That convenience becomes risky when an employee authorizes an unknown agent to read mail, files, calendars, or customer records.

Okta says browser signals can reveal the client application, the connected resource, and the requested permission scopes. Administrators can then register the agent, assign a human owner, and apply baseline policies.

The second question, “What can agents connect to?”, shifts attention from inventory to access paths. An agent may interact with applications, APIs, databases, tools, or Model Context Protocol servers. MCP is a standard interface that lets AI systems access external tools and information.

Okta’s blueprint includes a gateway for mediating those connections, credential vaulting, and API access management. These controls are intended to replace broad, persistent credentials with narrower decisions based on identity, context, and risk.

The third question, “What can agents do?”, reaches the hardest layer. Knowing that an agent can enter a system does not reveal whether it can read, write, transfer, approve, or delete information.

Okta proposes logging individual tool calls and authorization decisions. It also promotes Universal Logout as a kill switch that revokes an agent’s access tokens across connected systems.

This framing matters because an agent is not merely another employee account. It can execute many actions quickly, combine information across systems, and change its behavior when surrounding context changes.

It also differs from a traditional service account, which usually performs a predictable automated task. An AI agent can select tools, generate intermediate plans, and act through permissions delegated by a user.

Okta’s three questions therefore create a useful purchasing structure. They do not prove that every underlying control works across every agent platform. They give security leaders a common vocabulary for deciding what must be tested.

That vocabulary is the foundation of the company’s strategy. Okta wants enterprises to view agent security as an extension of identity governance, not as an isolated category of AI monitoring.

Confusion Is Creating Both Demand and Delay

The same uncertainty that brings customers to Okta can also lengthen evaluations and prevent agent security from becoming a predictable business.

Kelleher called confusion the company’s largest current competitor in agentic identity. Buyers face competing claims from security vendors, cloud providers, AI developers, and governance platforms. Many products use similar language while protecting different layers.

One vendor may scan prompts for malicious instructions. Another may discover machine identities or exposed credentials. A third may control network traffic, while an identity provider determines which agent can access a specific application.

These functions can complement each other, but enterprises still need to establish ownership. The security team may control access policies, while developers own the agent and business units define acceptable actions.

Procurement becomes harder when an organization cannot answer basic questions about its deployment. A company might know that employees use AI assistants without knowing which assistants possess durable application permissions.

Agent definitions also remain inconsistent. Some systems are chat interfaces that recommend actions. Others execute workflows after human approval, while autonomous agents can act without reviewing every step.

That ambiguity affects licensing and product measurement. Kelleher said Okta currently prices its agentic offering as an uplift to per-user pricing. He acknowledged that the model is imperfect for agent architecture, but described it as easy for customers to purchase.

Most early transactions are one-year agreements, according to his conference remarks. Okta expects both sides to obtain better information about agent usage and operating costs before renewals.

This approach lowers immediate purchasing friction. It also reveals how early the market remains. A mature security category usually has clearer units, such as users, devices, workloads, transactions, or protected data volume.

Agent activity can cut across all those units. One employee may use several agents, while one agent can spawn temporary workers or perform thousands of tool calls. A per-user model may become disconnected from the workload being secured.

Okta’s advantage is an existing relationship with enterprise identity teams. Kelleher said more than 20,000 companies already trust Okta with human and non-human identities. That installed base offers a direct route into security discussions.

However, trust does not remove implementation work. Customers must discover agents, classify their purposes, identify owners, reduce excessive permissions, and connect relevant applications to enforcement points.

Security leaders must also decide which actions require human approval. A summarization agent and a quote-to-cash agent should not receive identical controls, even if both use the same identity platform.

The latter may touch pricing, contracts, billing systems, and revenue records. A mistake could become a financial or compliance event rather than an inconvenient answer.

This distinction turns confusion into a product opportunity only when Okta can guide deployment. A blueprint helps customers ask better questions, but operational templates and integrations must deliver the answers.

That requirement puts pressure on Okta’s sales and professional-services motion. Buyers will expect the company to translate an abstract identity framework into controls for actual workflows.

Developers face a related challenge. They need secure access patterns that do not require rebuilding every agent for each customer’s identity system. That is why Okta’s standards strategy sits near the center of its product argument.

Cross App Access Is Okta’s Bid for an Open Control Layer

Okta is betting that an open authorization standard can make agent access portable while preserving identity providers as central policy enforcers.

Cross App Access, or XAA, is Okta’s proposed method for connecting agents to applications through standardized authorization. It extends concepts from OAuth and works alongside MCP, which provides a common way for agents to discover and call tools.

The distinction is important. MCP can describe an available tool and support the interaction, but enterprises still need to decide whether a particular agent may use it. XAA is intended to carry identity and authorization context into that connection.

Kelleher said Okta proposed Cross App Access as an open standard rather than a proprietary Okta format. He also said it had been accepted as an extension to MCP and was attracting broad industry interest.

Okta made Agent SSO generally available in August 2026. Agent SSO allows an administrator to register an agent as a workload principal, meaning an independently managed non-human identity.

When a supported agent connects to an application, Okta can place it in Universal Directory beside other governed identities. Administrators can then view ownership, connections, and applicable policies through existing identity processes.

The approach attempts to resolve a recurring weakness in agent deployments. Many early agents borrow a user’s access token or rely on a static credential stored inside a workflow.

Borrowed access can make attribution unclear. If an agent changes a record using an employee’s identity, an audit log may fail to distinguish software action from direct human action.

Static credentials create another problem. They can remain active longer than necessary and may appear in configuration files, logs, or development environments. An exposed secret can give an attacker persistent access.

A dedicated agent identity separates the actor from its sponsor. The business owner remains accountable, but the security system can apply different policies to the agent and the person.

That separation supports least privilege, which limits an identity to the minimum access needed for its assigned task. It can also support shorter-lived tokens and clearer decommissioning when an agent is retired.

Okta says Auth0 for AI Agents can help developers build agents that work with XAA. Those agents can store credentials with different identity providers, rather than requiring an Okta-only environment.

Openness strengthens Okta’s pitch to customers worried about platform lock-in. An enterprise may use agents from Microsoft, Google, Salesforce, custom development teams, and smaller vendors within the same environment.

A portable authorization layer would let those agents encounter consistent access decisions. It could also reduce custom integration work for developers selling into enterprises with different identity systems.

Yet a published standard does not automatically create interoperability. Applications must implement it, agent frameworks must carry the required context, and identity providers must interpret requests consistently.

Security teams must also trust the metadata used in each decision. An agent can possess a valid identity while still receiving manipulated instructions or selecting an unsafe action.

Identity answers who or what is requesting access. It does not independently determine whether a generated plan is accurate, ethical, or aligned with business intent.

Okta’s mechanism is therefore significant but bounded. XAA can make authorization more explicit and auditable. It cannot replace model safeguards, data governance, network controls, or application-level validation.

The company benefits if XAA becomes a neutral connection standard. It faces greater pressure if agent platforms keep identity enforcement inside their own bundled control planes.

That pressure is already visible through Microsoft’s expanding agent identity stack.

Microsoft Turns Identity Security Into a Distribution Fight

Okta’s primary competitive challenge is Microsoft’s ability to bundle agent identity with the applications, cloud services, and administration tools enterprises already use.

Microsoft Entra Agent ID became generally available in April 2026. It provides identity constructs, authentication, authorization, governance, and security controls designed for AI agents.

Its underlying argument closely resembles Okta’s. Agents should have identifiable owners, managed lifecycles, limited access, and auditable activity. Microsoft also supports OAuth, MCP, and agent-to-agent protocols.

The difference lies in distribution. Microsoft controls a large collection of business applications, developer services, cloud infrastructure, data platforms, and security products.

Agent 365 serves as the company’s unified catalog and management layer. Entra provides the identity foundation beneath it, according to Microsoft’s agent identity documentation.

Microsoft can connect an agent identity to Conditional Access, Identity Protection, Microsoft Graph, and its broader governance environment. Customers already operating inside that stack may prefer a consolidated administrative experience.

A practical example appears in Microsoft’s Dataverse integration. A sales-development agent can receive a dedicated identity and a limited role for reading leads, recording outreach, and updating eligible records.

Administrators can exclude unrelated tables or sensitive fields. Actions remain attributable to the agent rather than appearing under a shared employee or application account.

That scenario demonstrates the strategic risk for Okta. Microsoft does not need to sell agent identity as a separate category when it can embed governance into the application where work occurs.

Okta’s response is independence. Its value increases when an enterprise uses multiple clouds, agent builders, and software ecosystems. A neutral identity layer can offer consistent policy across those boundaries.

Kelleher emphasized that agentic identity combines characteristics of human and non-human identity. Okta already manages both categories, giving it experience with lifecycle governance, application access, and security signals.

Its integration catalog also gives the company a substantial starting point. Okta said in March that its network included more than 8,200 integrations, with agent support involving Boomi, DataRobot, and Google Vertex AI.

That breadth matters only if integrations offer meaningful enforcement. A catalog entry that registers an agent is different from one that authorizes individual tool calls and supports rapid revocation.

Microsoft faces the same test inside its ecosystem. Centralized identity can describe permissions, but applications must enforce those permissions correctly during fast, multi-step workflows.

Other security vendors add another layer of competition. Privileged-access companies can manage sensitive credentials, while endpoint and cloud-security providers can analyze behavior around an agent.

AI security specialists may focus on prompt injection, unsafe tool selection, data leakage, and model behavior. Those threats do not disappear after the agent receives a dedicated identity.

The likely enterprise architecture will include several control layers. The contested question is which platform becomes the central place for ownership, policy, and investigation.

Okta wants that place to be the identity security fabric. Microsoft wants Agent 365 and Entra to provide a unified control plane, especially across Microsoft applications.

Customers will judge those claims through mixed environments. A platform that governs only its native agents will leave security teams with fragmented inventories and policies.

Okta’s independence offers a credible answer to fragmentation. Microsoft’s integration depth offers a credible answer to operational complexity.

This is the article’s main contest: a neutral identity layer against a bundled application and cloud control plane. Confusion helps Okta start the conversation, but interoperability will determine who controls it.

Identity Controls Cannot Judge an Agent’s Intent

Okta can restrict what an agent is allowed to access, but valid credentials do not guarantee safe reasoning or correct action.

An agent may authenticate successfully and remain within an approved permission scope while still causing harm. It can misinterpret a request, follow a malicious instruction, or combine permitted actions into an unintended outcome.

Prompt injection illustrates the gap. An attacker can place concealed or misleading instructions inside content that an agent reads. The agent may treat those instructions as part of its task.

Identity controls can limit the resulting blast radius. They cannot always recognize that the agent’s decision process was manipulated.

The same limitation applies to incorrect planning. An authorized finance agent could select the wrong account, duplicate an action, or apply an approval rule to the wrong transaction.

A kill switch becomes valuable after suspicious behavior is detected. However, autonomous agents can execute many actions before a human recognizes the pattern and revokes access.

Runtime authorization attempts to narrow this window. Instead of granting broad standing access, a system evaluates individual requests using identity, context, risk, and intended action.

The quality of that evaluation depends on reliable context. Policies must distinguish ordinary variation from unsafe behavior without blocking legitimate workflows.

Organizations also need trustworthy logs. Recording an agent’s tool calls helps investigators reconstruct events, but logs must connect the agent, human sponsor, instruction, authorization decision, and resulting change.

A record that shows only a successful API call provides limited accountability. Security teams need to know why the agent called the API and what data shaped its decision.

Okta’s system-log and governance features address parts of that chain. The company says tool calls, access attempts, and authorization decisions can flow into security information and event management systems.

Those capabilities remain company claims until customers test them across varied agent frameworks and applications. Okta’s own announcement also warns that unreleased features may arrive late or not arrive at all.

Independent evidence remains limited because enterprise agent deployments are young. Academic work has begun examining identity management for agentic systems, but production benchmarks are still developing.

A further concern is ownership quality. Assigning a human sponsor creates accountability on paper, yet that person must understand the agent’s data, permissions, dependencies, and retirement conditions.

Ownership can become ceremonial when organizations deploy agents faster than managers can review them. Access certifications then risk becoming another approval queue with insufficient context.

Agent sprawl makes the problem worse. A primary agent may create temporary subagents for research, analysis, or execution. Security policy must determine whether those temporary identities inherit permissions.

Broad inheritance is easy to administer but increases exposure. Requiring separate approval for each short-lived agent can undermine the speed that makes agentic workflows attractive.

This is the central tradeoff in Okta AI agent security. Enterprises want agents to operate quickly across systems, while security teams need each action to remain bounded, attributable, and reversible.

Too little control creates unacceptable risk. Too much friction turns an autonomous workflow back into a slow series of human approvals.

The strongest deployments will begin with narrow tasks and explicit data boundaries. A support agent might classify tickets before receiving permission to issue credits or change customer records.

Teams should test failure paths, not only successful demonstrations. They need evidence showing how the system handles expired ownership, manipulated inputs, excessive permissions, and unavailable enforcement services.

A searchable knowledge base can help teams document owners, policies, and incident decisions. It does not replace access control, but it preserves the context reviewers need.

Okta’s strategy becomes more convincing when customers can connect identity decisions to reduced privileges and faster incident containment. Product announcements alone cannot establish that result.

Three Signals Will Show Whether Okta’s Push Is Working

Standards adoption, customer expansion, and cross-platform enforcement will determine whether Okta converts confusion into a lasting identity-security category.

The first signal is adoption of Cross App Access beyond Okta’s own products. Agent developers, application vendors, and competing identity providers must implement the protocol for it to become meaningful infrastructure.

Okta said at the September conference that broader announcements were approaching. The important detail will not be the number of named partners. Buyers should examine which actions those integrations can actually authorize.

Support for registration provides inventory. Support for scoped, contextual authorization provides control. Support for rapid revocation provides containment when an agent deviates from its intended role.

A growing set of working integrations would strengthen Okta’s neutral-platform argument. Limited adoption would leave XAA as a useful feature inside the Okta environment rather than an industry control layer.

The second signal is the shape of customer renewals and expansions. Kelleher said most early agentic transactions use one-year terms, giving customers and Okta time to understand usage.

Those renewals will reveal whether enterprises move beyond evaluation. Buyers should look for deployments that govern production agents across several business processes, not isolated demonstrations.

Expansion into additional agent platforms would support the claim that identity offers a common control plane. Growth tied only to experimental projects would suggest that confusion remains a sales barrier.

Pricing will provide another clue. Okta’s per-user uplift simplifies initial purchases, but agent volume and activity do not necessarily track employee counts.

The model may evolve toward protected agents, connections, transactions, or authorization events. Any change will reveal what customers value and which operating costs matter most.

A stable, understandable model would help the category mature. Complex usage pricing could reintroduce the uncertainty that Okta’s blueprint is designed to remove.

The third signal is competitive response from Microsoft and other identity providers. Microsoft’s Agent 365 model already combines a unified inventory with Entra-backed identity and governance.

If Microsoft expands simple governance for third-party agents, Okta’s independence claim will face a direct test. If Microsoft remains strongest inside its own environment, Okta gains room in heterogeneous enterprises.

Customers should compare enforcement across Microsoft 365, Google Workspace, Salesforce, cloud platforms, and custom applications. The winner will need more than a central agent list.

It must preserve agent identity across application boundaries, apply least privilege, expose ownership, and terminate access consistently. It must also deliver evidence that security teams can use during investigations and audits.

Competitor support for common standards would validate Okta’s broader thesis, even if it reduces product differentiation. Proprietary approaches would turn agent identity into another platform boundary.

Okta’s conference message deserves attention because it avoids treating AI agent security as a single detection feature. The company is framing the problem around accountability and access throughout an agent’s lifecycle.

That framing matches the operational challenge. An enterprise needs to know who created an agent, why it exists, which resources it can reach, and how to stop it.

However, identity is one control plane among several. Model safeguards, application validation, network monitoring, data governance, and human review remain necessary.

Security buyers should therefore treat Okta’s blueprint as a test framework. They can ask each vendor to demonstrate discovery, authorization, ownership, logging, and revocation across a real workflow.

The best proof will come from an intentionally constrained production deployment. Teams can begin with an agent that reads limited information and proposes actions for human approval.

They can then measure excessive permission requests, policy denials, investigation time, and decommissioning accuracy. Those outcomes reveal more than a polished autonomous demonstration.

Okta AI agent security is ultimately a bet that enterprises will not manage autonomous software through scattered credentials and isolated controls. The market is moving toward dedicated identities, explicit ownership, and continuous authorization.

The unresolved question is who will provide that layer across mixed environments. Watch XAA integrations first, production renewals second, and Microsoft’s third-party reach third.

If Okta advances on all three, confusion will become a durable identity opportunity. If adoption stays fragmented, bundled platforms will retain the advantage.

For enterprise teams, the next step is practical: select one agent, map every connection, and document every allowed action. Then ask whether your current identity system can see, restrict, audit, and revoke that agent without custom work.