The Enterprise Guide to Agentic AI Risk: Security, Governance, and the Cross-Functional Playbook

Summary

Databricks CISO Omar Khawaja introduces the 'lethal trifecta' of agentic AI risk—three converging conditions defined by sensitive data, external action, and state change that create enterprise-scale exposure.
The Databricks AI Security Framework (DASF) maps 97 identified agentic risks to 30 industry standards, giving security and data teams a structured, prioritized starting point for governing autonomous agents.
This video presents the OODA framework—Observe, Orient, Decide, Act—as an organizational model for moving from risk awareness to cross-functional governance alignment across security, legal, and technology leadership.

The Enterprise Guide to Agentic AI Risk: Security, Governance, and the Cross-Functional Playbook

When AI systems shift from analyzing to acting, the threat model changes fundamentally. Most enterprises are not ready. Agentic AI amplifies both the speed of innovation and the magnitude of risk, creating new attack surfaces and governance gaps that no single team can close alone. The organizations getting this right are building cross-functional response models that unite security, data, legal, and technology leadership around a shared risk framework. In this video, Databricks CISO Omar Khawaja introduces the lethal trifecta of agentic risk, the three converging conditions that create enterprise-scale exposure and the organizational playbook for neutralizing it. You'll walk away with a prioritized set of actions your enterprise can begin implementing in the next 30 days, and a model for the cross-functional partnerships that make agentic AI governable at scale.
Talk By:

Chapters

FAQs

What is the lethal trifecta of agentic AI risk?

The lethal trifecta describes three converging risk conditions—access to sensitive data, the ability to take external action, and the ability to change state—that together create enterprise-scale exposure when they occur in the same agentic system. This video uses this framework to help security teams prioritize which agent deployments require the most governance attention.

What is the Databricks AI Security Framework (DASF)?

DASF is a framework developed by Databricks that maps 97 identified AI and agentic risks to 30 industry standards, giving enterprises a structured way to assess and address their AI security posture. It is designed to move teams from vague 'scary vs. safe' labels to structured, scoreable risk assessments.

How does the OODA framework apply to agentic AI governance?

The OODA framework—Observe, Orient, Decide, Act—provides a structured model for enterprises to first understand what their agentic systems are and what they can do, then align cross-functional teams around a shared risk posture before deciding and acting on governance controls. This video uses it as a guide for building organizational readiness for agentic AI at scale.

Why do most organizations struggle to govern agentic AI?

According to this video, only 1 in 5 companies say they have a mature model for governing autonomous agents, and 88% of organizations remain stuck in pilot mode despite widespread AI adoption. The challenge is that agentic AI fundamentally changes the threat model compared to traditional analytics AI, requiring new cross-functional governance structures.

Full transcript

