Transcript
So look, normally we're joined by industry thought leaders and cybersecurity experts. Today we are joined by one such thought leader as well, but this one's a very special, special guest. This is our own Okta CEO and co-founder, Todd McGinnon. Todd, how are you doing? I'm excellent, Harish. Thank you for having me. Fantastic. So today's format is a little bit different. We're going to hear from Todd about his point of view on all things zero trust, agentic security, what every organization should think about before rolling agents into production. And after that, we're actually going to go into some live demos of exciting new innovations that are going to be rolling out in the next couple of weeks. So you do not want to miss this streamcast. Stick around for this. So let's just jump right into this. So, Todd, a couple of months ago, we launched what we call the blueprint for the secure enterprise. Why a blueprint? How did that come about? What's in it? What goes into that? I think a lot of things we do, it's really informed by our conversations with customers. And I was meeting with, like you do, meeting with many, many customers that are really excited about all the potential for AI, agentic software and agentic capabilities and automation. But it's kind of confusing to them on how all the pieces fit together. Vendors are coming at them saying that they have the answer and that they're the key link in the chain of AI management security. And it was one specific customer conversation. He said, you know, what we really need is we need you guys to get together and give us a plan or an outline of how it should all fit together. So I said, that's something really we should do that. So we put our pencils to paper and put together what became the blueprint, which is that's the purpose, is just kind of explain to customers and prospects how this world could fit together and what role Okta played in it. And most importantly, what Okta wasn't doing. We have very cool capabilities that we're invested in that we are doing, but like, where's the borderline and where do we integrate? And we're very good at integrating, but where's that borderline? What other technology should they put around Okta to make sure they can manage and secure this next generation of technology? Yeah, that makes sense. And so when a customer or organization sort of implements all parts of the blueprint and has that architecture rolled out, what does that look like? Like, how do they know that they're there? I think they get trust and confidence that this whole new layer of technology in their stack is, they have visibility and control and risk mitigation, while at the same time, it's actually providing the business value that they're going after. This is all about driving the business and how these systems can automate and reduce costs and open up new avenues of revenue for the companies and help them further their strategy. And they want to do that successfully is the top order. And then second order is like making sure it's all managed and secure and they have the visibility and the risk. And no one wants to take this whole new layer of technology and have it open up their risk aperture. They want to manage risk and make sure it's secure at the same time. Yeah. Yeah. Makes sense. Makes sense. Yeah. I've been hearing a little bit or a couple more often now about the notion of zero trust. So zero trust has been around for a while. Identity is a core part of zero trust, but that was for humans and maybe for some non-human identities. But when it comes to agents, what's your POV on how kind of zero trust needs to evolve in the age of agentic? And you could say it doesn't have to, but I'm just curious if you were to position it, how would it be? Yeah. I think about it in two layers. One is that, so zero trust was 15 years ago was a new concept and there was the BeyondCorp paper from Google that outlined Google's own evolution toward a zero trust architecture. And that was, I think it was coined by probably Gartner, the term zero trust. But I think it was this somewhat vague concept that had these goals and then coining the term put a stake in the ground on where the industry was headed. And then people made progress moving toward it and kind of eventually this architecture solidified around it. And so I think the similar thing needs to happen for agentic. We need to, as an industry, we need a way to think about what we're going for. And we've tried to articulate this with our blueprint. And then we need everyone to step up and do their part. And specifically around the analogy to zero trust for people, I think the equivalent was identity and phishing resistant multi-factor and the correct authorization inside of systems. There's a very strong analogy to agentic. Right now we need the equivalent of phishing resistant MFA for agents, but they're not there. And it's a big issue. You see token theft and all these agents having these credentials in their source code or in their config files. And so at a high level, we need a zero trust for agents to get everyone headed in the right direction in terms of an industry architecture. But then very specifically around identity, we have a clear and present problem, which is we don't have phishing resistant multi-factor authentication for agents. We need to put that in place at a tactical level at the same time, having it fit in with the rest of the equivalent of zero trust for agents. Yeah, it's interesting, right? Agents promise a lot of automation and straight through processing, and it's going to empower the workforce in a whole new way. But if an agent needs to check for permission every time, it kind of defeats the entire purpose. Should I take an action? Yes, please. After 15 of those, you're probably like, I'm just going to do this myself. So yeah, it's a fair point. It's like zero trust was made for humans on humans that were not moving as fast, but now if you have agents moving at agent speed, that whole construct changes. So it's, yeah, just different definition of trust and verify. So along those lines, I mean, the point of this screencast is we're going to get into practical demos. We're going to show some product. But at an implementation level, so many of our customers are looking to roll out agents to their production. They're there, they're on the start line. But if you were to give a CISO or CIO or CEO of a customer, three kind of pro tips on like, hey, do not roll out agents into production unless you have these things sorted out, right? Like identity, like kill switch, things of that sort. What would be something that come to mind, like three key pro tips? Well, the first thing is the way to think about agents is a new version of everything in the stack. So I would, especially when I talk to boards and CEOs, I would say, agentic is not one thing. It's a broad transformation of all the technology. And that means technology you're getting from your cloud providers, technology that you're getting from other infrastructure providers, application vendors, SaaS vendors, development tools. So it's a broad thing. And everything in the stack is going to be enhanced and reinvented to some degree with agentic. And so what that really means is that this, a system that can help you with visibility as to what's happening from the agents of all these different layers of your stack becomes very critical. And that, when I talk to people about that, it shifts their mindset from, hey, do I need to buy one thing for agents? Or do I need to get it from one vendor to more of what the reality is, which is it's a visibility you need into where agents are coming from across your whole stack. That's the first thing. And then the second thing is, and this is articulated talked about in our blueprint, is that there's many, many different visibility and management and security concerns, but probably the most important part of it is the connections. And what are the agents in various layers of the stack? What are they connecting to? And by the way, agents get better with more connections. So the trend from the technology people and the business people is more connections, more data, which if you don't have a good control of what the agents are connecting to in a way to make sure the authentication of those connections is done in a secure way, you're opening yourself up for a lot of risk. While at the same time, you're pushing all these new connections because that's the trend that makes all these things more powerful. And then the last thing is, what can the agents do when they navigate these connections? What can they actually do in the downstream systems? And how do you put the right authorization in place to make sure that agents are only acting in ways that they're supposed to, and that they're expected to based on what the task or the purpose of that agent is? So those are the three things. Where are the agents? And thinking about it as a catalog of things and a directory of things you need to think about across multiple layers of the stack, and then what can they connect to, and then what can they do? Yeah. Yeah, absolutely. Absolutely. And I would say there's the kill switch is the other key piece, right? It's like, once you have that central control plane, it's great for visibility, but if stuff goes wrong, which it will, can you react at agent speed and shut it off if stuff does go wrong? So it's kind of like making sure that you've got the final shutoff valve. So yeah, that's fantastic. Again, that's the thing that's valuable. My point, agents are a new version of everything in the tech stack. So they're all becoming agentic. And just like a kill switch is very valuable anytime in security, because you know you're going to have zero days, you know you're going to have things, breaches or things that are manipulated in an environment and you want a way to isolate and kill and cut things off. Same thing in agentic. Since everything is becoming agentic and there's going to be new attack patterns and new risks, you're going to be able to want to kill this agentic layer and shut it off and quarantine it based on these risks, which is a very important fundamental part of the stack. Fantastic. Well, Todd, thank you so much for your true thought leadership and insights on these topics. It's about time to be a real thought leader here. Exactly. Hey, for everyone here, he said it, not me. I'm going to bring up my friend, Gray, who's going to walk us through a series of exciting demos. We're going to show you how to secure cloud code. We're going to show you how to manage agentic authorization. We're going to show you how to hook up agent to agent. And finally, we're going to show you if everything goes wrong, how you activate the kill switch. This is going to be a lot of fun. Again, Todd, thank you so much. Let's go to the demos. So for the demos, I'm going to bring up my friend, Gray, who knows everything about anything that has to do with product and agents. So Gray, happy to have you here. We're going to show the audience a couple of key scenarios. What's the first one you want to walk us through? First one we're going to get to is one of the most common, one of the most urgent things that our customers are bringing to us, and that is these AI coding assistants, so like Copilot or Cloud Code. What are their employees connecting these to and how are they doing that? Why is that a risk? What's the actual risk with cloud code, for example? Yeah, I mean, for one, it's inconvenient for the users themselves. They have to configure MCP servers for each and every resource they want to connect to, but that's also a risk. Your employees are in control of that. Your IT and security teams don't have the visibility and they don't have the control over what users are connecting to. So this will show how Okta is allowing for not just a control plane for your IT and security teams in this instance, but also a single point of contact, really. So being able to expose multiple MCP servers and tools behind a single connection point. Okay, that sounds awesome. Let's take a look. So one of the most common scenarios we see from our customers or hear from our customers is concerns about their employees connecting AI agents to different resources. Typically, these are for their MCP servers. This introduces a couple issues. One is on the risk side and security side. IT and security teams don't have the visibility and control into what their users are connecting to and what's happening with those connections. And on the user side, it can be a little bit of a configuration hassle where each and every resource they need to connect to, they need to know what MCP server URL to add and be able to configure those and maintain those connections. So what we've done at Okta is added the ability to create like a virtual MCP server, a single point of contact for these AI agents to connect to and communicate with multiple resources, multiple MCP servers, and the tools that each of those provide, again, through a single point of contact. So think of it kind of like the Okta dashboard that users use. It's a single place where they can go to access all their applications without having to know where to go for each and every one of those. So let's take a look at it right now. So again, one of the most common scenarios is users connecting cloud code to different applications, whether these be homegrown applications or to things like GitHub for source code control. So in here, we can see I have a few different MCP servers configured directly. We don't see GitHub in there. We see one at the top, the Okta MCP. This is our virtual MCP where we should be able to access multiple applications. I'm going to authenticate as Sarah Sales and see what that gives us through that connection there. Assuming the authentication happens correctly, we should be able to go in here and view the tools. We see she's got 49 tools available. The initial ones we see ProGear Sales, ProGear Customer. These are separate MCP servers behind the scenes, and we can see the tools that those provide. Further down, we can see some additional tools. These are coming from GitHub MCP. So all of these things, all these resources are behind a single virtual MCP on the Okta side. So Sarah comes in here and tries to run a question, what are the prices of our basketballs? We should see that this will attempt to call some of those tools through that MCP server to the backend. So we see it trying to connect to Okta MCP and call the ProGear Customer MCP server and ProGear Sales behind the scenes. There we get a list of prices based off of order history. So we see some of the customer history, some of the sales from those MCP servers, but it's not pulling directly from inventory. So if she comes in and tries to ask how many basketballs do we have in inventory right now, we should see she doesn't have access to the ProGear inventory MCP server. This is based off of the policies that were defined over in Okta through that virtual MCP server there. So if we come in and we clear our authentication and authenticate as a different user that has different roles, it's going to be the same cloud session, same MCP server that we're using before, and see if this gives any different access to different MCP servers behind that, different tools, and see what we get here. So we're logging in as Mike Manager, and he has different accesses defined in Okta, and those policies should be checked once he tries to make a call here. So let's list the tools now for that same MCP server. Now we see ProGear inventory added to that list of things that can be accessed behind that. And if he tries to run that same command, how many basketballs do we have in stock, we should see that Mike does in fact have access to that and comes back with the right answer here. There we see through that same MCP server now we're calling the ProGear inventory tool, MCP server, and we get a list of all the basketballs in stock, the stock numbers, and the actual prices of those. So as we saw when we were listing the tools earlier, it wasn't just the ProGear MCP servers and tools that the users had access to, there were also some GitHub MCP servers and tools. So if Mike runs a quick command here to see what GitHub repos he has access to, we should see it should call the MCP or the GitHub MCP tools through that same virtual MCP server that we've configured. And here we go, we see Okta MCP, and it's getting the search repositories. This is one of the tools from the GitHub MCP. And here we go, you get the result here, he has access to one GitHub repo there. So just to recap, with Okta virtual MCP servers, your IT and security teams can provide a single connection point for your AI agents to connect to multiple resources, giving them the visibility and control that they need to make sure that this is done in a secure fashion. And for the end users, it makes configuration quite a bit easier. All right, that was pretty cool. That literally showed us how we can secure cloud code running on someone's local machine, but routing all the authorizations to Okta. I mean, if I were an organization of any respectable size trying to roll out coding assistance, this is how I would want them secured. So thank you for showing that to us. But that's just one, we got more. So great, what's next on the docket? So next up, we're going to show fine grained agent authorization. Since we're already securing these in Okta, we have the user context, we know that what they can do, they can access and the agent can access things on their behalf. So this allows us to create a model that takes in the attributes and the behavior of the user and be able to pivot and make those decisions on what they can do with each and every request rather than just a time of authorization. We're also going to show human in the loop. So anytime an agent is attempting to do a high risk or high value transaction on behalf of the user, making sure that an actual human reviews that and either approves or rejects that request before the agent actually executes on that. Yeah, that's actually even more cool, I think, because authorization is really going to be the key to this entire agentic security, I think. That's me, that's my point of view in the next couple of months, because you're going to have ephemeral agents, you're going to have autonomous agents. And controlling their identity is one thing, but controlling at a very extremely detailed, customizable, attribute-based level, what actions they can take in real time, I think that's good. That's what's going to separate the secure companies from the non-secure ones. So I'm excited to see this. Let's go. All right. So last year at Octane and earlier this year at Showcase, we showed how AI agents can be brought into Okta's universal directory. This can help secure the agents, define who's responsible for the agents, what users can access these agents, and then what the agents can access themselves. So whether they're other agents, MCP servers, applications. A lot of that was at coarse grain level. So agent accessing an MCP server and having access to those tools. What I'm going to show here today is fine-grained agent authorization. So being able to define models that factor in user attributes. These agents are acting on behalf of the users. So we have that context there through Okta. And then we'll also show bringing a human in the loop. So any high stakes or sensitive transactions that an agent might be taking, setting a threshold there and invoking requests to have an actual human review these requests before the agent takes action. So let's jump into it. Here on the left, we see our ProGear app. And on the right, we see user Bob Smith. This is who's going to be logging in. And we can see a couple attributes here, whether or not he's on vacation, is he a manager, and his clearance level. We've used these attributes within our agent authorization policy. And we can see how that will play out over here on the left. So we're authenticating to our application as Bob. That gives us the user context. The agent will know, and Okta will know who this agent is working on behalf of. So Bob's going to request to add 30 basketballs to the inventory. And we'll see if this works here. Our authorization policy defines, hey, if the user is a manager, has a clearance level of five, and is not on vacation, then they should be able to do this. And here we see 30 units have been added here. And then we see our authorization model on the right. He has the right clearance level. He's not on vacation, and he's a manager. But now let's see what happens if he tries to add even more. So he tries to add 600 pro basketballs to the inventory. In this case, we've set a threshold of 500 basketballs. So the agent is stopped in its tracks. It's not able to actually execute on that until a human has reviewed this request and has approved it. So if we go over to Okta Identity Governance, we should see this request sitting for review. And here we can see the request. All the information for the request is in the justification there. We can see it was Bob Smith who initially requested this. It wasn't under some arbitrary agent. And the details of the request, 600 basketballs to be added to inventory. Once this is approved, the agent should be able to detect this and then actually execute on that action there. And here we see 600 basketballs were added to the inventory as initially requested. Now let's say Bob goes on vacation. So we're going to come over here to Okta, update his attribute. Typically, this would be done in your HR system and synchronized to Okta, but we'll do it here directly. Set his vacation attribute to true. And we'll go back over to the ProGear app. Is he able to execute that initial request, adding 30 basketballs to inventory? In this case, we can see this was denied. It worked fine earlier, but based off of the agent authorization model that we had set up, it required not only he was a manager and had a clearance level of five, but also was not on vacation. Since he no longer met that criteria, now the request is denied. This shows how we've moved beyond just coarse-grained authorization decisions. Being able to define a model that factors in user attributes, making real-time decisions on what the users can do, what the agents can do on behalf of the users, and then bringing in humans to review and authorize high-risk or high-value requests there. All right. Thanks, Ray. That was excellent. That was like literally custom attributes from the user's profile, controlling what can be accessed. I mean, the possibilities are really endless here. So thank you for showing us that. We're going to keep the strain rolling. So I think you got one more in store for us. What can we see next? I do. I do. So in this last one, it's actually two things combined here. So when we're talking to our customers that are further in their agentic journey, we're seeing more complex environments coming up. So these are applications that might be calling one agent that is orchestrating communication among other agents. So having multiple hops from the point where the user asked for something, prompted something, but maybe it takes five or six hops and talks to a dozen different agents to actually execute on that. So the big risk there being we lose the user context. Who was that initial person that was requesting that? Or agent, if it was autonomous there. And then also that chain of custody. How did it get from point A to point Z when something was actually executed there? So from an auditing standpoint, we need that. But if something goes wrong, we need to be able to track that down quickly and figure out who was it that requested it and how did it get to that point? Yeah, that's very cool. Yeah. And let's say something does go wrong along the way. How do you ultimately kill that agent? As morbid as that sounds. So, yeah. I mean, why don't we, let's jump right into it. All right. We'll see both right now. Okay. So now we're going to see a user logging into this application. This application coordinates with multiple agents in order to execute on the different requests. User logs in through Okta. So that way the application and the agents have that user context. The app and the agents can do whatever the user can do and nothing beyond that. So quick prompt here just to see if there are enough laptops in stock for a specific deal. And we can say, okay, we've got the information back. Over on the right, we can see the flow of that request. The application called the sales agent to get details on this deal that's being asked about. And that sales agent called the inventory agent to see, hey, are there enough ProBook laptops in stock in order for this deal? The more important thing, as we see down on the bottom right here, is the chain of custody remains intact for this. We can see the last agent in this call, inventory agent. We still see who initiated that call, that first call, who was logged into the application, the demo.admin. And then we see the full path of this call here. So we see down at the very bottom, started with the web app. And then that called the first agent, the sales agent. And that sales agent called the inventory agent. So if anything goes wrong or for auditing purposes, we're able to see that full chain of custody, the full path. How did it get from user logging in to application all the way down to that inventory agent? And that's not just over on the application or agent side. If we look over in Okta, that same information is in our system logs. So if any forensics or auditing needs to be done, all that information's there. We could also take action on that in Okta as well. So we can see in here, we have the demo user. We can see that full chain of custody there going from web app to agent to agent in these records here. So, and just to take a quick look at how this was configured, if we go over to directory and AI agents, we can see we have both of our agents configured in here. I see the sales agent and the inventory agent. If we take a quick look in here, not only can we define things like who owns and is responsible for this agent, but we have a couple other things we can configure. So on the delegation side, who or what applications are allowed to call this sales agent? And we can see down at the bottom there, the sales chat app, that was that application that the user was logged into. That is allowed to call the sales agent and work on behalf of that user. And then down in the resource connections, we can see what can this agent call? What can the sales agent call? And in this case, it's the inventory agent, as we saw in the application there. But what if things go wrong? We need to be able to cut things off quickly. If we take a look at the inventory agent, let's say inventory agent went rogue and it started deleting everything in the inventory. We want to be able to, as quickly as possible, shut things down. So we've added a kill switch here. So we're going to deactivate this agent. And what it'll do is invalidate any active tokens that that agent has. Nothing can connect to it and the agent can't connect to anything at that point. So now that we've flipped the kill switch and inactivated this agent, let's take a look back at the application and see how this affects things. So if we submit a prompt here that we know would call the inventory agent, how many ProBooks do we have in stock? We'll see, does this work now? And no, it errors out because nothing, this application, the user can no longer call that agent. It's inactive. But if we make a prompt for a request for the sales agent, that one still works there. So we don't have to shut everything down. We can pinpoint where things went wrong and then quickly shut things down with a kill switch there. What this showed was in these complex environments, we have agent orchestration, agents talking to agents, talking to apps. We're able to maintain that user context, who initiated that request, and each of these agents down the chain, no matter how many hops, will still be working on that user's behalf. Whatever the user is able to do, these can do, and nothing beyond that. We also have that chain of custody, both in our audit logs and the tokens that are passed down to these agents, so we can take action on those and be able to look at those in case anything goes wrong. And when and if things do go wrong, we have that kill switch to be able to disable an agent, revoke any active tokens for that, so it can no longer make any requests and nothing can request anything of that agent. All right. These demos, Gray, were absolutely fantastic. I mean, we're literally giving customers and companies everything they need to securely roll out agents into production. I mean, if I were a company of any size, this is exactly what I would want to get going securely without getting in the way of innovation. Thank you so much, Gray. And to everyone watching, stay tuned for more exciting episodes of our Okta Streamcast, where we cover all things AI security and the latest in product innovation. Thank you, everybody.
