Cybersecurity Awareness Month 2026: Standing Access, Runtime Authorization and Agentic AI Security

Grounds for Access, Episode 2

Cybersecurity Awareness Month 2026: Standing Access, Runtime Authorization and Agentic AI Security

All right. You ready, Gerry?

Yeah, good to go.

Hey everybody, welcome to another episode of Grounds for Access. I'm super excited to have Gerald Auger on with us today. We'll be talking about Cybersecurity Awareness Month. It's that time of the year, Gerry, where we get to talk to people about what's going on in their cyber and security environments. But today's episode is freshly brewed. We talked a little before we hit record about coffee, and we've talked about that before. I'm curious, what did you have? I know you're over-caffeinated at this point, because we have a few hours of difference between us. I'm still in the morning out here in California.

Well, I'll tell you, if it's a day that ends in "y," I've had a French press with French roast coffee. So it's some French-on-French action. Pour-overs are good, but they take too long. Time is very valuable to me, and a pour-over, I just can't with you right now.

I'm not going to judge. I am a coffee snob. I've been on an espresso kick for a few years now, but I do love a good French press. I haven't had one in a bit, but I might go make one after this.

I have one stationed at my in-laws' house because we go up there for the summer. I have one at my local house, and then I have a travel one. So no matter what, I've got my bases covered.

There you go. I love it. And as opposed to espresso, you don't have to carry all this weird gear. You just need the press and something to heat up water with. I love it. So, we know that organizations are moving really fast today, and there are a lot of things hitting them from all over the place. I think Cybersecurity Awareness Month this year, Gerry, is going to take a different tone in many respects. But before we jump into it, tell us a little bit about Gerry. Tell us about Simply Cyber and what you've got cooking these days.

I'm a 20-plus-year cybersecurity professional. My favorite part of cybersecurity is how fresh it is, literally. Every day it's something new. So as a lifelong learner, it never gets stale and it never gets old. Some of the problems that persist year over year over year, those get old, but we deal with those. Maybe six or seven years ago, I started getting asked a lot of the same questions: How do I get in? What is GRC? All these things. I just don't have a lot of time. As I mentioned earlier, time is very valuable to me. But my heart goes out to people, and I hate to say, "I don't have time for you, kid." So I started making videos, and those videos became very popular, and it basically grew into a community. Simply Cyber started as a YouTube channel, but it's much bigger than that. There are probably 17,000 or 18,000 people in the community now, cyber practitioners ranging from the just-curious to CISOs, and we all help each other and have a good time doing it. That's what I do, and I'm very proud of it.

I love it. If you haven't had a chance, definitely go check out the podcast and the morning show. I was commenting to Gerry a little earlier: you get up every day and do this service for our community. I absolutely love it, and I commend you for it.

Thank you. For those listening who don't know exactly what John's referring to, in addition to all my other initiatives, the flagship is my Daily Cyber Threat Brief. The name is deliberately designed to explain what it does: it's a daily threat brief that I run every weekday morning. We've been doing it for four or five years now, so we're at maybe 1,200 or 1,300 episodes. And it was the SANS podcast of the year in 2024. So it's got its reps.

It's great. Being in California, I have to catch it on the replay because it's 5 a.m. my time, but I absolutely love it. I'm a night owl, like a lot of us in this business. That's when I do my best coding, actually, sometime between 11 p.m. and 1 a.m.

When inspiration hits, you've got to answer.

So, Cybersecurity Awareness Month. Like I was mentioning earlier, I think this year is going to be somewhat special. A lot of people want to get into the business these days, and we might get into that a little bit. But today's cybersecurity practitioners and professionals are getting hit with a lot of stuff all at the same time. And AI, I'm going to say the word, because that's what's top of everybody's mind. AI is hitting them, and that's going to be a lot of what we talk about next month, along with everything happening in the news. From a practitioner perspective, and especially for the leaders out there getting hit with this, it seems to me the table-stakes knowledge they need in today's world is not just broad, but can be pretty deep as well. So I want to get your take on that as we kick off. I know you talk to a lot of leaders and practitioners. What are you seeing out there? Are they worried? What's your take?

