Okta's Identity Chief: Most CISOs Can't Answer This AI Question

Hello everyone and welcome to SecureTalk. I'm your host, Justin Beals.
I spent a lot of years building software, and on almost every project there was a point early on where the work stopped, and we dealt with identity. Where are we going to store users. How do we decide what each of them can see. Where do they log in from. Setting that up used to take sixty days before we could build anything that was actually ours. When companies like Okta came along and let us hand that piece off, it changed how I built. That sixty days became about two weeks, and then we went straight to the work that made us different.
So I was glad to get this guest. Dan Cinnamon is a Distinguished Security Advisor at Okta, which is the largest independent identity platform in the world. He sits in the office of the field CTO, which means he spends his days advising the people who run identity for large organizations. When you want to understand where identity is actually heading, this is a good person to ask, because he can see across thousands of companies solving the same problem at once.
What makes Dan's view interesting to me is where he started. He wrote software first. CRM tools, content platforms, even grain operation systems. He architected identity programs after he had already lived on the developer's side of the fence, and that shows up in how he thinks. He points out that the tools we have now let a developer drop in a few lines of code and get authentication working right away. But when you get down to the database call, the training wheels come off, and it is back on the developer to decide what the authorization model looks like. Seventeen years in identity, and he still frames the problem the way a builder does.
We spend a good part of the conversation on where this is heading with AI. Dan gives real credit to the people working on the MCP standard, the protocol that lets AI agents connect to tools and data. The early versions worried a lot of security people. Over a short stretch of time the working group tightened it up, required OAuth, and folded in some of the controls Okta has been championing. It is becoming the connective tissue for a lot of agent work, and it is in much better shape than it was.
Then we get into agentic identity, which is the part still being worked out. When you ask an agent to do something for you, the whole stack should understand that the agent is acting on your behalf and not that you are doing it yourself. Right now that attribution mostly disappears. We are still handing out API keys and service accounts where the user context is just gone. And without that attribution, you cannot cap what the agent is allowed to do. Dan and I talk through the trade-offs of giving every agent its own identity, how you think about blast radius when something gets compromised, and why keeping a human in the loop is harder than it sounds once you have to decide exactly when the agent should stop and ask.
It is a technical conversation, and Dan is very good at making the hard parts clear.
Dan is a Distinguished Security Advisor within Okta's Office of the Field CTO. He's served the identity industry over the past 17 years as a practitioner, a consultant, and a champion of best practices. He has held the CISSP credential since 2013, and has a history of helping organizations enhance their identity governance programs, involving their most valuable, but also most complex technology. He enjoys spending time with his family, reading, and tinkering with electronics.
Join me today on SecureTalk for this conversation with Dan Cinnamon.


Justin Beals:  Hi Dan. Welcome to Secure Talk. Thanks for joining us today.

Dan Cinnamon: Thank you so much for having me.

Justin Beals:  Excellent. Well, you started off your career writing software, CRM tools, content platforms, grain operation systems. I don't think I'd ever heard that one for. a lot of different coding tools. I remember the old.NET days and ABAP, that was a new acronym for me too. Before you ever architected an identity program. Now, when you're advising a CISO today,

What does having built all that software and applications in the past help you see about identity risk that kind of a career security person might not understand?

Dan Cinnamon: Yeah, I think it can be really helpful to kind of maybe live on the other side a little bit, right? Like as a identity practitioner, there's certain expectations that we have of of the developers, you know, writing secure code. And so yeah, certainly being on the other side gives you you know, kind of gives you, you know, walk a mile in their shoes, sort of a of a perspective. I think one of the things that really I I think we've had some challenges with, and if you look at, you know, one of the industry standard kind of measures of identity threats and security threats more broadly is that OWASP top 10 for the software development, application development. If you look at those over the years, you know, security vulnerabilities around broken access control, broken authentication, pretty consistently at the top. And so yeah, I think that pretty much points to it's easier said than done. And so I think one area now we've made a lot of strides in that area.

