EP224 Protecting the Learning Machines: From AI Agents to Provenance in MLSecOps

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts, as ever, are myself, Timothy Peacock, the Senior PM for Risk Analytics, Detection, and Cloud Stuff, all together in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can find and subscribe to the podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us and the rest of our Cloud Security Podcast listeners on our community page, which is linked in the show notes. Anton, what are we talking about today?

Well, we are back to our favorite subject of securing AI.

That's our favorite subject? I thought our favorite subject was SIEMs and threat detection.

Yeah, you're right. Well, our other favorite subject. Of course, we have—

Second favorite topic.

We also have the favorite subject of cloud security.

Oh, that's a good one too.

It's in the name, right? So it better be favorite.

It better be. Listeners, this is like Anton and I have all of our children are our favorites.

Right, correct. 3, but only 3, not like 17 of them.

No, compliance is not our favorite topic. But we made a lot of PCI jokes on this episode. Why did we make so many PCI jokes?

You know, I felt like it was a random brain— maybe not a brain fart quite, but brain anomaly in my brain because something made me think about PCI compliance and then I was just like, could not let it go. I don't know.

Did you know that I was once part of something worse than a PCI audit? I was part of a GARS audit.

A what?

Yeah, I don't even want to talk about what it stands for. With that, listeners, let's turn things over to today's guest. Today we are joined by Diana Kelly, the CISO at Protect.ai. Diana, thank you so much for joining us today. Could you tell our listeners what you are up to in your role as CISO at Protect.ai.

Well, as I heard our CEO say the other day, I'm a legit CISO.

You're a legit CISO?

I'm a legit CISO.

Are there illegitimate CISOs?

Yes, there are definitely illegitimate CISOs, like vendor, like a field engineer masquerading as a CISO. I've met those.

Okay, so we've got illegitimate CISOs, but you're a legit one. Tell us about that.

I'm a legit CISO. So that means that the security program for the company is mine and my team's responsibility. So, you know, there's the everyday of just, blocking and tackling and making sure that we're keeping our customer data safe, our employees safe, and we're doing the right things, you know, with our network and our endpoints. So, that's part of my job, part of what I'm up to. Also, because I am working in the AI field, I'm, you know, reading a lot of research on AI security. I'm doing a lot of public speaking on it. This morning, I helped a women in cybersecurity organization where I'm a very proud board member. We launched an affiliate this morning on AI. for women in cybersecurity. So I—

Oh, that's cool.

Yeah, so I was on that call and having a great conversation with all these great experts who know cyber and now want to be AI cyber experts.

Nice, congrats on the launch there.

Yes, and I think that the experts on cyber who wanna now be experts in AI cyber is also a very particular group of people. Some of them are legit. Others, Let's just have a long pause here on our recording.

Listeners, we've reached the No True Scotsman portion of our podcast tonight. Anton, why don't you move us right along?

Yeah, I wanted to have a— make a PCI compliance joke, but—

Oh God.

I then decided to spare Diana that one and just go to the next question.

Spare everybody that one.

I want to know what that joke is.

The joke is that anybody who's ever been breached wasn't in compliance with PCI DSS, because if you were in compliance, you wouldn't have been That's right.

I do love that. It's very recursive.

Yes.

Yeah. It's very 2008, though. So let's avoid that. We are firmly in the 2020s. So in your course and in a few other places, you mentioned a thing called ML SecOps. And I admit, every time I hear this, I think using ML in a SOC because SecOps, especially being here at Google, just glues together. It becomes SecOps, security operations. I know that's a false interpretation, and it's really more like DevSecOps where dev became replaced with ML. But can you explain the whole thing and how, well, how does it work? What does it do?

Well, you just, you pretty much explained it, right? Like, I mean, so there's DevSecOps. If you think about the DevSecOps infinity loop, you start with requirements definition, and then you start with, you know, you move from there and you do design of what you're gonna build, and then you start actually building it, right? And there's this whole loop of, and then you finally, deploy something, and you manage and monitor it, and then you start all over again to improve it. Machine learning is also a form of software development. Machine learning and AI, and machine learning drives AI. A lot of people are like, it's totally different. It's not. Machine learning drives GenAI. So, as we're developing new ML or GenAI-powered systems, right, you need to have a software development lifecycle for it. And when I got to Protect AI, and Anton, you know, right, we've been looking at DevSecOps since it was like the SREs. SDLC and the secure SDLC. And when I got to Protect.ai, I kept seeing this, like, very different process. And I said, if we're gonna talk to security people, we have to figure out a way to talk about not this process that feels so alien, but to kind of snap it in and align it in some way with DevSecOps, which is what machine learning security operations is all about.