From what I'm seeing, for sure there's a lot of concern around a very disruptive, very wide-reaching technology that isn't just a tech stack. It integrates and interacts with all of your tech, all of your data, and all of your apps. I wouldn't call it a problem necessarily; it's a major opportunity. It's a major paradigm shift that has to be accounted for when we think about risk and risk management.

At the base, one thing I'm seeing that I don't know why people don't talk about enough is that there's a lot of misunderstanding about the sheer breadth of what AI security is, or cybersecurity associated with AI technologies. I feel like the stories of agents, like an OpenAI agent hacking Hugging Face, or the Anthropic one doing something, or the DeepSeek one doing something, yes, that's something to consider. But these are bleeding-edge frontier models set up in environments where the guardrails are taken off. That isn't the same as a vendor coming in and installing an application that has an AI agent in it, and that agent going rogue in your environment. There's a wide range of what this AI technology can do.

In addition, I almost think AI security warrants its own focus and discipline, as opposed to, "We're moving into a European market, so let's get smart on GDPR." It's much more than that. To me, it's: What can the AI do? What does it have permission to do? So there's an entire access and permissions piece. But also, what is it intended to do? Who's allowed to interact with it? How do we know it was implemented correctly?

John, I've heard a lot of real stories of people who rolled out a Microsoft Copilot-built agent. By default, all the interfaces with OneDrive, SharePoint, and the Microsoft Office stack are secure. But if you use an ODBC connection to hook back into some type of on-prem database, there's zero security with that. And unfortunately, if an engineer says, "No, look, you can see the landing page. Microsoft says it's all secure by default," the CIO or CISO is going to say, "All right, I got it." What's actually happening is it's not secure at all, because they're connecting it in a way that's outside the scope of what those promises are based on. So it's a hot mess express, honestly.

And the final thing is that CISOs are getting a lot of value from AI, as much as CIOs and CEOs. Really, every seat in the business is getting value from AI. No one's going to stop using AI. Every single person I know who uses AI is more productive and faster with it. So there's no compelling reason not to use it, other than that it's scary. Yes, it's scary, and it's a hard problem. Solve it.

Exactly. I think you hit it on the head. It is a hard problem. And I have not seen any security practitioners who aren't willing to take on hard problems. That's the nature of the job.

A hundred percent. To me, the most pressing problem is the over-permissioning of these agents and letting them go buck wild. But I think a sneaky, sleepy, second-tier big problem is that literally anyone in your organization, people who are not technical, and I don't mean this to insult or admonish them in any way, people who shouldn't be developing web apps and making tools, are vibe coding and pushing things into production with no context on how to maintain it, what it actually does, or what the risks are. It's just, "No, I'm faster. Look at me." That shotgun blast is what I'm calling "shadow slop." It's essentially shadow AI, shadow IT, but it's slop that's been developed. That shadow slop is like spilling a bucket of yuck all over your floor. It's not easy to clean up.

We're going to tag that one: the bucket of yuck. I like that one. But it's so true. On the flip side, there's the promise of AI. It's empowering to non-technical folks: I can go and accomplish something. But you're right. In the software development lifecycle, when you insert security best practices, you've got some kind of security review happening. Are you making your agent do a security review on the bucket of yuck you just put up on the public web?

Exactly. It's a major problem. And honestly, I've found that most end users, regardless of the environment across my career, want to do the right thing. Most people aren't interested in additional risk. But if they don't know they're supposed to ask "Is this secure?" or "How is it secured?" then they won't.

You're absolutely right. You touched on this a couple of minutes ago, but I want to dig a little deeper. It's around the fear, or the risk, of agents. Are those same leaders and practitioners distinguishing clearly enough between what is a frontier model risk, which we hear about quite a bit, and agent risk? I think in the news cycle, agent risk is now becoming front and center. It used to be, "Fable came out, so let's be scared of the frontier model," and we spent a lot of time on that. But at the end of the day, it's the agents that are executing your code or a process you put them out to do. In your view, are leaders and practitioners distinguishing enough between those two risks in their environments?