One you know with you know great standards, great frameworks. There's a lot of things now where as a developer you kind of just you put a few lines of code in and and lickety split, you're done, and it's great. However, that doesn't sort of solve the overall problem of you know, at some point the you at some point you lose those tools, right? So at some point you get to a layer in the stack where maybe we're making a database call and

It's pretty rare for your identity and authorization policies to extend all the way to within that database, right? And so at that point, it's on the developer to say, all right, what's my authorization model look like? Right. And so that's where some of those things, some of those training wheels, if you will, start to fall away. And so one of the things that we're doing at Okta is is, and others in the industry are doing this as well, is starting to you know, provide better standards and tooling or

Justin Beals: Yeah.

Dan Cinnamon: Centralized authorization. In our case, it's fine-grained off. It's kind of helping with that last mile of, you know, we've gone through all these layers of the stack. We know who the user is. We, you know, we made sure that all the like front door vulnerabilities have been addressed. But now, as we're translating them that into what can they do, we're providing some tooling and some standards there as well. So I guess that's my kind of my vision on that is we need to continue to make it easier all the way from beginning to end as a decision is being made.

Justin Beals: You know, listening to you answer this question, I'm I'm reminded that you're serving two different user populations in a way. You know, that front-end authentication is an end user and and there is an easy use question that sometimes the CISO might not not be aware of, but the product team is trying to hit. That that could be attention. And then there's the developer that needs an easy use situation to both figure out how to keep the application logging into the data layer.

Dan Cinnamon: Absolutely. Mm-hmm.

Justin Beals: As well as them being able to have the r have the right level of access to to what they need to write code, test code, get code into the production pipeline.

Dan Cinnamon: Yeah, absolutely. There's definitely there's always a little bit of a of a tug of war there. I I would say, just as a comment, you know, one of the things whenever we talk about those trade-offs, I think that the industry and the technology industry as a whole looks for some of those unicorn solutions where it's a better user experience and it's a better secure experience. One of those, I would we have one of those. I it's pretty well known at this point, but pass keys is one of those where it is genuinely a great user experience. you know, the the the tech giants of the world did a great job of coming together and making that better. And it offers a a lot higher assurance and is fishing resistant as well. So that is one of those that I definitely would want to call out as sort of like one of those unicorn you know, I wish we had more of those, frankly.

Justin Beals: Yeah. I you know, it's a drama I I beat when I talk to customers is you could make things you could certainly say I'm just gonna make things more efficient or you could make things easier to use. Security is one of those vectors where both need to be true for either to be successful. Yeah.

Dan Cinnamon: Yeah. Needs to be reasonable. Like I think there are cases, and this is what we when we talk about you know, a security model and how we're going to what friction we're gonna put in place. Yeah, I think people can understand if if I just ask for something super sensitive and you're gonna challenge me for that, I get it. I understand, right? Like and I think that argument can be made, but when you're asking to sign up for a newsletter or you're asking for this super simple thing and we're asking for like hypersensitive information, there's a mismatch there. And I think that that's part of the issue is we don't always do a good job of of aligning that friction with what the user's asking for, the risk of what the user's asking for.



Justin Beals: Yeah. So you were at General Mills and the you stood up SAP's governance, risk and compliance tooling. a great product, you know, we're we're definitely really aware of them. without but the one thing that was really unique that I was reading about is you did it without an external implementation partner and you know, as someone that used to sell an Oracle license and, you know, 3X that amount of revenue and services around it, what you decide to do is pretty unusual. I'm curious about that hands-on experience of rolling that out, you know, how you felt about it, and and maybe specifically to access control, you know, from a standing up compliance solution. Yeah.

Dan Cinnamon: Yeah, that's yeah, I realize that's a bit unusual and and I would say it was it's definitely a case of what's the saying? we didn't do it because it was easy, we did it because we thought it would be easy, right? It's it's kind of one of those scenarios. Yeah, w what what what happened there was it was it was upgrade. Like we had a deployment already, we were upgrading to a new version, right? And we kind of said, Well, that's just an upgrade, right? This is not an upgrade. This was a this is basically a re implementation, right? So that's kind of the
the how that came to be. 

