Video: AI Red Teaming | Duration: 1812s | Summary: AI Red Teaming | Chapters: Welcome & Introductions (29.39s), Introductions & Panelists (95.96s), AI Red Teaming (177.48s), AI Red Teaming (311.88s), Testing AI Systems (454.08s), Shadow AI Risks (538.21s), Agent Red Teaming (713.23s), AI Red Teaming (965.14s), Ownership and Governance (1108.94s), AI Risk Ownership (1241.49s), Shadow AI Discovery (1411.155s), Shadow AI Monitoring (1573.02s), Closing Recommendations (1653.42s)
Transcript for "AI Red Teaming": Good afternoon, and thank you for joining us. We're excited to to, lead this talk on AI Red Team in as part of the Purplebook community. We have a great discussion for you today, and we're excited to get into some, hopefully, some technical conversation and some expectations on, specifically around what it means to red team, what it... What red teaming will tell you and what it can't tell you, what the harder problem is, which is often knowing what AI you have, and then some practical next steps on what you can do, and we'll hopefully leave you with that. So I'm Evan Rolle. I'm managing director with our cyber managed services team at KPMG. I support our managed security testing, and I'm joined with... Joined also with MJ and Arvin. So MJ? Yeah. Hi. It's good to be here. I am Ratanjay. All my friends call me MJ. So either works, I'm the CSR at Instacart, and my core background has been in product security, right, teaming, enterprise security, and stuff. So, prior to this, I was at database for around four years. I've been in the industry for around twenty years. Thank you. Arvind? Yes. Arvind Bansal, I'm currently responsible for protecting, CNS family of companies. We are a, 30,000,000,000 revenue, 30,000 people, company. Prior to that, I've spent about a decade at, Citigroup, more than half a decade at, Fortune ten AmerisourceBergen. And I've also worked for Verizon, Experian, Willis Towers Watson. Happy to be here. Thanks, Arvind. Thanks, MJ. So, just to jump in, you know, there's a lot of questions. Obviously, a lot of interest around AI red teaming specifically. How do we secure AI? What does that mean? I think that there's, often a lot of confusion many many times around what red teaming is specifically, but, AI red teaming is different. So, MJ, if I could pose the first question to you, what is a... What is AI red teaming for for you, and why should an organization even care about red teaming? There's a lot of, you know, a lot of discussion around third party systems and AI systems and models being developed by others, and there's an expectation, I think, to secure... That that the organizations will secure those. But why should why should, organizations that take advantage of these care about securing their AI or red teaming their AI? Well, the AI teaming started, as of in HOMA 09/2023 pretty actively when it was just dealing with elements. And the whole objective of AI teaming was to make a model two stuff which you do not supposed to do. Now this whole thing became more dangerous once NC became and and more tools got activated where the large language models became more than just a chatbot. There was something that it... They can actually take action on. So as the evolution of the error and world move into the agentic space, the AI redeeming also sort of evolved, and the objective was not just about pushing, concept of, hey. Can I make the model talk or say something unexpected? But can I make the model do something unexpected? And that opened a whole different avenue for AI AI retraining. So the attacks are in the AI retainer space as of today becomes more of amalgamation between what tradition retaining walls, but the entry point typically becomes like in the account injection or or MCP tool exploitation. Or even in terms of supply chain. Right? Like, if I have a Ollama, I could go to, the GitHub repository for Ollama, find out the dependencies, identify a CVE, exploited, get into Ollama, steal cookies, steal tokens, move around. So it's pretty interesting space right now. It's pretty interesting. And I I would say, one of the interesting things is I think that a lot of, a lot of organizations feel like, because a model is from one of the, you know, one of the frontier organizations that they don't need to test it. They don't need to evaluate it. They don't they don't need as many guardrails in place. I'll I'll say from experience, and we've tested quite a few, models and LLMs rather, over the years. And, it's still necessary. It's still needed. There's still techniques that can be used and are often used to extract data from back end, databases, confusing the LLM, getting it to respond to things like emojis, and we see that quite often. So I think that to your point, yes. I think from a from a, complexity, Agintiq, MCP, all of that added into the mix, there are different things that have to be tested. But at its core level, I think the LM still need to be tested to some extent to validate the, to validate that you're gonna get what's expected. Arvin, in terms of the different types of tests that are out there, so we're talking about, agents, we're talking about LLMs, we're talking about MCP servers. What's what's the difference between traditional pen testing, red teaming, and now this AI red teaming? So, Evan, if we look at traditional pen test, you know, we we define a scope. And then the objective of pen test is, hey. Can we find what are the security gaps? Can we detect them and then respond to them? Right? So for example, in a pen test, you know, we'll check whether an API allows unauthorized payment changes. You know? And and your traditional red team, they will try to attempt a payment fraud through an attack chain. Right? Vulnerability access going through the layers. But in the AI red team name, yeah, we actually test that, hey. Here is a supplier's document. It's persuading the agent to change the payment details. So so it's sort of... You know, the the paradigm shift is it's huge. You know? Traditionally, we're just looking for security defects. Can you chain them? Can you detect and respond to them? But now AI is bringing another layer that, hey, with just prompt injection, with just certain instruction, the LLM will give you what you need. The model will change the bank account information or not. Yeah. So that... That's... The the bottom line from my perspective is, you know, it's AI introducing another path for exploitation. But the existing application security still matters, though. Right? Well... And and whether you're just testing an L and M or an agent, you know, there are some tests that are gonna be similar. And and to me, it's it's it's combining what we would traditionally do with social engineering and trying to commit someone to do something. Also with the technical testing, now you've got all that together, and it's become very interesting, you know, trying to get a model or an alum to do exactly what you wanted to do, go grab this information. And so it's a different world and a different way of working, I think, from a testing perspective. Would you agree? Yeah. Absolutely. You know, the the interesting example I'll give you is, let's say, in the MCP API and the LLM models, now we just... A supplier document can be inputted. And and the document can just say that, hey. Ignore the normal process and update my bank account. Now now is the agent supposed to follow it? No. Right? But have we tested and built that logic within the models or not? So those are the new creative ways we have to keep coming and and see whether the tool permission allows the change. You know, whether independent approvals, do they block it or not? So that's the paradigm shift we are seeing. Yeah. So, MJ, I have a question for you. So as you think through the various types of tests, so when we think about testing or at least when I think about testing of of AI systems, I think about it from, you know, from the LLM level to the protocol level to the GenTech level, or layers, you know, if you will. So when you think about that and you think of all the different types of things that can be or should be tested, where do you think organizations, where do you think the... Where do you think they're they're least prepared right now? Where should they focus their attention? I think, you cannot predict something you cannot see. And therefore, the... There's a lot of AI ecosystem living in the shadows, and that is something which I think is the biggest threat to the organization. So in the effort of being everybody AI enabled, so literally the entire, world moving to the idea that, okay. Hey. Every second day, there's a new AI tool out there, which is with a fancy option. Sometimes they give it for free, and people tend to, immediately opt for it. The comfort with which employees are able to connect, or even users are able to connect their personal data into these AI tools in the attempt to, you know, generate something or it is just crazy. Right? We were never going to post, a personal document on basement, but we are happy to give it to, you know, DeepSeek. So it's not that different, actually, but somehow the comfort has changed. This is is what actually puts a lot of risk because when I see from a redeeming perspective, I don't like to see LM as just a, just a frontier lab object or something. But I like to imagine this like a simple operating system. Like, it's like an AI operating system where everything in the MCP and every single skill which you put on it, and every command line is calling. It's effectively like an app, which is running on the operating system, which is why every every composition of this... So I may use the same cloud or OpenAI or whatever systems. Right? But what I connect to and what kind of keys I'm giving it, what kind of actions it can take, it changes the threat model of my entire ecosystem. It's like saying that my machine and your machine might go be Mac, but they... We both have a different level of security based on what is installed, what is activated, Sean. That's what we are trying to hit, essentially, when we're looking at the agentic, error team. And I would say, as long as we, I mean, I have had the opportunity to play against multiple kind of elements, and I'm not going to take names here. But we have also pretty interesting behaviors. Like, for example, lot of elements are trained with the idea that attacker will say, hey. Do this thing. This is super urgent. Go and do this quickly and, you know, execute this command. Adelands are trained to recognize those kind of parents now. Guess what? If you don't put that urgency, Adelands will actually do it. They will not stop you. So it's a very interesting paradoxical behavior you see because when elements are getting trained, they are basically non deterministic entities. They are relying on, the training to do things. The question here is less about whether we can trust agent. The question is more about whether the agent the agent can trust the user who's giving the prompt. And this is where the whole game is. Have you had a chance, and Arvin, this is for you as well. Have you had a chance to to tactically, test, agents in your environment or MCP servers as well? I know from a LLM perspective, that's a little more straightforward, and we can run various types of tests, specifically prompt injection, those types of things. But if you had a chance to really go after the agents and really probe the agents to see, can we somehow, can we can we somehow spoof authentication and and get access to, you know, a token that we can use to log in to a system? Can we somehow, get the agent to, basically, you know, achieve some, some some higher goal that maybe we've we've implanted in it, in some way. I don't know if that's... If you've had a chance to actually go and and test agents, but I'm just curious. Look. I'll I'll give you another recent phenomena that's happening in the industry, Evan. So so in the ideal situation, agent is supposed to do what it is tasked to do. Right? So when we started, building agents, how do you know what actions agent is going to take to get you the answer? So so there was there was a chain of reasoning that every agent had. And you can actually go and follow the chain of reasoning, how it is arriving at that answer. In last few months, the the pace of development and the pressure of competition among the top three players, you know, and every now and then you will see Google Gemini is top and then news is coming and then Anthropic is doing this. That has fundamentally changed how these agents are being built. There was an article in Wall Street Journal. They're talking about, you know, the developers are telling agent, hey. Just get me the result. How you get it, it's up to you. So guess what does that mean? If it gives you the answer that you want, whether it is cheating that or not. You know, we just had one of the entropic, study coming out that agents with read access only were circumventing to get to the training site for the material and then walking through the Internet. There was no chain of reasoning for that. So if those are the things that are happening in the background, I believe the risk is going to continue and increase. If things are not defined, where do we go and plug the security gap? Right? I think that I think that's interesting. You bring up, you bring up the, the OpenAI, Huddlian Face, scenario and, incident. And I think it's interesting if we look at that and as we think about red teaming and we put a lot of thought into, into evaluating scenarios and situations that have been, out in the wild in the news, so to speak, and if we look at those and that one in particular, there are a number of things that stood out. And so as we think about how we're going to how we're going to test systems and how we're gonna evaluate whether or not a system's vulnerable to a specific, you know, a specific attack scenario, we try to identify what we call measurable attributes, just how we're gonna test and the various types of tests that we're that we're gonna run. But, you know, it's interesting that as part of this incident that happened, there are a number of things. And when you think of it from a testing perspective, there are some things you can test. But if you think about things like unauthorized coordination among the agents, collective scope expansion, you know, agent initiated egress of the environment, expanded ecosystem exposure, all of those types of things, those lend to other areas. And so AI Red Timmy won't actually accomplish that. So we think about, you know, if we think about things like zero trust communication, ensuring that you have controls in place, or agenda governance, or what are your identity and egress protections, supply chain, protections that you have in place, those types of things pop up. So so, you know, as you think about if AI does it, AI red teaming doesn't secure the organization, how far will it get you? What do you think the value is in performing an AI red team specifically? There's a, any kind of a red teaming is generally not a substitute for security. Right? Like, red teaming should always be used as something to spot, to find the blind spots. And, so it's not a substitute for security. It's not a substitute for governance. We need to know our shared AI system. We need to know how to control and what to govern, what to stop, what to block. So those things will have to be in place before we do rating. And, a lot of times, there there is a... That there is a very good value we get from, AI rating. I'll I'll take a small example, actually. Let us say that you have an agent which is connected to, a Git MCP because, organization is doing push on code, and it makes sense, right, because they're using this, FrontierLab model to push something into Git. Now a scenario where the git repos are being created by standard processes and there... There's a human loop. So for creating a new repo in that environment, you actually need somebody to do that manually. Let's say that's the requirement. At this point, somebody who is like a citizen developer, somebody who was like, like a non engineering person who has got a hands on plot code and they have a managerial pressure to go and build some stuff, They go ahead and build some sort of automation. They do it really well. Now they're like, hey. You know what? I should check-in this code and get... They ask cloud or they ask OpenAI or codec. Whatever. Right? Like, hey. You check this into grid. There's a good MCP. It tries to do it. It fails. What does the agent do now? The agent is going to create a new repo and say, hey. There's no repo. Can I create one for you? But it is going to create a new repo. The default setting for GitHub is always a public repo, And there you go. There's a problem. You got all the code, all the data out in the public repo. Nobody intended harm. Nobody intended to do anything. AI red teaming usually can spot not just the ways by which somebody can breach into the system, but also about where your AI agents can start behaving like inside of the threats, where they will end up making decisions, which was not a intended decision and therefore would would, like, raise the security risk for the company. And that's the way we like to use it. Yeah. I'll just, so MJ is spot on. Right? It was not the intended behavior, but that resulted in that. The second piece it gives is, ownership. So so, you know, let's say if we find a failure path in the red teaming, then the evidence of that will lead you to who's the owner, who's making the decision, what is the fix, should we retest it. Right? So so I believe, let's say a a agent can send a confidential file to an external destination. Yep. So we can actually restrict the destination, enforce the data control, and then repeat the attack that, hey. Is the agent doing it again? Right? So so same example as MJ about the GitHub, about sending data. Now agents are doing our emails and calendar meetings. You know? So those things becomes even more critical. Well, I I think... So, Arvind, so I think that's a good point. I'm glad you brought that up. So, I think that there's... What we're seeing in in industry is that there is some confusion over who actually owns the risk. You may have an owner of the AI system. There may be various owners because of, you know, how it's built, designed. You're gonna have infrastructure. You're gonna have application involved as well. But financial services, as an example, may have, you know, model risk management. Is it model risk management in this scenario? Is it their remit to ensure that the models are secure? Typically, it's quantitative models. Right? And so I use that as an example, but there is some confusion in in in internal organizations, especially those who have maybe mature governance processes. And this is a new world, and we have new, new technology. We have new ideas. We have new processes, new ways of working with AI. So, how do you approach that? So as you think about overall governance for an AI system, how do you approach that, and how can some of the listeners think about governance for, for their systems? Yeah. So so my my thought process around that is at the end of the day, every agent, every model is delivering a business outcome. So who owns the risk? The business owns the risk. Right? So the engineering or the platform teams, we are implementing the technical fixes. Security is assessing the threats and testing the controls. But at the end of the day, it's the risk that lies with business to decide, yes, I accept the risk. Let it go. Or no, I don't accept the risk. Let's not release this or leave it back. And I'll give you a very simple example for that. Right? So so if you have a finance agent that changes the supplier's payment details, finance owns the risk. Engineering can fix it. We can authorize security retesting. We can look at the abuse scenario again, but it's the authorized business executive decides whether it can launch that agent without any... Or with any exposure or not. And and, Jay, do you have any thoughts on that as well? I'm interested to hear how you... How you're thinking about overall governance of, of AI risk. I mean, this is a super debated topic to be very honest. Right? Because, the risk can fall into three different areas. It could either be the business as Arvin was saying. The second option is that the person... The the group which created the agentic pipeline just touching all the data. So is the owner... Are they the owner of the risk? Because there was some... Something which went wrong there. Or is it the security team or the CISO who's eventually accountable, right, for any and all risks. So this question is something which is... I don't think it has found a good footing till now across the board that... Who really owns the risk? Yeah. I think it's a much debated question. I think that businesses will have to make some internal decisions. I do think that there's a technical aspect, also a business aspect to Arvin's point, as the ultimate arbiter of of accepting the risk. And I think at the end of the day, if we think about it from a red teaming perspective, MG, I think you made the point. You know, red teaming will only get you part of the way there. There there are things that we can test. We would prefer not to do it as a point in time to us. We'd prefer it to be ongoing testing, active testing, automation, you know, being careful not to introduce AI, testing AI, some of those kind of common sense concepts overall. But it only gets you a part of the way there, and I think that, you know, we're all still trying to figure out how this is gonna work efficiently in business operations and how do we get there. So I think that, another key question is... And and we're running up against this, and I think, MJ, you had brought this up earlier. How do we account for AI systems within the organization so that there's there's a discovery aspect, there's an expectation, the business teams are going to be, you know, going to understand what SaaS applications or what tools they're using that have AI built into it. There are, you know, there's potential for shadow AI across the business as everyone's excited. We're trying to build things, and we're trying to get things out there. But but how do you go about finding and monitoring, you know, AI systems when, you know, it could be air... It could be rapid. It could be everywhere across the organization. That's a that's a very, very hard problem, and I think everybody's working on it. There are multiple places where AI systems can exist. We broadly can classify those into, I would say, three arenas. One is production agents. Those are the most easy ones to do because those are the ones you know of. You put in a production. They are the known pipelines. Then the second one is other dev agents and dev agentic pipelines. They could exist on your, data lakes. It could exist on your laptops. It could be, like, purely containerized, and you have just installed a bunch of Docker containers doing things. So those are the ones which are the next class of problems. You could, like, you could identify those using, stuff like OS query. You can actually query the file systems. You can figure out what files or configuration are going. So that's what, that... That's one way to do it. And the third piece, which is the more complex piece, is the SaaS side of it. Because gone are the days when we could just rely on a yearly TPRM review and say, hey. You know what? This third party needs renewal and we'll also review. Guess what? The third party SaaS component just announced a new AI feature, which they gave for free, and they're transitioning data everywhere. And this is happening every two weeks, man. So it's just going crazy. So there's a significant evolution which is coming... Shadow IT has a winner history. It has always been there. With shadow AI coming in, it has become more risky. And identifying what people are installing, which... And which SaaS applications we are paying for, which are even free, that also enabling all these agent capabilities. When you combine all of that, we are dealing with a huge mess of a shadow AI. And the entire pathway of a shadow AI, if you imagine it like a connected graph, then you can actually see the significance of how risky the entire pathway is and how can attacker use... Like, if you have the entire shadow AI map of organization, you could essentially create amazing red team to compromise a lot. So, Arvin, the question to you. So specifically around shadow AI, how do you monitor that... Monitor that? How do you discover it? What are some practical steps you can take? Well, Arvin, we take three practical steps. The first one is on the productivity suite side. We monitor every Internet connection that is being made, whether it is to an AI sites, through an AI agent, or through MCP servers. The second one is on the desktop itself. You know, let's say developers are using, developing codes. So we look for what kind of tools developers are using, what kind of connections they are making, what kind of agents being run through their desktops and... Or laptops, and then, what kind of API calls are being made through that. So that gives us a true visibility across the AI infrastructure through development pieces. And then lastly, we look at big cloud service providers like GCP. You know, we have native solutions now, Google Model Armor, where we can actually inventory every agent, put in the ownership out there before it is approved, and then restrict what it can connect to internally or externally. The SaaS part is still unsolved, so we're figuring out that part. No. I think that's the right I think that's the right approach. And I think that we're, you know, as we're, wrapping up, I I know we wanna leave, our listeners with a few additional, points, and I wanted to call out a few of those. I think that one of the important things is is really to understand that there's a whole new level of complexity, and we... We're we're going to have to deal with that. I think that, you know, if we think about it from a red team perspective, there are things that need to be done. But first, which is, obviously, building an inventory, ensuring that you have ownership, the proper governance in place from a process standpoint, then ensuring that you have the proper risk tiering, prioritization of of AI systems that need to be tested. And then from there, moving on to practical common sense things like least privilege for agents, providing avenues for, for the business teams, to work within approved structure, and then ensuring that you're providing that testing on an ongoing basis. So I think that those are some practical examples of things that, our listeners hopefully can take advantage of, you know, as they're moving through their journey. So, MJ, Arvin, I wanna thank you. Thank you for your perspective and your time. These are interesting times for all of us, and we're, we're all kind of, you know, in the same, let's say, in the same boat trying to figure out some of the more, more, you know, more difficult complexities as we move through this. But really appreciate your perspective and your time today. Thank you. Thanks, Evan. Thank you.