I've seen a lot of technically inclined leaders easily distinguish: "We're not rolling Fable here. It would be cost-prohibitive." You don't need Fable to reset the tone of your email. That's excessive. So the technical leaders I've seen understand that those frontier models, while interesting and in some ways concerning, are not what's being implemented in their environment. I've seen a mixed bag when you're talking to vendors who are rolling something into your environment, or you're going to roll an enterprise version of Claude into your environment: Which models are we going to be using here? Which models are you using?

The non-technical leaders don't really understand the difference between the two. With the ones I've talked to, it's much more, "Yeah, but I think we'll be fine." It's hope as a strategy, which stinks. But at the end of the day, there's this whole idea of tokenomics and how expensive these models are to use. All of a sudden it's, "I fired all of my developers, yet somehow I'm burning 300x my monthly run rate because of AI." They're smart enough. Just by financial stewardship, they're not paying for the high-end models that would cause the problem. So they're protected by default, somehow.

It's funny you mention the cost aspect. I did a talk way back at the beginning of the cloud era, and I challenged the audience at the time that, at the end of the day, architecture is really all about cost containment. Yes, you're an engineer, and yes, this is a very technical thing you're building. But at the end of the day, you're limited by somebody in finance telling you, "No, this is costing way too much."

Oh my god. One of the best things I ever heard, John, was that as engineers we can geek out and build the coolest thing ever. But the second you tell a CEO it's going to cost a dime to save a nickel, they're going to say, "What are you talking about? Get out of here."

I don't want to go down a FinOps rabbit hole, but it's interesting. So, before the rest of us wake up, you've already seen the day's stories, what's happening today, what new breach is being disclosed. It seems like every week we see at least two or three disclosures.

Every day.

Well now, yeah, you're absolutely right. So my next question is around this. A lot of those disclosures start with a similar statement: "This happened in a lab," or "This happened in a sandbox." I'm just going to leave it trailing there. How do these incidents, if they happen in a "sandbox," translate into something leaders will worry about in production in their own environments? It goes with the previous question. We're seeing these happen in sandboxes. Should they be worried?

From my perspective, this is like looking into the future. It's easy to say it's just a frontier model in a lab, and some engineer misconfigured it, or they told it to win at all costs, so it exploited the Docker container it was in, busted out, and broke containment. Those are all true stories. But right now, it's like worrying about quantum computers cracking all the encryption. At some point it will happen, but that's not today's problem. We still have to deal with today. The house is on fire right now. We have to put it out. We can't be worrying about how hot the fire is going to be in a month. That's how I feel about these issues.

What I will say is two things. One, it is an indicator of what's coming, because these models are getting exponentially better, and eventually the one that's really good is going to be available to the mainstream. My daily concern would be much more focused on open-source models that anyone can download and use to make essentially malicious frameworks that can then be sold in a B2B or B2C way. We've already seen the affiliate model in ransomware for the last six years, and we've seen phishing as a service, malware as a service, whatever-as-a-service. So to me, the main concern is: a threat actor gets some type of pen-testing framework, an AI agent or tool set that doesn't have guardrails on it, trains it up, weaponizes it, and then offers it as a service. That's much more lucrative. Again, follow the money. A threat actor is going to make more money selling this to other criminals or potential criminals than using it to break in. Plus, it's a lot less traceable. If I break into a Fortune 500 company, my fingerprints are all over it. If I'm selling something to you and you're breaking in, now I'm one hop away from a safety perspective.

So, all of that is a long way of getting to this: my concern would be more around the weaponization of open-source models, making tools that give a much wider pool of potential threat actors the ability to target me. So my threat landscape grows. Having said that, I'm more in the mindset that AI tools right now are mostly just executing faster what humans are already doing. Another thing I think is over-sensationalized, though it is true, is AI finding zero-days in old software. Yes, that's happening, but I don't think that's the main vehicle for cybersecurity incidents involving AI. I think AI is just making humans move faster. I don't know about you, John, but I don't use it to innovate a brand-new way of doing work. I just do work faster with it.

