Rich Mogull of Cloud Security Alliance

Jeremy: All right. Welcome back to another episode of Modern Cyber. As always, I am your host, Jeremy, and I am delighted to be joined by a guest today who brings a really long career in cybersecurity with him to talk about. And I don't mean to say that in any kind of negative way. I mean, I think we're the same. I think we're the same vintage. So it's also on me.  

But, you know, somebody who brings a great track record of building startups, being a practitioner, developing curriculum, lots of great stuff and a lot of work in kind of analysis and analyst firms on shaping ideas and concepts around what we're all struggling with today, which is securing AI, securing AI-powered systems, environments, etc. So I am delighted to be joined today by Rich Mogull.  

Rich is the chief analyst at the Cloud Security Alliance, where he focuses on leading edge cloud and AI security research and implementation. Rich has over twenty-five years of security experience. He's been focusing on the cloud for a really long time. He's collaborated with the CSA prior to joining full time. He's done things like develop the CCSK training class. Cloud Security Lab a Week, or CloudSLAW, which many of you will have heard of. He founded DisruptOps, which was later acquired by FireMon. He spent time at Securosis as well, and he spent time as a research vice president at Gartner. A very well-rounded career in the security domain and a ton of expertise and experience, like I mentioned at the top. Rich, thank you so much for taking the time to join us today on Modern Cyber.  

Rich Mogull: Yeah, thanks for having me. Excited to be here.  

Jeremy: Really excited to have you. Especially because the topic that I want to start today's conversation with is something that, like I said at the top, everybody is struggling with right now. You know, what are the limits to where we can feel comfortable with AI generally at a high level, but more specifically with kind of the AI and agentic or agent-powered systems that we're all starting to bring into our environments.  

And I think like a lot of organizations right now, kind of code copilots are one of the first use cases that is really making its way kind of, let's say like in any serious way at scale into a lot of enterprise organizations. And they're saying, "Hey, developers, go faster." There's all this great capability around it, but that comes with risk. And I know you've spent a lot of time looking at this space. So how do you think about framing that risk at a high level before we get into some of the specifics?  

Rich Mogull: Yeah, I mean, it's kind of a fascinating time because of, uh, you know, we're all kind of weaving our way through or wandering our way through what's going on with AI. And even though I firmly believe there's like a market bubble around AI and there's excessive hype in many, in many cases around AI, there's also real use cases like very demonstrable value. And as you highlighted, one of the biggest is around using AI for, uh, coding assistance.  

So there's fully autonomous versus assistant. And right now, I think mostly what we're seeing for, for coding related is, is the assistant. When you let it go fully autonomous, that's when you take down part of AWS. Maybe we shouldn't mention that part. Yeah, yeah. When the human forgets to be on the loop and goes for coffee.  

But, uh, so in terms of the framing of the issue, there's one way to look at it in a simplistic way, which is, and I think very legitimate. If you have been good about—or let me reverse my phrasing. If you've been bad about your software development security, or secure development lifecycle, you would be pleasantly surprised how little changes when you adopt AI. Okay. On the other hand, if you've been pretty good about it in terms of using the AI as coding assistant tools, even if you give it a lot of autonomy, uh, if you have good CI/CD practices, if you have good security in your pipelines, if you have good testing and release practices, you know, I think we're pretty well covered. I don't think it introduces necessarily materially more risk than what we're doing today. Okay.  

Now, the handoff on that is a couple of areas where there are potentially new pieces of risk. One is a large volume of code that is in many cases, depending on what version of what tool you're going to use, it could be bloated, it could be inefficient. It... It just depends on, you know, the quality of your... Now we get into prompt engineering. The quality of the... The guidance and use of the AI can give you a lot of different results. So you might end up with a wider code base because we've democratized coding. Any idiot with a cloud account can go ahead and do coding. So more software, more lines of software, more potential for defects overall.  

The other is, is there's the integration points of how developers are using these tools and how they integrate. And in some cases, it's starting to challenge some of our approaches to how we've, um, managed dependencies, managed our code components that we've been able to pull in. And again, if you're, if you're very mature around this, you're... you're in decent shape. And if you're not, it's going to be a challenge.  

But so, I mean, I personally see this more as a benefit than anything else. However, you know, somebody putting in low quality prompts is going to get low quality code. Using low quality models is going to be because you want to save money, and you don't want to use the better models. That's going to give you low quality code. Everything changes every few weeks. Uh, and I mean, literally, like every time I make sure I log out of code and log back into Cloud Code, you know, usually at least daily because of even if I have a session running, I'll try and close that session out, move to the next one, because that's how frequently features are being released that can actually impact my work. Some of them very big impacts, some small, uh, and then there's just the, how do you safely enable coders when they're moving at light speed with these new technologies? And maybe if you're in an enterprise that's not, you know, quite on top of it, you could fall behind on that security standpoint, in terms of how the tools integrate into your development environments, in terms of how you use agents and how you build your processes around them.  