But I would say that you know there's a I think there's a lot of parallels between you know just kind of the core GRC space and the identity space where you know because it and I still actually still work with GRC to this day because there's a lot of interactions that we have from an identity security perspective. And what I see in the identity security perspective is, you know, on the one side you've got organizations that just do everything within grc, right? And you know, it can be there there are because there are some things about it that really only sap can do because it's super low level, super fine-grained, you know, and it's just in you you need that. but the the downside of that is that it's kind of on an island at that point, right? Like we see lots of things where it's like, hey, if you want to access something here's the instructions for everything except for SAP, if you want SAP access, you gotta go through this, right? And and this is, you know, you could you could apply this to any other kind of core ERP system or medical record system is another big one where you see stuff like this. but then on the flip side, you might have a case where you're trying to you know, go to you know a very easy to use, very simple solution that ties in all the rest of the, you know, ties the rest of the organization together.

But it can be challenging, of course, to actually work in the really deep permission models of a core ERP like that. And so you know, one of the things that I look to, you know, from my perspective, and I expect potentially even within the kind of the core, you know, GRC space would just be there's gotta be a bit of a of an orchestration or integration between them, right? Where you wanna kind of, you know, you have to leverage some of those deep kind of rule sets, kind of the deep understanding of the entitlements and surface that up to kind of the broader systems in a way that that's more consumable and understandable by the whole organization, but doesn't miss out on you know if we're not having leaving holes in the environment. So that's what we that's my position on Okta is like, hey, if you want to request access to SAP, we have to consult with GRC on that because there's some things that we that they have to do. 

But that's like that's something that we're orchestrating for the user, right? Like they're not having to have multiple places to go. You know, we're kind of, you know, orchestrating with it in a simple way. And I think, you know, that's something that I think you know we c we would see that more broadly with other with other products as well. That's what I've seen now.

Justin Beals: It's I yeah, I think what you're describing, Dan, is a little bit of like bleed over. I've seen this from a couple of different sectors into other sectors where we typically would have had different solutions. Like I've seen HR solutions start to do identity access management. I've seen GRC solutions start it to run security itself, like mobile device management. We've tended I I've tended to take the philosophy that we wouldn't run the control for a customer, but we needed the data that the control was run effectively. Yeah. Or we needed we needed to provide the control owner information about how to run the control effectively, like habits, procedures, processes. yeah, it it is really intriguing because I get code is easier than ever to write with with some of the the tools. And that's normal. It's been a natural progression, but it is interesting to watch these things bleed over.

Dan Cinnamon: Right.

Justin Beals: Where you know I I consider Okta and your other product OSZero to be kind of phenomenal, you know, at what they do exactly. Yeah.

Dan Cinnamon: Yeah, and it's and it's a you know, there's always the the question mark of, yeah, do we try to bleed over? You know, and I I think, you know, you know, but there's also an excellent option of maybe we should just do a great job of orchestrating. I I think and to maybe put a fine tip on this particular instance, and I exp again, I expect it's different for you know, for Oracle, the Oracles of the World, the other big kind of vendors, there's a certain level of detail that like I don't think we would ever be able to know, right? Like w without without having a full scale team constantly employing the software, being really close to product management as the vendor is updating their software, without that.

I just I don't I don't think first of all, I don't think that's our job. And secondly, it's just I don't know that we'd ever be able to keep up with it. So like, you know, as the business rules change, as the segregation duty you know, criteria changes in the product as they release software every however often, that's something that they have to manage and I but we have to orchestrate with it. Yeah.

Justin Beals: Yeah, yeah. There's definitely a, you know, locking arms and moving forward together with the other platforms. Well, you know, we the easy example for me is single sign on solutions for even our platform with your platform so that our customers that are using our platform can orchestrate identity and access management into our platform from their preferred spot instead of being competitive. Yeah.



Dan Cinnamon: Absolutely. Yeah. Yeah. It's it's gotta and that's where I think, you know, our our belief this that's what the standards really come in as well. And I feel like it's something that that you know, it's it's very it's serving of the community, and making it easy to do those things. Yeah.