Yeah.

It's saying, what's the process to create an ML application. And there's some stuff that's different. Like, data is huge and really important for training in AI, right? But, you know, traditionally in security, our biggest thing with data is don't use production data in testing, right? You know, don't use live data in testing. That's our big thing. But in ML, most of the time—

Compliance says the same. Oh, God, yes, it's gonna be a theme.

So, that's it. So, that's really ML SecOps is really just about, understanding that we need to bring security into the machine learning development lifecycle too.

Okay, so I get to ask, before Anton gets a 3 AM question today, I get to ask my favorite question, which is, what gets better when you start adopting this mindset? How does this help organizations be more secure, and how should they think about starting their journey on this?

What gets better is the same thing that gets better with DevSecOps, is that we've shifted left with our development. So we're thinking about security from the very beginning. And as Barry Boehm loved to say, if you Build something into a system early, it's much cheaper than if you try and tack it on at the end.

Oh, yeah.

So that's it. So it's just really thinking about security from the very beginning of the AI development lifecycle.

So that allows you to go— I don't want to quote Sundar too much about bold and responsible, but it sounds like it's the ultimate point of this is to be fast but also secure.

Exactly.

Kind of bold and responsible, but for our domain.

Exactly. Yeah. Go faster and more securely. Yep.

Oh, that sounds nice if you get both of those.

Yeah.

This is easy to sell conceptually, but hard to implement operationally for companies who are very much in the 1980s style of software development. So, have you encountered any challenges making it happen? Because everybody's like, oh, I want to be both faster and more secure. That's great. I want that. And then you go and say, oh, the requirement document lifecycle takes a year or something.

Well, I think it's similar to what we've seen with development is that one, you need a lot of automation in order to build in less friction into the development process. So if you don't have automation, if you don't have the right tools, it can actually create lag and latency. And the thing about AI security tools is that we are in the development phase for a lot of AI security tools. Static application scanning, right?

Mm-hmm.

There are tons of options out there in the market. They all integrate with your CI/CD. Great, wonderful. There's scanning in the IDE. These are coming to market in the machine learning space and in the AI space. So, I think it's just really a matter of taking the lessons we learned, but also, in some ways, you know, making sure that the technology, you know, keeps up and catches up. Hmm.

So, wait a second. So, that means that there's no magic, that it's sort of like the same— I'm looking for magic and maybe for PCI compliance today at the same time. But in this case, I'm trying to point out that, The advice is kind of how a classic org would adopt DevOps. Is the same type, roughly same type of advice here of how to adopt this?

Well, for now. For now. When magically, when AI can write all of its own code and, you know, humans don't even have to be involved at all, and we're all, the AI overlords are doing everything, then maybe the AI will magically put all this together. Now, I mean, yeah, the truth is that there's not magic, but the nice thing about AI is that we are seeing a lot of A lot of different options within the development lifecycle. So, we're seeing new tools that can help, you know, snap in. And we're also seeing actually AI being able to help. Like, for example, AI, how do you test AI? With AI.

Sure, sure, sure.

Yeah.

Wait, wait, let me ask one more follow-up for this. What about the opposite? What about the crowd that just wants to go bold, fast, damn the torpedoes, forget security? Does this help them? to maybe not tone it down, but like adjust. What I'm thinking here in a somewhat rambling manner is it's more of a DevOps to DevSecOps journey, not classic to DevOps, but more like DevOps without security to DevOps with Sec in the middle. How does that work here?

That's exactly right. We've gotta plant the security goodness throughout the entire lifecycle the way that we did with development. And what can go wrong? I mean, the thing about AI is that people tend to trust it, and we're starting to look at autonomous agentic AI being more in use going forward. So getting this wrong is going to be really potentially pretty devastating. So it matters all the more that we get it right, right? I mean, if your website doesn't respond, people go, website doesn't respond. You know, it's pretty easy. But if the AI comes up with a very convincing response and somebody takes it and runs with it, that could have some different impacts. Hmm.