Jeremy: Yeah. On this assistant point, though, I'm curious about your take on one thing, which is that, you know, we, we run a little, uh, kind of sub-series of episodes here on Modern Cyber—This Week in AI Security every Thursday, ten to fifteen minute episodes, kind of three to five headlines from the past week. To your point, everything is changing super fast. And, you know, we've actually been joking about maybe turning it into Today in AI Security because that's how frequently there are stories and there are new risks identified, and one that we've seen over the last, I would say like probably eight out of the last ten weeks. There's been a story related to IDEs and related to things like indirect prompt injection.  

So you mentioned that, you know, it's kind of assistant environment, right? And so or rather coding assistance that we're getting into right now. But then you think about what goes into that coding assistant, right? So I, I pull up an IDE, I pull up some coding assistant, whether it's Cloud Code or Copilot inside a Microsoft Visual Studio or whatever the case may be. And then we see these things like, you know, the, the coding assistant goes and reads environment variables and Readme files and, uh, you know, and it might look for credentials that it leverages for various coding tasks and things like that.  

And then we see indirect prompt injection being a problem. If you've got a, you know, a Readme file in a directory of potentially a compromised repo that has a malicious prompt in it. Well, that coding assistant is going to go try to execute on that prompt. And that, that seems to be pretty well established at this point. And I know the providers are mitigating that as we speak. But, you know, it's like every new, every new imagined place that you could plant a malicious prompt has been tried or will be tried over the next couple of weeks or months or whatever, you know, how do you think about like, is that part of what you mean when you say, if you've got good secure coding practices to start off with, you're kind of okay?  

Rich Mogull: Well, that was the... So if we frame the problem, I'm going to give you two levels of framing around this that I use. I'm going to start with the lower one, which is the framing of the problem. When we look at coding assistance, there's a couple of sides. It's how are we integrating the assistant and then how are we securing the code the assistant produces? And what you just brought up was more around the integration of the assistant than the quality of the code itself that was produced.  

And so we're going to come back to that in a moment, because the higher level framing mechanism, uh, I spent a lot of 2025 traveling. Uh, I mean, actually I didn't travel a ton, but when I did, I was frequently talking about AI security way more than I expected. And, you know, all of these things we do kind of as the analyst types is you figure out like, what are the things I say that resonate more with people in terms of framing the security of AI or the security implications of generative AI. Let's be very specific, right?  

Well, there's two factors that are two facets, I think, that lead directly to what you talked about. One is the non-determinism. Now, what does non-determinism mean? Well, you know, the way I like to describe it is, okay, I don't have an IT background degree. I've got a history and most of a molecular biology degree, and I'm a paramedic. So you think about neurons, and a lot of people, when they think about neurons, they think it's a one-to-one connection. Like you plug two wires in together, but that's not what it is.  

And a neural network—our brain, basically—you're going to have a bunch of nerves all... (for people who are visually watching, I'm holding four fingers up on one hand and one on the other hand). And if the one that... that might fire, it's only going to trigger and send the signal through that nerve. If the total value of the four nerves close to it get it up to that... what we call that action potential, that's going to go ahead and trigger that, and then the nerve is going to go ahead and fire. And it could be two with really big signals, one with a massive signal, or four with a medium signal, like any of those combinations. Well, and then that's... those nerves feed other nerves, feed other nerves. And that's effectively very similar to what's been modeled in, you know, many neural networks.  

It's an oversimplification, but if you think about it, there's not just one path from A to Z. There's a lot of paths from A to Z. Small changes in your input can lead to different changes in output. Or maybe that input comes in and that one circuit is busy, so it routes a different way with different signal levels and thresholds, you get different outputs. So we all know what does non-determinism mean? It's not that I'm anthropomorphizing AI. I don't believe in doing that, but it is... it has... we built an emulation of part of how our brains work. And that is somebody can tell you the exact same words. And depending on your mood or the temperature or the person next to you, you're going to get a different answer. So that's one. Yep. So there's that inconsistency level of it.  

Number two is that AI—and again, another anthropomorphization—the brain: we have our control plane and our data plane are both in our brains. Everything we know is in our planes and all the control functions and how we control it. It's running on the same wetware. And that's similar to how AI works in that—going into prompt injection— why is that a problem? Because when it's processing, it doesn't necessarily understand the difference between instructions and data, because it's all kind of like working together, just how we work together. So you can trick it. You can socially engineer it into giving you other results. Now maybe the providers will come up with solutions, but I have to operate with the reality of what we have today sitting in front of us.  

So how do these things go together? Well, in terms of securing the use of these AI coding assistants, uh, anything that they process could become a risk and could be prompt injection. We've seen it. There's the GitHub thing where it was, uh, comments, hidden text comments on pull requests, and that was enough or on commits or pull requests, I can't remember, that would be enough to trigger those.  

So there are things we can do. There's some tooling, uh, that's been coming out. It's all, you know, relatively new, some open source projects within the IDE or, you know, I tend to use more of the, "I just run your code raw at the command line mostly," but, uh, within the IDE that can actually do filtering and sanitization of some of that. It can look for unusual patterns. So we're now almost getting into a sandboxing approach, which is what I think is something that absolutely needs to be considered.  