Absolutely. I always tell people why I'm not afraid of AI personally: it does two things for me in my daily job. Like you're saying, it makes me way faster. And it's also a force multiplier for the knowledge that's in my brain. That's the way I look at it.

But you bring up an interesting aspect, and it ties back to something I've been preaching in my day job for over three years now: the problem of standing access. I'm coming at it from the identity perspective, so let's hit that straight on. I perceive that with a lot of these new technologies, we tend to say, "That agent I'm putting out there to do this production thing will make us faster," without really understanding it. And I think there's an interesting conundrum there. I'll be speaking in Singapore in a couple of weeks on the fact that these agents are non-deterministic. You don't know how they're going to execute their goal. Those of us in security have always thrived on being able to deterministically secure the thing that's going to be out there doing something on our behalf. AI agents have completely flipped the table on that model. So my question is about the standing access problem. Like you talked about earlier, sometimes we're dealing with old problems in a new way, but at light speed. Tell me a little about that. What do you see in that regard?

This is probably the biggest challenge right now with AI and security. It's not necessarily the scariest or the riskiest problem, but to me it's the largest, most mainstream issue, because agents need access to do things, and the business wants agents doing things, so they're going to give them access. This is a problem that has existed ever since somebody needed access to something.

So here's the deal. I'll tell you a couple of hard truths. Number one: when someone, or an agent, doesn't have access, it doesn't work. They don't work, they complain. It's a very squeaky wheel, and you give them access. Nobody squeaks or complains if they have too much access or no longer need the access. No one's going to complain about that. Oftentimes the only time you catch it is when they leave and you shut it off, and either A, you think, "Thank God, I didn't realize they had access to that," or B, more often, something breaks because they had put their account into an automation or something like that.

I think standing access for agents takes that problem even further. Say I give you access, John, and you're like, "I can't get to the SharePoint, Gerry." And I just right-click, domain admin. "Let me know if you have any problems, John," which you won't, because now you have access to literally everything. For better or worse, as a help desk person or an IT admin, I'm perversely incentivized to give you full access. You're a very nice person, John, and we're going to have coffee every day, but I don't want you calling me all the time. I'm trying to get caught up on my Avengers movies before the new one comes out in December. I'm watching this movie at work. I don't need you buzzing me. So there's an incentive to over-provision you. The thing is, you are unlikely to abuse that access. An agent doesn't have that moral compass. It's just trying to accomplish its goal.

So that's part of the challenge. Plus there's the speed and scale at which these agents can take action. You're working nine to five, maybe Monday through Friday. The whole promise of an agent is 24/7, 365, no breaks, moving at "machine speed." If you had a nickel for every time you heard that. So the scale of the problem can explode very quickly. Like I said at the beginning of this response, I really think access for agents is the single most important thing organizations need to get their arms around right now, because it's going to decide how bad something is if it goes wrong.

Right. And a reaction to the standing access problem, something else I've been preaching for three years or so, is runtime authorization. So I don't give you access. When you were talking about IT folks being incentivized to right-click and give Gerry admin rights...

And for those listening, that is a straw-man argument, and it's not every situation. I know you don't do that, but it's a thing that happens.

I get it. I had visions of an episode of The IT Crowd going through my head. "Garbage can on fire."

Oh my god, that show's great.

But runtime authorization is a counterbalance to that, just like just-in-time access. It's all in the same vein: don't grant standing permissions or rights; evaluate what that person is trying to do at runtime before you actually grant the authorization. So does that matter in this world? I don't know how much you've thought about it, but what new protections can leaders put in their environments using runtime authorization?

I was talking to another CISO about this exact issue, and I liked her take on it, so I'll give my version of that. I think runtime authorization is great. But anytime you introduce complexity to any workflow, problem, or solution, it adds maintenance, burden, governance, and management. So if your options are to use no AI agents or to give them full access to everything, most people are going to give them access to everything and go back to hope as a strategy.

