AI Security, Cyber Risk, and Cloud Strategy on ClearTech Loop

The USB Problem for AI: Phil Stafford on Agents, Governance, and MCP Risk

• ClearTech Research / Jo Peterson • Season 3 • Episode 1

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 13:11

Short Description 

Season 3 of ClearTech Loop kicks off with AI security architect Phil Stafford in a practical conversation about AI governance, agent permissions, fractional identity, and why MCP servers may be the next software supply chain risk hiding in plain sight. 

Episode Description 

AI agents are moving from interesting experiments into real business environments. That means they are not just answering questions anymore. They are calling tools, touching systems, inheriting permissions, and creating a new layer of operational risk that technology and security leaders need to understand. 

In the Season 3 kickoff of ClearTech Loop, Jo Peterson sits down with Phil Stafford, AI security architect, security researcher, and cybersecurity professional, to talk about what happens when agentic AI stops being theoretical and starts acting inside the enterprise. 

This conversation gets into the practical questions leaders should be asking now: How do we govern agents when the legal system is still catching up? How do we limit what agents can actually do? What happens when an agent inherits a user’s full permissions? And are MCP servers becoming the next software supply chain problem? 

Phil puts it plainly: MCP has been described as the USB for AI. That is useful, but also a little terrifying if organizations treat every new connector like it belongs in the enterprise by default. No one would pick up a random USB stick in a parking lot and plug it into a company system. And yet, that is not a bad description of how some AI tooling is being adopted right now. 

This episode is for anyone thinking about AI governance, AI security, agentic AI, MCP servers, identity, permissions, supply chain risk, or what due diligence needs to look like when AI systems are allowed to take action. 

In This Episode 

Jo and Phil discuss: 

  • Why AI governance has to move beyond policy language and into operational controls 
  • Why measurement is the first step in governing AI agents 
  • Who may be accountable when an AI agent makes an unauthorized decision 
  • How the confused deputy problem shows up in agentic AI 
  • Why agents should not automatically inherit full user permissions 
  • What fractional identity means and why it matters 
  • How sub-agents can create another layer of access risk 
  • Why MCP servers need to be treated like part of the enterprise stack 
  • How MCP security connects to software supply chain security 
  • Why AI SBOM-style thinking may become increasingly important 

Featured Quote 

“MCP was sold to us as the USB for AI… You would not pick up a USB stick in your parking lot and put it into your enterprise environment. That’s what people are doing right now.” 

— Phil Stafford 

Why Listen 

Because AI governance is no longer just a strategy conversation. Once agents begin acting inside workflows, systems, and business processes, the risk becomes operational. This episode helps leaders think more clearly about what needs to be measured, limited, validated, monitored, and documented before agent behavior becomes tomorrow morning’s problem. 

Chapters 

00:00 — Introduction to Season 3 of ClearTech Loop 
00:28 — Meet Phil Stafford 
01:00 — Operationalizing AI governance 
01:14 — Why measurement comes first 
01:58 — Legal accountability and due diligence 
02:43 — The confused deputy problem 
03:39 — Why agent permissions need to be scoped 
04:05 — What fractional identity means 
05:45 — Time-bound permissions and agent behavior 
06:48 — Sub-agents and inherited access 
08:17 — MCP servers and the AI security lifecycle 
08:35 — MCP as the USB for AI 
09:53 — Allow lists, detection, and unapproved servers 
10:35 — MCP as a software supply chain issue 
11:32 — AI SBOMs and applying existing controls 
12:18 — Closing thoughts 

Guest Bio 

Phil Stafford is an AI security architect, security researcher, and cybersecurity professional. He advises organizations on AI security infrastructure, cybersecurity foundations, AI transformation strategy, and secure implementation practices. His work focuses on practical approaches to AI security, MCP risk, agent reliability, and the infrastructure needed to support safer AI adoption. 

Resources 

Follow ClearTech Loop 

ClearTech Loop is hosted by Jo Peterson, CIO of Clarify360 and Chief Analyst at ClearTech Research. Subscribe for more Season 3 conversations on AI security, governance, infrastructure, cloud, cybersecurity, and the technology decisions shaping enterprise strategy. 

🎧 Listen: In Buzzsprout Player
▶ Watch on YouTube: https://www.youtube.com/@ClearTechResearch/videos
📰 Subscribe to the Newsletter:
https://www.linkedin.com/newsletters/7346174860760416256/  

Jo Peterson:

Hey everyone, thank you so much for joining this episode of Clear Tech Loop. I'm Joe Peterson, I'm the CIO of Clarify 360 and the chief analyst at Clear Tech Research. And today I've got mr. Phil Stafford here with me. Hi, Phil.

Phil Stafford:

Hi, how are you doing?

Jo Peterson:

