Welcome. Thanks for making it in. Harish, thanks for making it in here. All good. Thank you for having us. I think we're just going to try to get Dave in, and then we'll try to kick things off here. In any case, maybe I'll just make some quick intros just while we try to get Dave into the room. There's Dave. Here we go. Hey, Dave. Ely, Harish, David, thanks for being here. Janice as well. I very much appreciate you all being here to hopefully get a technical session for people and go into a topic that I think is very interesting. Ely, the Chief Product Officer, Harish, SVP and GM of AI Security, and then we all know Dave and Janice on the IR side of things. I'm going to throw it over to Dave to hit the safe harbor, and then Ely and Harish have some prepared slides and topics to hit. I'll throw it over to you, Dave. Thanks so much. Thanks, Eric, thanks for hosting us today. Really appreciate it. Just Janice is going to throw the safe harbor up. You guys are all familiar with the safe harbor language, just a reminder of that. Just to remind you that today's conversation is really about the technology. We're not going to be taking financially- related questions today. With that, I'll throw it over to Ely. Thanks so much. Once again, my name's Ely Kahn, Chief Product Officer here at Okta. I've been here about almost six months, but been in cybersecurity my whole career. First inside the U.S. government, U.S. intelligence community doing cybersecurity, then a startup called Sqrrl that was acquired by AWS. Spent four and a half years there building product. Most recently before Okta, I was Chief Product Officer at SentinelOne. E xcited to be here to talk a bit about our vision, our roadmap, and our strategy. Just as a refresher, I thought I'd start with a reminder about what is the Okta platform. Really over the last, three to four years, we've been building out a complete identity platform that covers all the major use cases that you need to protect your identities, pre-authorization, add authorization, and then, post-authorization. Maybe first starting with the pre-authorization focus products, we have our Identity Security Posture Management product. This was via an acquisition that we did three years ago, a company called Spera. This gives us the ability to discover misconfigurations, identity-related misconfigurations in hundreds of your SaaS and other types of applications. Generally speaking, we're looking for overprivileged or misprivileged administrators or other identities, including administrators that haven't been used in a period of time, or other examples of misconfigurations that increase your blast radius. Next up, we have our Identity Governance product. This has become one of the fastest-growing products in our portfolio. It just recently has crossed over 2,000 customers, which puts us on par now in terms of customer adoption with other IGA products like SailPoint. This gives us the ability to ensure that those users that you've onboarded to Okta have least privilege allows us to do access requests and access certifications to ensure that those users continue to have the right amount of privileges over time. This is also complemented with Okta Privileged Access, which I think about as the flip side of the coin to our IGA product. With Okta Identity Governance, you're provisioning access to standard sorts of applications. With our Okta Privileged Access, you're provisioning access to high-risk, high-trust resources things like databases or Amazon EC2 instances. When we do that, we can do session recording. We can also plug into on-prem resources, ensure that even if you're using a long-lived credential or API access key, we then short-term ephemeral tokens to ensure that even if there is a compromise, the blast radius is small. Next up, at authorization time, we have a couple of products. Of course, our flagship MFA SSO product or Okta Access Management, which provides secure cross-platform, phishing-resistant authentication. We sync that up with Okta Device Access so that you can use the same login processes both into your device and into your applications. Lastly, Identity Threat Protection. This is our identity threat detection response product. This gives us real-time signals that can be used to look for misbehaviors and anomalies during the session. The real power here is these aren't producing just another set of alerts. We can tie this into our other products so that if we see users above a certain risk threshold, we can do things like universal logout, or step-up authentication to really contain that risk within that session. These products, they're not siloed. The power here is that they're part of a unified identity security fabric. They allow us to cover a broad set of users and devices, including employees, partners, contractors. It can plug into both modern SaaS applications and legacy on-prem infrastructure. Now, most recently, we've extended the platform to support AI agents as a first-class identity in the platform. I'll get more into that, and Harish is going to go real deep into that. In terms of that unified identity security fabric, let me give you just one example. Let's say as part of our ISPM— our Identity Security Posture Management product, we've identified that a particular administrator is not being used, that account's not being used. We can use that information, then kick off an access certification in our IGA product to officially recertify whether that user needs that administrator account, and if not, revoke it. We have a bunch of out-of-the-box integrations across our products. We also have a low-code, no-code solution called Okta Workflows that lets you stitch together any other type of custom integration between the products that you might want. Lastly, and certainly not least important, is our uptime story. We're at four nines as our official SLA. This year, we're actually at 100% uptime. Over the last three years, this means that we've had roughly 69 minutes of downtime. Compare that to a Microsoft that's had over 2,000 minutes of reported uptime, this is a key differentiator for our platform and one of the reasons customers love us. Next up. A big move for Okta has been that we've been really pushing towards this identity platformization story. We've been working with some of our largest, most complex customers on this story, where they're making a big bet, and they want to take a very complex set of legacy solutions and simplify. This is a customer that we've been working with for the last year. We'll complete this platformization story this year, and they're very typical of a large Fortune 2000 company. In this case, they've used a legacy solution for identity management. I think they're using SailPoint here, and they're using another vendor for their access management in this case Ping, and then another vendor for privileged access management in this case, CyberArk. They have specialized teams for each of these vendor solutions. It's not only a cost issue for them, but it's a complexity issue. That complexity also translates to security, meaning, the more complex your stack is, the more likely there are gaps in which adversaries can compromise. They wanted to solidify down into a single vendor, Okta, not only to reduce costs, not only to reduce complexity, but also to increase their overall security posture. We're well on the way to this. We'll finish this complete re-platformization this year. T he customer will be seeing significant they're estimating somewhere around 40% economies of scope gain in the form of cost savings. Maybe backing out now in terms of our 2026 product strategy, this closely relates to that last slide there in terms of the platformization play that we're making. We have five main elements to our product strategy. These are not the only things that we're working on, but these are the top five most important things that we're putting our efforts around. The first one is our Okta for AI agent story and ensuring that we have a first-class set of experiences across all of our products to support AI agents and to protect the identities of AI agents. I'll get more into that in just a second. Next up, second and third, maturing our IGA and PAM solutions to be world-class so that they can rip and replace legacy vendors like a SailPoint or like a CyberArk, and even just win head-to-head in greenfield competitions where the customer may not even be using us for access management. We're well on our way to that as well this year, and we have a number of wins where that's happened. Identity security fabric. I'll actually talk about identity security fabric in a little more detail in the next slide through the lens of Okta for AI Agents and how all of our products are coming together to provide that unified identity security fabric for the AI agent use case. Lastly, Okta, like a number of companies, is all in on AI native product development. We are aggressively using coding agents across all of our product teams and seeing 50% gains in product life cycle development, which means we're shipping products and features faster to our customers while still maintaining the really high bar around uptime, resiliency, and security. Let's jump into the AI agent story here quickly. I'm not going to go through this in detail, but I saw there were some questions in the pre-reads about what type of agents does Okta protect. This is a common question. We actually built out an AI agent taxonomy to help with this. At a high level, the four major categories of agents as we think about them are embedded agents. These are things like your Zoom companion agents. Embedded agents are the one type of agent that we do not try to protect. These agents are essentially hard-coded into SaaS applications. They don't expose APIs, so we can't really manage them. Next up, standalone SaaS agents. This would be something like a Devin or a Fin. This is an AI agent that exists as a SaaS agent. We can onboard these types of agents into our platform to govern and protect them. Agents associated with automation platforms, where the agent built into a Boomi or a Torq or Tines, that's also a type of agent that we're working to protect. Homegrown agents as well. If you built out a fully- custom agent using LangChain or an agent builder platform like Amazon Bedrock, t hose are also agents we support. The other dimensions of agents that we oftentimes look at and have some unique characteristics in terms of how we protect them is the delegation pattern. Is this simply a human prompting agent, or is there a set of sub-agents that are spawning? How long does that agent exist? Is it a very short-term ephemeral agent or a long-lasting one? These are all considerations that we've gone through as we built out our Okta for AI Agents platform. Let me talk about that quickly in the next slide. This is a busy slide here. Let me talk through it real quickly, and then Harish is going to, I think, touch on some of the details here in more depth. When we talk about our Okta for AI Agents story, at the top level, we think about through three simple questions. Where are my agents? What can they connect to? Ultimately, what can they do? What you're seeing here is our reference architecture. Most of these things are in place not all of them yet but these are all the things that we're building towards, really over the next either we have them now or building over the next 6 to 12 months. It starts with discovering your agents. We built integrations with a number of different tools to directly import agents from those tools. This could be things like Amazon Bedrock or Salesforce Control Tower. Any of those types of agents, we can directly embed them into our registry through a direct import by calling their APIs. If you build a homegrown agent, you can use our SDK to then import that agent directly into our registry. We also have the ability to discover unknown agents. The first capability that we launched earlier this year is using our browser extension to discover OAuth claims between users and agentic tooling, and then giving the users or the administrators the workflow to register those unknown agents in our registry. Once they're in our registry, they can be registered with a human owner, or they can be registered as a fully -autonomous agent. You can apply additional metadata to them to ensure they have a full identity, and they can come under user entitlement reviews. Is this a user that should have access to that agent and doing access requests and access certifications? Does this agent have the right access to resources and able to do access certifications over time on that? Once that agent is registered in our agent registry with a first-class identity, you can start giving it permissions in the form of scopes. These are considered coarse-grained permissions, you might give it certain permissions to Slack or to GitHub or to Jira in terms of being able to read versus write versus update, et cetera. This is really important because you want to give those agents the least amount of privilege possible, but enough privilege to fulfill their goals and objectives. We've also shown we've put some blogs out on this recently, how you can apply fine-grained access controls to agents. Not only can you apply these coarse-grained scopes, but if you also wanted to give it a more fine-grained access policy, like say, hey, this agent can only view not sensitive data, or, they can't write sensitive data. Those would be additional fine-grained access controls. This is where we bring in some of our Auth0 capabilities and its FGA product to combine with our Okta for AI Agents solution. Once you've defined the access policies, then it can start accessing resources. It can access resources through our MCP servers, authorization servers, our SaaS authorization servers. We also have a new agent-to-agent capability. Ultimately, we are able to monitor these capabilities, produce logs that can be shipped to a SIEM, and perhaps, most importantly, if things start going wrong, if that agent starts misbehaving, acting suspiciously we also give you a kill switch that allows you to revoke tokens and ensure that those agents cannot continue accessing resources in a malicious way. Like I said, there's a mix here of things that we've delivered and things that we're working on, but this is really the complete story that we're working towards and will ultimately help customers not only identify their agents, but ensure those agents operate with least privilege and have a small blast radius if they're compromised. With that, I'll hand over the mic to Harish. Thank you so much, Ely. I see some questions trickling in. I will keep this brief so we can make sure everyone's questions get addressed, because that is what is most critical. For introduction, I am Harish Peri. I run the AI business at Okta. I spend majority of my time with our customers in the field, making sure everything to do with our AI security story resonates and that we're growing this business. That is why I'm here. Some of the content I have is more around how we're positioning our capabilities and how we tell the story to the broader market, which I think will also be very helpful to this audience. If you go to the next slide. The goal that we have for every one of our customers, and folks that are not our customers that are embarking on their agentic journey, is every company will become an agentic enterprise in the next year and a half. What that means is many pieces of their product development, portions of how their employees interact with their tools, how they connect with their end customers, how they connect with their partner suppliers, all those are going to become agentified. There's going to be agents in the flow there. Our appeal to all of them is you could be an agentic enterprise, or you could be a secure agentic enterprise, which means you have a centralized security offering to be able to control the identity and access and authorization of everything those agents are connecting to. That's the broader kind of hook that we have for the market, which is to say, how do you not just be an agentic enterprise, but how do you do it in a way that's secure? Because the difference between building agents and rolling them out into production is security and scalability concerns. That's really how we're starting our position. Can we go to the next slide, please? Since we've embarked on this journey, we've engaged with hundreds and hundreds of customers. We're talking CISOs, CIOs across some of the largest companies in the world. T he thing is, the tongue-in-cheek way of putting this is the cat is out of the bag. Everyone has agents that are rolling out. The question is, where did the cat go? That gets into some of what Ely was touching on, which is discovery is a really huge issue. The common themes are everyone in our company is going to become a developer at some point. How do I know that they're developing within the right guardrails? How do I ensure that all of my Claude Code or my OpenAI or my Cursors or all those development assistants are actually being controlled in the right way? H ow do I ensure that they don't execute judgment and delete something important overnight with no human oversight? This problem is very real. It is very top of mind for pretty much every one of our customers and every new company that we're talking to. It is very much in the zeitgeist of the topic of securing AI agents. If you go to the next slide, please. I want to spend a little bit of time on maybe some broader topics, which is, I actually spend a ton of my time educating our customers about just the nature of the overall problem. One of the topics I get pulled into a lot is, well, I have an AI gateway. I have guardrails around my LLMs. To that, my response is, that is necessary but not sufficient. When you think about what it takes to secure agents, you really have to think about models, which is, of course, the brain behind the agent that is making decisions in response to a prompt, and deciding what tools need to be accessed. There's a second part of it, which is how do I actually secure the identity and the authorization of what that agent is actually accessing? That's a lot of what Ely was touching on. Model is one piece, identity is the other piece, and the third piece is the data itself. For those agents that are accessing your data at large scale, either for retrieval-augmented generation, or as part of just their daily operations, also getting down to the level of, is this agent authorized to access this data at this moment in time, given all environmental signals, is a third big piece. We like to think about model, identity, and data, and where Okta is really starting right now is this notion of how do we control the identity, the authorization, and the access of every one of these enterprise agents that are running around your organization. This is an important concept because people sometimes get hung up on the model side, but that's only one out of three things of the bigger problem. If you go to the next slide, please. This is just an example. This is a completely hypothetical example, but as we see agents being rolled out, this is a kind of a common pattern. One of the fundamental issues you're dealing with when it comes to agents is unpredictability. This idea that in response to a given prompt this is a hypothetical finance agent that's going to help your procurement team with contract or PO approvals, i n response to the same prompt, there's going to be tools, there's going to be memory, there's going to be LLMs that are accessed, and it might come out with different responses in each situation. I bring up this slide because it's very critical for people to understand that you're not dealing with a deterministic piece of software. You're fundamentally dealing with something that, at scale, will get you a lot of efficiencies, but has a level of nondeterminism to it that does require a level of human control, which is where identity comes in. Again, very powerful, but also has a very nondeterministic aspect to how they work. If you go to the next piece, there's a build here, we can just kind of click through this in the interest of time. We'll pause here. When you take an average large enterprise, once you think of their agentic rollout at scale, and you think about their users, you think about their various functions, you think about the various applications and resources that this agent is accessing. When you start to do the math, you multiply through the various MCP servers, the various other agents that single agents are calling, when you think about the external services that they're accessing, this is a little bit of a large number, but when you do the math, you're talking on the order of billions of access decisions that have to happen per day to get a truly agentic enterprise to work. Again, when you multiply the users, the applications, the resources, the agents, the agent-to-agent chaining, the complexity increases tremendously, and each one of these access arrows is a potential risk factor, because what you're dealing with is not just a deterministic access claim, but it's an agent that is making a decision at that moment in time and could be exercising judgment. That's why the notion of the attack surface becomes even more complicated when you're thinking about agents. A s you multiply that across the entire estate of technology that your average large company has, the complexity is quite mind-boggling and requires centralized control. If we go to the next slide. There's another thing that you would need to think about here, which is, I touched on nondeterminism. There's also a notion of autonomy. Agents are going to take actions on their own. Traditional Zero Trust was not made for a world where you have these autonomous actors that are nondeterministic. You really need to think about how do you control that. The other important piece which— there was a question in the chat about differentiation is this notion of delegation chain. Every regulator, every auditor out there is going to come knocking on a company's door to say, can you prove to me that a specific resource was accessed by a user, was accessed by an agent, or was accessed by an agent acting on behalf of a user through a multi-agent access chain? Being able to centralize and track that delegation chain is the other important concern that breaks kind of Zero Trust as we know it today, which was made for humans, really. Finally, there are more and more models emerging of ephemeral agents, which is agents that spin up other agents that are short-lived that might execute a specific task. It's an entirely new paradigm of technology and software. We really need to think about Zero Trust more holistically. W hy we are so bullish on this is the one common thread across all of this is that context, is what was the intent of the original user that gave a prompt to an agent that then either spun up an ephemeral agent or called a sub-agent that then accessed a resource. It's the authorization and the identity that's the core of all that to be able to say we can actually control the chain of what is happening. I know there's a little bit of zoomed out, but it does require the industry at large to rethink what Zero Trust is all about, and identity and authorization end up being at the core of all of this. If we go to the next piece. Again, when we think about what Okta for Agents is, really the direction that we're heading in, and actually not even heading in, the GA capabilities that we have in market today are really providing this notion of a control plane for every enterprise agent in your organization accessing every resource on behalf of any user in the organization. Centralizing that, governing every call, binding it to user context, ensuring that access is provided just in time with least privilege, and then creating an immutable layered audit trail so you know exactly what resource was accessed by who, on behalf of who at what moment in time is the core of the platform that the capabilities we're adding on top of the identity security fabric that Ely touched on earlier. It's very powerful stuff. It's in market today. In the interest of time, I'll go to the next slide, which is actually this. I want to leave you with maybe something a little provocative. I said maybe a minute ago that I spend a lot of my time educating our customers. There's a lot of myths that are popping up that we end up doing myth-busting around. Things like, oh, I have an MCP gateway. I think that's good enough. The answer is, that's good enough if you're not interested in full user-to-agent-to-resource chain mapping and auditing, which is something that every company is going to need. That's some education we have to do. The other thing is, oh, I use Bedrock AgentCore or Copilot Studio today, and that has some identity stuff built in. Think about where Okta is today. We are an independent, neutral, central broker of human identity to every resource in your ecosystem. That's exactly what we're doing with agents. Separating the identity from the core agentic platforms actually gives you not only a level of control, but also a layered defense and depth strategy that reduces your single points of failure. That's the other big myth that we spend a lot of time on. The third is, well, this is just acting on behalf of a human, so why do I care? It's just going to carry the human's credentials. Sort of, but not really. When you have agents that really are helping your organization, these are multiplayer agents, to use a term from Anthropic. Or these are enterprise agents that are accessing multiple resources. They do need their own independent identity that can be intersected with the permissions of the invoking user to then create the perfect permission chain. This is just an example of some of the education we're doing. The market is moving very fast. We are right at the forefront of it. We're spending a lot of time educating our customers, but there's tremendous momentum on that front. I'll pause there. Actually, I think we can call it a day on the slides, because I want to make sure we have time for questions. I don't know, Eric, if we hand it back over to you. Thanks, Harish and Ely, for the comprehensive overview. A lot of things I want to dig into. Maybe, Ely, just coming back to where you started, or one of the things you started with, was the four different buckets of agents. Today, can you just high level give us, set the ground, or just lay the framework for us in terms of what's the maturity of AI agents today in organizations that you're talking to? Secondarily, what are the most prevalent types of agents that you're seeing? One quick anecdote here. We had a large financial services customer in our customer executive briefing center a month ago, and I was asking them how many production agents they had. They responded with over 2,000. When we were first doing our pricing analyses for Okta for AI Agents, we assumed there would be somewhere around 20 production agents in a large customer. That was done back in October, and you can see how fast the market's moving just from that one customer anecdote. In reality, the most prevalent type of AI agent that's out there in our customers right now are coding agents. There's certainly a lot of, and probably more sophisticated, customers are building their own agents, but almost every organization we walk into has a Claude Code or a Codex or another coding agent. These are top of mind. With those agents, it's not really about the number of agents, because typically you can think about that as one agent for the entire development team. It's the breadth of usage that's happening and the types of tools that those coding agents are able to connect to, and it's those developer- to- agent- to- tool interactions that need to be protected. Harish, one of the things that you said that I thought was interesting is I think you called out that discovery is the biggest i ssue that customers are facing right now. Can you just help us understand what Okta does today from a discovery of agents perspective? Really, I think there's a lot of emerging vendors out there that we are familiar with and see getting a lot of momentum. What are they doing that's unique and novel, and how differentiated is this capability that either you or the emerging vendors have when it comes to discovering agents? More broadly, discovery is— it's not enough to say, I ran something and I have a dashboard that shows me a list of 10,000 agents. That's fine. What do you do? Where Okta is coming in is to say, where most likely are the most critical agents going to be living, and how can we find them the fastest? That's what Ely touched on. There are known platforms like AWS, Copilot Studio, Azure Foundry, Agentforce, ServiceNow. There's a whole host of them that are already partners of ours, and we can easily detect agents in their agentic runtimes and then import them to Okta. That's one kind of discovery. The point I want to hit on is discovery is half the equation. You also want to register those agents in a central identity directory and give them their own identity such that all the tool calls then get routed through Okta. That's the real value there is discovery is part of it, but giving them identity and then controlling the flow of access is the other part of it. There's the known platforms. There's browser plugin capabilities for a variety of browsers, because one type of agent is also sort of the SaaS agent that you're accessing through the browser. The other one are local endpoint. The good news is we already have deep partnerships with the major cyber providers to be able to tap into their APIs and detect agents that might be running on the machine. Again, I want to emphasize that finding them and showing them on a dashboard is 50% of the equation. The other part of it is to say, now what? That's the part where the full connectivity with Okta matters, is to say, now I'm going to give you a unique identity, and ensure that there's no MCP calls, there's no tool calls that this agent is making that is not authorized and vetted and brokered by Okta. It's really becoming inline, and the flow is the end goal that we have here. From a product capability perspective, is Okta on equal footing with some of the emerging vendors out there when it comes to discovery, or do you think this is an area for development, if you will? I'll let Ely take that, as he's deep in that on a day-to-day basis. Right now, what Okta supports is one mode of discovery, which is browser-based discovery. This is for unknown agents. We also have those direct imports for known agents. For unknown agents, we support browser-based discovery. You can see in our strategy slide, we'll be adding additional forms of discovery. I do think that there are some really unique aspects of the Okta platform that will allow us to differentiate. Something that folks forget is that Okta is on every endpoint. Every Okta customer has an endpoint agent called Okta Verify, and this is a very powerful capability that can give us broad visibility into what is running on that endpoint. I mentioned Okta Device Access. That's how we discover what's running on that device to ensure that you have a secure login experience. We'll continue expanding our discovery capabilities, including using the full power of the Okta platform to do so. Staying on the governance topic for one more question, maybe switching to runtime. On the governance side of things, I think one of the maybe things that one might theorize in terms of who has an advantage when it comes to the identity stack is the IGA vendors, the traditional ones, have a lot of understanding of all the entitlements. T hey have the connectors to all these applications, and they have deep visibility into all those different fine-grained nuances that you need to know in terms of establishing access in the application. What's your perspective on the IGA vendors having that unique advantage? I understand that Okta has IGA so it's a little bit of you're in both camps but what's your perspective on that being a strategic advantage or moat? My take is that we've caught up with the legacy IGA vendors. It's proven out through our customer adoption, w ith over 2,000 customers using Okta IGA. We have a very powerful IGA product where some of the biggest customers in the world are looking at us from an IGA-first perspective. I think this is an area where we've invested significantly. We're going to continue to invest to close some of the long tail of feature gaps. I'm very happy with where we're at on the IGA side. I t's a critical part of our overall product to secure AI agents, but I'd say it's one component. Frankly, it's a really important component, but it's not the most important one. The most important one is ensuring that the AI agents themselves have a least privileged identity that has a small blast radius. The IGA piece can help you ensure that blast radius stays small over time, but we see it as an add-on capability, not the core central capability to our offering. What we hear from customers across the board is they're looking for a system of action versus a system of record where you can keep track of rules and things. They need a system that can enforce the most critical thing, which is this agent allowed to execute this specific action on behalf of this user at this moment in time based on a variety of signals, some of them being entitlements in the governance system. There are other signals, like network signals and endpoint signals and other risk signals. That ability to do dynamic real-time authorization, managing the entire chain of custody is the true ask that the requirement that the entire market is converging on. IGA is a portion of it, but it's not the be-all, end-all. That's where the identity piece comes in. Be cause you need a platform that can stitch together user, agent, resource, and that entire chain. Maybe moving to the authentication runtime side of things. We talked about the gateway. I think there's been lots of mentions of gateways from all sorts of vendors, et cetera. Can you just double-click on what you guys mean by agent gateway or access gateway, if you want to delineate the language there, and what role that is playing? We did this in our piece. Okta's role from the authentication side of things is we need to narrowly define the scope of what the user and the agent can do. If we do that right, the simple side of me might say, it's all established in the token itself when they go to authenticate. I think you and the market are saying, no, you need the agent gateway on top of that. Just help us understand what the agent gateway is adding incrementally that's not defined in the agent's token. The agent gateway does a couple of things. One, you can think about it as a single endpoint or access point for a variety of agentic tools. If you're using Claude Code or Codex, the agent gateway is the access point for how those tools interconnect into our platform. The gateway itself once those agentic tools are connected to the platform, serves as a policy enforcement point. It's where we enforce that those agents are accessing the tools that they're authorized to access. It's also where we provide the inventory of tools that those agents can access. Onboarding various MCP servers, each of those MCP servers have a variety of tools. We'll allow folks to mix and match those tools into least privileged virtual MCP servers that then those agents could access. I t serves as the real-time policy enforcement point to ensure that they're only accessing things that they're authorized to. Can you just be more specific, Ely and Harish, with real-time enforcement? To be candid, I think we see that in a lot of product announcements and press releases. Just be a little bit more specific, if you could, on what real-time policy enforcement is. To me, that seems like it is where the market is really trying to focus its efforts on when it comes to AI agents. I'll start. Harish, feel free to jump in. Go ahead. Each agent is granted a set of scopes as part of its access policy. The agents themselves can either be acting on behalf of a user or fully autonomously. We support both of those modes. If they're acting on behalf of a user, they actually get the intersection of the human's permissions and the permissions granted to the agents. Ultimately, you need a policy enforcement point to decide whether that agent, which is making a request to access certain tools, should be granted that request. That enforcement point is the agent gateway. It's making the decision there, or it's enforcing the decision whether that agent should get access to the tools based on the permissions of the agent and the permissions of the user, if it's acting on behalf of the user. That happens in the agent gateway. Harish, anything else to add on that? Maybe I'll give a different way of thinking about it, which is, put coding assistance aside because their access patterns are, I need to talk to Jira, I need to talk to my S3 buckets, I need to talk to Artifactory, like those. We have many large customers that are building internal agents to help their employees with a finance use case. The downstream systems that agent needs to touch are the ERP, in some cases, the MRP, inventory, very complex legacy systems that all may or may not have APIs and may or may not support Cross-App Access, for example. In the flow would be somebody in finance, they have the interface to the agent, they say, can you approve this PO? Like the hypothetical example I gave. The LLM behind the agent will say, I need to first go check inventory, then I need to go make an update in SAP, then I have to go talk to this other system, then I have to send an email, whatever it may be. There's different levels of scoping, meaning what level of access does this agent have to Workday or to SAP? That's the first piece that Okta is controlling. There might be custom authorization rules that also need to be enforced depending on attributes in the user's profile, depending on other attributes that might be custom. You chaining all those together and making a real-time decision based on all that available context, that's the core runtime, the authorization that we're getting at. The gateway brings all that together in a highly performant way. We can support some of this with our fine-grained authorization capabilities today, and we're pushing towards this notion of intent driven, which is what is the other theme that you might be hearing in the market today, which is, let's make sure this agent doesn't go off on its own and try to execute an action that was not matched with the intent of the original user. Keeping track of that entire context at every transaction and enforcing that in a highly performant way based on things like OAuth scopes, but then also custom authorization rules, that's the holy grail of this runtime capability that we're pushing towards. Having a central authorization point is critical, and that's a big part of what the gateway does. Maybe kind of jumping to the punchline, Harish and Ely. How do you see this market evolving in terms of where the point of differentiation is going to be in the identity stack, whether it's the registry, the IdP, the discovery, the gateway, the token path, like the actual issue of the tokens. Just how do you think about it? Give us the framework of where you think the unique differentiated aspect is going to be in this market. I think I'll double down on something Harish was just talking about. This also touches on some of the other questions that came in. In terms of what is fundamentally different about AI agent identity versus human identity. There's a number of technical differences, tactical differences, like agent-to-agent connectivity required a whole new type of standard, because there wasn't a good corollary on the human side. I think one of the most interesting differences where Okta's making big investment here is the fact that we're going to have to fundamentally rethink identity management and access management with agents because the traditional process of defining static permissions and then every quarter reviewing those permissions to see if they're still least privilege, that's eventually going to break down, because AI agents are becoming more and more powerful and more and more autonomous. That means that it's going to become harder and harder for an administrator to predefine all the permissions that an AI agent might need upfront. Instead, we're going to need to move to a world where the permissions are granted to agents in a more dynamic, just-in-time basis. They'll be granted if the tool invocation that the agent's attempting to do is not anomalous, does not drift too far from the original agent intent, does not contradict any guardrails that you want to ensure are adhered to. It's this mode of moving towards just-in-time dynamic permissions for AI agents that I think will become the biggest differentiator, that's a big place where Okta is focusing. I wanted to hit maybe a little bit less of a technical question, maybe a little bit more market questions. One thing I've noticed and picked up over the last several months is you guys seem to have a tight relationship with Anthropic when it comes to their identity announcements and with workload and [exfiltration] and I've forget the other things but it seems like you have a tight integration. Can you just elaborate on what you do or don't have when it comes to partnerships, whether on product or go to market with these frontier AI labs? I could. Go ahead, Harish. More broadly, we have been and always will be an ecosystem player. The power of Okta is very much to do with how we can, one, help drive the right industry standard, and then help bring all the ecosystem players along with us and implement that standard. Anthropic is one example. T here's been a lot of public announcements around how they're supporting Cross-App Access. What that does is, one, that helps drive the adoption of the standard called Cross-App Access, which reduces things like continuous OAuth consent fatigue and also creates a central way to control permissions. It helps drive Anthropic adoption, helps drive our adoption, helps bring the industry standard up. T hat's one example of many. Ultimately, to make an enterprise a secure agentic enterprise, we have to make sure that our ecosystem integrations are tight with every player in that blueprint that Ely was showing. Anthropic and their frontier models are one of them. We have integrations with the cybersecurity vendors like CrowdStrike and Zscaler. We have integrations with the agentic platforms where agents are created. We need to think about integrations with other gateways that customers may have. It's the same story that we've had for human identities. We need to plug into all the players in the ecosystem to bring it to life. Same thing for agents. It's just a new set of players. One thing I wanted to ask you and get your perspective on is, I always tell clients, investors that identity is probably the most fragmented market in cybersecurity. There's a whole slew of startup vendors out there and point solution vendors out there. Maybe help frame for us, if an organization spends $100 on identity today for humans, I don't know, Okta maybe can get 20% wallet share of that. Maybe it's 40% with IGA and PAM. Then we have agents. W e can decide if that $100 for agents is equal to humans, and it's another $100. Do you agree with the premise that your share of wallet opportunity is relatively small today in the grand scheme of the identity stack? With agents, could that 20% of wallet share be 80% of wallet share, 90% of wallet share? Does that question make sense, and does it resonate at all? It resonates a bit. My take is that this is not the same wallet share and that the wallet's expanding. Meaning, as customers more quickly adopt AI, they're also adding budgets to protect those AI agents, and that's not coming from the same budget that they are using to protect their other identities. I think what we're tapping into with our customer base is new budget associated with AI adoption. It's not the same denominator. Now, putting that aside, the stack for protecting AI agents looks very similar at the 30,000- foot view as the stack for protecting human identities. We have ISPM, we have ITDR, we have SSO. We're building out that full stack to protect AI agents and the identities of them. I would say that our wallet share for human identities is very similar to our expected wallet share for AI agents, but it's a different wallet. I would agree. The simple part of the question is just the identity market is highly fragmented today. Does it look much more consolidated when it comes to securing AI agents? Is the punchline. It goes back to what Ely was saying, which is, companies are taking a more centralized approach to rolling out AI. This is a decision being made at the CEO level, at the board level to say, okay, we're going to spend X billion dollars on an agent transforming our company with AI. Given that agents live in the application layer and identity authorization is the center of all of it, two things. We do believe that we have a shot to go and take a slice of that entire spend, which is a more elevated conversation, and the evidence bears fruit. I have conversations every day now with CISOs and CIOs who are coming saying, we need you to draw the reference architecture of how everything comes together. We are the middle of the ecosystem now, and the evidence is showing that. It's a different wallet, it's a bigger wallet, and the mechanics are going to be different. It's a slice of the entire thing because it's essentially a security blanket around your entire agentic investment. Eric, I think, to answer your question, is it fragmented or more fragmented or less fragmented? It is a brand new technology area, so there is a plethora of startups in this space, which makes it feel very noisy. I think, similar to what we saw with cloud security vendors, there will be a consolidation because, ultimately and we hear this from our customers our customers don't want different stacks to manage their human identities and their agentic identities. They want one unified solution where they can manage all of their identity issues together. I think there will continue to be consolidation and platformization in this area. Well, Ely, Harish, David, thank you so much. Great place to leave at the top of the hour here. Wish I could spend a lot more time with you guys, but it's been a pleasure tracking what Okta's been doing in terms of leading and shaping this market for AI agents, it's definitely been great to see. I appreciate it. Appreciate the time. Thank you everybody for tuning in and listening, and I'm here to help if anybody needs it. Thank you. Thank you all. Thanks, Eric. Thanks everyone. Bye.