Okta used Oktane 2026 to stake a larger role in enterprise security. The company wants to extend from controlling access to applications into governing what AI agents can do once they operate inside the business.
That is the right problem to pursue. Enterprises are moving agents into production before security teams have the controls to govern them. The question for customers is how identity policy, runtime telemetry, business context, and recovery fit together when an authorized agent takes an action the enterprise does not want.
Okta’s Blueprint for the Secure Agentic Enterprise organizes the problem around four questions:
- Where are my agents?
- What can they do?
- What are they doing?
- How do I respond?
Keynote Analysis | Okta Oktane 2026
Okta is addressing those questions through agent discovery, identity governance, Agent Gateway, and runtime response capabilities such as token revocation. Its Blueprint stops at response, however, leaving recovery as an open requirement. Containing a misbehaving agent may prevent further activity, but it leaves the business with whatever changes the agent has already made. Eric Kelleher, Okta President and COO, told theCUBE that recovery starts with tracing what happened and that Blueprint Alliance members including Databricks, network providers, and cloud providers would play roles in recovering data and systems. That is a plausible division of responsibility, but it does not yet amount to an end-to-end recovery capability. Customers evaluating the Blueprint should ask who owns recovery, what each provider can restore and how the business establishes a trusted state after an agent has acted.
Start with agent discovery
Before recovery can be resolved, enterprises need to get a handle on which agents are operating in their environments. At Oktane, Okta shared the experience of a large regulated asset manager that illustrates the scale of this discovery problem. The company scanned its environment and found approximately 13,000 agents, only about 1,000 of which it considered valid. It also found more than 500 MCP servers against a handful that had been approved. The customer said many of the agents came from platforms and development environments, including agents Microsoft creates when a new environment is spun up, and that developers often did not know they existed.
That gap matters for governance. Traditional identity lifecycle processes are built around employees, contractors, and service accounts. Agent creation does not necessarily pass through those processes. Agents can originate inside SaaS platforms, cloud services, development environments, and AI tools, and the number of identities capable of taking actions is growing exponentially faster than their human workforce.
Discovery gets an enterprise to the starting line. Every production agent should have an owner, a purpose, approved resources, and a lifecycle policy. An agent without an accountable owner should be treated as an exception requiring investigation, and should not simply be added to the inventory.
Agent proliferation is also an architectural issue. Enterprises should understand which platforms create agents automatically, what credentials those agents receive, how long they persist, and whether they disappear when the originating workload does.
Machine or colleague: Okta’s leaders and customers do not agree on how to treat agents
Agent authorization is exposing a disagreement over how enterprises should govern AI agents. At Oktane, Okta leaders and customers described three approaches: treat agents as machines requiring their own authentication and policy model; tie an agent’s entitlements to those of its human owner; or treat agents more like colleagues, with their own identities and restricted access governed through the same security framework as employees.
The model is still being worked out. One view is that agents should be treated as machines because they cannot satisfy the same authentication requirements as people. An agent cannot present a biometric factor or hardware key, for example, so routing it through human authentication paths can create exceptions in application IAM policy. That approach calls for machine-specific authentication backed by richer context and policy.
Another view ties the agent more closely to its human owner, with the owner’s entitlements defining what the agent can access and dynamic controls governing temporary privileges. Under that model, time-bound break-glass access could require written justification when policy permits it.
James Simcox, Equals | Okta Oktane 2026
James Simcox, chief product officer at Equals, a UK fintech, described a third approach. He told theCUBE that Equals treats agents like colleagues. Each agent receives its own identity and tightly restricted access, but it operates within the same security controls used for employees, giving Equals one governance framework for both. Equals also records the reasoning behind agent actions because regulators or customers may need to understand why an agent made a decision. Simcox said a harder problem remains unresolved: how to govern the handoff when a person instructs an agent and that agent subsequently performs more privileged work.
The disagreement matters because authentication, governance, and authorization are separate problems. An agent may need machine-specific credentials without receiving all of the authority held by the person directing it. Lifecycle management, ownership, audit and revocation can still operate through a common governance program. Tying an agent’s authority directly to its owner’s full set of entitlements creates unnecessary exposure when the agent has been assigned a much narrower task.
For customers, the owner’s entitlements should establish the outer boundary of what an agent could be permitted to do, while the assigned task determines what it can actually do. Agents should receive credentials appropriate for machine identities, policy should incorporate the context surrounding the request, and authorization should be limited to the resources and actions required to complete the task. That authority should also expire when the task ends.
The regulated asset manager described how this can work in practice. A processing agent may receive read-only access while another is permitted to update a record, even when the person behind those agents has broader rights. Updates can also be time-bound. The customer is applying the same principle to agent chains and is holding back broader agent-to-agent communication until it completes a reference architecture for governing those interactions.
That leaves customers with a more precise least-privilege question for agentic systems: What resources and actions does this agent need for this task, and for how long?
Authorization has to move closer to the action
An agent can be authenticated, authorized to reach an application, and still take a risky action inadvertently. Controlling access and controlling execution are different jobs. Okta is beginning to push policy into runtime through Agent Gateway, where identity governance policy is checked against what an agent is attempting.
This issue can be addressed through separation of duties. For example, an employee may have permission to both create and approve purchase orders, but an agent acting on that employee’s behalf could be restricted to creating them. Agent Gateway would check the requested action against governance policy and block the agent if it attempted to approve the purchase order.
Okta’s product team is also studying the emerging area of intent-based authorization, in which access to a tool would not authorize every action available through it. Intent is far from another clean IAM attribute, though. Identity, device state, and entitlement can generally be evaluated deterministically, while inferring intent from a prompt or agent workflow adds probabilistic judgment to the authorization decision. High-consequence actions should not depend solely on inferred intent.
Customers should list the actions that carry the most consequence: changing payment information, moving money, deleting data, modifying identities, changing security configurations and communicating externally. Those actions warrant stronger authorization whether or not the agent already has access to the underlying application. For some actions, that authorization will require human approval.
Human oversight needs a consequence tier
The question is where to require it. Human review on every action would undermine the value of agent autonomy, while applying it too narrowly could leave consequential actions unchecked. Two customers at Oktane described tying human intervention to the risk of the action. One allows agents to draft email but not send it, after users who did not realize what they had enabled sent large volumes of messages. Its customer-facing agents can provide account settings and basic support, while password resets and routing changes require identity validation. Simcox, on the other hand, said Equals does not let customers instruct payments through its MCP server, where access is read-only or allows writes for non-sensitive data. Agents perform tasks directly only where Equals controls the full journey.
Actions should be classified per business consequence and reversibility. Reading a document, drafting an email, and changing routing information deserve different treatment, as do generating a report and modifying production infrastructure. Low-risk, reversible actions can carry more autonomy, and higher-risk actions should require stronger authorization, more context or explicit approval. The goal is to place human judgment where the consequences justify it.
The kill switch answers containment, and recovery needs its own test
Okta repeatedly emphasized the ability to shut down an agent by revoking its access, and customers want it. Simcox said Equals can cancel agent tokens today, but the process is manual. What he needs is an automated trigger when an agent stops behaving like the role it was given. He also framed the stakes: a human who goes rogue is one person, while an agent that goes rogue could run across a very large number of instances at once. Deployments are still early, so that scenario is a trajectory, and it is the one that justifies automated containment.
Bhakti Pitre, vice president of AI Platform Security Product at ServiceNow, told theCUBE that response should be graduated based on the risk and business context. An agent that returns no results from a knowledge base might only need to be paused and investigated, while an agent whose discount limit was overridden by prompt injection could require immediate shutdown. The appropriate response depends on what the agent is doing and the potential business impact.
Revoking credentials stops future activity. It does not reverse database changes, restore deleted information, recall external communications or unwind actions already started in other systems. Agent-to-agent execution makes this harder. An originating agent may trigger several downstream agents before the enterprise detects the problem, and security teams then have to determine which changes came from the original execution and which remain trustworthy.
Customers should add this scenario to their cyber recovery exercises. Start with an authorized agent that makes a wrong high-impact decision. Can the organization reconstruct its actions, trace downstream activity, identify affected data and systems, establish the last trusted business state and selectively reverse the damage? Agentic resilience requires recovering business state, and disabling an identity is only the first step.
Okta cannot own all of the context runtime enforcement requires
The Blueprint Alliance may prove as important as Okta’s individual product announcements. Agent execution crosses identity, applications, endpoints, networks, cloud infrastructure and data, and no single provider sees the whole transaction.
Stephen Lee, Okta’s Architect, Strategy & Partnerships, described the old zero trust picture as clean: identity, devices, network, application workloads and data, with roughly one logo per pillar and clear swim lanes. AI has blurred those lanes, and vendors now overlap across the same agentic workflows. The Alliance launched with 14 members and a white paper intended to help establish a shared model across the ecosystem. Lee acknowledged that Okta does not claim to have every answer.
That coordination gets harder when providers do not see risk the same way.
Charlotte Wylie, Okta | Okta Oktane 2026
Charlotte Wylie, Okta’s Deputy Chief Security Officer, said the Blueprint Alliance is intended to bring signals from providers such as endpoint, network and identity platforms together to support higher-confidence, risk-informed decisions. When I asked what happens when those signals conflict, Wylie pointed to the Alliance as the mechanism for bringing the providers together. The answer reinforces the value of the ecosystem approach, but it leaves an operational question for customers: who adjudicates conflicting signals and which policy wins when providers disagree?
For customers, the test is operational interoperability. They need to know how quickly risk signals move between systems, which provider makes the enforcement decision, what happens when signals conflict, whether policies stay consistent across platforms and whether runtime checks add material latency. The architecture becomes far more valuable when telemetry from several vendors produces one coherent policy decision before an action executes.
Do not neglect the identity attacks happening now
Agent security dominated Oktane, and Okta’s threat intelligence researchers highlighted that AI makes reconnaissance and the search for customer misconfigurations far easier for attackers. Separately, the team is focused on what it calls operator-in-the-loop attacks, in which a social engineer on the phone guides a victim while phishing pages change in step with each authentication challenge the victim sees.
The takeaway for customers is to make phishing-resistant authentication a very high priority: enforce it, through passkeys and similar methods, for every resource that matters, and remove fallback paths to weaker factors, because that fallback is what the social engineers are steering victims toward.
Enterprises still operating weak authentication, excessive standing privilege and poorly governed service accounts have immediate identity exposure, and AI makes those weaknesses easier to exploit. Run the programs in parallel: keep eliminating weak authentication and excess privilege while extending identity governance to agents.
What customers should take away from Oktane
Okta’s strategy points in the right direction because the identity decision itself is changing. Authentication and governance answer who is acting and what that identity may access. Agentic systems add a third requirement: controlling what an authorized identity does once it is inside.
Whether Okta becomes the broader agentic control plane will depend on execution, particularly on reconciling identity policy with context generated elsewhere in the stack, and on how much recovery its partners deliver. Customers can act before either question is settled. Build an authoritative inventory, assign an owner to every agent, separate human permissions from agent authority, constrain delegation across agent chains, put stronger controls around consequential actions, establish runtime telemetry and decide where human approval is required.
Ask every platform team this quarter for a written list of the agents they have deployed, who owns each and which credentials each holds, then run the rogue-agent recovery exercise against the first agent on the list.