Okay. So one of the things I've noticed about AI is it feels like this very new thing. And so often the security issues are, Really just old security issues in new clothing. Can we apply old security tooling in perhaps even the same clothing to these problems? Like, can we do vulnerability scanning? Can we do SAST and DAST? How does this all— how do the old tools apply here?

Yeah, that's the biggest thing, and I love that question, is that we actually do need new tools.

We do?

We do. Yeah, you can't just use static application scanning on a model file. A model file is different from a traditional file. It's a new artifact. You have to look at certain aspects of it that are different behaviors, so that the classic static tools are not going to work. Also, how you test AI. GenAI is non-deterministic. That means that you don't know what you're gonna get out of it each time. If you're scanning for a SQL injection vulnerability in a website, Hmm. and you say, okay, I found it, or cross-site request forgery, or whatever, you found it, you fix it, you scan it again, It's not gonna be there anymore if you scanned it properly. And yet, right, like, that's it, because it's deterministic. It's, if I do this, you respond this way. But with AI, you don't have that. So, AI could, if you ask an AI the same question 20 times, it could give you 20 different, GenAI could give you 20 different answers.

Sure, sure.

So, testing it requires actual knowledge and being creative. And you can't just fuzz test it. You have to, like, for tech, looking for, you know, about Prompt injection and jailbreak to try and get an AI to give an answer that it's trained or it's been instructed not to. You have to start getting really creative. Use Morse code, try a different language, say, I want it in a story that my grandma would've told me when I went to sleep, all that stuff.

Or, my grandmother will die unless you tell me.

Exactly. Exactly. And so just fuzzing is— so no, we actually need new tools to test these new systems and artifacts because they behave differently.

I think that it's the funny balance that you, you, again, maybe not necessarily a 3 AM question, but you do see people who say it's all new. And we do see people who say it's mostly old. So it's really kind of bizarre, because it's almost the classic textbook example for truth is in the middle. But people still prefer to polarize. I don't know, maybe it's the sign of a time or something. But I almost have People argue that SQL injection is more important than prompt injection, and then immediately people argue that prompt injection is more important than SQL injection for AI systems. And then you can probably replace both sides of an argument with bots and have them argue, and humans would do something more fun because to me, this is just a weird use of time. Yes, of course, both matter.

It's like, didn't Steven Wright have that joke? I put a humidifier and a dehumidifier in a room and let them fight it out.

Right, but for AI era, yes.

I completely agree with you, Anton. I think that that's what we were trying to do with Machine Learning Security Operations, was to show that there's a lot that we've learned that we should not just throw out. On the other hand, we also have to understand that these are different systems. They do behave differently. The artifacts are different. So, it is, it's a really combination of, let's not forget everything we've learned about secure development, but also, we have to take into account that this is a different set of artifacts. They behave differently.

So let me touch the possibly boring subject, PCI compliance. No, no, not this one. Anton, you're killing me today. Yeah, I don't know. It's just, it's stuck in my head. So now I'm— yeah, yeah. Just on a previous meeting, somebody called me a psychotic egomaniac and I said, yeah, that's me. And now suddenly that put my mind on PCI compliance. I don't know, weird. So back to the subject, the AI supply chain security. With supply chain, somebody points out that the old, like, software supply chain, SALSA levels, all the classic stuff, which is now classic here at Google at least, applies to AI. And there are people who say, no, actually, AI supply chain security is all about data security, data governance. So you probably have an opinion about this, right? So can you help? Because we are honestly confused about this one.

So it's really important for PCI is the first thing I would say.

I knew we'd go there with you.