I think what we need to do first, and it's not an easy first step, is identify what's considered critical or sensitive. Basically, take an inventory of where you would not want an agent operating autonomously without some type of human intervention. A very easy, extreme example is launching a nuclear weapon. That should never be the agent's decision. But there was a story maybe a month or two ago where an agent wiped out a company's production database, and the backups. That's clearly something that shouldn't have happened. But it's hard work. Someone has to go and catalog all these things, and by the way, that's not a point-in-time activity. It's a programmatic activity that needs to happen consistently.

And even then, it's a good idea, but these agents are smart. Say, to make a simple example, it's a segmented network, and they have access to the AI section. They don't have access to the medical devices or the financial segment, but they have access to the guest network and the AI network. Because they can get into the AI network and then the guest network, they're able to come back around into the worker-bee network, which has access to the finance network. And now you're screwed. So even when you do it right, you can still have a problem, because AI is very good at thinking through scenarios you didn't consider, because it's an outrageous approach to solving a problem. They have exhaustive time to think through all the permutations of how a goal can be achieved. And that's ultimately the point of these things: achieve the goal.

I think there's an aspect of that tied to what I said about non-deterministic agents. Like you're saying, they can take a different path to achieve the goal every single time. So the challenge for us as human operators and admins, in constraining these agents from a security perspective, is reintroducing some determinism into that path. I liken it to bumpers at a bowling alley. Maybe that's too simplistic.

No, it's a good metaphor. I just want to speak to the listener who's thinking, "What's the big deal? We've got this solved." Anyone who's worked in cyber for more than a minute knows privileged access management is a wonderful control. We know that with PAM, end users can't run PowerShell scripts. We know that with PAM, the exposure of sensitive things doesn't happen, or it's nonexistent. Yet in 2026, we still have massive privileged access management issues. So this is just another PAM issue. And if we haven't solved it already, do you think you're just going to get it right this time? No. It's a big challenge.

So, in the next phase of this, you used the word "machine" a little while ago. I'd been trying to avoid that term, but it's true. These are bots, machines out there doing things on our behalf. Like you're mentioning, we still struggle to manage the humans, much less the machines. I've seen all the stats, and I'm sure you have too, about how machines outnumber humans, how many of those machines are agents, and how that's exploding. So this is a two-pronged question. Number one, in your view, how does ownership of those identities work? We're preaching that those are full-on identities, with access and the ability to do things like drop a table in production. And two, what changes when those identities are given autonomy to do things in production?

In a perfect world, I would love for some human to "own" the machine identity. I authorize it: "You work for me, Agent 1234, go off and run." And if something goes wrong, my phone rings, not the agent's phone, which wouldn't exist. In a perfect world, I like that. Unfortunately, I don't see how practical that is from an implementation perspective right now. Say the CIO owns it. Come on. The CIO or the chief applications officer doesn't know the configurations of the applications. It's not feasible. I also don't think it's a good idea for a department to own a certain agent's identity. In my experience, I've never seen department ownership of something ever materialize, because there's diffusion of responsibility: "I don't know. IT owns it." So it's a very difficult problem to solve.

As far as accountability goes, I think we should at least have an inventory of these agents' identities. If you have an identity and access management program, these agents have to have identities created. They don't just operate in a vacuum. I almost think it might be a specialized role on the identity and access management team to look at these things: which one is taking up the most network bandwidth, which one is accessing resources that don't make sense, getting an inventory of what resources they use. In fact, honestly, John, I could even see agents being used to reconcile agents, almost like an independent auditor or third-party regulator that monitors agents' access to look for anomalies.

But right now, like I said earlier, anybody and everybody can whip up shadow slop, and we're getting vendors bringing technology into the environment that may or may not have AI. There are even instances where you've had software in your environment for three, five, ten years, and the vendor pushes an update that now has AI. You don't even know it's there, and it's operating with whatever service account you gave that application years ago. It just borrows those permissions, and off it goes. So we're definitely identifying a lot of the challenges, and it's all in the weeds. The devil's in the details. It's easy to say, "Just give it an identity with the right permissions and keep an eye on it." Okay, show me what that looks like on paper.

Well, and that's the thing. We talk about the human in the loop. To your point, if I have some kind of approval workflow that says, "Before you drop a table in this production database, go call a human," how feasible is that? I think that's the question on a lot of people's minds. How do I balance the benefit of having these autonomous agents do real work on our behalf against the blockers or checks I have on them before they do something inherently dangerous?

