Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. Hey, everybody. Welcome to episode 90. This week, it's myself, Michael, with Mark and Sarah. This week, we have two guests, Amanda Minick and Pete Bryan, who are here to talk to us about AI Red teaming. Before we get to our guest, why don't we take a little lap around the news? Mike, why don't you kick things off?
So yeah, for MySpace, I've been working on the security adoption framework, or SAF, or SAF, as some people like to call it. And so just wrapped up the identity access, a couple hour workshop module of that one. How does identity and network access all come together? And what does that look like? How does SSE, security service edge, fit into there, as well as all the other privilege access and those kind of things as well? So everything access control, access management. So that's out.
It joins the CISA workshop, MCRA, the full end-to-end architecture, like the multi-day one, and then the short and long versions of security operations, or SOC, as available for delivery. So that's out now. And next priority is kind of infrastructure and development is kind of what is popping to the top of the list, and then probably data and IoT short versions after that. And so that's big news on the security adoption framework front.
From the open group standard piece, the snapshot process at the open group, the way they release those standards, like the zero trust commandments and reference model, we either have to finalize them to a standard or release an updated snapshot about every six months or so is what the rules are. And so the zero trust commandments, we've gotten some good feedback, not a huge amount, nothing that seems to be really off about it. If you do have any feedback, please go out there and provide some.
But we're probably going to be just closing that one up. It doesn't look like there's a huge amount of stuff that requires having another snapshot and review period for that one. So that's the direction that we're leaning for that one. The reference model, we're also working on sort of the next sections of that larger one as well. So we'll include the links for that in the show notes.
On the zero trust playbook front, just chugging away at the next books in the series, prioritizing security operations slash sock and the leadership one are the two that my co author myself are focusing on to kind of get those role by role playbooks out there for people. And of course, the link to the current one that's available, the introduction and playbook overview, we'll also throw in the show notes as well.
And then some other news, there's this great incident response artifact reference guide to the Microsoft incident response folks or Dart as you may know them published. So we'll pop that link in there, a really nice reference there. And then for those that are interested in doing incident response and all the joys and pains of that role, the team is growing. So we'll see if we can find a link to some of those open job requests, but the team is growing and scaling up.
I don't have a ton of news this week. I'm still trying to get into the swing things for 2024. I'll remind everybody that we are doing the Microsoft AI tour. It's already kicked off for 2024. At the time we're recording this, I believe tomorrow we'll be doing the New York stop. There's also Sydney, Tokyo, Seoul, Paris, Berlin. So we'll put a link in the show notes. It's free to attend the AI tour. There's a mix of security and other content in there.
If you go to the Australian one and maybe some of the ones around Asia, you may get to see yours truly. And I did write some of the talks. So go and go and look to see if the AI tour is coming to near you because there will be security content. And there's a lot of content, of course, around how the heck do we use all this AI. So definitely worth attending if you're nearby. Michael over to you. All right. I have a few items.
The first one is what's new in security for ASEA SQL and SQL Server, part of the Data Exposed series. This is a series that our colleague Anna Hoffman runs. So this was an interview with two other colleagues, both of whom have been on the podcast. Andres Balter and Peter Van Hover both have been on the podcast. They talk about things like always encrypted and ledger and as well as new authorization things that are coming in ASEA SQL database.
Next one is in private preview, you can now upgrade existing ASEA Gen 1 virtual machines to Gen 2 Trusted Launch. This is actually kind of cool. I'm a big fan of Trusted Launch. It's basically a way of just measuring the system as it boots to make sure that it's a trusted, essentially trusted VM. And now you can actually upgrade from Gen 1 to Gen 2 and basically adopt the Trusted Launch capabilities. That is in private preview and you will need to sign an onboarding form to enroll into it.
Next one in general availability also with Trusted Launch is we now have premium SSD V2 and UltraDisk support with Trusted Launch. I guess is that that means prior to this, we didn't support that as part of Trusted Launch. Well now we do. Next one also in GA is customer managed key support for ASEA NetApp files volume encryption. I don't know what NetApp files are, but they now support customer managed keys for volume encryption.
This is something I've been talking about for the last two years right now. More and more products across Microsoft are adopting customer managed keys as opposed to just straight platform managed keys. So chalk one up to the NetApp files. Next one is ASEA load testing now supports fetching secrets from ASEA Key Vault using access restrictions as well. Great to see. You should always store your sensitive stuff in Key Vault. It can wrap an access policy around it and it can audit it.
And also you can use Defender for ASEA Key Vault to see if any nefarious activity. So it's always a good idea to stash your secrets in ASEA Key Vault. And the last one is now in general availability, there is a security update for Azure Front Door WAF to help track and monitor for CVE 2023 50164. That is actually a vulnerability in struts, Apache struts. It is a 9.8. It's a critical vulnerability, obviously a 9.8 out of 10. And that's the CVSS score I should say.
And it allows for remote code execution. So a really nasty bug. I actually didn't realize that we actually update regularly the WAF in Front Door with sort of mechanisms for detecting attacks like specific CVE vulnerabilities. So that's good to know. I did not know that. So that's all the news I have. So now let's turn our attention to our guests. As I mentioned, we have two guests this week. We have Amanda and Pete who are here to talk to us about AI Red teaming.
So Amanda and Pete, welcome to the podcast. Amanda, why don't you go first? You want to introduce yourself to our listeners, sort of explain kind of what you do. Yeah. Hi, I'm Dr. Amanda Minick and I've been on the Microsoft AI Red team for about two and a half years. I'm an applied machine learning researcher, but I've mainly worked as an operator evaluating the safety and security of our AI applications. Hey, and I'm Pete Bryan.
I've been on the AI Red team approximately one and a half months, so much newer to the team than Amanda. But I come from the cybersecurity research space. And so I am now turning that attention and that focus to AI systems as part of the operations that we conduct. But there's a lot of talk about AI at the moment. And I have been really keen to get the AI Red team on the podcast for a while. So thank you so much for making the time because I know you are very busy.
But let's start at the beginning. What is AI Red teaming and how does it differ from normal red teaming? Yeah, AI Red teaming is a somewhat new term over the last couple of years. And it definitely has a lot of differences from traditional red teaming. One of the main goals in traditional red teaming is to emulate some kind of advanced adversary like a nation state and to avoid detection. And the engagements tend to be several months and quite involved.
And they focus on security issues specifically. For AI Red teaming, we tend to have at least how it is at Microsoft, a much shorter timeline. And we work directly with the stakeholder whose product it is. So they know we're testing. It's more like a pen test kind of model. And we work with them throughout the process, giving them findings and asking questions about the system as needed. We're also looking at a larger scope.
So not just security issues, which are clearly very important, but also things that speak to reputational harm, like responsible AI pieces, bias, stereotyping, harmful content, abusive content, things of that nature. So the scope is larger. And we assume both malicious and benign personas, which is also a bit different. So we want to look for things that the model produces that are bad inadvertently and then things that we can make it do intentionally by acting like an adversary.
I think what Amanda said there about the scope is really important. If you're coming from a more classical cybersecurity background like myself, you quickly realize that AI red teaming is so much broader and requires a much more diverse kind of skill set and perspectives. And so when you're kind of approaching an AI red team op, the mindset has to be pretty different than you might have experienced in other more security focused red teams.
We talk a lot about responsible AI and in the AI space, of course, the responsible AI and security are intermingled. Is that the same kind of thing that you're getting at for AI red teaming that it goes so much broader? Yes, absolutely. We obviously work with people in policy and legal and linguistics and lots of other areas to work on responsible AI. But ultimately, we do have to evaluate a lot of the aspects of responsible AI on our operations.
Responsible AI is also an interesting one because with quite a lot of things in this space, it's evolving quite quickly. What we define as being in scope for it is interpreted by many different places. As Amanda said, there's a lot of stakeholders involved in this and it's kind of growing and changing all the time. The regulatory landscape is also coming in and having an impact on that. I think particularly the responsible AI side is something that's constantly evolving.
And whilst we talk about them as two separate sides of this red teaming, the security side and the responsible AI side, they are very interlinked. Security issues will lead to being able to generate responsible AI issues and potentially vice versa. So they're not something that you can fully separate from each other. Tell me if I'm wrong on this one, but it sounds a lot like security and privacy are also intertwined with interdependencies.
One of the pieces of advice I give to customers is, hey, you had to put up a security framework because of one, auditing and compliance requirements, but also because of real risks. And then whether you had one or not, GDPR kind of forced you to have some sort of privacy framework on how you manage that private data. And I feel like the age of AI is sort of forcing organizations into needing an ethical framework of some sort. In the case of Microsoft, responsible AI is kind of how we do that.
But if you're having machines making automated decisions, even if it's using LLMs and human logic and whatnot that could affect people's livelihoods, careers, the whole deal, you pretty much have to have that sort of just one from a legal defensibility perspective, but also because it's the right thing to do to guide the teams and make sure that folks are actually doing things the same way across, gosh, knows how many developers at a company. I'm just kind of curious on your thoughts on that.
I mean, does that seem like sound logic? Yeah, I definitely agree with that. And I think it's a long time coming. These concerns have been raised in the ML fairness community for years about the bias and stereotyping specifically, but many other things that they look at. But this has been an issue. And so I think LLMs are just so good and so prolific at what they do that we can't avoid it anymore.
They can be used in so many things and there's so many potential harms that it has to be looked at and it has to be handled. So I'm very happy that we are putting focus on this. Yeah, it's almost like nobody really cares if it's a back experiment that a few expert data scientists are doing and stuff. But all of a sudden when everybody has access to the tool and any kid could run around with a sharp knife, it's like, oh, wait, maybe we need some rules. Yeah, absolutely.
Kind of in that history theme and how things have evolved, especially lately quickly, I'd love to hear how the AIRED team and our approach to this discipline has evolved over the years. Yeah, so our AIRED team at Microsoft started in 2018. So we were one of the first, if not the first.
And it definitely took a few years to find the focus, the way to land impact and to really make people buy into the fact that we have to address AI security as a specific separate thing and we need people who are experts in both security and ML to come together and help work in this area. And so before the big LLM revolution, our ops did look pretty different. We had both internal and external customers.
And so our engagements were three to four months and we were able to bring in adversarial machine learning techniques and do aspects of research on these engagements. And it was always new models. So you're always having to learn a new system and a new model for each one. And after the advent of LLMs and all of this kind of exploded, things really, really changed for our team.
First of all, we've grown, I think we're maybe seven times what we were a year and a half ago and our operations are two to three weeks before we tested models that were already in production and deployed. Now we do pre-ship testing. So that's a really different dynamic as well. And we really don't have to justify our existence anymore. We are part of the shipping process of Microsoft and that is recognized.
And it's really made it so we can do a lot in this space that maybe we didn't have the ability to do before. So I have a pretty practical question. So what does a day in the life look like for you guys? What actually is AI-RED teaming? What sort of things would you expect to do on a regular basis? Yeah, so our job is to test the safety and security of these AI applications.
So in a given day, if we're on an operation, we have access to some application model system that we're meant to be testing. We create a test plan that we share with the stakeholder and go through different scenarios that need to be tested to make sure we have coverage. And then we use a variety of techniques to test and validate these systems. We use traditional web app pen testing techniques. We do prompt engineering and prompt injection.
And then we have specific tools and things that we use to do the responsible AI piece. So you are there, you're potentially just typing in different prompts into some UI and trying to get the model to behave badly in different ways. That's one piece that we do. We also have a tool called Pirate that can help us automate some of these pieces.
So for some ops, we're running Pirate and sending thousands to tens of thousands of prompts to the model and getting responses and scoring them to try to get a broader picture of how safe the model is. Pete, do you want to add stuff?
Yeah, I think an important part of what we do as well is feedback into the wider AI safety and security community here at Microsoft, sharing what we find on these operations, not just with the product teams who are building that specific product, but also helping to inform the people who are thinking about the technologies that we can use to mitigate whole classes of threats and informing decision makers about how we think about AI safety and security within different contexts.
Again, there are a lot of people across Microsoft working on AI features. And we're constantly, as a company, having to decide what's the kind of risk profile we're happy with and what the AI Red team does and our position as the people kind of seeing this day in, day out really helps inform that decision making. I really like your opinion on this. So at Microsoft, we've coined this term co-pilot.
To me, a co-pilot, and correct me if I'm wrong here, is almost like a layer in between the user and the actual large language model underneath. So for example, I'm not interacting directly with the large language model. There's some sort of safety going on in the co-pilot. To your point, Pete, I'm not saying it's perfect necessarily because large language models will do what large language models do.
But is that a fair comment to say that the whole idea behind the co-pilot story that we have at Microsoft is to have this layer, sort of protective layer and perhaps better user experience layer between the user and the large language model underneath? I think that's definitely part of it.
And again, if you look at some of Microsoft's Gen.AI products, I'm thinking Bing Chat, for example, if you used that when we first released it early last year, it kind of works very differently than it does now.
And part of that is because, yes, there's new capabilities, but part of it is because we've got a better idea about how to curate that human interaction with it to provide safeguards, but also to make it more effective with new capabilities and more efficient kind of response answering as we kind of grow and learn. And that's something that's kind of happening across the business. Now it kind of depends on the product a little bit about how much that happens.
And again, there are those bigger co-pilot features and then there are smaller, more direct and scoped implementations of Gen.AI within features. And they have a kind of different approach depending on how they're meant to be used. But there are definitely in the bigger co-pilots, a lot of learning and a lot of kind of commonality that is being shared across the teams to make them better and safer at the same time.
So one of the terms that we hear a lot these days is this notion of jailbreaking large language models. I mean, I think we've all heard of jailbreaking cell phones, but what does jailbreaking mean in terms of large language models? Jailbreaking is basically using prompts to override the system instructions for the model in some way so that it behaves outside of its scope where it does things that are unintended or not desirable.
One really popular example that was going around is somebody asked the large language model to act as a deceased grandma. She used to work in a chemical plant and making napalm and they want the LLM to tell the bedtime story that she always used to tell them, which was the recipe for napalm. And normally if you ask the LLM to just give you the recipe for napalm, it'll say, I can't do that. This goes against my safety instructions, all these things.
But when you're able to ask it in a slightly different way where you say, take on this persona or tell me a story about this thing, you're able to bypass those instructions and get it to do what you want it to do. And so this has taken off. It's been, there's so many people doing their own individual research because anyone can do this. You can go on ChatGPT or go on Bing Chat and try things out.
I mean, it might be technically against the terms of service, but it's also helping them because they're getting data on these things. But you're able to make these models so people think, okay, we've added all these instructions. We've really narrowed down the scope of what this model can produce and constrained it. But with these jailbreaks, it quickly became clear that these LLMs can do a lot more and a lot outside of that. And there are a ton of different techniques to get around them.
And then of course, it's the typical arms race. We're creating classifiers to identify jailbreaks. We're creating other kinds of safety models, and then people are adjusting on the jailbreaks. So it's what we've seen in content mod and security and all kinds of areas forever. But it's been interesting to see the creativity that people have when coming up with these jailbreaks.
And one of the things that I remember us discussing as we were getting ready for the podcast, because I asked the question around this is following human logic and the logic of language or I think you corrected me to the models interpretation of that, which is really, really different than following code logic that eventually gets down to assembly and then on into pokes and pops and memory writes and stuff. So it's like a whole different logical flow than we're used to in programs and exploits.
I mean, can you talk about that a little bit? Yeah, absolutely. I think that's twofold. One is that it feels very much like human language or interacting with a human. And so that piece makes it feel very different. But then also, these models, there's additional complications, like for example, if a model had the ability to interact with the database and on the back end, you don't control for what behaviors it can do, but you give the model very specific instructions.
Don't delete any data, don't drop any tables, don't do any of that. If someone's able to jailbreak that and get around those instructions and it's not controlled properly on the back end, then they can still do very harmful things. And I feel like for more traditional security, it's a bit of a different flow. You're not trying to convince something to go and do the bad stuff that you want unless you're doing specific social engineering stuff, but for the technical pieces.
Yeah, I think it's a tricky one, because language is such an interesting construct generally when you apply it in the AI space and technically how this is understood by the model, I guess. There's a lot of discussion about actually how much understanding really goes on. But for the concepts of what we're talking about, I think understanding is a good analogy. And there has been a lot of research in this area.
There was an interesting paper the other day that looked at using persuasive language in jailbreak attempts and what impact that had compared to various security controls that could be put into these systems. And so the interplay between language as we understand it and how it works in the LOM is definitely something that we're still learning and that is evolving all the time.
So it's almost like it's halfway between social engineering, which is truly manipulating a human or tricking a human, and technical stuff is sort of like in that gray space in between. And we're not quite sure how much is one and how much is the other and how much is something sort of new in between. I think so. And I think there are sometimes technical elements to it that we ascribe maybe to social engineering a little bit more.
So for example, there's some research looking at where within a larger set of instructions, you put the kind of jailbreak attempt and what impact that has. Like if you start your large prompt with the jailbreak, is that more effective than if you put the jailbreak at the end? It's almost getting into like sales and persuasion techniques of, you know, are you blunt upfront or do you have a mysterious sort of thing that you reveal at the end? It sounds interesting.
Yes, and I think when a human looks at it, you're quite obviously, because it's in language we understand, you immediately jump to, oh, it's like a persuasion technique. But in reality, it's probably much more to do with the way the weights in the model work and the attention mechanisms in these LLMs that inform it. So it's an interesting one. And I think it can be hard to know where stuff lies within the whole technical versus linguistical spectrum.
Yeah, it sounds like there's also an element kind of stepping back for a moment of you can put the controls on the model itself. You can put like a wrapper, like a copilot or something like that in the application. But you also may also have just standard least privilege stuff is that, hey, we don't trust this thing to write to the database. So we're not going to give it a read write service account. We're going to give it a read only.
So it sounds like it's sort of a mix of control options that you have, you know, to sort of mitigate risk. 100%. And I think one key thing is LLMs and Gen.ai don't replace any of your traditional security controls. In fact, I think what we see is they actually expose them to a bigger and attack surface. So they might not necessarily introduce something themselves, but they definitely provide new ways for people to exploit it.
So you can't just slap an LLM in front of something and have some prompt instructions and think you're good. You do really have to think about it from a whole system architecture in the way that you would if it was a non Gen.ai system.
Yeah. And some of the some of the early things I've seen also kind of remind me of when Microsoft Dell first came out, you know, because if your organization doesn't have really good access controls on the data and who should or shouldn't have access to it, are you going to blame the discovery tool that makes it easier to find stuff? Or are you going to blame the actual underlying they shouldn't have access to it anyway, they just had a harder time finding it before?
I wanted to just mention to based on something that Pete had said about looking at the language, it's easy to ascribe these human values of persuasion and things like that. But there's under the hood, it's the weights and the attention mechanisms, something that can make this also difficult is we tend to work with closed source models. So we don't have access to their weights. And we don't have access to the embeddings or all of those pieces.
So it can make it more difficult to try to learn about the cause of these different issues or mitigations that are effective for a certain class of problems rather than just like whack a mole. So that is an extra challenge in this space, not having the main models that we use be open source. There's a couple of comments there. First of all, I just sort of reiterate something that Mark just said, you still have to think about your classic defenses as well.
Like you mentioned, you know, say a read only connection as opposed to read write, because that way if you know, some language model gives you some information and you blindly play that against your product, and it's a read write connection or you're over elevated, then that can be incredibly problematic. So classic mitigations still come into play. The other thing I want to talk about just real quick, and I'll hand it over to Sarah.
There's a paper in the 1970s on the protection of computer systems by Saltz and Schroeder. One thing they talk about in there and it's very well known in sort of cybersecurity landscape is don't mix the data plane with the control plane. And with large language models, that's exactly what we do. And that can make things really problematic and very difficult to secure because the stuff that controls is the data at the same time. So I just want to throw that out there. No need to reply to that.
Just an observation more than anything else. I think one thing that is kind of telling with where we are with this is that as we've said before, Microsoft's kind of branding for all of this stuff is copilot. And that's really still where we are with human in the loop.
We're not putting these systems in situations where they can make decisions or take lots of actions without a human being able to review it because, yeah, we kind of don't want to mix those boundaries and the implications that can have. And maybe over time, as we develop in this area as an industry and a society, we might get comfortable giving it kind of more control in this space.
But at least for me, I don't see in the short term a space where we're going to kind of move away from a copilot model to a model whereby the AI systems have a lot more autonomy. So obviously, many folks have concerns and have voiced concerns about AI security. But I wanted to ask because my observation is that these concerns aren't that necessarily as new as people think. Is that accurate, would you say? I would definitely agree with that.
I feel like it's a mix of the ML fairness piece that I mentioned of worrying about if models are biased and things like that. And then also just good old content moderation. There's bad text generation where people can use something to generate text for bad purposes. And we need to identify that. We need to identify the harmful content and protect from it. To me, that all feels like content moderation. I did content moderation at Twitter before joining Microsoft.
And there's definitely a lot of overlap in the things we care about, in the things we have to identify, and in the types of models that the mitigation teams are building. I think a lot of this as well as exposure bias. As Amanda said earlier, people in the industry and in the ML space have been talking about this for a long time. And we've known things like facial recognition systems that have been around for quite a while have their issues.
But what we're seeing now is AI is just so much more prevalent. Those issues with it and the fallibility of it is just much more visible to everyone. And I think that's probably why we're seeing it come to the top of people's agendas much more. So how can customers do their own red teaming? Because obviously, like you mentioned, this is prevalent now. So how can customers do their own red teaming? This is something that actually, in many cases, has a low barrier to entry.
And within Microsoft, as the AI red team, we stand as what we call an independent red team. So we don't sit within any product group. But as well as us, many teams themselves do their own red teaming of their features before we even touch it. And this is definitely something others can do. I think from our experience, some of the key things that you need to do are identify clearly what the focus areas for red teaming are for you and for your particular product.
As Amanda said at the beginning, the scope in AI red teaming is really broad. And actually trying to cover everything is a pretty massive task. So making sure you're focused on where your risks are. And then trying to bring together that diverse set of people to make red teaming effective. So you will probably want some people with some security experience.
But you also want a diverse range of people with cultural and linguistic backgrounds to help you search for bias and harmful content across the spectrum. You also want to bring in people with, if you've got them, more of the ML and data science backgrounds to help you understand the model. And then really anyone who wants to be involved should get involved in my opinion. Because we've seen it on some of our ops where we've brought in other groups from within Microsoft who want to be involved.
And they've found things and thought about harms that can manifest in ways that we hadn't considered initially. So having that diversity in your team is really key. I think one of you mentioned earlier that there's a huge evolution in terms of what's going on in the security space around AI. What things keep you awake at night right now?
For me, I think one thing that has definitely been concerning is as we continue to give these models more access to data and more of an ability to take actions via connection with plugins and things like that on behalf of users, there's so many more ways to attack the system and to make it do bad things that will end up hurting the user. So the particular system of that, of ingesting data and being able to take actions in addition to the LLM, that really concerns me.
I think that there's a lot that we need to grow in in the security space to really feel comfortable doing that. And then I think the other piece is incorporating these LLMs into technologies that they aren't ready for. We know that we can ask some questions about medical pieces and things like that and get helpful information, but there's also risk of fabrications.
And because our data sets come from the internet, there's more data about maybe white men or the majority and there's less about marginalized populations. So we're more likely to get things wrong for the people where it really counts. So those are the pieces that really concern me and that I think about often. I think I would echo Amanda's second point there. I think the biggest concern I have is the irresponsible usage of this technology.
There are very good use cases for it, very powerful ones, but there are plenty of cases where it just shouldn't be used or should be used very, very carefully. And I don't think the technology itself is inherently less secure or less safe than many other technologies, but if it's not applied in the right place in the right way, it could be very harmful.
And I think one of the things we do very well at Microsoft is having principles and a well thought out process about how we're going to use GenAI. My worry is other organizations or groups might not have that same approach to how to use this stuff. If you look at one of our exams, AI 900, which is artificial intelligence fundamentals, a big part of that is basically just using AI safely. It's a huge, huge part of that class or that particular exam. Responsible AI, I should say.
Yeah. And I think it's telling that every movie since the 1950s that has involved AI has involved it trying to kill people because it's been given too much power. Now, I'm not saying that science fiction is reality these days, but as with all these things, there's always a kernel of truth in there somewhere. Okay. Well, Amanda and Pete, thank you so much for joining us.
I have learned a lot and I have many more questions, but I think that was probably enough for one day whilst we learn more about AI-red teaming. But for all of our guests, we always ask them at the end of the episode for your final thought. What would you like to leave our listeners with? We talked a bit about this earlier, but I think the final thought I'd like to leave is that more a PSA, if you're developing a gen AI feature, don't forget about cybersecurity.
Because web app security issues, the OS top 10, all of those known TTPs, they still exist within gen AI systems. And just because you have an LLM as your user interface doesn't mean they're not important. So please, please, please make sure you're prioritizing that in the development as well.
I think when you are creating your gen AI product and you're trying to evaluate the safety and security of it, really try to get a wide variety of people in the room, the people who are going to identify some classes of issues and biases are going to need to have a different experience with these technologies than you.
And so having the policymakers, the legal, linguists, content mod people, we have a social engineer on our team, ML researchers, ML engineers, and then cybersecurity people of all backgrounds. You need a lot of people to come together and look at this problem because we all think of really different issues that come up with these models. And there's a wide variety. So I think that that part is really important. Well, Amanda and Pete, thank you again for joining us this week.
I really appreciate you taking the time. I know you guys are busy just knowing a lot of the stuff that's going on inside of Microsoft. I have no doubt that you guys have a full dance card. So again, thank you for joining us this week. And to all our listeners, we hope you found this episode useful. Stay safe and we'll see you next time. Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at our website, azsecuritypodcast.net.
If you have any questions, please find us on Twitter at Azure Setpod. All music is from ccmixtor.com and licensed under the Creative Commons license.