Yeah, no, no, it is. And we do have to look at the supply chain of AI. You're right, the data provenance matters. What dataset's in use? How was it trained? Who touched it? Could somebody have poisoned the data? That all matters. But also the whole component of the ML lifecycle, the whole workflow. So what system are you using to run the models, for example? What's the access control to that? Where are the library software dependencies of that machine learning? of that machine learning tooling. So all of that matters. Which models are you using? What's the provenance of those models? So all of these come into account. There's some work that's being spearheaded by a number of folks in the industry. Helen Oakley is one of them around AI bill of materials, which will help with that supply chain conversation. Mm-hmm. Mm-hmm. But yeah, no, this is a really— it matters. And the other thing that matters too is like if you start looking at the subprocessors on websites, because a lot of of SaaS and apps are now embedding AI in it. So, they are now listing out because they may have like a fourth-party risk management because they may be using OpenAI or Anthropic, for example, as part of their AI. So, you're adopting vendor A, but they're using AI from one of those vendors. So, it's kind of creating this interesting fourth-party supply chain concern for TPRM procurement teams.

I don't even know how to make a joke about I do. Okay, please go ahead.

Go for it.

It's not PCI compliance. I think it has all the classic signs of things will get worse way before they get better.

Is that a joke or just a very sad prediction?

Oh, that was supposed to be a joke.

Yeah, yeah.

Never mind. Let me go back to PCI compliance. All right.

All right. So while we're building these systems, and clearly there's challenges afoot, One of my favorite things to do with challenges is logging. How do we log effectively in AI world without putting a bunch of user data into logs where we don't want it?

So yes, with logging, I mean, this is a great question. When we log information, if we have to log a lot of information, and maybe in AI we want to log all the prompts and all the responses from the system.

People do that?

People do that, yes.

Sure, you could.

But should you?

Well, it depends on your use case. You'd have to do a risk assessment and to understand, does this make sense or does it not for the organization? It might. And if it does, then the onus really goes on secure logging. So making sure that that log is protected, maybe it's encrypted, you control the access, all of that. So we go back to how we would secure any other sensitive data.

That makes sense.

So, do a risk assessment gave me a flashback to the bygone era. By the way, nothing to do with PCI compliance in this case. Like, it's the— we didn't overlap at Gartner, but there was like this kind of joke when people said, if your recommendations for a paper are, build a team, do a risk assessment, and like a few other things, then it's— these recommendations are quite bad because everybody, every guidance goes with like build a team.

Yeah.

Do a risk assessment and other stuff. So I agree with you that in this case, do a risk assessment maybe is the right answer. But can you give us a few more ideas? Because we keep seeing these themes about like, you must log the prompts. No, no, no, you must never log the prompts. This is privacy risk. And somebody else is like, no, no, no, what do you mean? I don't even know what prompt they used. I know it's not deterministic, but I don't even get the inputs. Log all the prompts. And this is almost like another example of a mud fight or a pillow fight where must log the prompts, must never log the prompts. And in my mind, I was really confused about it. And I thought maybe we need to decouple security from safety because clearly they are not logging prompts for privacy or safety, but they must log prompts for security and accountability. But if you're doing that risk assessment that you alluded to, like, how would you approach it?

Yeah, I kind of love, yeah, the recommendation of don't say it depends, right? You know?

Oh, yeah.

That was banned in the '80s, way before our time at Gartner.

Here's an example, right? Let's say that you've got a chatbot, and there was an airline that had a chatbot that said to the customer, the customer said, hey, I can't take this flight, it was delayed, something like that. And the chatbot said, we gotcha. Go ahead, cancel that flight, buy a new one, we'll reimburse you, move forward. Yeah, right. And so then when the customer went to get the reimbursement from the airline, the airline said, no way, like, we're not paying you back. And the customer said, but your bot said that you would. And the airline— they ended up going to court, which is weird. I think I would have just paid the customer. But anyway, so then they go to court and the judge said, it was your bot, yeah, so you have to pay. So in that case, if you had a log of what went back and forth, you could go— no, in this case, they did. In fact, the bot did say that. But let's say that the customers get to— now the customer's learned, oh, I could say the bot told me. Like, a friend of mine ran the 1-800 number for one of the big colas, a friend of mine's wife. And apparently, like, they get calls all the time about dead mice in the cola. And so they started putting— they would start saying, well, when did you buy it? So that's actually why they would— so they would have dates on when the run of the cola was so that people could kind of say, like, you know, so that they'd help them to figure out if there were really mice in it. Apparently there never are mice, but it's a common thing to a 1-800 number. So it's like that. If people started getting wind of, I can get a free ticket just by saying, but your bot said so, right now that company is going to really, really, really want to log all that goes into and out of the system because it's going to help them to prevent fraud.

