
Listen on Your Favorite App
Episode description
What if the person whose whole job is risk was the most excited one in the room about AI? That's Mea Clift, and it's a pretty refreshing way to walk into all this. She's the CISO of Cengage, where the data she's protecting belongs to students, so the stakes are real. But instead of bracing for what could go wrong, she leans in, she calls it being "risk excited." She and Mo get into why security is so much better as the Department of KNOW than the department of no, how she handles shadow AI without punishing people for being curious, why she'd tailor a framework she already has instead of building one from scratch, and how she ends up teaching security through Marvel and Monsters Inc. Which, it turns out, is every bit as fun as it sounds.
Meet the guest

Mea Clift
Mea Clift is the Chief Information Security Officer (CISO) at Cengage, a seasoned cybersecurity executive known for aligning security strategy with enterprise risk and resilience. With decades of experience, she specializes in governance, risk, and compliance (GRC), helping organizations navigate complex threats and translate technical risk into clear business value.
Full transcript
Why Your CISO Shouldn't Be the Department of No
Curiouser & Curiouser, Episode 13 with Mea Clift
A lightly edited transcript. Disfluencies and false starts have been cleaned up for readability. The substance is unchanged.
Mea Clift: I've never been a fan of cybersecurity, or InfoSec, or however you want to call it, being the department of no. I need to give people the information to make informed decisions. So I want to be the Department of KNOW. I want to say, hey, this system is going to pull data out of systems that have intellectual property, or this system needs access that's going to put us at extensive risk, and here's the risk, here's the impact if it gets compromised, and here's where we need to look at securing it. That's all the informing I can do to say, I'm cool with us doing these things, I just want to make sure we're making the right decision from a risk and a security perspective.
Mo: If AI has ever made you stop and think, "wait, what is happening?", you're not alone. I'm Mo, and I'm a security researcher asking the same questions. On Curiouser and Curiouser, we have open conversations with experts, researchers, and leaders working at the edge of this space, talking through how AI is taking shape, what's shifting, and how the people inside the work are thinking about it as it happens. So join us and listen in as the conversation takes shape.
Meet Mea Clift
Mo: Hello and welcome back to Curiouser and Curiouser. I'm Mo, and you're stuck with me for another week. But this week is made much better, because we're joined by, and I was told not to say this, but I'm going to, the LeBron James of GRC, the Lionel Messi of cybersecurity, one of the top 25 women of all time. I'll say of all time, but it's 2026. Mea Clift, the CISO of Cengage. Mea, welcome to the show. Tell us more about yourself so I don't skewer your intro any more than I already have.
Mea Clift: Hi, hello. Well, thank you. So, again, I'm CISO of Cengage. I've been here a few months, I'm new to the role. It's my second time being a CISO; I was once CISO of a water and wastewater consultancy firm. I've been in cybersecurity for 28 years. I worked my way up from desktop support all the way through, learning all the ropes, servers, everything. I'm in GRC, and that's really where I got my sea legs under me in security proper.
I teach the only hands-on cybersecurity GRC course in the world as of right now, and I teach it for WiCyS, Women in Cybersecurity, and I mentor for them too. I live in the Twin Cities of Minnesota, where I collect antique quilts, and I'm a quilt appraiser for fun and teach quilt history. And I have three dogs. So I'm really excited to be here.
Mo: We're super excited to have you, and such a cool history. But before we go into any of that, I want to hear more about what Cengage is, because I'd honestly never heard of the company. At first I thought it sounded like the N-Gage, which was a definite failure of a device, but a very good attempt at mobile gaming before mobile gaming was mobile gaming.
Mea Clift: It's so funny you say that about the gaming system, because every time I think about it, I think of Picard saying "engage" on Star Trek: The Next Generation. So, Cengage is an educational technology platform. We handle several different verticals: workforce education, higher education, textbooks and the like, and K through 12 education. We even do English as a single language. We support different initiatives with National Geographic and with library systems around the country.
We started as a textbook printing company and worked our way into the digital space. We handle textbooks for many universities, so a lot of people have that. We also have products like Visible Body, which is a mobile app where you can do dissections or anatomy work. So med students, veterinary students, even biology classes, if you don't want to do the little frog dissection, you can do it on the app. So we have a lot of different flavors of education.
Mo: Were you specifically interested in joining Cengage because you too have been an eighteenth-century surgeon, or is that just a coincidence?
Mea Clift: Totally a coincidence. I had a passion for coming into education because, having been a teacher and a student, learning is so important. And I've seen where other organizations have had breaches and compromises, and I wanted to help protect student identities, student data, and the property around it. So it was a really interesting opportunity, and thankfully they let me come on and help protect all of those environments.
Adopting AI in an innovative organization
Mo: You're one of the few people we've had on from an ed-tech place, and it sounds like you have a lot of student data to deal with. So one of the things I like to ask: when AI first started being adopted by orgs, what did that look like for you? A lot of orgs took a governance-heavy approach at the beginning because of the types of data they had, and others took a more innovative approach, innovate first and figure out the problems later. How did it happen for you?
Mea Clift: Our organization is very innovative. We're very much into how we can use AI to shape the future of the organization. So it's been a journey of, what are we doing with it? How can we do it? How can we leverage it to make our environment better, to make the customer experience better, whether that's engaging with support or with our education components? I said this at a different presentation: we've taken a very risk-excited posture when it comes to AI. We're willing to see where it's going to go and how well it can work in our environment.
Mo: Risk excited is one way to say it. Most people outside of GRC, I've never actually heard them say risk excited.
Mea Clift: I literally came up with it on a panel. I was exhausted, super tired, I'd only had like half a cup of coffee, and it was the first panel of the day, and I just dropped it and everybody went with it. They were like, that's a really good term, and I was like, okay, we're doing this.
Balancing risk and innovation
Mo: It makes sense, though. For a lot of organizations, it's, okay, we're going to build, we're going to do it fast, we're excited to build, and there's a lot of risk associated with both the excitement and the technology. So how do you help your organization make the right decisions around risk, so you can minimize the risk part and maximize the excitement?
Mea Clift: It's really the understanding around it. What is the actual risk of whatever we're looking to do? Is it the risk of how the tool is going to work, how we're going to use the tool, what data is going to be provided to the tool? All of those components go into storytelling and understanding what the true risk is. I've never been a fan of cybersecurity being the department of no. I need to give people the information to make informed decisions. So I want to be the Department of KNOW.
I want to say, hey, this system is going to pull data out of systems that have intellectual property, or this system needs access that's going to put us at extensive risk, and here's the risk, here's the impact if it gets compromised, and here's where we're thinking we need to look at securing. That's all the informing I can do to say, I'm cool with us doing these things, I just want to make sure we're making the right decision from a risk and a security perspective, and that we don't get caught in a situation we can't come back from or can't be resilient to.
That's the challenge a lot of organizations are facing. They want the guardrails, and they've started to create those governance guardrails, but now it's, what do we actually need to think about? We've gotten to the point where we're buying all these tools, or playing with all these tools, and now it's, what is the actual impact of these tools? What are we getting in return? Is the juice even worth the squeeze for what we're getting out of it versus what we're sacrificing in risk or in cost? So it's a continuing discussion, and it changes continuously.
Where I was six months ago on how I felt about AI, the question I was asking was, how do you get the data out if you can't remove the data from the model? Well, now the AI companies have gotten smarter, creating individualized model environments for each of their customers, so they don't have to delete their main model to get the data out. They're looking to answer the questions we've been asking as security and data professionals, and meeting us where we are. So I really appreciate that's happening, and what I'm talking about today may be irrelevant tomorrow, because they're going to come up with a different way to protect it.
Mo: I remember when, in some environments, every 30 days they'd basically reset the model, and you'd have to make sure you had all the learnings stored, so you could do this ragtag RAG system where you go back, load it up, and say, here are all the learnings from the last 30 days, stack it on top of this. The context gets huge, and it was very not helpful. Now, at least from the foundation model companies, we're seeing much better ways to manage it, and even some of the startups building memory and all these new functions. It's really cool.
Working cross-functionally without being the blocker
Mo: It sounds like there are a lot of verticals Cengage is involved in. So how do you work cross-functionally with teams whenever a new thing comes up that you'd rather buy than build? How do you make sure they're able to test, iterate, bring new things into the environment, and get the most value out of it?
Mea Clift: You have to work on collaboration. Nobody can work in a silo. In a lot of organizations there's been siloing, where security just hangs off in the corner and comes in and goes, no, you can't do all these things because it's horrible. It's the same with AI, the same with any tool or project. We have to be collaborative and understand what the true problem is and the true concern. And sometimes it's not even a big concern.
If my team wants to be able to impersonate another user, cool, how do we do that securely? I don't just want to say no because it's an access-control concern. We still have a valid use case for it. So how can we add additional monitoring? How can we allow these innovations to happen while minimizing exposure to data loss or risk or compromise?
A lot of times CISOs come into the room and people automatically think, the CISO's here, they're going to say no because it's a security issue. I want to be the person who asks, how can we do it, and how can we prioritize it? For example, we have a large international presence, and some of our people want to use international messaging systems that may be insecure. I'm super concerned about that, I wouldn't want them to use it, but I also understand that in the international construct, we have to allow them to. So how can I let them do it safely? I can add monitoring, I can add controls, and I can limit the exposure to just these systems, for just these people who have to use it, on this device. If we see it being used on other managed devices, then we curtail that and come to a different discussion.
So it's not just saying no for the sake of no, or because the sky is falling. It's, here's how we can do it safely. And what I've found is that if you do it that way, you earn a lot of trust in the organization. Security is sometimes that place nobody trusts, because they think it's just going to come in and block everything. I never want to be a blocker, unless there's something really fundamentally broken. I want to be that collaborative person and earn the trust of the organization. In my first few months, I've actually seen that happening, where project teams and business leads come and ask me questions or engage me in opportunities, because I haven't come in and just said no. If I come in and just say no, they don't trust me, because they're not going to be able to meet their goals. And I have to be there to empower their goals and objectives.
Managing international data and compliance
Mo: That makes a lot of sense. The international piece is where things get very difficult. It really requires everyone to be on the same page. When you have users in different jurisdictions, you trigger different compliance requirements, something you can accidentally overlook, and it may require completely different infrastructure managed in different ways in different places. It also requires very strict policies around role-based access control, how you store data, who can access it, and when. So you have all this regulation around it. I think the reason people default to no is that it's so easy to say no when there are so many rules and people are so afraid of accidentally tripping a requirement. It's like, if we don't tell anybody about it, we can't trigger a rule. So building trust is one of the biggest things you have to do. And the compliance requirements just keep mounting with AI. Over the last four years, every time something happens, we add more requirements. The pace of the technology is so fast that one minute you have access to a model, the next it's too dangerous to use, the next you get it back. Definitely not pointing at the US government. So how does that work within an organization? How do you streamline the knowledge so that as we're building, we don't feel slowed down, we feel empowered by the security team?
Mea Clift: It's meeting them where they are. It's getting on the meetings, talking to them, listening. A lot of what I do is listening. And it's not just looking at the regulation. I'm reading a book right now called Stupid Rules, and it talks about how rules don't solve problems. Rules actually cause more problems, they cause red tape, complexity, and challenge. What we're actually missing is authority.
So I come in and say, you have the authority to make this decision. I'm just giving you the information to say, here's where we need to set a hard line, and here's where we need to find a way to flex and work together. That's challenging for a lot of people, especially those from a GRC or regulatory-controlled background. I find it fascinating when you think about fintech, because they have so many regulations, and so many competing ones. You have to meet NYDFS if you're doing New York work, and your national rules, and your international rules, and sometimes they conflict. So which one is right? And then you scope down to the point that you're only talking about this one little part of the controls, whereas the whole environment could be on fire behind it. It's like, no, this is secure, don't look behind the curtain.
No, all of it plays together and ties together. You just have to be able to flex it, acknowledge where your gaps are, be honest about it, and then compensate for those gaps. That's what GRC should be doing. GRC shouldn't just be, hey, check this box, you're not compliant, you should be fined. It's, you're not compliant here, but here's how you're compensating for it, or here's how you're resilient to it, and here's a thing we need to work on and improve. It's like audit, too, where people think a deficiency is the end of the world. It's not. A deficiency is a place to grow from.
I took up running about a year ago. There are days I run really far and hit a distance I haven't before and I'm super excited, and there are mornings I can barely do the distance I normally do. But I don't stop running because I did a three-mile that day. I go, okay, today's that day, and I still need to keep running, because every day helps me get stronger and move toward the goal. So a deficiency is something to work on to improve your security posture, not just a black spot on your record.
Why you tailor a framework instead of building your own
Mo: I relate to that a little too much. I'm training for a Hyrox right now, and it's the worst thing in the world, a lot of running plus insane requirements for all the obstacles. But going back to building the conditioning around a security program, I remember my football coach saying, keep it simple, stupid, the KISS philosophy, where you make things easy enough to implement that you don't have to continuously think about it. Some of the people we work with have mentioned building their own frameworks to work within their organization, getting the lowest common denominator across everything to make it simple to enable security by default. You giggle, and I want to know why, because that either means this is ridiculous and everybody tries it and it doesn't work, or we're doing the same thing.
Mea Clift: I applaud anybody who tries to build their own framework, but why reinvent the wheel? This is why I'm a big fan and proponent of NIST 800-53. Everybody goes, it's 1,400 controls, it's so much work. But it allows you to build that tailored system. It's something I want to implement here, where we have all the policies controlled at the organizational level. All the main controls are something the executives agree to that everybody has to follow. Then you tailor down to the things that are important to your data center, or your cloud environment, or your office. And then you tailor down to the individual information system. So in reality, you're not answering 1,400 controls. Depending on the criticality of the system, you're answering a hundred controls, two hundred, five hundred. It's a lot easier.
And you can automate most of that now. So it gives you better visibility and control over what's required, but also doesn't ask a cloud environment to answer physical security questions, because that's a shared responsibility model; the cloud provider handles that, not you. It also lets you see the full breadth and gaps of your organization, categorize each individual information system, and do that business impact analysis we're all craving so we understand our critical systems. So you build a comprehensive program that lets you really understand the full risk posture. Everybody's like, I created my own framework with 29 controls. Cool. Does that meet the need for everything across the org? The answer is it doesn't, because each operating system is different, each information system is different, each SaaS product is different, each AI you bring in is different, each contract is different. You have to meet that difference with the framework, and sometimes it just isn't one to one.
The role of GRC in a fast-moving world
Mo: The reason people go for the custom thing is that sometimes they don't know an all-encompassing resource exists, or they decide they want to use MITRE and then throw something else on top, and it feels like a hodgepodge. I'll throw a little shade at AI: I think AI makes it easy for people to copy and paste documents into a folder and say, can you summarize all these and tell me what we've got to do? So, since you come from a GRC background, and GRC engineering has become this amazing new field taking up a lot of career space recently, how do you see the role of a GRC person changing? Whereas before it was more of a consulting role, now GRC professionals are enabled to do more faster, and the teams tend to be smaller but able to force-multiply.
Mea Clift: GRC engineering is that force multiplier, but it's really just APIs going into your GRC, and you still have to understand what good looks like. If you're getting the data from whatever integration you're doing, you still have to understand what good looks like in your environment. So it's not binary. The GRC professional in that situation becomes even more important as the risk advisor, to say, this is the information we're getting, it looks okay, but it's not comprehensive, or here's the gap we're seeing.
In some ways it's really great, because it lets them be a little more technical, learning APIs, pulling in integrations, understanding the software. But it also doesn't change the fact that we still have to document how and why we're using these tools, and provide the understanding of why it's important that we meet the control needs. The engineering doesn't tell us why we need to do this, and the why is so important. There's a whole book on starting with the why. Why do I need to lock this system down? GRC gives you the answer. One, because it's part of this framework, but also, here's the thing, this builds on this, builds on this, and if you don't have this part, you're leaving yourself open to exposure, which opens this risk, which leads to this data, which means all your stuff is out on the internet and it's really bad.
So it becomes even more imperative for the GRC professional to talk in terms of risk and see the interplay between all these things, and not just go, I have this integration and it says I'm compliant. Well, what does compliant mean? Audit is very binary, it's checking the box, saying you have this or you don't. GRC can't be that way. Let me be prescriptive: you shouldn't be that way.
I tell this story to my students. Years ago I had my lawn guys looking at the trees in my backyard. I have a birch forest behind my house, and I had a couple of trees that needed to come down. He was looking at the sky, and I asked what he was doing. He said, I'm looking at the tops of the trees. Look at that one, it's not moving in the wind. All the other trees are moving. That tree is dead and it needs to come down. You want to be able to flex in the wind. If your tree is flexing, it's alive, and it's not going to take anything out. If it's not moving when the wind is going, it's going to be the one to fall, and it's going to take other trees with it.
So when we talk about GRC and security, we can't be that rigid. We have roots, very strong roots, in that ethical and moral understanding of why security is important to us, and that passion that keeps us going. But it also means we have to be able to weave and go, okay, this isn't the biggest risk in my environment today, the biggest risk is over here, so I need to be a little firmer here and weave in the wind over there. That's where GRC professionals are really going to excel.
Mo: I like the tree-in-the-wind example. It's also similar to why we stretch before we run. You don't want those muscles to be tired, and if you can't tell, I'm very sore. But you do want to stretch, so you're able to run without knee pain in the middle of your run.
Mea Clift: Or ankle pain, or side pain. I had a pain in my side the other day because I didn't stretch my upper arm. You don't think your upper arm plays into it, but I can assure you it does.
Teaching GRC through pop culture
Mo: You went into this a bit with how GRC teams are evolving, but I want to go back to something you said at the beginning: you teach GRC professionals. When I started in security, I was focused on AppSec for a number of years, and a lot of what you described, understanding the foundations and how something is built, was a lot about how we do threat modeling and build systems. That's not something GRC professionals were taught at first, but now it seems to be becoming a necessity. So how have you seen that education evolve?
Mea Clift: Really good question. Because of the way I teach, I teach foundationally, and I don't teach to the technology. I teach the foundations of governance, risk, and compliance. And I actually encourage my students to use pop culture as their example. I don't make them find a business or a use case. They're talking about something they can humanize and familiarize themselves with, and that lets them see the risk in a bigger light. They do get some IT knowledge, and you should have some. But I'm not of the school that you have to be super technical to do GRC. One of the advantages of GRC is that you can learn how to speak security, you know how to speak to a normal person, and you can learn to speak technology, or get the technology information from the people you're asking. It's about asking good questions and asking to understand.
So the example presentation I give is about SHIELD from Marvel, an organization protecting secrets and protecting superheroes who are protecting the world. They're a very high-risk organization that has to be very secure. Yet they had an insider risk. In the movie Avengers, they have a guy playing Galaga. That's an insider risk problem, and an unapproved-software problem, because he was able to install Galaga on a workstation on a helicarrier that's protecting the world. Thinking about that opens up a new world for people to go, oh, that's why security is important. It doesn't matter if it was running Windows or SentinelOne. This person did this thing that exposed a risk that could have caused an incident. And then if they want to go learn technology, there are tons of schools for that. I tell my students, go take a CCNA course, go play with Hack the Box or any of the CTFs at different events. Find what gets you excited and fall down that hole. But here's what you need to understand to do GRC.
Mo: I like the Agents of SHIELD example. It reminds me of Secret Wars, when enough information was leaking outside the organization and this alien race was feigning to be other people in the organization. And the Galaga example reminds me of change management, someone introducing new pieces of software: I just wanted to play this, I wanted to try this out. All these things come in, and it's like, okay, we're expanding the threat surface again and introducing shadow AI, and we don't have proper change management, we just didn't communicate it. That shifting behavior isn't a bad thing intentionally, it's just happening, and it's very hard to keep up with. I don't know how to describe the partnership piece, because this could just be a curious engineer versus someone acting with malicious intent.
Shadow AI, and assuming positive intent
Mea Clift: I think you have to assume positive intent as much as possible. As much as we want to think everybody's out to get us, and I personally think like a super villain because of the things I worry about from a risk perspective, I do still have to assume positive intent. They're just trying to do this thing. Even threat actors, they're trying to make money. Is that really a bad thing? Yes, because they're hacking our systems, but I digress. When it comes to people wanting to play with new things, wanting to innovate, doing the shadow AI thing, they're just wanting to do better work. They want to show they can do their best work and come up with great solutions.
So it's the combination of, how do we put controls in place to ensure they can do those things safely, but also make sure they're not going to put us at greater risk? Yes, it's going to expand our attack surface, but everything we do expands our attack surface, even the things we know about. How many tools do we have that magically turn an AI feature on the next day and triple our attack surface because they didn't talk to us about it? Was it the Chipotle one, the burrito bot, that you could get to write code for you?
Mo: Yeah, the burrito bot.
Mea Clift: So, thinking through that, but also being prepared to say, okay, we have to put these guardrails in. Someone mentioned in another presentation, it's kind of like a teenager. You still need to teach them how to drive the car. You don't just give them the Ferrari and tell them to go, because they're going to go super fast, wreck it, and everybody's going to get hurt. You say, let's go to driver's ed, and then we have guardrails on the roads. I remember teaching one of my nieces to drive; she was a baker and kept trying to weave into the right side of the road. I said, no, picture a line of cupcakes in the center of the road that you cannot run over, and keep your wheels on either side of the cupcakes. It's the same kind of thing. How do we teach them to keep the wheels on either side of the cupcake?
That's an education component and that human-risk component. We want to empower people to make the right decisions. That's why we do training, and why we come to them and say, help me understand what you're trying to do and how we can do it securely. And building that trust with the organization, then with the business, then making that example so our customers trust us. That's really what it's all about.
Cyber maturity across the Marvel universe
Mea Clift: Marvel's great in general, because you can actually see cyber maturity throughout the entire MCU, and I love it.
Mo: For some reason, when you said maturity, I immediately imagined that scene after everything happened in Age of Ultron, where they're like, we need a way to understand every superhero, we need to log all of you. And there's a group that's like, no.
Mea Clift: Yeah, the Accords. That goes back to stupid rules, right? Too many rules for these people. But think about it. You've got the Avengers, the insider risk, but you also think about how Tony Stark walked on and basically plugged in a USB drive and hacked all of SHIELD in 30 seconds in Captain America: The Winter Soldier. They're using facial recognition. You have separation of duties, because Nick can't get into Project Insight by himself, it's locked. Except it wasn't locked by himself, it was hacked. But then they use facial recognition and retinal scans to give elevated privileges to Natasha to release all the SHIELD data to the internet. That's cool maturity over time in how they protect it. Then you go to Civil War and they're like, we need more regulation around this, and that becomes a challenge. And then you have Black Panther and all the Wakandan stuff, and even Secret Wars, where the deepfakes are coming in.
I actually just rewatched Winter Soldier on a flight this weekend, and I was like, Project Insight is hitting really close to home, with how this AI is taking all this information about all these people and making determinations on their success or failure and whether they're a threat. That's scary now.
Mo: It's really good. I'm going to have to rewatch some of these movies, because I never thought of them from a cyber lens, but there are so many parallels.
Mea Clift: Years and years ago I did an IG audit, an Office of Inspector General audit, on the Death Star from episode four of Star Wars. That was great, because I ended up in an hour-long discussion with a colleague at the time, this was around 2015, 2016, on whether R2-D2 was a mobile device or removable media.
Mo: To interact with most systems, he had to plug in. I don't remember him ever doing anything wirelessly. He always had to be plugged into something, and that was the only way he got context on a system or made changes.
Mea Clift: But think about this, Princess Leia had to plug a thing into him to give him the message, and then he just played that video of her without having to plug into anything. So it was a transfer. It could have been a mobile device, but he was transmitting a movie. Now he'd just be considered an AI. But at the time, it was a very intense discussion, and super fun. Cybersecurity is everywhere.
Cybersecurity lessons from Monsters Inc.
Mea Clift: My students are even doing this. Somebody did a cybersecurity presentation on Monsters Inc., somebody did one on Bridgerton this year. I was really impressed by the Bridgerton one. So cybersecurity's everywhere if you look for it.
Mo: I'm very interested in the Monsters Inc. one personally, so I'll have to ask you to share that one.
Mea Clift: That one was great. So they have to give the controls that are in place, the policies in place, the categorization, the risk impacts to the CIA triad, and then they have to identify the risk. And the risk was that all the doors were in one facility. It was a single-point-of-failure risk. You didn't have redundancy, you didn't have business continuity. So if something had happened to that one facility where all the doors were, you couldn't get to the other world, you were done. So the proposal was to create a second offsite facility to replicate the doors, or at least split the doors up, so you'd have business continuity.
Mo: There are a lot of places I want to go with the Monsters Inc. one. I really love Monsters Inc. There's almost no access control over the doors. Anybody can get to a door. I forget what it's called in AppSec, but it's basically where you pick an ID and you can go to it. There are no real controls there. I don't ever remember them having to swipe a badge or authenticate to get to a door.
Mea Clift: Well, they had to get through Roz. Roz was physical security. But yeah, no swiping, no access control.
Mo: She walks really slow too. I remember her speed. But anyway, I think that's about the time we've got for today, which makes me a little sad, because I wanted to ask more about your quilting, your antiquing, and how you repair antique sewing machines. But I'll have to leave that for another day. Where can people find you? What are you working on? What's next?
Where to find Mea
Mea Clift: I post to LinkedIn a lot. Every Friday I post Human Fridays, which is just a human-aspect thing, so you can learn a little more about me and what I do. It's completely unrelated to security 99% of the time, and then I post about security the rest of the week. If you want to follow my quilting adventures and my antique stuff, you can find me on Facebook at Patches of Time. And my GRC courses are through WiCyS, with our next cohort sometime next year. I think I'll also be speaking at a CISO Society summit in LA in September. That'll be my next gig.
Mo: We'll have to look out for you there. Until then, thank you so much for joining us today. It was really a pleasure, a very fun conversation.
Mea Clift: Absolutely. Thank you so much.
Mo: Stay curious, everybody. Have a great and safe day, and enjoy your drive or wherever you're listening from. If this episode helped cut through the noise, like or subscribe so you don't miss what's next. Thanks for spending time with us. Until next time, stay curious.
COMING UP
Black Hat USA 2026
Alice @ Black Hat USA - Where AI systems are tested the hard way, before attackers do.
GO DEEPER
A Practical Guide to AI Safety and Security
Discover how to operationalize AI safety and security. Protect your platform from emerging threats and explore real-world case studies, evolving risk surfaces, and best practices for building adaptive safety policies, red teaming, and deploying effective AI guardrails at scale.
Subscribe for new episodes
What’s New from Alice
Why Your CISO Shouldn't Be the Department of No
What if the person whose whole job is risk was the most excited one in the room about AI? That's Mea Clift, and it's a pretty refreshing way to walk into all this. She's the CISO of Cengage, where the data she's protecting belongs to students, so the stakes are real. But instead of bracing for what could go wrong, she leans in, she calls it being "risk excited." She and Mo get into why security is so much better as the Department of KNOW than the department of no, how she handles shadow AI without punishing people for being curious, why she'd tailor a framework she already has instead of building one from scratch, and how she ends up teaching security through Marvel and Monsters Inc. Which, it turns out, is every bit as fun as it sounds.
It Takes AI to Break AI: The Case for AI Red Teaming
As AI systems gain autonomy, organizations need security approaches built specifically for AI behavior. Learn why AI-driven red teaming is becoming a critical defense layer.
Demystifying AI Red Teaming
Your AI passed every check. That doesn't mean it's safe. Learn how to red team AI systems before adversaries find the gaps you missed.