Justin Beals: Yeah, absolutely. you so we can't get through a any podcast recording without talking about AI. So sorry or congratulations, we're here, however you're feeling about it. and of course the big one is non-human identities, agentic AI. and a lot of our identity management systems were not designed for that. We're thinking of persistent employee that needs access to particular systems with permissions and roles. When our old school human era identity management meets these machine-driven, you know, high-speed kind of agents, what do you think is the first thing that structurally breaks down?

Dan Cinnamon: I think the biggest one from my perspective is, well, it kind of permeates in a number of areas, but the biggest one is attribution. Right. So if I, Dan Cinnamon, ask my agent, whatever that doesn't matter what it is, to do something on my behalf, ideally what would happen is that all layers of the stack, wherever that terminates, would be aware that it's not me doing the thing.

It is the agent doing that thing on my behalf. And that is something that we haven't really, you know, not haven't really done fully, right? Whether, you know, I mean, even if you count, well, I'll set this aside for a moment, but I mean a lot of stuff is still like when you get into the machine part of the stack, heck, we're still using API keys, right? Where there's no human identity at all there, right? You've got like service accounts and things like that, where that whole like attribution of the user permissions is completely lost, right? Like they're completely gone. Now, now, even if you take like the most you know well designed and modern API that's following proper OAuth standards and things like that, we are we are in a better position there for sure, because at least there's like a machine identity and a user identity. But it's still not really in the context of the agent yet, right? 

Like, we know that there's some inbound machine identity that we did consent for, but we don't really know there isn't really a distinction that says this is an agent that is, you know, non-deterministic. And there's not really a way of saying in this instance, we want to pair it back, right? Like a lot of the OAuth tokens that you would get today.

Are kind of fully f fledged on behalf of that user, right? And so there hasn't been a lot of downscoping so that when an agent tries to use that OAuth token, it's actually more finely scoped than if the human really is themselves. So I I think there's even some limitations there. but I I yeah, I think that attribution is a huge part. And I think that kind of getting back to what I was getting into earlier is if you don't have attribution, you don't like you can't cap you can't cap the agent's activities, right? Like it's very easy then for the agent to maybe make a mistake and do something that the human shouldn't be doing if you don't have that user context, right? Like, so having that attribution not only make sure that the you know that we know who did what, it's also providing the foundation for being able to cap the access that the agent has.

Justin Beals: How do you how do you feel in these scenarios about the maturity of like the MCP type API integration with LLMs? And we certainly I use it my personal work to with our LLM of choice to go and access large data sets and work with me, but it's operating under my instructions, but not under my guidance.

Dan Cinnamon: Yeah, I I will say the MCP standard has has in a lot of great ways has matured over over the last well in the short time we've had it. it's done a great job of maturing, right? Like if you look at the very first release, there's a lot of you know concerns that we have from the security perspective. you know, some of my colleagues in the industry kind of jumped in and and you know helped guide you know that working group.

And to great effect, actually. I mean they and they've been great. I I I would point personally, I I know there's a lot of questions about what's the winning standard, but I personally you know, would throw a lot of kudos the way of the MCP team, work on that spec 'cause they've done a lot of things to you know advance it over time, you know, requiring OAuth. they even one of the protocols that you know we at Okta have been really you know, helping to develop and champion. it's what we call a cross app access, but it's a it's essentially a new profile of OAuth that has some specific controls to fix some of these problems. And that actually has made its way into the MCP spec as well. And there's been some recent developments there. So so yeah, it's it's I'm not saying the job's done, but I think that you know, it's certainly I think they're heading in the right direction.


Justin Beals: Yeah. Okay, that's great to hear. I I think it's been the leader in a way in in this work. Yeah. so one of the things that you have been framing on the enterprise side, you know, three questions when we're thinking about this agent work is which agents can access what, whether those permissions are right or wrong, and how you stop a compromised agent mid-action, which sounds very esoteric, but as it you know, happens.

Of those three, which ones are the enterprises least prepared to answer today? And what do you think like an answer looks like for that aspect?

Dan Cinnamon: Yeah, I think you're right. And I would say that discoverability is probably the biggest challenge to it. and then to some degree, and actually this is true for a lot of the you know topics of AI we could talk about. I feel like there's a lot of parallels between what we're seeing now and what we saw when cloud was being adopted, right? Like, you know.