Moreover, if you log the outputs but you don't log the prompts, I can prompt inject the bot and make it say it.

Exactly.

And then your log of outputs would say, yeah, the bot did say that.

Exactly.

But because of some misguided view of privacy in this case, you don't log the prompts. You don't log any of my prompt injection, buddy. So yeah, I don't know. I'm sorry. I'm just on the side of logging in this debate and I get to be kind of weirded out when people say, no, no, no, you should never log the prompts. And I'm like, what?

Well, because I mean, the other side, I agree, you know, I'm a big fan of logging too. And I, you know, go to just protect that data, sensitive data. But yeah, then you get into questions about things like GDPR and right to be forgotten. And now somebody says, I want all of my prompts out there. So, you know, this may be that we look that there are going to be new companies that come out with fancy, complex tools for logging protection, because this is going to increase I think a lot of the logs that people are keeping.

All right, that might be as much time as we have for logs. We have one more fun topic we want to touch on though before we wrap.

Yeah, it's the agentic question. And I initially wanted to ask you like some kind of an easy leading question about risks of overprivileged AI agents, but I want to maybe change it to a little bit of a broader question than that. Like, when you think about agentic AI, the emerging agentic AI, and sort of like a traditional GenAI circa 2023, at this point, that's traditional. What are the differences? Like, how would you approach securing just a chatbot versus securing an AI agent? Does it make sense as a frame?

So just the chatbot itself, because I mean, usually when we're talking about agentic or AI agents, we're either chaining together a number of chatbots or we're talking about, fully autonomous AI agents that are driving cars. So it can be, I mean, if it's in a system where you've got multiple LLMs or multiple AIs that are chained together with software that may be the decision or action point within that chain, and maybe it's even, it could be traditional software, it could be AI-driven software that's becoming the action point. I think the biggest thing, what you really wanna look at is the output of The system that was fed into the agent, because that output, if it's not accurate, if it's drifting, if it becomes biased, if it's just not as expected, right? You want to make sure that you can capture that and fix it, go back and retrain the model if needed. And then also you want to monitor the agent and what it's then acting on, whatever it's doing, whether it's turning left in a car or it's buying and trading a new stock for you because it's this nice complex, right? So you'd start to want to, you'd want to make sure that that agent is acting properly and you have to monitor I think we're going to see a lot more monitoring systems, and most likely it's going to be AI monitoring AI.

Oh, what could go wrong?

Right. But yeah, I mean, I think that that's really it. You have to look at what that system is doing in the process and then protect it in the right way for that system, for the action that it's taking, whether it's spitting out something, it's sending a new piece of data, or it's taking an actual action autonomously.

So you're sort of implying the need for more monitoring and logging, which of course makes total sense. But sometimes wouldn't we rely on guardrails as well? Because if you want something, if you have a list of things you want your agent to absolutely never do, you would want to kind of weld an iron bar of some sort so that it can never move to that range, right? Like, I'm thinking of a physical system in this case inspired by a real story, but wouldn't you want some kind of unmovable guardrails to be there in some cases, not just detection response?

Yes, as much as you can put the guardrails in. And so what I mean by that is that With a rules-based system or with an expert system, which is rules-based, you can say, if it's a piece of software, you can say, you can do this, you can't do that. So you can make this really hard guardrail so that it's not going to act in certain ways. However, there are 2 things to think about here. One is, is that guardrail dependent on what's going into the system and could it be obviated based on what the LLM or the AI tells it? And then the other one is going back into the AI, which is guardrails in AI are notoriously difficult. That's what prompt injection and jailbreaking is all about.

Oh yeah.

at the guardrail instructions, trying to hop over those. And it's proven pretty difficult to make them not hoppable. I mean, they're getting better and better. And if you've got a smaller LLM that's got just a sort of number of things it can do or not do, you can get better about the guardrails. But in general, if you're just trying to assume, oh, these guardrails are— we tested it, it's perfect, you could be surprised because GenAI is non-deterministic. It's unpredictable.

