AI Security, Cyber Risk, and Cloud Strategy on ClearTech Loop · 2026-07-01 · 14 min
Key moments - from our scoring
Substance score
40 / 100
Five dimensions, 20 points each
Derek Fisher, founder of Securely Built and director of Temple University's Cyber Defense program, unpacks the operational and legal challenges of AI governance in mid-market organizations. The conversation addresses three critical gaps: discovery of sanctioned versus shadow AI use (including direct ChatGPT, Claude, and local LLM deployments), establishing accountability through cross-functional governance boards that span technology, legal, HR, and compliance, and preventing unauthorized agent actions through proper RBAC, service whitelisting, and audit trails. Fisher treats AI agents as privileged accounts comparable to service accounts but with far greater autonomy, and emphasizes that MCP (Model Context Protocol) servers - which connect clients to external services dynamically - require the same third-party risk assessment rigor organizations apply to traditional vendors. He argues that security teams are often too resource-constrained to ask the right questions during AI tool adoption, and positions AI as a potential lever to reduce burnout rather than compound it.
Establish a cross-functional AI governance board (including tech, legal, HR, compliance) that reports to executive leadership who owns risk appetite. The board sets standards and approves exceptions; product owners manage day-to-day use case outcomes in the trenches.
Treat AI agents as privileged accounts with proper RBAC, maintain a registry of allowable services that MCP can connect to, implement comprehensive auditing of all agent interactions, and use guardrails to shape what traffic and connections are permitted.
Apply traditional third-party risk management: validate the business need, assess internal capability to manage and oversee the tool, evaluate data handling and regulatory concerns, and determine whether critical decisions depend on outputs - before onboarding.
The confused deputy refers to how MCP clients can dynamically add tools and connect to services on the fly, creating a scenario where the agent (deputy) might execute actions it shouldn't because guardrails and service whitelists aren't properly constrained.
Derek suggests AI tools can reduce cognitive load and operational stress on overworked security teams by automating routine tasks, provided organizations intentionally position AI as a solution to burnout rather than just adding more complexity.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode covers three relevant AI security topics but stays largely at the framework level - governance layers, RBAC, auditing, third-party risk - without producing any non-obvious claims. The filler-to-insight ratio is high for a 14-minute show, with lots of hedging and repetition instead of dense takeaways.
it really comes down to again, shaping that connection, uh, having a solid uh, auditing, uh, around, you know, what it's doing and then having that visibility into it
you really have product uh, owners. Um, the product owners are the ones that are managing the use case outcomes
The MCP-as-privileged-account framing is a moderately useful analogy, but the rest of the content recycles standard governance playbooks, the overused nuclear-technology comparison, and generic 'apply what you already know' advice. Nothing challenges conventional security thinking.
sometimes about AI agents specifically as, as and I know this is like an oversimplification but as a privileged account
AI is not. AI is a novel way for us to sort of tackle technical problems, but at the same time it's a tool
Derek Fisher has genuine practitioner credentials - 30 years in cybersecurity, mid-market advisory work, and a university program directorship - making him a credible voice, though not a top-tier operator who has built and scaled security programs at a name company. The transcript reveals competence but not unusually deep domain authority.
With over 30 years of cybersecurity experience, Derek serves as director of Temple University's Cyber Defense and Information Assurance Program
He designs and implements security programs including volume management, secure sdlc and incident response in order to help firms strengthen their resilience
Concrete examples are nearly absent; the only named specifics are Claude and Salesforce used as passing illustrations, with no metrics, case studies, incident data, or dollar figures. The Word-document MCP example is the most concrete moment but is trivial in scope.
let's say uh, if you take Claude as an example, that just happens to be my tool choice. Um I can ask it to generate a Word document out of ah, a text that it output
whether it's being used within sanctioned platforms, salesforce, if you're creating, uh, uh, workflows within there to automate
The host introduces three genuinely relevant and timely questions - including the 'confused deputy' MCP framing - but consistently accepts vague answers with validation rather than pressing for specifics or challenging positions. The rapid-fire format structurally prevents real follow-up depth.
I just heard MCP referred to as the confused deputy, which I thought was funny
That's a great answer. Thank you.
Computed from the transcript - who did the talking, and the words that came up most.
AI governance is no longer just a policy conversation. As AI moves into business workflows, sanctioned platforms, employee tools, local models, agents, and third-party services, organizations need to understand where AI is being used, what it can access, who approved it, and who owns the outcome when something goes wrong. In this episode of ClearTech Loop, Jo Peterson speaks with Derek Fisher, founder of Securely Built, cybersecurity educator, author, and Director of Temple University’s Cyber Defense and Information Assurance Program. Derek brings a practical security lens to AI governance, AI agents, and third-party MCP risk. The conversation covers why governance needs clear ownership, how organizations should think about AI agents as non-human actors with access and authority, and why MCP servers and AI-enabled services should be evaluated through a third-party risk management lens. This episode is especially relevant for security leaders, technology leaders, compliance teams, and business executives trying to move AI from experimentation into controlled, accountable use.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign.
Speaker B: Thank you so much for joining today's edition of Clear Tech Loop. I am Joe, um, Peterson. I'm the CIO of Clarify360 and the Chief Analyst at Cleartech Research. And I'm here today with Derek Fisher, founder of Securely Built. Hi Derek.
Speaker A: Hi, how you doing? Thanks for having m me on, Joe.
Speaker B: Thanks for taking time to visit. Um, in case you're not following, Derek, you should. Derek and his company provide advisory services to mid market firms for strategic planning, risk management and regulatory compliance. He designs and implements security programs including volume management, secure sdlc and incident response in order to help firms strengthen their resilience. And he delivers cybersecurity education and training awareness to advance from, I should say uh, education and training to advanced technical skills. With over 30 years of cybersecurity experience, Derek serves as director of Temple University's Cyber Defense and Information Assurance Program. So welcome, Derek.
Speaker A: Hey, thank you very much.
Speaker B: Um, as you guys know, we do three rapid fire questions that are of the moment that security professionals are thinking about. So let's not deviate from the norm. Let's get going with question one. Uh, Derek, how do we operationalize AI governance and who is legally accountable when an AI agent makes an unauthorized decision?
Speaker A: So that's, I mean that's tricky because I think one of the biggest challenges is that a lot of organizations don't know where the AI is, where AI is being used. So there's, you know, whether it's being used within sanctioned platforms, salesforce, if you're creating, uh, uh, workflows within there to automate and create, uh, um, features and that's great. But then there's also, you know, shadow AI where people are able to, whether you're going directly to ChatGPT or Claude, or you're creating your own local, um, you know, agents and you know, utilizing local LLMs. I mean this, this is one of those things where it's very difficult to put the toothpaste back in the, in the bottle, right? Or, or the tube. Because once these tools are, are in the hands of, of everybody, it's very hard to, to get a, a grip on where it's being used, how it's being used, and more importantly, how is the company data being used in those systems? Um, you know, one of the podcasts I was listening to recently, I think it was yesterday, they were talking about how, you know, when we had these massive changes in technology, like let's take nuclear technology as an example here, you know, as a collective, as a society, we all decided like, hey, this is very powerful technology we really need to get our hands around and make sure that it's not you know, uh, nobody can build a nuclear reactor in their home. Right. And so that's a little different now because we have a technology that could have very far reaching implications and yet it's pretty much in the hands of everybody. And so being able to get your hands around that and be able to make sure that we understand how decisions are being made and how we can get um, the appropriate controls around it can be difficult. But what that really starts with is having an AI uh governance board, uh, that's in um, that is cross cutting. So you don't want to just have it in the technology side, but you also need it uh, you know, members of that governance board that are part of ah, hr, that are part of legal compliance, um, and have that like cross cutting across the organization visibility into, you know, what is it the organization uh, really um, you know, what are the impacts of this technology? Uh, above that uh, AI governance is really an executive, uh leadership now depends on the organization, who that executive or what that executive leadership looks like. But they should be the ones that are in control of the actual risk appetite of the organization as it relates to AI. So the executive at the top uh, owns that risk appetite. The governance board below that really uh, decides the standards and um, and the way that uh, any like exception use cases and things like that that are, that need approval go uh, through that AI governance board. But down at the, in the trenches you really have product uh, owners. Um, the product owners are the ones that are managing the use case outcomes. So for instance like if you have um, you know, if you're utilizing AI in order to you know, create um, I don't know, create better reporting or something like that within a certain business unit, you know the product owner of that particular area needs to have the, the at least in the lower levels the, the ownership of the outcomes from that AI. Um, but again you have above that the governance board above that the risk uh, being owned at the executive leadership. So that's sort of the way in a nutshell that that should be divvied up.
Speaker B: Yeah, and that's fair and that's very thoughtful in terms of the approach. Um, so I just heard MCP referred to as the confused deputy, which I thought was funny. Um, how do we prevent agents from executing actions that the user should not be allowed to perform?
Speaker A: So you know, I think sometimes about AI agents specifically as, as and I know this is like an oversimplification but as a privileged account, right? It's an account, it's a, it's a non carbon user um that has the ability to um, you know, make changes in the environment. I mean we're not that, it's not that far removed from like a service account. Uh with the exception that you know these are far more powerful, have far more uh, access can do more uh, you know with, with the service count you sort of have a you know, single direction or bi directional type of interaction that you can really kind of shape that, what that traffic looks like and that interaction looks like with um, you know, with, with mcp, uh in particular where you have um, clients and you have you know, servers or clients and, and uh, services, you know that the MCP is, is you know making that connection to. It's a little bit different because tools can be added on the fly. Uh so let's say uh, if you take Claude as an example, that just happens to be my tool choice. Um I can ask it to generate a Word document out of ah, a text that it output. It's utilizing MCP in the background to connect to a service to generate a Word document. Um, that's a lot different than what we would typically see in a service account type of activity. But it really comes down to like shaping that access uh and putting the guardrails around it so you know, having the appropriate RBAC in control, you know, uh, rule based uh access control or uh, role based access control. Um having also uh, a registry of allowable services. Like here are the services that this, you know, um, that uh, this client is allowed to be able to access. Um, in terms of like you know you can't just create, you know, connect to a service uh on the fly. Like it has to be in an allowable set of services that that mcp uh is allowed to connect to. Um, you know putting those, those guardrails around in terms of how it interacts with those services, uh, and also having auditing in place. So you know that like okay, here's what it did, you know, here's what it connected to. Um, here um, was the way it interacted. Um, um. And so that you're able to at least peel back the onion at some point should something go wrong that you're able to at least audit that interaction. Um, and then really just having that transparency around how the mcp, um, you know, how it's making those connections between the services and the client and um, knowing what types of you know again that sort of ties into that auditing. But like what is that? What is it? How is it thinking about making those connections? How is it thinking about um, you know, uh, meeting the goals of what the client is asking. So it really comes down to again, shaping that connection, uh, having a solid uh, auditing, uh, around, you know, what it's doing and then having that visibility into it and, and then really just having uh, those guardrails, uh, in place, shaping the type of traffic that it's allowed to do.
Speaker B: That's a great answer. Thank you. Um, one of the things I think about and I wonder how we solve for is there's more and more MCP servers coming into everyone's environment somehow, some way. How do organizations verify the authenticity and security of these third party servers coming in?
Speaker A: And m. This comes back down. And I don't mean to like sort of like tie back down, uh, into like what's sort of uh, been security classic or whatever, but I think, you know, it comes down to third party management. Like we, like we've been doing third party risk management. Um, you know, the first thing is, you know, what, what business need is this particular M. You know, what business need is this? Is this really solving, like what problem are we solving with this? Yeah, um, because, because you know, again we would ask that question in a third party risk assessment is like, do we need this? Like, do we not already have this capability? Is this something that we really need to go external for, uh, or use, you know, another service, uh, before onboarding them? Um, so really, you know, what is the, what is the value and what is the problem that this, that this is uh, that this particular uh, case is solving? Um, and then it comes down to um, you know, understanding, um, do we have an internal team that's actually capable of being able to manage this? Uh, because again looking at like a third party risk assessment, like okay, we can get this tool and bring it in, but do we have people that have, number one, the knowledge to be able to uh, manage this tool or utilize it appropriately? Um, do we have the ability to uh, provide proper oversight for it and so forth? And then also you know, compliance and regulatory, uh, um, more importantly like the regulatory aspects of utilizing that service? You know, is there uh, concerns in that, in that aspect? Do we have um, concerns about how our data is being used? Do we have concerns about, you know, the way they're, you know, the way they're processing the data, the information we're getting back? Are we, you know, doing critical, uh, or making critical decisions based on the interaction that we have there? So you know, those are sort of, again, not the, not the sort of put, put it in the same bucket as like three, uh, third party risk assessment. But it sort of is that right? We, we should be treating it in the same way. Um, AI is not. AI is a novel way for us to sort of tackle technical problems, but at the same time it's a tool, it's a technology tool that uh, we should be leveraging as much of our kind of learned experience and learned knowledge, uh, to be able to uh, apply in this case. Um, yes, it's more powerful, yes, it can do more things. But in essence we should be utilizing what we already know from a security standpoint, uh, on how to better, uh, get our hands around it.
Speaker B: Right, And I asked that and you went exactly where I think you needed to with that. One is, I want to draw out the idea that I don't think people are asking the question right. It's just for whatever reason there's some sort of disconnect. And um, sure, large companies have lots of talented folks, but the smaller you get in terms of companies, the less bench you normally have. And not that those people aren't smart, but they're overworked and they just may not have enough resources. And I don't think sometimes the question's getting asked. What do you think?
Speaker A: Yeah, agreed. I mean, uh, you know, I sort of think about, and I was thinking about this the other day, that we've been complaining for so long, you know, in, in cybersecurity and technology and in general that like we have people that are just burned out. You're working many hours, you're never getting ahead, you're never catching up. Um, you know, this is our moment to utilize these tools, whether it's, you know, AI, particularly AI to be able to hopefully, um, reduce that cognitive load and hopefully reduce that amount of stress and burnout in the people that we uh, that we employ. And you know, hopefully AI is going to be a solution to that. Um, and I hope that that is the direction we're heading. Um, sorry. I hope that sort of answers your question.
Speaker B: It did. It was perfect. It was, it was a perfect answer. And you and I are thinking about it the same way. So that's, that was great. Well, it's been great to have you visit. Thank you so much for taking time to visit with me. And guys, we'll catch you later.
Speaker A: Thank.
Speaker B: You.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Paul Graham On Startups, Ambition, and Great FoundersY Combinator Startup Podcast · on ChatGPT88 / 100
The AI-Native Law Firm, with Ryan Walker of General LegalMeeting of the Minds · on Claude88 / 100
Shadow AI: 7 Out of 10 Workers Use AI Their Company Can’t See | Ravi Soin, CISO SmartsheetCXO Spotlight · on shadow AI87 / 100
How SSW turned AI into ½ their pipeline - Ulysses Maclaren, COO of SSWSaaS Stories · on Claude86 / 100
657. Waziri Garuba, CEO of Harlem Labs, Introducing G.R.I.O.TUnleashed · on Claude80 / 100
Unresolved.cx - When Feedback Has To Matter - Paul TuckerUnresolved.cx · on Claude80 / 100
The USB Problem for AI: Phil Stafford on Agents, Governance, and MCP Risk84 / 100
AI Security: Gerald Auger on Shadow AI, Non Human Identities, and AI Defense84 / 100
AI Security: Patricia Titus on Shadow AI, Non-Human Identities, and AI Defense79 / 100
ClearTech Loop Special Edition: Rethinking CDN Pricing with AWS CloudFront63 / 100
AI Security Starts with Education: James McQuiggan on Shadow AI, NHIs, and AI Defense71 / 100