Back when Okta was getting its start, back when Cloud was being adopted, we all have a lot of the same problems, right? We have shadow IT, people adopting things that people didn't know about. of course the identity stacks weren't ready, right? So it's a lot of the same conversations we're seeing now. And I do think one of the biggest kind of gap areas is the discoverability. And I think the reason why is it's a little it's a little bit like a lot of the other like zero trust conversations. It's a it's a team sport, right? 

Like there's not there's not like a silver bullet that's gonna say, you know, hey CISO, here's everything you have in your entire environment, go fix it, right? So, like, from our perspective, we're doing a lot of things to help discover, like OAuth grants, you know, OAuth consents. So we're kind of looking for that MCP pattern where people are consenting. we've got our partners doing things on the endpoint; we've got the SASE vendors doing things at the network.

All of those are gonna kind of have to come together to really provide the full visibility. And so I think that's why the biggest gap is there, because there isn't a silver bullet. I would say the other area from our perspective is there's also the question of like, here's what's there, now what? Right. So that's kind of, you know, where you know we focus on our end is sort of like, if you know the agents or if you have a project of an agent you know you're building, let's make sure we set forward the foundation for the future. and so we put a lot of focus on that. But yeah, I would say in terms of the biggest gap in my perspective, it is that discoverability. Cause I'm I'd I'd love to say there was a silver bullet, but I I don't think there is. and you know, it's gonna take it's gonna take a village to to really discover all.

Justin Beals: 
Yeah, it's certainly, you know, exponentially complicated as we scale out the the use of these tools. I mean, inside of our own infrastructure we run a a lot of different models. We've chosen to host our own. From a security perspective, I think we just also, I think from an innovation perspective, it's allowed us to leap forward in some ways because we had to have a team that was ready to train models and look for good data and test for accuracy and efficacy of the work we do. You know, and it's been interesting in building our agents. And one of the reasons we got put in touch is part of your team interviewed our chief product officer, Micah Spieler, at Identiverse recently. We were really glad to join you guys and Micah Came back and said, hey, you should talk to Okta..  They're a great group. And I'm a fan of you guys, obviously. You know, and I think even in our implementation of this work, one of the struggles we're having is, you know, agents and their identities. And, you know, Micah stated that identity granularity should follow permission granularity, that there's a real inheritance model there, that the agent inherits the service role that kicks it off.

And really doesn't necessarily need distinct privileges and and you may just need that referenceability back to this agent got spawned by this identity. Kind of a a real, you know, object oriented classic inheritance model. I think we've seen that before. Where do you agree and where does the identity first case for treating every agent as a first class identity actually become super important? Yeah.

Dan Cinnamon:  Yeah, I think there are a couple philosophical questions there. just kind of as I as I hear kind of the position on that. there's definitely some philosophical questions on that. And I've I've actually had some of these discussions even before the world of AI. But yeah, whenever I talk about, I think whenever I talk about the like what layers of the stack should have an identity and should get its own kind of dedicated identity, it always kind of from my perspective, it comes down to the like.

How do you define your security zones and how do you like limit your blast radius? Right. So the more you partition some things out, and the more it's like, okay, this agent identity has an identity, this MCP server has an identity, this API, this API, this. So the more like all those things have their own identities, on the one side, you're really limiting the blast radius. So if one of those will be compromised, there's very little, you know, there's not a whole lot that can happen. Not as much that can happen.

Right. On the flip side, if you're kind of the like the MM model where you've got the hard outer shell and then like the inner, the the soft inner innts, right? Big blast radius if you have a challenge. And so I I think that's kind of maybe where some of that was coming in. It's like, you know,  I generally do advise like, hey, if you've got something that is maybe a little bit of a logical construct. Yeah, like that should just be one thing. You know, you could handle like like a lot of times you have like an API and the API gateway. Those are logically kind of the same thing, and the gateways have ways of like protecting that really, really short link between the two. And so yeah, it doesn't generally make sense to have like an extra identity there, right? So that's kind of the way I've been kind of framing that up is you really kind of have to pick your like granularity of what's going to have an identity with that trade-off of complexity and performance if you have way too many identities versus the big blast radius if you have way too few. So I think there's there's definitely room there. And I'm generally kind of lean towards hey, if you've got logically separate things that you could argue the different security zone, that you should have a separate identity for that.