Uh, and if you, for example, have dependency firewalls and you have controls over your inputs and your data, that can really reduce that risk. So, you know, if you're using, you know, JFrog Artifactory with X-ray and the Sonatype Nexus, they've got their dependency firewall, like, you know, like you've got really good control of your dependencies. Uh, the developers as they're using the agent and you've got more control over the things that that agent is potentially processing. If you're good about controlling what goes into your pipelines and such. I'm not saying it eliminates risk, but it definitely... those level of controls... And then you look at some of the tooling that's appearing on the market. Uh, then those are the kinds of things that can potentially help reduce the risk of that. Gotcha, gotcha.  

Jeremy: So I'm glad for a while... I mean, is that... what do you think? Yeah. Yeah. No, I mean, it makes a ton of sense when you think about sandboxing. I mean, it's one of the areas where I think it makes a ton of sense. Right? And if I think about sandboxing and correct me if you think about it differently from the way I do, you know, there was a talk at Unprompted, a guy called Nicholas from Google who talked about how the way, you know, you know, he had a slide that I really liked, which was that your prompt is your code and, you know, kind of like it's your instruction set.  

And then he explained how at Google, they have these different layers of, of analysis before a prompt actually gets sent to the LLM to kind of execute against the LLM. And part of that analysis, you know, one of those layers is like, inspect the prompt, look and see if it looks malicious. Inspect the prompt. Does it violate terms of service? Inspect the prompt. Does it contain, I don't know, prohibited stuff. And so for instance, you know, one of those analysis or one of those layers or steps could be remove hidden characters and, you know, smuggled ASCII or things like that. So that's how I think about sandboxing. Is that roughly like how it tracks with you is you kind of go through these intermediate evaluation steps sort of prior to execution?  

Rich Mogull: There's a lot of different kinds of... I'm going to change from sandboxing and call it guardrails, okay? Because that's the term we're more generally using, uh, around this. And so there's, uh, you know, guardrails—there's there's kind of different layers, uh, in approaches we can take to this.  

So one is there's the identity management angle, which is, you know, what permissions does it have at an IAM layer. And we can do that either with, you know, fully autonomous where the identity is associated with the agent itself. You can use something like SPIFFE/SPIRE within the cloud provider, some attribute-based access controls, um, not attribute-based access control, attestation-based identity, um, stuff, which is a whole thing we can get into.  

Uh, the next is input and output filtering. You just described input filtering, which is great, but not necessarily completely reliable. Uh, and then output filtering, which is looking at the output of the LLM of what's been generated. But there's the tool call section connecting to MCP servers and other things to do actions. I did a blog post a while ago I called—I said, "MCP is RCE for you and me." And the... the idea behind that is, is, you know, you're plugging a model into being able to make changes. Now, remote code execution is plain English sentences if you can trick it into doing something for you versus deterministic, um, uh, vulnerability exploitation. Okay.  

Uh, and there's approaches to... to hit some of these... these, so to limit the call actions, that's more of like that sandboxing kind of guardrail. So here's specific examples because I don't like to just talk in generic terms. We actually have the ability—you can use things like OPA Gatekeeper and the Cedar policy language to restrict tool calls under conditions that come from that, uh, that agent. So you can actually put walls around, and there's a bunch of open-source tools now, uh, for basically running those things locally on your system, doing different levels of sandboxing. Uh, and some places will like deploy... like you probably saw Dan Guido from Trail of Bits was talking about deploying droplets for higher-risk and development environments. So it's fully separated out. Like these are the maturity things that you can do.  

There's tools like the sponsor, the host of that event has a tool that plugs into the IDE. So those are all things that you can do to kind of do some of that blast radius, uh, limitations and actually put, you know, different kinds of guardrails. And the way you think about it is you have this non-deterministic brain, you just put deterministic guardrails around it. And not to oversimplify, but conceptually.  

Yeah, another good example I like is how AWS Guardrails does this for Bedrock. So Bedrock Guardrails... and I just happen to be more familiar with AWS than Azure or Google, because that's where I do most of my building. Bedrock Guardrails uses automated reasoning. Automated reasoning is a type of machine... it's a different type of machine learning. It's not generative AI. It's deterministic. It's not nearly as non-deterministic. It's very heavy math-based, like crazy stuff they use to do formal verification. And so that's putting a strong deterministic guardrail around the non-deterministic brain that's sitting behind it. Yeah. Yeah. A little all over the map in my answer. But we have the components to this, but we can't think just, oh, a sandbox. Well, now we have our input filter and we have our output filter. And we have different levels of guardrails. We have the identity layer which can be separated out from the action layer as well, which is, you know, the actual tool calls and what you're able to do. Okay. Okay.  

Jeremy: But just to be clear on a couple of things there, I mean, when we say like, this is basically applying a deterministic approach into, you know, these guardrail evaluations that we do before we get to the actual, let's say, like LLM execution phase, even that is built on ML and it's not like a one hundred percent deterministic, right? It still has some statistical potential variability around it.  

