Video: Four AI Risks Companies Ask About The Most (Asia, Pacific Islands) | Duration: 1508s | Summary: Four AI Risks Companies Ask About The Most (Asia, Pacific Islands) | Chapters: Introduction and Welcome (24.25s), Shadow AI Management (176.09999s), Shadow Agents (447.825s), Data Security Guardrails (719.04004s), Internal LLMs (1047.735s), Continuous AI Monitoring (1444.0499s), Closing Remarks (1499.3339s)
Transcript for "Four AI Risks Companies Ask About The Most (Asia, Pacific Islands)": Hi. Thank you all for joining me today for our webinar discussing the main challenges that organizations face with operationalizing AI for their organization. I'm your host today, Corey Keyswatter, senior product marketing manager here at Forcepoint. And I have the pleasure and the honor of being joined by our chief data security strategist, Ronan Murphy. Ronan, how are you doing today? Hey, Corey. I'm wonderful. Looking forward to the conversation. Likewise. Now for our audience here, can you tell us a little bit about yourself and your experience? I know you've been in the industry for, I think, about two, two decades helping organizations secure their their networks and their critical intellectual property. Yeah. Spot on. I've been looking in the industry for twenty years. Obviously, heavily invested in in AI for the last, you know, several years. And, obviously, my role in Forcepoint, I'm very fortunate. I get a front seat, role a front seat to seeing how, organizations in every corner of the globe are operationalizing AI across their business, and that includes manufacturing, health care, retail, aviation, defense. So, yeah, it's a it's a fascinating time to be involved in data security, cyber security, and and information security. Thank you for that. I think that's, part of the reason why we wanted to have you here. You have that front row seat, as you said, as each of these, companies that you work with across all these different verticals experiment with AI, how they can onboard it and and utilize it safely to get better return on investment for their organization, again, while mitigating the risks which seem to be cropping up all over the place, in terms of using AI. So with that being said, I wanna jump into what we found are four of the the big themes or challenges that that we're hearing often from customers as well as, security and risk management professionals out at conferences and elsewhere. One of the number one things that we often hear about is concern about how to address sanctioned AI services versus unsanctioned AI services. And some of the the subtle differences, between how sanctioned and unsanctioned are used and just the controls that people have at their disposal to to put guardrails around those two different types of AI. Yeah. Look. You're spot on. It's a it's a topic of conversation which I have with many of our clients in every industry vertical. So when when we talk about, sanctioned versus unsanctioned, or let's call it, shadow AI, the the instinct in most organizations is to treat it purely as kind of a control problem. But in reality, it's much more of a demand and, enablement problem. So shadow AI typically shows up because employees are trying to solve, you know, real business problems, Corey. You know, if they wanna write faster, write better, do better coding, do better analysis, customer responses. And in many cases, the official tools either don't exist in the organization or they're too restrictive. So, if you respond to your employees by banning AI, what you effectively do is you just, push shadow AI further out. So, the the more effective approach is to balance enablement with governance. So first organizations need to provide, you know, a a sanctioned baseline. You'll see in Forcepoint, we've done that with our, adoption of Claude and Entropic, and we've got a really structured AI policy within the business. So you you like like we've done in Forcepoint, you've an approved set of AI tools that are easy to access, that are genuinely useful for every department. And if the sanction option is too clunky or it's too limited, people went will then just default to kind of external tools every time. So usability, is is fundamentally important. Second, you need to move from a mindset of kind of prohibition to guardrails. Instead of saying, you know, don't use AI, define what types of data are safe to use, you know, public versus confidential versus regulated. What use cases are acceptable? Where is, where where is human oversight required? And that creates a lot of clarity, let's say, without killing productivity within the organization. And and and finally then, I think probably the single most important aspect is visibility. Visibility is absolutely crucial. Organizations need to invest in understanding how AI is actually being used across browsers, across, endpoints, across SaaS apps, and and they need to know where their demand is highest, what data they're using, where the potential risks are. So, you know, if if you approach it with a good AI counsel, with good tools that are delivering, the right outcomes for your users, shadow AI doesn't become a problem. But if you if if if if you try and block everything, people will naturally gravitate towards using those, and that's where you really create a problem. I mean, this sounds very similar to some of the old, shadow IT conversations that I'm used to having. If you put overly restrictive controls in place, people will just find a way around them. So you wanna be able to, you know, facilitate what people want to do naturally while putting those guardrails in place. So as you mentioned, visibility, being able to see, hey. What systems are people using? Are people identifying, you know or are people using systems that aren't sanctioned because it's a better user experience, because they're more productive? If so, there's a feedback loop that's valuable to the business. Maybe we sanction those. We get more use out of those. But I think the real critical point that you highlighted is the value of the the internal kind of formal policies. And and I think a lot about, you know, the the philosophy of zero trust here. Identifying and putting it in writing with your AI counsel, hey. These systems are approved, for these use cases with these users and only these datasets are allowed in them. Maybe other ones, they're not denied. They're they're they're permitted even though they might not be, controlled by central IT, and they have more restrictive guardrails. Say, you know, no company data, but you can use it as you see fit to help with some of the more mundane tasks. Exactly. Exactly. Spot on. You know, this also brings up, one of the other four big concerns, as, is we've seen this kind of evolution. You know? So we've been talking about, shadow AI. So the movement from shadow IT to shadow AI, and now we're seeing that kind of evolve to shadow agents. Can you tell me a little bit about the conversations you're having with organizations that are starting to to actually allow their users to build agents, across the organization and and how that may be, impacting internal security policies? Yeah. I mean, look, I'm not sure how much you played with building agents or working with OpenFlow or any of that stuff, but it's it I mean, it's astonishing. Right? I have a guy working on my team, and he he he built an agent for, correlating his children's, schedules for football and ballet and whatever else they're doing. The agent goes in. It's and and all of these family groups, they they plan these events through WhatsApp. So he uses the agent to to to crawl his WhatsApp, pull out all of the timings that are required, cross reference it against his calendar, and then see what is available to do or not. This guy never wrote a line of code in his life, and now he's automating, his his his his collection and drop off for his children using agents. But that that's obviously, you know, a a very simple example. But what we're seeing in Forcepoint globally is the impact that agents are making, the level of automation that it's driving across organizations is truly astonishing. Honestly, I've never seen anything like it, and it's incredibly exciting. But it's also, in equal measure, absolutely terrifying because, with with an agent, if you want to get the type of, effectiveness and the levels of automation required from these things, you need to, you know, give them unfettered access to a whole lot of very, sensitive repos across your organization. In in the scenario I just described, he's giving an agent access to all of his WhatsApp. He's giving an agent access to his calendars, and he's allowing that agent to schedule on his behalf. You can imagine as companies roll out thousands of agents and it has has those agents looking at emails and, calendars and SharePoint environments and, you know, locations where you could, house very sensitive data. That obviously can bring tremendous, benefits. It can help, you know, do a lot more with less cut cost, drive automation, become much more effective. But at the same time, if you are not in a position where you've got accurate visibility into what these agents are doing, arguably, you're probably introducing one of the single biggest risks from an infosec, from a governance, from a risk and a compliance perspective your company has ever had to wrestle with because it it the thing about about agents, it's not just, you know, losing data. These things have the ability to action as well. So there's a whole pile of different, scenarios where these these could go very, very wrong very, very quickly for organizations that don't have a very, structured approach with the correct guardrails, with the correct visibility, with the access to the correct data, all built into the foundation of how they approach this technology. You know, thinking about especially the example and by the way, I think I'm gonna steal that agent example because I also have I've got three little ones and being able to coordinate automatically without having to schedule it myself, that stuff, like I said, I'm sure he licensed it to you. Right. But that that also brings the concept of, okay, if he's using you know, he's got some preferred agents maybe for scheduling on his personal device, a lot of us are working on the go when we access work applications from our personal device. What's to stop us using our own personal agents to start looking at some of these corporate applications and the data within those? How do we mitigate the risks of that personal, using personal agentic AI and and kind of setting up a barrier between that and data that's managed by the company through SaaS applications, that we might also be accessing from that personal BYOD device. Yeah. Look. I mean, that that is a huge, huge risk. I I fundamentally believe that, organizations who hold sensitive data, it might be financial data, it might be customer data, it might be trade secrets or RIP or regulated content, You know, you need to have the guardrails in place so that, you know, random agents that developers or even, you know, regular employees that can now build these very powerful tools using a whole host of different AI, systems that are available on the market, they should not be allowed to access your data full stop. So, I mean, from a Forcepoint perspective, we have a philosophy of data security everywhere that doesn't just include discovering data, classifying data, contextualizing data, but it also controls, you know, what and how we can access these different systems. And we provide the com the the kind of controls or the guardrails between, how how these systems will access your data, what they can access, but also what users who are on your corporate network can access. So I think, you know, Corey, you have to, despite the tremendous benefits that these technologies can bring, the internal framework for deployment of AgenTic, has to be taught through very carefully and diligently by every organization. Otherwise, you know, you're potentially looking at some very significant, risks to your business and to your data. So, again, it sounds like the value of that internal formal AI document of, hey, what is the AI council say says is, acceptable use? That that needs to be an important part of that document is, hey. How are we thinking about BYOD agents that might be on there? The value of MDM solutions is also gonna be important here. You might wanna go revisit some of the policies associated with that. But I wanna now pivot to the the third, challenge that we're also hearing about, because this is okay. If we move away from shadow AI and we start going back towards the sanctioned AI, there's still some, big risks associated with SaaS applications that most organizations already have running in their environment that are having AI added to them. So I'm thinking of things like Copilot, Salesforce's Agent Force, Workday's Asana, and potentially, the ability of those agents to start sharing information with each other if an organization doesn't have guardrails in place to protect that. Yeah. Look, I I I guess it's kind of the same problem. Right? I I heard an interview recently where John Collison, the president of Stripe, was interviewing Satya Nadella, the CEO of Microsoft, and he asked him, you know, what's the the you know, why isn't Copilot being adopted faster, globally than you'd anticipate? And he said, look. It's the first time in history that Microsoft have put structure to all of this unstructured data that's sitting in SharePoint and sitting around your organization. So it's almost like that all of a sudden, that vast array of data that your organization is holding suddenly has structure to it, and you can query it and as if it were a database. Right? And, obviously, when you have a database, the specific people that have access to that database, they've got different rights when they access that database. It's the exact same problem with data being used in any of these productivity tools or agents. You have to ask the question, well, think about it like a bank. Right? And if it's gonna be the database with all of the the customer information with their account numbers and their balance and their personal information, you know, there's only specific people in the bank that can access that and there's, specific fields within that database they can access. If you turn on a an application like Microsoft Copilot or any of these powerful agentic tools or productivity tools, and if you don't, clearly know which data they've got access to, how that data is classified, should that data be allowed to be queried or a prompt associated with it, either at the ingress or egress point to any of these systems. That's a huge potential risk. And Satya's point to John Collison in this particular, webcast was, you know what? It takes time for people to get their house in order. People need to come in. They need to look at their data footprint. They need to ask the question, which data represents the most opportunity or the most risk? Do we want that data accessible by, either agents or by humans who want to, you know, query, different data assets using these productivity tools? And what type of risks does that introduce? And should we, as an organization, either through our regulatory obligations or compliance obligations or our risk appetite, ensure that that's either included or not included in these different systems? And then do we implement, you know, proper data discovery, data classification, least privilege, and ensure that, all of this data is, in a good place for turning on at these powerful tools? Because one thing I'll tell you, Corey, and I've seen it, you know, a thousand times, if your data is not ready for AI, then you're not ready for AI because data is the oxygen that powers these systems. It seems like the two biggest aspects to be able to really have some kind of meaningful control around the use of AI is a up to date and detailed understanding of your data and identity. And that's not just human identity, but nonhuman identity. And because agents can be ephemeral, we can't just do scanned regular inventories. It needs to be on demand always on. Does that I it it seems like that would also hold true for the fourth consideration, the fourth big challenge, which is internal LLMs. I've, talked with a number of organizations that are, taking down models, from open source models, using them maybe in an air gapped, environment internally, to build their own models for or build their own processes. How does that approach, differ in terms of securing internal LLMs? How is that different? Yeah. It's a it's a very interesting one. Right? So so you have, this kind of, let's say, evolving landscape where you have a lot of organizations taking, AI in the cloud. Right? And we all know the the the various different flavors of AI in the cloud. But you also then have the internal, LLM, environment where you have your search and development teams who want to pull down these models, as you rightly said, Corey, from, you know, the likes of hugging face. And they and and and typically, the reason they're doing that is they want, to have control and customization, around that LLM. Right? And that becomes incredibly powerful when you can privately host the LLM. You know where your data lives. You know how it's processed. You know, whether, or not, the types of data internally that are used used for training on it. You can control the bias in it, and you can integrate them with internal systems, let's say, highly sensitive systems. This becomes, let's say, especially important in heavily regulated industries where you're dealing with, let's say, core intellectual property. It allows you to fine tune those models, on on, let's say, very proprietary data. You know, in many cases, these models are used in very, domain specific type industries, and it can become an incredibly competitive differentiator. Obviously, there's trade offs. Right? Running internal models, means that you can have high infrastructure and compute costs. You typically have to hire AI talent, you know, to, you know, help build and maintain these models and tune them. So, it is definitely a huge area of growth, and many people are arguing that this new kind of hybrid, adoption of LLMs globally, is damaging to the cloud. And I and I totally get that because, you know, I was at a large pharmaceutical a few weeks ago in The US, and they have blocked external AI, and they only do their own internal LLM development because they're so paranoid about, you know, specific IP that they're yeah. IP are building leaky gouge. You know? So it's it's it's it's it's very, very, very interesting area and, it's an area that's definitely growing. That seems like a big trend with organizations. A lot of the the impetus to take a a model, bring it internal, and maybe air gap it is because of concerns around intellectual property and not wanting that to get out through the vendor. Maybe the vendor gets hacked or something, and then they lose their the most valuable, data for their own Well, I I think what I think one of the big ones that we hear is, their, you know, control and transparency. You know, if you're using a SaaS AI model, you have less visibility in how the model behaves. Data governance becomes more complex, especially around, let's say, retention and, and and training usage. And then there's obviously, you know, risk of vendor lock in. The Pentagon are kind of wrestling with that now with Entropic. Right? That's true. Yeah. So so there's a lot of a lot of reasons why you could argue potentially makes sense, you know, to do a lot of this on prem or or at a minimum, as a hybrid. But that also means that you don't get to rely on that vendor to do some of that, you know, runtime security. You you're probably gonna have to take that on yourself. So, as we wrap up, how do you help customers navigate, the the different you know, the maturity model, let's say, of what to do first and how to kinda evolve into things that might be a little harder to do like runtime security. Yeah. So so look, we have a very pragmatic and very logical, and a very straightforward approach to helping our clients globally to operationalize AI at scale, and that starts off from a kind of bottom up approach. At a foundational level, you need to know where your data is. That sounds easy, Corey. It's not. And the bigger you get as a company, the more complex it gets because you've got data. It's sitting on prem in, NetApp and SharePoint and, you know, on prem SMBs. And then it's in the cloud, and it's in SaaS apps, and it's in Dropbox and OneDrive and Google and Oracle and s three buckets. So firstly, figure out where your data is and having a kind of a, you know, a 20,000 foot view of of of where where it is. Once you know where it is, you then need, you know, very accurate classification of that data. So, for example, where do we have PII data? Where are our trade secrets? Where do we have regulated content? And making sure that data is properly labeled and classified and ready for ingestion into any of these powerful AI tools that we've spoken about today, Corey. Your third, step is then prioritizing what is it we want to do. Do we wanna operationalize an agentic initiative? Do we want to roll out a productivity initiative like Microsoft Copilot? Do we want to use RAG? Do we want to deploy applications that are powered by AI? We can now answer, the questions associated with these and the potential risks in a very clear and concise manner. Once that's done and that's a process that never ends, it's it's con because you're continually creating more data, so you need to, you know, continually kind of move through the gears in terms of how you do that. You then move into runtime security. How's the data how how are how are these models performing? AI, do we need to, you know, run offensive security testing, red teaming, and how do we continually monitor the the ingress and the egress and the continue help the continuous help to those models? Forcepoint as a company, our philosophy is data security everywhere. We start from the ground up, and we go through the whole way through from the discovery, classification, prioritization, remediation, and all of the runtime security for continuous monitoring. And it seems like that runtime security is going to be extremely important because with AI, you're not dealing with deterministic software. With deterministic software, you can check, hey, is this vulnerability or exploit able to be exploited? And if it's being blocked, you know you're good. But with AI, it's different. It's probabilistic. Maybe the agent just didn't take a pathway that it could have taken. So you need to continuously be doing this. Exactly. Exactly. Well, thank you for your time and your insight today, Ronan. I