It really is a frustrating governance challenge. You have to identify what qualifies to have a human in the loop. Because effectively, and this is the scariest thing, without getting too doom and gloom, humans are the friction. We are the friction in the machine now. If you're talking about removing friction and making things smooth, that removes us, which is slightly concerning. So you have to put a lot of effort into identifying what situations, resources, applications, and activities must have human intervention in some capacity.

And then, and I haven't heard anyone talk about this, what does that look like? When people have this conversation, even you and me right now, we say there's a human in the loop. Do you think it's just a terminal shell with code ripping through, and all of a sudden there's a blinking prompt that says Y or N, and you hit yes? It would never look like that. Plus, how are you evaluating whether to hit yes or no in that situation? You essentially have to build some type of interface or infrastructure for the human in the loop to actually understand what decision they need to make during that intervention. I haven't heard many people talk about that, so I think it's going to be challenging. I like to think the new job is going to be "AI wrangler." You're watching what they're doing on some type of visual dashboard, and you're effectively a manager over autonomous agents.

That's interesting. Maybe because you mentioned it earlier, my brain goes to WarGames, with the missiles flying across the screen.

Yeah, and the screen's just going brrrr, and no human can even keep up with it.

One other thing that popped into my head: if humans are the friction, the concern I have is that we as humans tend to be completely oversaturated with approval requests. So approval fatigue, kind of like MFA fatigue, sets in. I just put Claude Code into YOLO mode, and everything's okay.

That is a real concern. That's a real human condition. And like you said, it's shown itself already. With a lot of these problems, we can almost always point to a pre-existing issue in our industry, which is wild. We're so lucky to work in cyber and to have already seen all these issues. AI isn't a cyber problem. It's a paradigm-shifting, society-impacting technology. We have front-row seats and pre-existing knowledge that's very germane.

That leads to an interesting question, and I know you talk about this daily. What should the next generation, or actually the current generation, of practitioners and leaders go out and learn to educate themselves and be prepared for the reality we're living in today?

I have kids who are 14 and 11, so I think through that. Software engineering is kind of cooked, in my opinion. I have two computer science degrees and was a software engineer at one point, and I'm saying this. Being able to read code is valuable, but you don't need to write it so much anymore. Whether you're a CISO or senior leader with 25 years of career left wondering how to stay relevant, or you're graduating college, I think there's a lot of value in getting your hands incredibly filthy with AI technologies. Install them, play with them, understand them, try to break them. Understanding what they are enables you to speak intelligently about them and understand the challenges they present to an organization and a workforce.

I used to have this belief, but I've walked it back: I don't think we're going to get into a situation where no one can work because AI has done all the jobs. I think it's going to be too cost-prohibitive to have AI do all the things. I also think you need people. I'm not trying to be righteous; you need people because when something breaks, you want to call a human and say, "You fix it." You don't want to prompt an agent. If I get one more message from Claude saying, "You're absolutely right, Gerry. I did it completely incorrectly. Let me fix that," and then it does it wrong again. No, I need a human who can think through it and think outside the box.

But I do think you need to understand agents. You should be able to answer, "What's a harness?" You should understand what a frontier model is versus a model that was trained to read radiographic X-ray images. You don't need to be a medical doctor, but you should understand those concepts. Then, when vendors are bringing stuff in, or you're trying to piece a few things together into a solution, you have the context to understand it. This is definitely not a flash in the pan. You could have gotten by without learning Azure or AWS during the big cloud move. But this one is here to stay, and it will be ubiquitous. It is ubiquitous, frankly.

At this point, yes. And that leads me to my next question. Because it is Cybersecurity Awareness Month, a lot of organizations are going through their annual security awareness training. We watch a few videos, 15 minutes long each, and take a test at the end. I can't force an agent to take training and generate a certificate. So how do we change that training, especially for the non-tech folks who are now doing all these technical things because ChatGPT enables them to? How does that change going forward?