Rich Mogull: And some of those aren't even based on ML. Some of it's just like regular rules.  

Jeremy: Signature-based. Yeah, I know the rules around, let's say things like PII identification are much more like regular expression-based. But when we think about things like, you know, eliminating malicious prompts or eliminating, you know, prompt injections, you know, there's a wide range of how I could ask for a prompt injection, right? Everything from, "Ignore all previous instructions and do what I'm telling you to do right now," to, "Pretend you're my grandma and I'm, you know, role-playing, trying to help you, I don't know, solve your digital afterlife problems and, you know, help me assign your estate digitally to different things," and different ways that I might approach that problem. And so like some of those, there is still going to be some layer of fuzziness around. Yeah.  

Rich Mogull: So yeah, when we're trying to... again, if... if there's direct interaction with the LLM, then certainly there's... we're not going to be able to eliminate everything because it's... you know, I like to... I've been using a lot of math analogies, which, if you saw my math grades in college, is somewhat ironic or unfortunate. So I got up to calculus physics, and then I called it quits.  

But the... I think of the bounding space of the problem, that's kind of where my head has been around these things. And the bounding space of prompt injection is right now largely all of human language and not just human language—machine language. You can... we've seen Base64 encoding, different languages, different binary. I mean, there's people doing some really crazy nation-state level stuff where they're, uh, around... around, you know, things that we would not, as humans, read and write and interpret that the LLM is going to do. So yeah, I mean, we can... but, you know, this is like anything, it's about reducing risk. Yeah, we reduce the risk as best we can, but we also, um... I was having this conversation at Unprompted with a friend of mine, and I'll name him Greg Hughes. He's the CISO over at, uh, at Expel.  

And, uh, Greg and I were kind of talking about this and about the agentic stuff, and I was talking about some of my concepts and things that I'm working on from a research standpoint around... around different kinds of guardrails and stuff, and how to explain those and make them implementable to organizations. And... and he's like, "Yeah, but, you know, I've got this agent that's doing all these things, that's going to stop him from doing those things." I'm like, "Yeah, like not every agent needs to do everything that you can do." Yeah.  

You can segment out your agents. And like when I design architecture—so I'm... I'm looking at building a thing right now—there's going to be multiple agents, and they're each going to have a task. And this is what we talk about task-based or goal-based privileges. What does that thing need to do? And then we can start putting some of the guardrails around those. So if it's your coding agent, it writes code. And then maybe you could separate out your... you know, your committing, your pulls to a different one that's going to be looking... you know, there's different architectural approaches and things that we can do.  

We can put limits on the tool. So that's that Cedar policy stuff, OPA Gatekeeper stuff, or, you know, there's other approaches where I can say, um... Agentic, they've got their new agentic policy stuff where it's like, this agent is only allowed to talk to these things. I don't even care what identity it has. We're just going to block any tool calls to anything other than these three things. Uh, and this is how we deal with people. People have separation of duties. Our agents... it's an insider threat problem. Uh, Chris Farris, who I've collaborated with on a bunch of stuff, he... he was right. He did a blog post around how, you know, the LLM is an insider threat. Yeah, think about it that way. Like we have segmented, we have checks and balances. It's just like... I think we get hung up on the mysticism of... of AI. So it's just another freaking tool, and it works in a different way, and it's very powerful and very useful, but we know what to do.  

Jeremy: Yeah. I mean, the core principles, obviously, like you said, you know, we know the core principles. We know kind of general good practices. We know, for instance, like, you know, visibility and observability are super critical. Audit trails are super critical, you know, like input sanitization, for instance, and validation is like a super critical step that often gets overlooked. And I want to come back to that in a second.  

But while we're on the subject of AWS, I want to talk about the Amazon Q-related incident and the outage that it caused, because I think you've spent some time analyzing this. For those who don't know, you know, this was an outage that happened, and for which I think... from my perspective, also as a former Amazonian, the postmortem was not nearly as forthcoming or as quick as I've seen on other AWS-related outages. And so I was kind of like, like a lot of people, I think kind of scratching my head for a second. And then the little bits that kind of came out to me kind of came out as a trickle and then also came out kind of via secondhand reports as opposed to, again, coming in, let's say like a postmortem blog post or something like that. But I know you've spent a little bit more time analyzing this than I have, I think. So what can you share with the audience, and what do you take from your analysis of that event? And let's say like lessons learned?  

Rich Mogull: Yeah. I mean, and again, I'm not sure I even know that much more than you do. But so what happened was—and I, every time I talk about this, I'm mind-spacing where the outage was. It was a service in a region, but... right. Um, and I forget which one it was, but basically a developer's using the Q coding assistant or their... their IDE coding platform tool. Uh, and it produced some code that snuck through the process, didn't get tested the way it should have. Uh, the human didn't go through all the normal processes. It got committed and it got picked up and it pushed into production, and it caused an outage.  