Justin Beals: I appreciate this nuance around this. And I think too often we're looking for the easy security answer, like do X, you know, or or do Y. I see this in everything from cybersecurity to compliance broadly. And and it really does depend a lot of times, mostly on how you want to operate your business or architecture, you know. I could see our particular scenario being much more of a walled garden where we have a lot of comfort around what's happening internally, because there's very little external data flowing in or out, or you know, reliance on on there's no reliance on like a third-party LLM to perform the AI functions that our platform does. Whereas if we were heavily reliant on multiple AI platforms that were hosted on other servers that we didn't have control with, I think I would be a lot more nervous about identity management in that scenario.

Dan Cinnamon: Yeah, certainly. Yeah. I I I think that there's and I I always tend to kind of remind people too, like some of these standards, like OAuth, for example, is a framework, right? And so there's certainly things that like our no-nos and certainly things you would never do, but there actually is a fair bit of of power there to kind of say, all right, we understand the implications of what we're doing. This is the risk profile of what we're doing. In response, yeah, it's kind of the traditional like I'm not sure the frameworks for this, but got your risk analysis of the situation, right?

Justin Beals: Yeah, I think I think some of these frameworks like OAuth and even some of the more esoteric ones that we deal with, one of the ones more recently are things like CMMC and NIST 800-171 R2. They I tell people all the time that these are assessment methodologies, they're not gonna tell you what to do. They're gonna tell you how they're gonna test you. And and so if you t walked into an OAuth implementation situation and said, This is our quality assurance testing for OAuth, I think you'd be interpreting the framework a lot better than this is what it's telling me to do. Yeah. Yeah. you know, let's talk just a little bit more about the MCP work. you you're a fan of where it's going so far and it's gone better. you know, it's doing agent authorization and permissions, and the access patterns can be a little dynamic and task driven. I, you know, I notice this when I ask the LLM that I use in my day-to-day work to do something, it's like, okay, I'm reading through what's available and dynamically deciding what data to go in and ask. I'm curious what kind of secure onboarding and continuously verifying an agent means in practice and kind of what teams are doing today that that looks like verification or that validation work.

Dan Cinnamon: Yeah, I I think there's maybe two areas of this. I think one there there's well, I'll tell I'll take kind of maybe the easier one first, right? The the the the easier one is still hard, where is sort of like what we call human in the loop, right? So I go and ask an agent to do something, agent goes off on its own and it does all sorts of things, and at some point, it's not sure if it's okay or not. So it's gonna ask me, right? And so I I think for in that case, we have a lot of standards in place. there's one called SIBA, it's called client initiated back channel authentication, where basically agent can actually, you know, I could be out mowing my lawn and the agent can ping me and say, Hey, is it okay if I do XYZ? Right? Like that's a you know, that's a thing. That is there, like the the how we do it is there. I think where I think we we need to see a lot more maturity is the like the policy of knowing when. How do we know when to do that? Right? There's no standard around that right now that I'm aware of. You know, it's kind of up to the domain owners to say, hey, before we allow you to do XYZ, you've got to ask permissions first. I do think there's concerns around like how you know the the thing after I say yes on my phone while I'm you know mowing the lawn, how do we prove that?

How do we prove that I said yes? Right? Like, what's the thing auditing it? Is it like an OAuth token that has my yes answer in it? What is it? There's some of those things that kind of play into the like when we start getting more advanced, you know, does the user actually have you know, did they provide consent for that? I do think kind of an offshoot of that that I I've been seeing in the industry as well.

That's maybe a little bit further away from what we've been doing so far in a product has been around watching the traffic, right? Watching that gentic traffic and getting a risk score or a scoring that says, yes, that action the agent is taking is of the same intent that the user had. And that's like a traffic analysis thing.