I'm thinking of this in the moment, so this is a hot take right off the top of my head. Agents are very good at taking context in. They're terrible at remembering context unless you build them that way. But I could envision, and I haven't thought through the whole solution yet, a situation where you have your organizational policy, your organizational vibe, however you want to put it. And it's not once a year with the agents. It would be during onboarding, and then maybe a quarterly or annual touch. Have it ingest your policy. You could even curate the policy so it's built for agent consumption. The same way we educate our workforce, we could, not educate, but effectively tune these agents to align with our organizational policy. That's great, because financial services is going to have much stricter, tighter policy than, say, a mid-sized publishing company. So I think that could work. Is it guaranteed to keep the agent from going rogue or doing something off the recipe? No. But we educate end users, and they click on silly stuff and do silly things. So it's one-to-one as far as what risk you're mitigating and what the training is actually doing. Some agents might not be able to take context, but I think many of them will.

I think that's absolutely correct. Now, really quickly, back on the accountability piece and the enablement piece for the business. We're seeing the emergence of the chief AI officer. How do you even pronounce that acronym? CAO. "Chao."

"Ciao"? Like, "Hey, ciao"?

I love that. But just like we elevated the CISO role for very good reasons, in my opinion, ten years ago or whenever it was, what does the emergence of these roles give back to the business, and to accountability for all the AI things happening in your enterprise? What do you think about that, Gerry?

I was firmly on the chief AI officer train in 2023 and 2024. I've adjusted my position on that. I'm not saying you can't have a chief AI officer; it's certainly not a bad idea. But because AI is so dynamic and multifaceted, I think several different departments own different pieces of it. General counsel owns liability. If you have an AI agent and it goes off and attacks somebody, like OpenAI's did, what is your liability? That's not a question for the CIO. General counsel should own that and should have thought it through. The CFO owns the spend and accounting for all of that. Licensing an app costs money, so that piece doesn't fall to the CFO; the CIO owns it. There are all these elements. IT would certainly own a significant piece. Identity would own one. So from an accountability perspective, have the reasonable parts thought through and owned by those individual groups.

And then you can have a committee if you want. I know that can be somewhat slow. I said "committee" kind of mockingly, but as I think about it, a committee may not be bad for the people who own these pieces. AI is moving and changing incredibly quickly. If you had a regular touchpoint with these different groups on accountability for how AI is deployed in your environment, you could keep the heartbeat going and keep your finger on the pulse, to throw in another cardio-related metaphor. You'd make sure you're taking advantage of all you can get from AI while trying to minimize the blast radius of an impact from an event.

That's a good point. So as we head into October and Cybersecurity Awareness Month, you'll be talking to a lot of CISOs. What's the answer you hope you'll get, or hope you don't get, from CISOs in terms of accountability?

That's part of the CISOs at Work series, where I'm going to be interviewing several CISOs across multiple cultures, industries, and experience backgrounds. I'm really excited about that. It's coming out in October. As far as the best thing I could get from that set of conversations, I think there's always power in hearing other people's stories and perspectives. There's an old saying I like quite a bit: "If you want to go fast, go alone. If you want to go far, go with others." This is a very complicated problem, and a lot of smart people are working on it. I feel like we're still in the storming phase of forming, storming, norming, if you're familiar with that model: trying things, failing fast, breaking things. By leveraging other people's experiences, what they've seen, what they've heard, and what hasn't worked for them, I don't think we'll move as quickly as AI is moving, but we'll be able to level each other up and figure out best practices a lot faster, then implement them in our own environments.

Absolutely. Gerry, thank you so much for being with us today. I really appreciate your time. And for everybody out there, consider this the starting point for Cybersecurity Awareness Month. Gerry, thank you again. SimplyCyber.io and the Daily Cyber Threat Brief are amazing resources at your disposal. Anything you want to close with today?

Just remember, AI is a big problem, but that's the challenge. It's never easy in cybersecurity. This is just a nice big problem to work on and solve.

Absolutely. And that's it, everybody. That's what we have in our cup today. We'll see you on the next one, and see you all for Cybersecurity Awareness Month. Thank you.

All right.