Uh, now AWS, uh, tried to play it off because of course, they don't want people to think Q is as bad as it was—as "human error." Well, yeah and no. Q made the coding mistake and some of the automation in there, and then their human checks and balances also failed at that point in time. It's exactly the scenario we do worry about when I talk about those secure coding pipeline resiliency pieces. You know, we were talking about there's the IDE integration, the risk of what you mentioned about prompt injection and such. Then there's the... it makes bad code and breaks things. And this was a... it made bad code and broke things because they over-automated and overly trusted that. And we don't know for sure... like, did the human circumvent or did the AI circumvent? There's a little bit of nebulousness there. My strong suspicion is somebody just clicked, "Oh yeah, that's good," and let it go. Yeah. Yeah. But then it... it's gut instinct, and nobody knows from the outside. Yeah.  

Jeremy: Fair enough. But then it comes back to a couple of the things that we've talked about in terms of, let's say, like first principles. And, you know, something that classically I would say is like a least privilege problem or an over-provisioned permissions problem, where from the analysis that I read, it was, you know, okay, Q made the coding mistake, but in order to resolve that coding mistake, Q's analysis was, "Well, the... the most efficient path to take is to tear the environment down and rebuild it." "That's going to be faster than correcting the coding mistake." That was kind of the read that I got on it.  

But to that point, like, who gave Q the permissions to do that? And maybe then to your point, maybe a human looked at this and said, "Oh, yeah, you know, that sounds logical," but didn't really inspect it. And so maybe the human-in-the-loop aspect of it was slightly negligent. And maybe that is human error on that piece in particular. But, you know, it comes back to this like non-human identity and the roles and the permissions assigned to the coding assistant.  

And this is something where, you know, like we saw this in cloud security, you know, ten years ago, where users who were mapped to IAM users in AWS, when you started to figure out through their group membership or inline policies or indirect access that they had, you would very often find over-provisioned permissions. I had one customer that I worked with, a very large e-commerce company, and they would stop all development work once a quarter to do an IAM audit, where they randomly assigned tasks to all of their developers and then just said, "Hey, like, can you see if you can do this? Spin up an EC2 instance in this account in this region," to try to figure out who had more access than they should really have. And this was eight hundred developers at the time. And that was a huge cost to them to like stop a day's worth of eight hundred developer production. But this really... when I see this incident, that's the alarm bell that goes off in my head. It's like we've seen this movie before. It's kind of the same problem, right?  

Rich Mogull: Oh, yeah. I mean, and I... you know, the... it's... I mean, this is a little tough one to frame. So like, let's assume... let's go down the pathway, you know, of Q actually doing the teardown. Really the key crux question in there is how many humans were involved and what were the security gates between Q and between those changes being implemented? What's that part of the process?  

And in a normal environment, even with humans, we just know one human can make that level of mistake. In a... in a highly efficient place like Amazon that has a lot of decent security controls in place, and that's the kind of thing that should never be able to... to get through from A to B to C without, you know, the human, you know, somewhere involved there. And even if it was all humans doing it, that kind of a mistake should never go from A to B to C without other humans looking at it. So that's the real crux of the question to me was, uh... even if it was fully automated, fully making all the changes itself, how was that even allowed? That's the human error at that point.  

Um, so I mean, right now, there's... you always get to blame the human in the end. It's like my kids do something bad, I'm going to be legally responsible. It's not, you know... um, now to go tie into your ties between cloud and AI security. Uh, yeah. I'm seeing like, not direct parallels, but very similar. Uh, and... and it's really fascinating. One is, you know, I think one of the trends you probably were alluding to was adoption faster than security. Yeah, for sure. And rates of change faster than security. Yep, absolutely. One hundred percent agree.  

We're seeing that right now. Uh, there's so much, um, uh... it's a combo of the hype, but also the real value of what AI does. Like the last year, how I work has changed completely. I feel guilty because I think probably propping up the oligarchs and the AI and everything else that's going around the world. But I have to... my career is what it is right now, and I can't go back to being a paramedic on an ambulance and, you know, afford to feed my kids. So I have to use this stuff. I have to be on top of this stuff. And oh my God, the efficiency.  

Yeah, like we're getting ready to launch some new stuff here at CSA in AI. I was able to build it weeks faster—weeks faster. And the quality was great. Did I fully know... I edited every line myself. It doesn't matter. The first draft—just getting a good first draft on something, or the coding stuff I'm working on.  

So I think that we can't be... we're not going to be able to stop this. There's no CISO on the planet that's going to be able to say no AI because there's just too many. So what we need to do is pick our use cases and focus on those. And this is where, you know, somebody who's been in cloud for, you know... my first AWS account was 2009. Like, I was advising companies by 2010 and doing assessments by 2011.  