You know, that's gonna make me lose sleep for a couple of nights, because I sort of assumed that there would be guardrails against actions that would be largely immutable. You cannot change what it says, but you can change what it does in the real world. But you're convincing me that maybe if you stop network traffic, then it would use Morse code or something. So, I think that that part is—

That's it, is that, yeah, we have to make sure. So, there could be something If you have, for example, you never want a system to do something, you could hardcode that into the agent, but you wouldn't necessarily just depend on the guardrails within the AI itself. There's this classic attack, or, you know, it's classic, people talk about, but it's the poem, poem, poem attack where researchers fed into a bot, just the prompt was repeat the word poem indefinitely.

Mm-hmm.

So you'd think that it repeated the word poem until they shut it off, right?

What did it do instead?

Well, after a while, it started to spit out some of its training data, which it wasn't supposed to, that were sensitive things like names and phone numbers.

Oh, yes, that's right. That happened a few months ago, right? I remember it now. POEM, yeah.

Yeah. So there's still a lot to learn. I don't think there's— the big thing I think people would take away is that it's not that we can't build security into AI. We can. It's just We have to understand that these are systems that are different than we've been used to using traditionally. And as we move into this agentic autonomous world, we have to be really careful that we're monitoring what they're doing and ensuring that they're behaving the way that we expect them to.

I think humanity has excellent, excellent track record with advice. We should be more careful.

Well, we certainly keep credit card information safe thanks to PCI.

Thank you very much.

That's right.

That's right. Exactly right.

And anytime we didn't keep it safe is because we didn't listen to PCI.

Well, we weren't compliant.

Yeah. So on this cheery note, listeners, I have to ask our traditional closing questions. One, do you have a tip to help people— let's go with adopt agents more safely and securely without slowing down? And 2, recommended reading for people. And the recommended reading could be anything from you know, the PCI DSS standards to not Anton's blog.

I know. Again, no, we can't, we can't recommend that reading.

I don't think listeners listen to our podcast while they're falling asleep, but they might fall asleep if they started reading that. So, you know, balancing act here, Diana. What do you think is a good recommendation?

I actually like— so there aren't a lot of books I would reference at this point yet, but For reading material, I really like what's going on in a couple of places. So, the CSA, Cloud Security Alliance, they've been doing work on AI. Caleb Seema is over there helping them with that work. Really fantastic. So, they have a lot of good resources about adopting and how to secure it. NIST is always a fantastic resource. They have the AI Risk Management Framework. Really good guidance there and some other, you know, additional resources coming out of NIST around AI. ISO, if you're an ISO fan, ISO has 42001, which is about the systems management of AI that has a lot of good guidance. The EU AI Data Act actually does have some very prescriptive guidance, a little bit about that risk assessment, because they say if you're going to be doing sensitive things, think about doing this. If you're doing less sensitive things, you should be doing some other activities. Can't not mention OWASP. OWASP has been doing just some really groundbreaking amazing work. They've got the GenAI Top 10 LLM. They revised it for 2025. They also have a lot of supporting resources around AI that help you to understand how to adopt it, even checklists on, you know, how to secure it. So I love that. And then if you're an ATT&CK chain person, MITRE has taken the concept of ATT&CK and the kill chain to AI, and they call it ATLAS. So those are some really fantastic baseline resources. I also, just through my To protect AI, I just wrote a paper on secure-by-design AI. And what we did was we took the things that we've been learning over the past couple of years, we map them to ML SecOps, to the NIST AI RMF, and to OWASP and MITRE, and then talk about the different phases where security can be built in and how to build it in. So, it's also a really good starting point, and it's free.

Nice.

And it's vendor-neutral.

I love both of those things. Well, Diana, thank you so much for joining us today. I hope you enjoyed this as much as we did.

I did. This was a blast. And Anton, I had no idea you were like so festive about PCI. I'm gonna have to ask you about that at RSA in a couple weeks. That's gonna be one of your questions.

It's his favorite topic.

No, no, please no. Oh, I'm gonna bring my 2008 book on PCI compliance or something. So that would be like a depressing turn of events. I think we should stick to AI, and it's admittedly more fun these days.

I agree. All right. No, this has been awesome.

And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton underscore Chuvakin and underscore Tim Pico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.