I think that can maybe play into some of the things I'm talking about with like sending a text or you know, push or something like that. But I think that's another aspect of it. I think it's a more challenging one because that in itself is an AI problem of well, what did they mean? What did the person mean? You know, did this action they take, does that match up with the thing that they meant? Like the whole thing is very squishy, but I think it's an area of definitely an area of development. and it's one that I think ultimately where we need to get to on that is a robust way of saying, Hey, I'm I'm about to you know, do you know, do XYZ, is that okay, human?

Justin Beals: Yeah, it's I I think it's an intriguing almost human computer ac interaction type of philosophy space. You know, we we saw a lot of opportunities for a platform to do automated things, but it made us very nervous. And so we started with a fundamental philosophy of human in the loop kind of always. Is it really that painful to click a button and say, yes, that's an approved action? Or yes, I approve that you go and make this change. Well, there's one thing to go and research and make recommendations. It's another then then we we put a stop gap and and generally in all our user experience we do that now where it's like, but before I go make this change, I need some human being to buy in that that's the right change to make. Yeah.

Dan Cinnamon:  Yeah. Yeah, and I think it's sort it's a tough balance because you know, it was up to you to draw that line as to which changes you're gonna make sure you get consent for and which not. And so, you know, it's like the more the more changes you require that for, the less the less useful the agent becomes. It does less on its own than the other half, the more you let it do without that consent, the riskier it becomes. So yeah, it's a it's a tough balancing act, and I I don't know if we'll fully have like the the right answer fully, but I feel like that's where like just the standards development and the best practices we need to improve upon industry wide.

Justin Beals: Love how you bring risk into it. To me, that that's exactly where the architect, you know, that's that's working on a particular feature or platform needs to be like, so what's the risk if it goes to do this? Like, what could really go wrong? And while we might not have the tooling to give just in time risk today and and stop an action or approve an action, at least we as people that build this software could say, Hey, yeah, if this agent just goes and rewrites my policy or adjusts the where it's pulling for us it would be like an example of a firewall implementation from, that's really risky. That's super risky. And we really need someone to take a look before it goes and does that particular work. Whereas an agent accidentally sending an email off from a personal email to the wrong person is just not that high a risk, perhaps. Yeah.

Dan Cinnamon: Perhaps. Yeah, exactly. Exactly. That's where I just I think there's could be some maturity there of of having a common design language around that. Because I think right now there's you know, like I said, we're doing some things, you know, with our kind of fine grained access products and things, but but there's I think there's a difference between kind of like having some of the tooling there and maybe even having some of the raw standards there and like having everyone actually employ them in a similar way. Big difference there, yeah.

Justin Beals: Yeah. Well, one of the things we've been talking about here is, you know, containment. Obviously, we have a philosophy around our architecture and containment of agents and models. we're fairly strict about it. When you're advising an enterprise, where do you start thinking about the hard boundary or how to define the hard boundaries around containment?

Dan Cinnamon: So,  I think and and correct if I'm if I'm misstating this, but I I think from my perspective, when I think about containment and like access control models, I think one thing that we need to start doing, especially in this kind of this new world of of AI, is start moving some of that containment a little closer to the data. Because I think about, like, for example, you know, you could have, you know, containment at like the tool level or you can have containment at the API level. And I think so long as that's like the only path to the data, that's fine. But I think what we're gonna start seeing, especially as we have a bunch of MCPs, a bunch of things that don't use MCP, call APIs directly, multiple chains, agent to agent to agent, I think that it's gonna be harder and harder to control things at those like interface layers. I think we're gonna have to start getting closer to the data.

The kind of the joke, the joke that we use internally is sort of the if mom says no, ask dad kind of thing, where you know an agent asks for something, it says no, it's just gonna ask another agent that might say yes, right? So that's the worry that customers are coming to us with. So kind of having some of those access control systems kind of further down in the stack can maybe help us with some of that containment; that was sort of sort of my thinking, but


Justin Beals: Yeah. I think to your point about mom ask, you know, asking mom and then asking dad, we do have some scenarios and use cases where multiple models that were trained differently with different kinds of prompt structures around them double-check each other. And it's really dramatically improved the accuracy and recall on some of the outcomes of the models. And I don't think people think about doing that enough yet in their architectures.