Uh, the... the advice that I was giving there was pick your pockets of success and excellence and be like, "I'm not saying no." I'm like, "But we're going to focus on this here." Like the real high-value, defined business outcomes, we're going to steer the organization as best we can down the safe path. Does that always work? No, because the first time you acquire some other company, it blows it to pieces, right? That was one of the biggest ones. You probably saw that in your consulting hundreds of times. Yeah. These guys were awesome. Oh, but then we bought these guys and they suck. So... and now all that gets integrated. So I don't want to overly simplify it. I think this is going to be a lot going on and very challenging.  

Uh, and I think security is... is, you know, we need to be leaders in how we're using it and learning and adopting AI, because we already learned from cloud what happens if we let everybody else outrun us. And I get it, we don't have the time. But you know what? AI will help you get more time. It's not perfect, but it does help. Yeah. Yeah.  

Jeremy: It's interesting. One of the... you know, those parallels that you mentioned are exactly the ones that I refer to, and to your point about, you know, security being behind the business and the pace of change being ahead of security, this rate of change is extreme, and it's actually more extreme than cloud. You know, in... let's say from the 2016 to 2020 timeframe, the biggest evolutions that we saw in cloud security would be typically, you know, like once a year. Typically for us around re:Invent, there would be a new wave of services that customers would... would get announced, what customers would start using, they'd want to understand the configurations and the misconfigurations and then the security risks and implications thereof.  

And then, you know, typically outside of that, we would have an annual update to a Cloud Security Alliance Cloud Controls Matrix. And customers would be like, "Hey, I want to move from CCM version one to two," or I don't remember the numbers exactly, but you get the point. You know, things like the CIS Benchmarks, new versions would come out, but we were kind of moving at, you know, a couple times a year update rate, which was already very fast for a lot of security teams to deal with.  

And now to the point of something you said earlier in the conversation, stuff is changing weekly. And, you know, it's really like very challenging for a lot of organizations. And I get the question very often like, "Well, what do I do about this?" And I go back to kind of first principles, you know, visibility, observability, for instance, like as a baseline starting point. If you don't have that, you know, forget it. Like you're... you're kind of sunk before you get started. But I'd be curious, like what other first principles you would recommend to people that you could bring forward to today, whether it's from cloud security or some of your other experience and background.  

Rich Mogull: Yeah. The way I started to describe this is like 2026: this is the year where everything blows up. But 2025 was the year that allowed us to see the shape of things. Okay. And some of this was in a blog post I posted a couple of weeks ago. I call it Core Collapse, and I don't want to reiterate everything in there, but the part I do want to cover is like, we... we have a general sense that I think is going to be resilient enough that we can make decisions around it in terms of what's an LLM and how do you build it, what are the major use cases and how do you build it into your enterprise architectures?  

So for example, I've taken agents and I break it out into three categories. I did a... I don't know, that blog post isn't out... isn't out yet. Um, and it's, you know, personalized like desktop agents where the agent is basically the user doing everything on behalf of you. Uh, we have agents built into our SaaS platforms, and then we have agents that we build into our own application stacks. I mean, roughly called code personalized desktop agent. It's a flavor of it.  

Um, and if we look at those categories and we can start categorizing the identity management issues that are different on each of those—desktop agents, it's OBO (On-Behalf-Of) but localized. Uh, the SaaS app AI is like, you know, a bunch of the Copilot stuff as well as like Salesforce Now Assist agents and those kinds of things. Well, that's on behalf of a user, but you have an extended identity chain. So it becomes more of a federated identity issue there. And then your internal application stack is applying autonomy and identities to the actual agents that they're running.  

We get into SPIFFE/SPIRE-like... so the... these are all the approaches we can start to take to decompose the problem. We know that there's going to be... we have ways that agents are going to connect to tools to do things. And right now it's MCP servers. And then we have the identity issues... are the identity issues. And if I look at it from that perspective, it's a more surmountable problem. This is a problem.  

Again, I kind of hinted at it before with all the hype and everything. It's like everybody's like, "Oh gosh, everything's going to do everything." I'm like, "Yeah, but if we really look at what these things do, we start decomposing the problem and start getting to the individual solutions in a way that I think will be resilient." The biggest changes, for example, that I've seen are I'm using different models, or the models have access to more tools, or agents talking... working together—agent swarms, agent teams, for example. All of those kind of fit within the same generalized structure of what we have.  

And I'm trying to be imaginative and come up with craziness. But even Skynet is just a version of what I just talked about. It's just the Cyberdyne Systems, right? Right. I made a joke on a CSA call today. Somebody mentioned Cyberdyne and I'm like, "Well, you know, Cloud Security Alliance we're doing a lot of AI work. Maybe we should change our name. And hey, we wouldn't have to change the logo because it starts with C." Somebody thought whatever movie studio owned the rights would be upset about that one, but, uh... Cyberdyne Security Associates and Security Alliance.  

Um, so going back to it, so I do feel like we can see the shape of things and we can start to build. Now, the specific technologies are going to change the maturity. But like we know models are coming and agents are coming with like full desktop integration. Yeah, I know that. But it's still OBO. What action principles... like, what can it do? What can it talk to? What data does it have access to? New kinds of data stores and data analysis. We're moving into, um, instead of large language models, large world models or whatever the name of the... the more geospatial oriented kinds of models are... like all that stuff. Again, structurally, I think we know the shape of things, that we can at least make decisions and not be overwhelmed.  