Good, thank you for joining today.

Phil Stafford:

Glad to be here

Jo Peterson:

Yes, nice to have you here. So, Phil is an AI security architect and researcher. He advises founders and companies on AI security and cyber security foundations, including best practices and security customization schemes. Additionally, he shepherds SMBs and startups through AI awareness and implementation to self-sufficiency. And who doesn't want to be self-sufficient? Everybody does. So, as normal, we have three questions. And let me get going with the first one, Phil. How do we operationalize AI governance? That's the first part, and then who is legally accountable when an AI agent makes an unauthorized decision.

Phil Stafford:

So, the first part about governance, the first step is measurement. You need to know what your agents are doing. A lot of organizations will just start writing policies for best case scenarios, or what they think it should be going on. That's not really governance, that's just liability theater. So, first you have to make sure you're measuring what agents are actually doing in your environment. As far as accountability, the problem is that legal system really hasn't given us answers yet. We're still working all of that out, but in the meantime, what organizations can do is make sure that they can prove that they exercise due diligence before they've deployed anything. Then you have evidence and you can show that you actually did something.

Jo Peterson:

I love that, and I love the term legal theater. I think you should coin that. That's great, you know. It's, I mean, it's such a dicey environment, and I would hate for the poor system to get blamed for an AI agent that made a bad decision, right? Because whose fault should it be? Not, you know, it's.. it seems that we're. is that is where the arrow goes these days.

Phil Stafford:

Yeah, I think that it's really about whose authority the agent was was deployed under, not necessarily pushing the person who pushes the button, but the person who signed off on it.

Jo Peterson:

Right, right. And you're right, the legal system is just sorting some of this out. It seems that legal is always a bit behind tech,

Phil Stafford:

always

Jo Peterson:

just the way it works, right? I just, I like this. I just heard MCP referred to as the confused deputy. How do we prevent agents from executing actions that the user should not be allowed to perform?

Phil Stafford:

So the confused deputy issue arises when you have an agent that's deployed, and it, it, the system sees your agent as you, it inherits all of your permissions, so in the course of doing its task, it also doesn't know what it shouldn't do, it just knows what it can do, and it has your full permission set, so it does anything it can do to get to its goal, which may not necessarily be the right thing. It's like if I gave an intern my badge to get into the office, but my badge also lets them into the server room.

Jo Peterson:

Yeah, that's a problem. So part of the issue is really just scoping down permissions for agents, maybe with fractional identities, so that the system then sees Phil's agent, not Phil. Yeah, so take, get, let's stand there a second, because I'm not sure that everybody understands the concept of a fractional identity. What is that? A

Phil Stafford:

fractional identity, so normal normal identity is then the system recognizes you as you with all of your permissions and authorizations. A fractional one ties that to you, but is more of your delegate, so an agent is still you as far as the system is concerned about upward stream, like accountability, things like that, but it can only do a limited set of your permissions, so it's a subset of your permissions.

Jo Peterson:

Okay, so, so then let me tease that out a minute, because I think that's fascinating with this fractional identity, is it then a sub identity of mine? How are we baselining and accounting for that identity?

Phil Stafford:

You've got it right. It really is kind of a sub identity we're using, you know, in this case, you. The accountable person, and you're the one with permissions, but it only has a small amount of your permission, so the system now constrains that agent even tighter, so that now it, what it can do, is limited to what it should

Jo Peterson:

do. Okay, so two other questions come to me from that. The first is the idea of duration of permissions. Does this subset of my identity have my sort of like I could log into something 24/7 How about this subset? How do we rationalize for the amount of time that that subset of my permissions is allowed to access things,

Phil Stafford:

it's the same kind of thing. That's what fractional identity helps with, is that it now has limited time. You can have limited permissions, you can have limited time, any sort of behavior that you would normally do, it now is constrained. So maybe you're working from nine to five, but this agent's only going to run at 11, only going to run right in the morning, that's it. If it runs at any other time, the system flags it, even if you are supposed to be there, right? Agent wasn't supposed to be on, and so it notices it's we've got the tooling that we're working on. There's a lot of tooling in this space right now, yeah, but everything's new. That's the thing about this field. Every day, there's something else.

Jo Peterson:

Yeah, literally

Phil Stafford:

every day.

Jo Peterson:

Yes, it, yeah, it feels like, oh, right. And then let me stand here a second, because so this subset of my identity, this partial agent, or this, this partial identity of mine, can it spend spin up an ephemeral agent on its own?

Phil Stafford:

That depends on if you give it the permissions to do that, you know. There's tooling that allows you to do that. Sub agents, Claude has that right now, where it also spin off sub agents. If you give it permission, absolutely, it could kind of

Jo Peterson:

why I asked the question. Yeah,

Phil Stafford:

yeah, and then you have the same, the same issue, where the sub agent, if you don't have any more controls, would inherit all the permissions of your agent, so maybe you want to give it a smaller fraction, that's why fractional is the word to work on.

Jo Peterson:

Yeah, that's slice

Phil Stafford:

that pie even smaller. Let your agent go put a bunch of sub-agents out in the world, but with even more limited permissions, so that they're only doing the thing they need to be doing, and that's all because they'll try, they'll try really hard to do whatever it is you set them out to do, and they just don't know what they shouldn't do,

Jo Peterson:

what they shouldn't do, right? Okay, another thing that drives me a little bit crazy, I know we need it, I know it's a necessary evil, is MCP servers, and it drives me a little crazy because it feels wild west, just to me, I don't know, so let me stand still there. Any, any personal grudges against MCP servers that you'd like to share? Do you love them? Do you hate them? Are they, are they, are they met, like oatmeal to you? Like, why?

Phil Stafford:

Well, I don't. I wouldn't say that I have a personal grudge against them, but I do, in the way that we deploy them, and this is this is this security, the security lifecycle in a nutshell. For the last 50 years, we make a thing that works, and then we try to secure

Jo Peterson:

it. Yes,

Phil Stafford:

which is, of course, it's how you would do it, because why wouldn't you? But sometimes we're a little too reckless. One of the things that MCP was sold to us as, and I think it's a really apt parallel, is that it's like the USB for AI.

Jo Peterson:

Oh, that's good,

Phil Stafford:

which is great. I think it's great. That's exactly what it does. It allows you to talk to other tools universally, but it's also the USB for AI. You would not pick up a USB stick in your parking lot and put it into your enterprise environment. That's what people are doing right now. That's what's happening. So it's really, it's a matter of knowing what it is that you're using, knowing which servers are good, which servers are bad? Having an approved list in your enterprise environment, and then not allowing other ones to run

Jo Peterson:

well. Let's talk about the not allowing other ones to run thing, because that seems like a great idea, but what's happening is everybody's got an MCP server, and so now the security team is tasked with authenticating and trying to figure out security for third party MCP servers. How do we do that?

Phil Stafford:

Well, it's very similar to when we all had cloud apps, we all had that. Shadow, it's going on, where you'd have users just installing whatever they could to get their job done, very similar to agents, they're going to do whatever they can to get their job done, not necessarily what they should do the right way, right. Okay, so if we're scoping everything down to an allow list of MCP servers, and you have detection tools in your environment to know what else is being run. There's a call out to an MCP server in, you know, a country that you know you don't, you don't have anything in,

Jo Peterson:

right?

Phil Stafford:

You can flag that, and you can stop that. That's a simple, simple way of doing that.

Jo Peterson:

Yeah,

Phil Stafford:

but a lot of this is supply chain too, just, just like recently, you know, the supply chain attacks are all the rage now. We solve this for security or for software, you know. We did desk bombs, we did co-signing dependencies.

Jo Peterson:

Yeah,

Phil Stafford:

we just do the same thing for MCP servers. Know what your MCP server is doing, what it's calling, what it needs, and then where in that chain might be weakest,

Jo Peterson:

so I mean, I think you're a fortune teller, because I think we're going to start seeing S bombish type software for MCP servers. I think that's what we're going to start seeing come out, because how could we not? Because it's

Phil Stafford:

absolutely

Jo Peterson:

right, it's too hard to figure out otherwise. I mean, you know, it's kind of like in my head going, well, how do we blacklist

Phil Stafford:

it? Right, it's, it's, it, we have the controls already.

Jo Peterson:

Yeah,

Phil Stafford:

it's not magic, it just means thinking about it the same way we always have and reapplying what's different, so it really is more like a software supply chain than anything else. I'm working on the work stream for the Coalition for Secure AI's S Bom, actually AI S Bomb,

Jo Peterson:

that's so cool. Yeah,

Phil Stafford:

I know, and that's the kind of things that we work on, is really like building things out the exact same way using the exact same formats. What does this MCP server need? What does it do? What do the dependencies need, and what do they do? Because that's that's where you, that's where we're getting hit. People are sneaking in something up their supply chain.

Jo Peterson:

Yeah, and now, and now on top of it we find out our AI doesn't like us through Mult Book, they don't like us, even

Phil Stafford:

I don't know about that, I think I think Malt Book was AI, AI knows how to pretend to be Reddit.

Jo Peterson:

Oh, nice. Okay, that's cute. All right. Well, you know what? We had another guest, Gerald, recommend you, and he said you were smart and fun, and he was right. So, I'm so glad that you took some time out of your day to come visit, and y'all, thank you for taking time to visit with us as well. Feel nice chatting with you.

Phil Stafford:

Thank you so much. Great to be here.