Transcript
Hey, everybody. Welcome back to another episode of Into the Breach. And today's topic, the AI shared responsibility model. Whose job is this anyway? No better to go in deep with this than Philip here, who's joining me. Philip, welcome back to the show. Yeah, thanks for having me, Chase. Yeah, so all right, let's dive in. What is the AI shared responsibility model as per Microsoft? Yeah, so we've had these shared responsibility models before, right? So if people who have some experience working with the public cloud or Microsoft 365, for example, you've probably seen a type of shared responsibility model where there's like a demarcation between what is the responsibility of the cloud service provider versus what is the responsibility of the consumer of the service, let's say, when it comes to public cloud and some of these SaaS services. So at a super high level, I would say you can summarize it as the cloud provider is responsible for security of the cloud, and the consumer is responsible for security in the cloud. So whatever you're sort of using, especially from a data perspective in the cloud, that will remain the responsibility of the organization or sort of the consumer. And then for AI specifically, Microsoft did a really great job of sort of laying out how there's now a shared responsibility model for the AI stack. So Microsoft takes some responsibility in this three-layer AI stack, if you will, and then they sort of point out what you are still responsible for. It's a little bit different from public cloud and SaaS in that there's an additional sort of catch here, which is the model provider. So even though you're using generative AI, Microsoft supports different model providers like, you know, OpenAI, Metaslam, Cohere, and so on. And of course, there is some security responsibility for those model providers as well. So that's sort of what makes this a little bit more opaque or a little bit more difficult to navigate, if you will. Yeah, no, that's a good explanation of what this is all about. So let's break this down a little further. Give us an overview of who is responsible for what, specifically. Yeah, so for AI, Microsoft divides the AI stack in three parts, as I mentioned. So they look at the platform, think of this as the infrastructure, as you will, to sort of build your own or bring your own Gen AI capabilities and basically use Azure as an infrastructure as a service layer and then build everything yourself on top. They also look at the application part and then sort of the usage part. That's sort of how they break it down. And then if you look at the different usage models from a cloud perspective, you have infrastructure as a service. So that's sort of the bring your own. You have PaaS, which in the world of Microsoft is mostly Azure AI services, things like Azure OpenAI. And you have SaaS, Copilot. Everybody sort of knows about Copilot, I assume. But even if you take the most managed usage model, Copilot, the customer is still responsible for data connections, data governance, access control, data exposure and so on. And then for PaaS and SaaS, or sort of for PaaS and EaaS, the responsibility shifts sort of more deeper into the consumer stack, if you will. All right. So that's a great overview of some of the things that customers are responsible for. What did we miss? What's like common that, you know, what do you think customers might not know that they're responsible for, but they are? Yeah, I think one of the most surprising things looking at the AI shift responsibility model is in the PaaS side of the house, if you will. So when you're using things like Azure AI services, and you use these third party models, like I mentioned before, like Metal, Lama, and so on, there are certain things that you can do. Like you can tune the model, you can filter out some terms, et cetera, et cetera. But it changes the potential outcome of your AI application. Like assume you're building a simple chat bot, if you're sort of tuning the model parameters, it changes the potential output of that model. So then if you start asking yourself the question of who is ultimately responsible for that outcome now, is it Microsoft? Is it you, the consumer? Is it a model provider sort of in between? Because your tuning might change the output in very sort of unforeseen ways. So that's typically something that's quite unexpected when sort of talking to customers is, well, how do I navigate this successfully? And how do I make sure I'm not sort of painting myself in a corner by, you know, trying to make all of these modifications to the model in a PaaS environment? Yeah. And you mentioned CoPilot earlier. What does it say about who is responsible for data security and access management? Yeah. Generally speaking, the consumer or the customer is responsible for the AI usage layer. So the AI usage layer sort of determines how these capabilities from CoPilot are used and consumed naturally. But the thing with CoPilot is it changes the game a little bit compared to traditional programming. What I mean is, if you think about how you interact with a traditional program is, okay, maybe you have an API you can talk to, maybe you have a GUI or some other input output system. With CoPilot, you have the same, right? You typically have a chatbot or some other way, but you as a user of that chatbot have a lot more flexibility and dynamic impact on what happens with that application. If you think about a traditional application, the input and output are very static, are very determined upfront. But with CoPilot, that's completely different. If you know how to do some prompt engineering, if you're a little bit creative there, you can get the CoPilot model to do things that might be unexpected. So that is a little bit of a shift. So you need to provide these guardrails around data filtering, security controls, and so on. Those are definitely fully in the responsibility of the consumer or of the organization making CoPilot available. So anything that's data access related, it's really you as a customer, you remain fully in control or fully responsible for that. The other thing I would say is that for CoPilot specifically, you have to understand what data is accessible through CoPilot. So CoPilot reuses the existing security controls that are in place from a user perspective. So whatever user is using CoPilot at that particular point in time, his or her access is going to be adhered to from a CoPilot perspective. But a lot of people don't really know what that means. So there's a lot of oversharing of data. There's over-permissioning of data that you might not be aware of. So a user might be able to ask a question and get a response that might be pretty embarrassing from an organizational perspective in terms of what it has access to and what can come back. So that is really a challenge that a lot of customers underestimate. So I think you really have to get in front of that and make sure you up-level your existing data access patterns and data security controls before you enable a powerful tool like CoPilot. Yeah, it sounds pretty scary if folks don't take a proactive approach. It could do more harm than good in some cases, like you're kind of alluding to here. Let's take this home. That's kind of where we're at today with all of this. Where do you think it's headed? How is this all going to evolve over the next few years? Yeah, I think just to reiterate, I think there's no Gen AI without lots and lots of data. I think that's very well understood. But of course, you have to think about this in terms of secure data. I think that is the foundation of these tools. These tools are very, very powerful, but without proper data governance and proper data security, you're sort of setting yourself up for failure. I think that's the first thing. The other thing is, where is this going and how will it evolve over the next few years? It's evolving so rapidly, it's hard to sort of predict, of course. There's going to be more and more capabilities as part of these models and what model providers will offer will change as well from a security controls perspective. But I think one thing that sort of helps a lot in these scenarios is keep a lookout for things like the OWASP top 10 for AI and LLM applications. Have a look at the MITRE Atlas website to track attacks or new types of attacks against these Gen AI tools. That will give you a good idea of what malicious actors are sort of thinking and experimenting with and gives you some leeway in sort of getting in front of some of those challenges and making sure that you can keep on using this technology in a safe way for the next years to come. Awesome. Data is good, but it's better if it's secure. Philip, thanks so much for joining us today. We'll catch you next time.