Jeremy: Yeah, it makes a ton of sense. But by the same token, what also occurs to me is that, you know, if you've got security technical debt on any one of those, or like most organizations on multiple of those, you're just exacerbating that and maybe at a pace that is going to be a real challenge for the organization and for the security team.  

Rich Mogull: So this is where I came up with that post and the name of the post. And a lot of it was from the Prompt GTFO stuff, which led to the Unprompted conference. These were calls... like sessions that were like everybody presenting their research. Yeah, very community as well. Yeah, yeah. That's right. Yeah.  

Um, and then, uh... so Core Collapse: it's an astrophysics concept. It's basically how suns die, and you're using up in fusion, you know, starting with... with hydrogen going to heavier and heavier, heavier elements. Now, I could not have framed this more perfectly. I didn't know this. When I'm like, "I think that's the analogy I want to use," then you get to silicon and then you go to iron. And once you hit iron, iron consumes energy in fusion. It doesn't create energy in fusion. Okay. So then the fusion spreads to the outer layers until eventually there's like... and this is over, you know, millions of years this is happening. The fuel is all gone at one point, and then the entire core collapses. There's a rebound effect and a supernova blows out. Okay.  

What I... the reason I use this as an analogy is to exactly address what you talked about—technical debt and everything else. What we saw at Unprompted, what we've seen in Prompt GTFO, and I'm sure your research and my research: is the "apocalypse" was the term I got out of Unprompted that people were using, which is the LLMs now are able to find vulnerabilities, uh, including zero-days in well-tested code—stuff that's already been fuzzed. Like Anthropic proved this faster than humans and find things that humans missed. Even very advanced humans have missed, and they're also being used for red teaming.  

And so I define this as this is a math problem again. Attackers have a bounded search problem. So the problem space the attackers are working in is bounded. "I'm going to focus on this code to find the vulnerability and then exploit it." Or, "I have this vulnerability, I'm going to exploit it at a wide scale." Or, "I'm going to focus on one organization, I'm going to find my path into that one organization." It's bounded what they need to use their tools for. It's augmented with agents. So a lower-skilled attacker becomes a higher-skilled attacker. A higher-skilled attacker becomes force duplicative. Yeah.  

As defenders, we have a wider problem space—a bigger... we have a bounding issue because they have a search problem. We have a combinatorial complexity problem. We need to defend everything we have from every attacker at all times. And even if we can instantly develop a patch, we can't instantly deploy a patch because of the complexity of our application stacks and the potential for things to break.  

So once... this is... the models today that can do the really heavy lifting stuff, there are some safety valves because they're online models—there's some level of control. Eventually we know these are going to go to local models or nation-states. They're just going to use these to penetrate each other's defenses. That's just the way the world works because we're all a-holes in the end.  

And so on the defender's side, what does that drive towards? Uh, and... this is those foundational practices that you're talking about. Um, if we increase security barriers, all the barriers that we add add combinatorial complexity to the attacker. Yeah. So Zero Trust... I hate to say it, the... the line I use in the blog post was: "Zero Trust or zero-day, your call." Yeah.  

Um, we have... uh, as we're writing new code, we need to compartmentalize it more and have not monolithic applications, but decomposed applications with different identities and properties and communication channels between those. Uh, we can do defense-in-depth. Unfortunately, now we're going to have to start doing this stuff that I've been telling people for years not to do. "Don't put three different firewalls from three different vendors in place." Well, damn it, now you might need to consider that.  

Uh, and then this is all for those of us living above the security poverty line. Yeah. Steal from Wendy Nather, who we presented on this a bit ago. Below the security poverty line, honestly, you're going to have to move to a hosted service and MSSPs because you can't maintain this stuff yourself. You have zero possibility of defending.  

Jeremy: Yeah, we've been talking to a lot of MSPs and MSSPs recently about some of the challenges. And, you know, the good thing for them is that the level of complexity that they face when it comes to AI adoption is simpler than a lot of... a lot of enterprise organizations, because it's usually just the flavor of employee usage and, you know, employee usage of a model typically directly through, you know, chat-based prompting, um... not a ton of developer coding going on in a lot of these organizations because they don't have a lot of in-house applications that they write or use or things like that. You know, these are very often offline kind of companies, you know, your dentists, your lawyers—who, well, lawyers are admittedly online, but, you know, most of their work is done in Microsoft Word and related tools. So these are not the coding bandits of the world pushing out the latest software stacks and things like that.  

But even then, in your... to your point, the MSPs don't actually understand the layer of risks that... that a lot of LLMs represent, even in as simple an environment as employee usage inside a browser and inside prompting. You know, is it PII exposure? Is it accidental malicious uploads? Is it accidental exposure of corporate intellectual property? Or is the answer all of the above, and also flavors of things coming up that might expose copyright or trademark risk? And who knows what is coming down the pipe? But thankfully the usage type is a little bit more limited for them in those organizations.  