Dan Cinnamon: Yeah, I certainly- I've seen it, but yeah, it's great. I personally, some of the things I do as I prepare for customer meetings, I could do more of that. That's a great callout. Yeah.

Justin Beals: Yeah. One thing that I was a little curious about on healthcare interoperability, you've done some work around this, and I think it speaks to this agentic situation. Standards like FHIR and a smart on FHIR, where delegated access to patient data is is how you know these these systems what that what they're doing. When you introduce an autonomous agent into a flow like that, where we're dealing with delegated patient data.

What you think the hardest problem to solve is it is consent, provenance, or logging and monitoring or approving after the fact who the agent was acting for?

Dan Cinnamon: Yeah, I do think from my perspective consent is the big one. And actually kind of like as we're as we started to get into earlier where it's it's intent. Does the, you know, is the action being taken aligned with the intent and consent of the person? I think that that's, yeah, I think some of the technical bits and bytes around kind of knowing who did what and all that, that's something that you know, we'll certainly require some spec updates and, you know, some technical changes. But I think kind of to my point earlier, once you get past all that, you do get into a much murkier scenario of is the thing really doing the thing that I asked for? And I think that's the one that's gonna kind of be the gatekeeper, or the limiting, the governor, or the slowdown effect on some of the adoption.

One thing I have seen is I have seen a fair bit of some lower-impact things that agents can do, like like s making schedule, scheduling appointments. Right. Where I think that's a great use case where, you know, an agent can help schedule an appointment. And that's a case where there's not a lot of ambiguity in that. The risk of, you know, the risk of failure there is, hey, we, I guess we waste some people's time, but you know, nothing we can't undo, you know. So think that's a great use case, but yeah, I do think the intent is gonna limit us from going a whole lot farther.

Justin Beals:  Well, a lot less risky than a HIPAA violation, right? Which could be very costly for a business and, of course, lose a lot of confidence in your customers, you know, patience, to trust you with that data. Yeah. Well, Dan,

Dan Cinnamon: Yeah, yeah, totally.

Justin Beals: I think it's been a really amazing discussion. I'm really glad to talk to you. I love digging into the technical work here of how you guys are thinking. And I was joking with you before the podcast, but I've built software for many years. And the very first thing, you know, we used to have a stack of JIRA tickets for every software we built. Right at the beginning, it was like, okay, so for the next two months, we're building identity access management. And Okta and OS Zero, you guys really changed that where it's, you know, it's just a couple weeks' worth of work to get the basic identity management in place. We can go build what's valuable, what we think is innovative in the marketplace. Yeah. And certainly appreciate we're we we use y'all's platform for our identity access management and some of our agent management work that we're doing. And recently some of the MCP work where we offer up MCP servers.

And so I just have a lot of gratitude for what you guys are doing, as well as joining us today on the podcast. We really appreciate it.

Dan Cinnamon: Yeah, thank you so much for having me and thank you for the kind words. I know it's, you know it's something that, you know, as we talked about today, there are lots of trade-offs and that usually leads attention, of course. And so to kind of take a step back and say, Hey, the look, look at what we did is always very well appreciated. So think


Justin Beals: And it brings it full circle to that consent thing. I think I certainly feel this way. I'm not sure if you share it, but we do this to help people have a better life, be able to accomplish more, be able to serve at scale. I love building businesses. Certainly, I like being successful at that, but there's a real human aspect to the products we build and what they do for people.

Dan Cinnamon: Absolutely. Yeah, that's I will say that's I've had a few moments in my career at all, you know, all the positions I've had, where it's like to actually sit down and say or and actually maybe even be users of your own product, right? Be on that side. And especially in Okta we do a lot of customer identity things where, you know, as a consumer I'm using the you know, I'm using our customers as a customer myself and kind of, you know, having benefits of my own life on that. And so I don't I like, I share your appreciation for how rewarding it is to see the change of the world for the better. Yeah.

Justin Beals: Well, thanks, Dan, for joining us on Secure Talk today. We really appreciate it.

Dan Cinnamon: Thank you so much, Justin.