[00:08] Good afternoon, everyone. Thank you for being here. Um all of you are likely somewhere on your agentic journey, and as you've gone through the agentic journey, there's been a few ups and a few downs. What do
[00:20] you guys think? More ups or more downs? More ups? More downs? A little bit of a little bit of a split. Okay, I see the contrarians are on that side. The ups are sitting on this side.
[00:32] So, we've we've segregated ourselves based on whether you're excited about it or not. Uh some stats to sort of ground this discussion. A 40% of enterprise apps
[00:44] will embed agents by the end of the year. That's up from 5% last year. I was talking to a CISO a few minutes ago at lunch, and he said it used to be that if
[00:56] an app had AI, we wouldn't want it. And now, if an app doesn't have AI, we actually don't want it. So, it's gone from being a nice-to-have to a must-have expectation, but it still feels pretty
[01:10] rocky. It still feels like it's not an easy path to get to the other side. The other thing that we know is 88% of organizations use AI, yet 2/3 remain stuck in pilot mode. It's really easy to
[01:23] set up a sandbox. It's really easy to do a POC. It's common for organizations that I meet with to tell me that they have 100, 200, 300 AI use cases, but when I ask them how
[01:36] many of them are in production, the vast majority of the ones in production are for internal use cases. Very few can say that they even have two, three, or four AI use cases, agentic use cases that are
[01:50] making it into customer-facing contexts. And then, 1/5 of companies say they have a mature model for governing autonomous agents. All of this means that the excitement
[02:02] around AI and agents is met with a wet blanket in many organizations. So, we're going to talk a little bit about how you get this convergence to to work and for
[02:14] there to be alignment and for there to be speed and functionality and do it in such a way that you're not compromising security, risk, responsibility, the rule of law, and things like that.
[02:26] The big thing that changes when AI shifts from simply analyzing data and producing data to actually acting on behalf of another user, on behalf of a
[02:38] department, is that the underlying risks actually change fairly dramatically. And I'll quantify for you exactly what that means instead of just being generic and um hand um hand-wavy.
[02:53] Before we get there, um I have a confession to make. My uh build's clearly messed up, so uh the act should be at the end, so please cover your right eye so you don't see the last box being built out there.
[03:07] Um as I think about how to do this from an enterprise perspective, not from an individual, not from a developer, but when you are operating in a larger enterprise and you have tens of
[03:19] thousands of employees, you have thousands of traditional applications, you have hundreds of agents that teams would love to have been built, you've got a lot of governance functions, you have security, you have risk, you have
[03:32] legal, you have procurement, you have finance, you have privacy, you have compliance. The list might even be longer in some of your organizations. How do you go about doing this in a way that you can satisfy everyone? And so,
[03:45] the very simple framework that I'm going to use is the OODA framework. How many of you have heard of the OODA loop? Okay, awesome. I love it. I've got a couple of people that I can uh phone for
[03:57] help in case I get messed up around here. So, um so the OODA Loop is extremely important. The rest of the conversation, we're going to talk about some aspects of this four-phase loop where there's opportunity for
[04:09] enterprises to do better, but we'll use this as a frame for the conversation. The very first part of the OODA Loop is observe. Observe is all about understanding what is happening and
[04:21] figuring out what might happen. So, it's all about knowing, it's about observing. The second piece of it is orient. Orient is all about trying to figure out, what does it mean for us?
[04:35] I realize that that's happening. I got the weather forecast. I got the sports score. I got the revenue numbers. I got these logs from the firewall. Whatever it is that I got under observe, now I
[04:48] have to make some sense out of it. I have to convert it into some meaning, into some context as was discussed in the in the keynotes earlier. And then the third piece is, ultimately,
[05:01] what am I going to do with this? As a result of now understanding what this means to us, I need to be able to determine how I'm going to respond. And
[05:13] the last piece, of course, now that you see it up there and many of you were smart enough to have guessed what it would have been, is act. Act is to actually do it. Mo- most organizations, what do you
[05:25] think most organizations are very good at out of these four? What do you guys think? Is it observe? Is it orient? Is it decide? Or is it act? Number four. Okay, so we've got one vote
[05:37] for act. Another vote for observe, observe, observe. Observe. Okay, any votes for orient and decide? Okay.
[05:49] So, you represent a pretty good representation of the enterprises I meet with. In the last 2 years, I've probably met with six or 700 enterprises. And what I find is there is an appetite,
[06:02] dare I say it, there's even a tenacity to know more, to collect more, to hoard more. And there is also this strong push starting all the way from the top, from
[06:14] the board and the CEO and the CXOs to say go do something. Go do anything. But the part in the middle, orient, making it make sense for us, and deciding very
[06:27] deliberately what to do, that often is what is missing. And so, we'll talk about this more from the context of how you manage agentic
[06:39] risk. And when it comes to managing agentic risk, skipping those two steps in the middle are a really, really big challenge, and they can make life much harder, they can cost more in terms of
[06:51] dollars, and they can cost more in terms of time as well. When it comes to observe, the first thing that we have to do in the agentic AI world is we have to say, "What is this? Can we come up with a framework for what
[07:04] AI is?" And if this wasn't a lightning talk, I would spend 30 minutes describing what this is. And so, you will have to trust me that these 13 components that you see in blue
[07:16] are what makes up the entire AI agentic system. And so, when you're observing, this is the landscape that you are observing. What we layer on top of these 13
[07:29] components are risks. Across every single one of those components, there are things that can go bad in the agentic AI system. And instead of saying, "AI is scary,"
[07:42] instead of saying a gen tech is risky, instead of saying we've never done that, those are very gross generalizations and they don't instill any confidence in our ability to move forward. It's as if you
[07:56] went to the doctor and the doctor said, "Yeah, your loved one is um is very sick." Well, no expletive. We know that they're sick. What you expect from a doctor is
[08:08] what? What do you expect a doctor to tell you? Do you expect to be them to be general? Or do you expect them to be very specific? You expect them to tell you
[08:20] this is what is going on with your loved one. It is this particular organ and that particular organ is malfunctioning in this particular way. This is the condition that they are afflicted with.
[08:32] This explains the symptom that your loved ones are dealing with. In organizations, we have to move away from this is risky, this is secure, this is insecure, this is scary, this is
[08:45] something that our regulators won't happy with, compliance won't allow this, FINRA won't be happy, FFIEC won't be happy, OCR won't be happy. Those are all pretty good indicators that the team
[08:58] that is saying that actually doesn't know, they actually don't understand what's going on. It's like the doctor that after 30 minutes simply says, "This patient is very sick." You have no
[09:10] confidence in that doctor. You then ask, "Okay, who should I go to that can help me figure this out?" Unfortunately, in your organizations, you don't get to get a second opinion. There is no second legal department. There is no second
[09:23] security department. So, how do you manage? How do you address this? You figure out what is the list of risks that can afflict across your agentic
[09:35] system and across these 13 components, we've identified 97 risks. Out of those 97 risks, it turns out that 40 of them are specific to agents.
[09:47] And so, if you're thinking about how much scarier is it to go from machine learning to generative AI to agentic AI, agentic AI itself introduces about 40
[10:00] new things that we have to worry about, and we have to find ways to actually mitigate. If you want more information, there is a QR code, or you could go to your favorite web browser or AI and ask
[10:13] it for DASF, which stands for the Databricks AI Security Framework. It is an open vendor-agnostic framework that maps to uh probably about 30 different industry standards out there.
[10:27] When it comes to the agentic risks, if we were to double-click on them, those risks are spread across the agent core. You could think of this as the agent's memory. You could think of this as the actual LLM itself. You could think of
[10:39] this as the planning function. And then, there are many specific risks that are associated with the MCP server, and lastly, with the MCP
[10:51] client. In the future, we'll likely add risks that are specific to A2A, agent-to-agent communication. That isn't nearly as commonly used right now, and so we didn't want to make this framework
[11:04] too bloated, and so we uh we left it out of this framework. On the one hand, I could leave you with there's 97 risks, figure out how to go deploy all of them. Good luck. Godspeed. That would be very, very unkind of me to
[11:18] leave you with that guidance. Although, it would make for a shorter lightning talk. Uh here's something that you can use as a very quick and dirty way to threat model. Any of you on a security team or
[11:31] have a security background? Okay. Three of you, four of you. For those of you that don't have a security background, and you want to impress your security colleagues, tell them about the lethal trifecta and ask them if they understand
[11:45] how to threat model an agent, and in the next 3 minutes, you will understand at a high level how to threat model an agent, perhaps better than even some of your security teams. The way that you mitigate the risks
[11:59] associated to the agents is one, you don't try to mitigate all 97 of those risks. It's like going to the doctor and the doctor said, "I went to med school and I learned about 97 diseases. I would love
[12:13] to treat you for all 97 diseases." Who thinks that sounds a little stupid? Okay. Thank you for those of you that are awake and listening. Um
[12:25] That would be stupid. And yet, this is how we manage risks in most enterprises. We say, "This is the universe of what's possible, and we are going to treat the enterprise for every single one of these conditions." What are they missing? They
[12:38] did the observe, but they forgot to do what? Did they orient? No. Did they decide? No. When you are deciding to do everything, that is the opposite of
[12:51] explicitly making a decision, the decision in that case is implied, it's not actually explicit. So, the biggest learning is, how do you get from a lot of risks down to the few that actually
[13:04] matter in your context, in your use case? And the way that you do it is, you try to understand three aspects of how the agent is deployed. You try to understand, does the access does the
[13:16] agent have access to something that you would consider private, sensitive, keys to the kingdom, the crown jewels? You would then ask, is there any untrusted content that this
[13:28] agent is going to be exposed to. Somehow could someone upload malware? Could someone upload even an image that may have a Trojan, it may have some malware
[13:40] infected in it? And then the third piece is, does it the ability to act externally or does it have the ability to change state of a system? So, if I can access something that's sensitive,
[13:53] I've got something that is malicious, that is going to cause me to do things I shouldn't do, and I have the ability to exfiltrate data, or have the ability to go into a system and change the state,
[14:06] make changes to it. All of a sudden, if all three of those exist, I now am in the lethal zone, and that is considered the lethal trifecta. And so, the way that you mitigate risk isn't to say,
[14:19] I've got to prevent all of those three from happening. If you prevent one of those three from happening, the risk, by definition, cannot be realized. Now, if you're operating in an environment and you're going to have
[14:32] some use cases where you say, we want to be extra careful. If you want to be extra careful, then you can say, instead of just mitigating one of those three circles in the Venn diagram, you may
[14:44] say, I'm going to mitigate two of those circles in the Venn diagram. If you're looking for what is the process for how to do this, that's formalized a little bit more and defined
[14:57] across the four phases of the OODA loop, uh this is how it would work. And it starts with what we the first image that we started with. You have to have a mental model of what all the AI components look like. One of
[15:09] my favorite questions to ask teams of leaders and sometimes even professionals is, can you draw me a picture of AI? Because if you can't draw me a picture of what you are chartered with
[15:21] protecting and mitigating the risk thereof, then how could you possibly have confidence in your ability to do so? And there should be likely one common view of what that looks like across your
[15:34] enterprise. The second is you need to have some understanding of all the possible things that could happen in your environment. Remember, here we're still in observe, so this is observing what's in your environment and also
[15:47] observing what's outside your environment. Remember we said observe is what is happening, but also what could happen. So we care about the hypotheticals in the observe phase. In the next phase, we move to
[16:01] understanding the architecture, understanding the deployment models, understanding what the approved patterns are hopefully being used, and if not, the architectural primitives, the
[16:13] canonical components that are used in order to actuate your particular use case, and how they interact with each other, the data flows, have significant bearing on the risks that are valid. So
[16:27] you don't have to worry about all the risk, but some of them based on the particular architecture you have, same thing with the threats. All of the threats are not going to be able to cause the risk to be realized depending
[16:40] on your architecture, depending on your use case, only some will. And so, step number five then takes the outcomes from the architecture, from the threats, from the use case, and it says
[16:52] of all of the 97 risks, which ones do I actually care about? Just like the doctor says, we need to run some tests, we need to do some imaging, I need to do some
[17:04] um I need to feel your bones, I need to hear your breathing, I need to test your heart rate, and based on that, I'm going to decide what you most likely have, and then the very last thing is going to be
[17:18] let's make sure we've got the right operating model, the right people and processes to go make it happen. And the very last thing is the controls. Now, we've mapped, if you were to if you were to click on the QR code,
[17:31] download the DCAF, the last version that we released, version 3 in March, actually has all the agentic risks and it maps every single risk to one or more of the 73 controls.
[17:44] The average organization says, "Here's a list of controls. Let us go deploy them." The average organization skips 1 through 6 and then tells you it's going to take a year to do it. Why? Because
[17:56] they are treating the problem as big as possible. Going through steps 1 through 4 allows you to actually be very deliberate and do the single most important thing that you can do when you
[18:09] have a big problem to solve. Do you know what the single most important thing to do is when you have a really really big problem to solve? Spend some time to make it smaller.
[18:21] And that is what steps 1 through 4 do. It is investing the time to say, "I don't need to assess and mitigate 97 risks. I don't need to deploy 73 controls." That sounds kind of dumb,
[18:35] like the doctor saying, "I want to treat you for every single condition I learned about in med school." We already talked about which roles are are skipped. In the last couple minutes, I'll sort of share a framing with you that I've seen
[18:49] fits quite well across most organizations. Anyone Everyone know what knows what FOMO is? And so, in the early days of AI, that was the dominant reason why enterprises
[19:01] were deploying AI. Board member came back, C-level came back, "I heard everyone else is doing this. My friend told me this over the weekend. I want to do it." Resonate with you guys? Yeah. And now the tables have
[19:14] sort of the pendulum has swung and now it's oh my god, this is getting real. How can we trust it? How can we protect it? How can we secure it? How can we govern it? What about the regulators? A lot of what we talked about upstairs
[19:26] with A Gentic with Unity AI Gateway with Genie Anthology with the Omnigent. All of those are about how do you get better governance because people are now
[19:39] worried about FOMU. Anyone know what FOMU stands for? FOMU stands for fear of messing up. And so what many of you experience in your organizations is you have the FOMO
[19:53] people and you have the FOMU people and they are both trying to make decisions but they are pointing in opposite directions. It's like they're both in the same car and one of them is hitting the gas and the other one is hitting the
[20:06] brakes and you guys are along for the ride and thinking boy does this feel kind of dysfunctional. Why can't we figure it out and move together in a coordinated way?
[20:18] There is a way. The way to do this is you need to figure out where you need to be in the FOMO FOMU spectrum. The typical startup better be very very close to the FOMO FOMU side of the
[20:30] spectrum. Typical insurance company that has a 100,000 customers and a 125-year reputation to protect, they better be closer to the FOMU. And so every organization needs to figure out where
[20:42] along the spectrum does it make sense for them to be and get the FOMO people and FOMU people to say neither of those are helpful. This is the approach that we're taking. That is called the process of calibration. What that looks like in
[20:56] most enterprises, the function that does this is the enterprise risk function. This function's job is to figure out how to balance the aspirations of the business and its strategy and its
[21:08] executives with the reality of what is going to be harmful or beneficial to the organization. So, you're looking at the upside, the downside, and you're setting
[21:20] your risk tolerance very very clearly. Second last thing I'll mention is the Databricks AI governance framework. What I walked you through was much of the security framework, which is the technical risk. If you're thinking about
[21:33] the non-technical risk, the operating model, regulations, ethics, and transparency, the DAGF is an open framework that focuses on exactly that. It defines the 43 key considerations
[21:46] that most enterprises are worried about, and it gives you some very specific steps and actions that you can take in order to enable strong governance across your AI and agentic use cases. So, if I
[22:00] were to sum this up across the UDA loop, there's lots and lots of capabilities and products that we have that address each of these four items, and we've got many amazing talented folks that your
[22:14] account team can connect you to to help you and your leaders make sure you are journeying through AI in a responsible, secure way where the FOMO people and the FOMU people are actually aligned and it
[22:27] feels like a very very smooth ride into the future of your organization. So, thank you. You guys have been You guys have been awesome. I hope you found this to be valuable.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.