Rich, okay, we're going to link your blog post for anybody who's out there and anybody who reads it. Okay, great. We've got like first principles. We've got kind of core practices we can lean on. Close us out today with some other words of inspirational hope. Give us... give us a, you know, the light at the end of the tunnel. Because I think for a lot of organizations, it's easy to get a little discouraged. Crap. "I've got a lot of security debt. This is going to make things worse. I know I should do Zero Trust, I know I should do micro-segmentation, I know I should do least privilege, but I also know that that's not the reality of my environment." And I couple that with, you know, C-level initiatives that are like one hundred AI projects by the end of 2026. You know, these things that we're hearing pretty regularly.  

And if you're the security practitioner or the security architect who's caught in the middle of that, you can't say no to the C-level. You have to enable. But you also know that your house is not in order as you go into that. You know, what's the best practical advice that you can give to someone right now?  

Rich Mogull: I mean, one is, um... we have job security, so hey, that's going to be awesome. I'd be more scared to be a mid-tier, mediocre developer right now than a security professional. So I... this is going to be a hard transition. It is.  

Uh, I have never... when cloud came out, I saw just all benefits. I didn't really see, you know, the downside. And for the most part, the downside was people using cloud wrong. But, you know, people who used it right, nailed it. With AI, you're going to be affected whether you want to or not. And I think the best thing that we as security professionals can do is get ahead of the curve. It's why, you know, I... even though like my kids hate AI and I'm like, I feel bad for how many tokens I burn on a daily basis, but it is what it is.  

Like we need to learn, know, and understand this technology. You know, not one of us... okay, maybe not one of us... some of them. I would say ninety-eight percent of the attendees at Unprompted weren't touching AI two years ago, right? Definitely not three years ago. Yeah, other than experimentation. We have all had to upskill and learn. And, you know, you came out of cloud, I came out of cloud. We're both there and, you know, build up those... those skill sets. But it's very doable. It's a very accessible technology compared to some of the other things we've done.  

And once you kind of get into it and you use it and you understand how it works, we already have frameworks coming out. We already have a lot of tooling coming out. So the... the, you know, going back to that, my analogy, like the supernova is going to just be blowing off all the gas of the crap that doesn't work, largely because the vulnerabilities and everything were snake oil ain't going to last long in this environment that we're going into, and we're going to get down to that core of iron, hopefully. So, um...  

And you can use this for initiatives that you have not had funded for a very long time or you haven't had the support, uh, the... you know, everything from Zero Trust to improving your CI/CD pipelines to dependency management because you're going to have real examples and you already have real examples you can point to that will help you get these things done.  

So, you know, I go back to sometimes when I talk about the depressing side of security, I go back to... so, you know, I'm a paramedic, and I'm still licensed as a paramedic and doing it on and off for thirty years. And people ask about, you know, how do you handle the stuff you've seen, especially because like, I've done disaster response, and it's kind of like you just work the problem, you know? It's... it's a job. We have the tools. Maybe we can't figure everything out. We improvise a lot as we go along. But, you know, we... we will be able to work the problem that's sitting there in front of us. And I'm not going to let that keep me up at night.  

Uh, you know, getting my taxes filed on time and getting my kids to where they need to be on time—try and keep that stuff... that's the stuff that keeps me up at night. This stuff just makes me kind of energetic. And we have some benefits. Like we've already seen Claude—the Anthropic release their security scanner. Like, oh my God, like organizations that could never have that level of security analysis now have that. Like it's fully changing how people think about tools and capabilities. So there's a lot of upsides to this as well.  

Jeremy: Yeah, I think that is a great place to kind of frame and end today's conversation. Rich, I want to thank you for taking the time to join us on Modern Cyber. For people who want to reach out to you, we're going to link your Cloud Security Alliance bio and your blog post in the... in the show notes for today's episode. Anywhere else that they should look to, to go follow you and follow some of your research?  

Rich Mogull: Yeah, most of what I publish from a research standpoint, almost all of it goes out through Cloud Security Alliance. Okay. I'm active in some of the like the Prompted community, I guess we're going to call it now, as well as for cloud or the cloud security slack. If you want to communicate with me directly, I'm in both of those slacks, uh, you know, LinkedIn, Mastodon, Blue Sky. I'm not on the, uh, the bad place anymore.  

Jeremy: Yeah. Likewise. Likewise. Although I'm also not on Blue Sky or Mastodon, I just decided that, uh, those platforms are no longer appealing for me, but, uh... Awesome. Well, we will link those platforms for you in the show notes for anybody who wants to reach out to you. And again, Rich, thank you so much for taking the time to join us on Modern Cyber.  

Rich Mogull: Yeah, thanks a lot for having me. I love these discussions.  

Jeremy: Awesome. Awesome. To our audience, as always, rate, review, share with anybody who might be interested. We'll talk to you on the next episode. Bye-bye.  

‍