Cyber Sentries: AI Insight to Cloud Security

When “Ship Fast” Meets “Secure by Design” in AI Apps
AI-driven development is moving at breakneck speed—and attackers are taking advantage of the shortcuts. In this episode of Cyber Sentries: AI Insights for Cloud Security, host John Richards sits down with Gaetan Ferry, security researcher at GitGuardian, to unpack how modern AI tooling, MCP servers, and cloud platforms are reshaping the security landscape. The core problem: the same agentic workflows that boost productivity can also multiply identities, credentials, and blast radius if something goes wrong.
After John and Gaetan set the stage, Gaetan walks through a real-world-style vulnerability chain involving smithery.ai, an MCP server registry/hosting platform. It’s a practical look at how “classic” web issues can still show up in brand-new AI ecosystems—and how one small weakness can cascade into bigger supply chain risk. Along the way, they explore why secret sprawl is accelerating, what attackers are hunting for, and why observability is becoming as essential for identities and tokens as it is for infrastructure.
Why MCP Servers, OAuth, and Secret Sprawl Are Colliding
A big theme is the tension between usability and security: teams want agents that can “do everything,” which often means broad permissions and long-lived credentials. Gaetan explains why adopting OAuth is directionally better than static API keys, but still not a silver bullet in a world where agents need delegated access and tokens inevitably “live somewhere.” John pushes on what builders can do now—especially when new frameworks (and new hype cycles) keep resetting hard-won security practices.
The conversation lands on pragmatic guidance: reduce blast radius where you can, inventory identities and secrets, and invest in observability so you can respond fast when—not if—credentials leak. Note: This episode discusses breach scenarios and exploitation chains—be thoughtful about sharing internal security details and incident response specifics.
Questions We Answer in This Episode
  • How can a simple web flaw turn into an AI supply chain attack through MCP server hosting?
  • Why doesn’t OAuth automatically “solve” agent security and credential risk?
  • What does “limiting blast radius” look like when agents need broad permissions to be useful?
  • How can observability help you detect and respond to secrets sprawl across AI tools?
Key Takeaways
  • Treat MCP servers and agent integrations like critical supply chain dependencies—because they are.
  • Prefer short-lived, scoped credentials (OAuth when possible), but plan for token theft scenarios anyway.
  • Reduce blast radius with least privilege, separation of duties, and segmented agent access.
  • Build identity and secret observability so you can triage and remediate leaks quickly.
The Bottom Line for AI Security Teams in 2026
If you’re experimenting with MCP servers or rolling out agentic workflows, this episode is a timely reminder that fundamentals still win. John and Gaetan make the case that “moving fast” doesn’t have to mean accepting unlimited credential risk—you can ship quickly while still tightening scopes, tracking identities, and watching where secrets spread. Tune in for the real-world examples and the practical mindset shift that helps teams stay productive without becoming the next supply chain headline.
Links & Notes
  • (00:04) - Welcome to Cyber Sentries
  • (01:07) - Meet Gaetan Ferry
  • (02:19) - Attacks
  • (03:17) - Vulnerabilities
  • (07:38) - One-Off or Widespread?
  • (10:20) - Recommendations to Avoid
  • (14:19) - Exploiting
  • (16:50) - Resolving
  • (23:13) - Path Forward
  • (30:53) - Impact
  • (34:48) - Year of Supply Chain Attacks
  • (35:51) - Wrap Up

Creators and Guests

Host
John Richards II
Head of Developer Relations @ Paladin Cloud The avatar of non sequiturs. Passions: WordPress 🧑‍💻, cats 🐈‍⬛, food 🍱, boardgames ♟, a Jewish rabbi ✝️.

What is Cyber Sentries: AI Insight to Cloud Security?

Cyber Sentries explores the critical convergence of AI, cloud, and cybersecurity, diving deep into how these three pillars are actively redefining the modern Security Operations Center (SOC). As the threat landscape grows in complexity, we showcase the accelerating role of AI in defending cloud infrastructure, applications, and data. Join us as we illuminate this high-stakes intersection—a space where cutting-edge innovation meets the necessity for continuous vigilance—to transform how organizations approach resilience in a digital-first world.

John Richards
Welcome to Cyber Sentries from CyberProof on TruStory FM. I'm your host, John Richards. Here, we explore the transformative potential of AI, cloud, and cybersecurity, where rapid innovation meets the need for continuous vigilance. This episode is brought to you by CyberProof, a leading managed security services provider. Learn more at CyberProof.com. On this episode, I'm joined by GitGuardian security researcher Gaetan Ferry. He walks us through real-world examples of the vulnerabilities and exploits plaguing MCP servers and the latest AI-driven applications. We discuss ways to limit the blast radius and the importance of observability in preventing and responding to the proliferation of credentials across agents. All right, let's dive in. Hello everyone, welcome. Today we are joined by Gaetan Ferry. He's a security researcher at GitGuardian. Hey, thank you so much for coming on the podcast.

Gaetan Ferry
Okay, thanks for having me.

John Richards
Well, it's a delight to have you here. I want to start out by getting to know you a little better. Can you tell me how you got into security, and especially how that led to researching security over at GitGuardian?

Gaetan Ferry
Yeah, so I've been into security since the early days of my career. Basically, I started with it. I've worked as a red teamer for around seven or eight years in a great French consulting company. That's really where I learned about offensive security and things like this. And it was five years ago, something like that, that I switched to a more research profile. I've been doing security research since then, currently at GitGuardian, working around secrets, identity, authentication, and related topics.

John Richards
Awesome. I'm excited to have your knowledge here. I know you've been studying some of the recent attacks targeting AI. Can you share what you're seeing out in the field? What are the new ways we're seeing attacks, especially around MCP servers and things like that?

Gaetan Ferry
Yeah. This year, I mean 2025, and it's still early 2026, but 2025 has been, in my personal opinion, the year of supply chain attacks targeting all kinds of systems, including AI systems or AI-based applications. I documented what could have been a pretty severe supply chain attack in MCP servers in June or July last year, if I remember correctly, with a vulnerability chain in the smithery.ai MCP hosting platform.

John Richards
What did you find from looking into that attack? What was the real source of vulnerability there, and what was the danger? How were they using this to exploit?

Gaetan Ferry
Yeah, it was quite a funny study and funny vulnerabilities. I had been looking at smithery.ai for other reasons. So just to put the context here: smithery.ai was, and I think still is, an MCP server registry. Basically something like Docker Hub but for MCP servers. We were looking at MCP servers, especially MCP server code, looking for secrets when MCP started to get traction. So we studied MCP server code, and we used smithery as an entry point to a lot of servers’ code.

And while we were doing this study, we saw some little things that sounded fishy and could have led to vulnerabilities. We later came back to it and actually exploited those vulnerabilities.

How to explain this without getting too technical: MCP is a registry for MCPs, but it’s a little bit more than that. If you take Docker Hub, they host images, then you pull the images and run them wherever you want, on your machine or server. For MCPs, smithery is slightly different. They can host the MCP for you, as long as an MCP is a remote MCP, meaning it gives access to a remote service. So you can host it pretty much anywhere you want, and then smithery will allow you to host the server on their side. Basically, they take the code of an MCP server, build it on their infrastructure, and then run the server so you can interact with it remotely without having to think about where to put the server or how to host it. That’s really where the issue was.

To do that, smithery had to build your code. They had a small configuration file you need to add in your code repository. In the parsing of that configuration file, there was a vulnerability that is well known and called a path traversal. Basically, you could change the path of the repository on their infrastructure and get access to pretty much everything you wanted.

So that’s what we exploited originally. This vulnerability allowed us to read files in smithery’s infrastructure on their build servers, which is already pretty bad. What we found: at the time, smithery was hosted on Fly.io, which is a hosting platform that allows you to run virtual machines and things like this. They were using a Docker registry provided by Fly to store images of the MCP servers. To do so, they needed an access key to this registry. This access key was stored in a configuration file on the file system, and we could access this file using the vulnerability we discovered.

So we could steal this authentication token, which was already pretty bad, because it meant you could pull and push any service code. But worse than this: this token was poorly scoped and gave access to the whole API of Fly.io, which includes code execution on any machine they host. So basically, code execution on all the MCP servers they were hosting.

John Richards
Wow, that escalated quite a bit there, starting with the first vulnerability and then chaining through. What were your thoughts coming out of this? Is this a one-off where they made choices most folks aren’t? Or do you think this is more widespread, this kind of vulnerability?

Gaetan Ferry
As I said, it’s a funny one because it’s very well known. This kind of vulnerability, like path traversal, already existed in the 90s. It’s a very typical, very classical web vulnerability that, in theory, everyone is aware of and knows how to protect against. In that case it was really the bread and butter of path traversal. It was a very simple one. Exploitation was slightly tricky, but the vulnerability itself was very easy to find.

So, yeah, classical, but it shouldn’t have been there. Any serious developer should be able to see this and just not push that code into production.

My best guess is that the whole smithery service was highly vibe-coded, and it was vibe-coded a year ago, which is somehow the prehistory of AI if you look at the pace of evolution of these technologies. And I’m pretty sure that led to this issue going into production.

Then the token scope issue is very classical, and that’s systemic. We see this occur everywhere, especially in our work at GitGuardian. We study a lot of secrets and, basically, the least privilege principle isn’t always applied, or is even rarely applied. So that’s a classical one.

But the first one was funny because it was so easy and so classical.

What I found interesting: I found this vulnerability in smithery around June, if I remember correctly, and just two or three weeks later there was another service, about as young, called CodeRabbit, which was supposed to perform a code audit in CI using AI. And it got breached exactly in the same way. So probably something to look at here. And I’m pretty sure both services were vibe-coded, poorly vibe-coded.

John Richards
Yeah, so obviously there’s the first round of: how do we make sure we’re building this securely? But then once you got in, you got access to credentials that escalated the problem to a whole other level. What are your recommendations for folks out there trying to build these things to avoid this?

Everybody wants to get out there so fast, and so we’re throwing our keys in to make it work. Then either those can get committed and stored, but even if you’re pulling them out, do you remember to? Maybe they’re sitting out there exposed. It feels like we’ve reset on a lot of good security practices. What are your thoughts on why that is, and what people should be doing to make sure they don’t fall into those bad practices?

Gaetan Ferry
I have this opinion, and I think it’s shared by a lot of people: it’s something we see every couple of years. When you have a new technology coming out, everyone wants to take their share of the treasure and wants to go as fast as possible to provide new services leveraging those technologies. AI has been a crazy example of this, and MCP in particular.

What I find funny is how a year ago, mostly, MCP was not a thing. No one talked about MCP a year ago. Maybe one or two months in, but it wasn’t really something. Then it grew so fast, and there were a lot of services that popped up. The number of MCP servers available on the internet just exploded.

When I exploited this vulnerability, there were a little bit more than 4,000 different MCP servers hosted on smithery, which sounds like a lot. Every single server had to be linked to some service, and 4,000 was already pretty big. So it just exploded.

Now, like three months ago or two months ago, there’s this new “skills” by Anthropic that popped, and MCP is nearly already deprecated. It’s not really the case, but it’s happening again. MCP is less used, skills pop, and we’ll probably see more or less the same thing. I had a look at smithery just before we recorded this and they turned into a skills registry too, which was quite funny.

And that’s probably one reason why security is left behind. When you want to go fast, it’s hard to cope with security, and more often than not you leave security aside to move faster. It’s amplified by AI because now you don’t even have to type your own code; your AI will do it for you. It’s maybe less and less the case, but there have been a lot of studies proving that code produced by AI tends to contain more security issues. I’m not an expert on the topic, but I feel like it’s still the case. So it doesn’t help.

John Richards
Yeah. And I have more questions on that topic, but as you were saying this, it made me feel like I should clarify. You mentioned you’re a researcher at GitGuardian. You mentioned exploiting this. Can you talk a little bit about what that looks like? Because I know you’re not out there hacking this to steal money from these companies or with bad intentions. Share what that looks like when you’re coming in as a good guy but trying to find these issues, and what that reporting structure looks like when you do find exploits.

Gaetan Ferry
In this case it was a little bit special, but what we did: when we found the vulnerability, we wrote a proof of concept. We showed what was possible by exploiting the issue and then we reported immediately to smithery, which, by the way, was great in handling the report. They fixed the vulnerability very fast. We tested again, found more things, and that’s kind of the usual process: you find a vulnerability, it gets fixed, then you retest, and if there’s still something you report again, and they fix again. That’s definitely what happened. After two rounds, I think everything was better on smithery’s side.

So there was no red teaming. It was responsible disclosure.

But the consequences could really have been terrible. Once we had code execution on the MCP servers, you could execute whatever you wanted on them. And once you can execute what you want on the server, you can also see what the server receives.

What’s really interesting with those MCP servers is that they are used to connect to services. Let’s say GitHub, for example. You can connect via an MCP server. If you can see the requests to the server, you can collect the credentials to the service. That’s where this could have turned into a supply chain nightmare. We could have collected the credentials of all smithery customers and users across the world and used them to access whatever resources they had access to.

John Richards
Wow. I’m glad we’ve got good guys out there like yourself helping make sure we’re staying secure here.

For resolving this, is the answer just: use better authentication protocols, OAuth or something like that? Or is the challenge deeper than that?

Gaetan Ferry
It’s a complicated issue. There is OAuth in the MCP protocol specification, which is great. It’s what we’ve been trying to push as an authentication and authorization framework for services across the internet for years, slowly catching up.

The thing is, what we observe is that OAuth isn’t yet there for the MCP ecosystem. There are so many servers that don’t implement it and rely on legacy API keys, API tokens, and things like this, which makes the issue worse. In most cases when you use an API key or another kind of static credential to authenticate to a service, the key has a high chance of being badly scoped, as we’ve seen with smithery’s own keys. And it’s very often a long-lived credential. It can be live for a year, if not more, which opens a window for exploitation for a very long time.

It’s the classical scenario. It’s what we’ve seen in applications relying on API keys. And you should move to OAuth for your MCP server like you should move to OAuth for other kinds of APIs and applications.

So yes, OAuth would help, but in that specific case with such a supply chain attack scenario, it’s not a silver bullet. You can use OAuth, but if you use OAuth you need to at some point either store OAuth credentials, which doesn’t change anything, or you need to use delegation, and at that point the application will have to store some tokens somewhere to be able to act on your behalf. Those can also be weak points and can be stolen.

We were talking at the beginning about attacks we’ve seen this year, and one attack illustrates this: the Salesloft/Drift supply chain that occurred somewhere around the summer. Threat actors managed to compromise the Drift application by Salesloft. It’s a complicated chain, but they were in for months after compromising the CI/CD of Drift.

What they did: they compromised the Drift application. Drift was an AI chatbot that allowed people to query their knowledge base and especially their Salesforce installation. In that process, Drift used OAuth for authorization against Salesforce instances. When attackers got into Drift, they collected all the OAuth application tokens stored by Drift and used them to access Salesforce and Google Workspace environments and dumped everything.

John Richards
Oh wow.

Gaetan Ferry
So it’s more or less the same with MCPs. If you use OAuth, that’s definitely better. You can more easily refine scope and make tokens short-lived. But at some point the credential lives somewhere. If an MCP server gets compromised, if it stores OAuth credentials, it’s going to be a nightmare too.

John Richards
That makes sense. You may be able to limit the blast radius and you should be shortening keys and limiting scope as much as possible. But you can’t solve everything with just “drop this in” as a security practice. You really need to be paying attention to each layer of your defense.

Gaetan Ferry
Yeah, that’s true. And I would even say, maybe slightly unpopular opinion: I don’t think we solve anything with OAuth in MCP. I mean, we solve the issue MCP had. But we’ve been using OAuth for years. I think the first version of the OAuth spec dates back from 2014, if I’m correct. We’ve been using OAuth for all kinds of services for years, so we already know it’s better.

MCP didn’t include OAuth in their original specification, which was not a smart move, but things have to evolve.

The real issue we have is that systems, agents, and things like this come with a lot of identities. OAuth in MCP doesn’t really solve the issue, it just amplifies an existing issue, which is the explosion in the number of identities. Using OAuth is better than using a plain old API key, but it doesn’t solve the underlying issue: you’re putting credentials everywhere for every kind of application and service.

John Richards
So what’s the path forward from here? Maybe that helps us be a little more secure, but we’re still dealing with mass proliferation of identities and keys out there. And every time we swap technologies—now skills or whatever comes next—we’re resetting these practices. Is there something you’re recommending, or is it really: pay attention to security fundamentals? What should folks actively developing and building this technology be doing differently to avoid the risks, or minimize them?

Gaetan Ferry
That’s a very good question. My opinion is that as an industry we are not quite there yet in terms of security for agentic infrastructure, especially authentication and authorization and identities in general. OAuth was a good step forward, and I’m glad we came up with OAuth in the MCP specification, but it doesn’t solve the whole issue.

The problem with agents is: when you give your coding agent access to your GitLab because you want it to work with GitLab, you want it to do pretty much everything because that’s what helps you in your development process. In a lot of cases, when you configure your agent, even if you use OAuth, you’ll provide all the privileges—or at least enough privileges—that if the credentials leak, it’s going to be a nightmare. You want your agent to read code, push code, write issues, all kinds of things attackers would be happy to do on your GitLab. I don’t see a way to really limit this. People want this, and if they want this, they’ll do it. OAuth can’t really solve that.

We can partially restrict actions in some cases, but not in others, just using OAuth. That’s where I think we are lacking new frameworks and technologies: context-aware authorization and things like this. I’m imagining here—I don’t think this exists in a usable form or as a standard—but what would be great is behavioral authorization for agents that would allow or prevent agents from doing things in specific contexts.

For example, if we remember an attack on the GitHub MCP server a few months ago, one of the first documented attacks using prompt injection: someone pushed an issue to your repo, and via MCP your agent pulled the issue, parsed it, and wanted to react. The issue could contain a prompt injection that forced the agent to do things, and it could use the GitHub MCP itself to do harm on your repositories. I think the attack made a private repository public or something like that. In that case OAuth doesn’t help. You want your agent to pull issues and push code. What we need is technology to filter in which cases those actions can occur, and how you can link actions.

We’re not quite there yet. So if you are an AI developer, or an AI agent user—and they are pretty much everywhere now—you need to be conscious of what’s happening with identities and the privileges you give to your agents. The number one thing is: be conscious of what you’re doing and understand there is a risk. You can accept that risk. Most people will accept it because they want to use AI that way.

But as soon as you understand you’re introducing a risk—connecting everything everywhere, opening gates, giving privileges to your agent, privileges that you can give to an attacker in some cases, like with a supply chain attack like smithery—then you can start thinking about limiting the blast radius. That’s really the only thing we can do right now: limiting the blast radius with the classics like least privilege, scope reductions, separating your agents into categories depending on what data they need to access, and things like this. The classic stuff.

John Richards
Getting back to fundamentals seems more important as things move quickly, so you don’t forget those and just try to get out the door first.

Gaetan Ferry
Yeah, absolutely. It’s like in sports: you always need to go back to the fundamentals at some point because that’s the only thing that will always work and always provide good security. Then you can think about the next step.

At the moment, an important measure you can set up is observability on your identities. It’s not an easy problem, but at least we already have solutions and products off the shelf that try to solve it. With good observability you can know where things are going wild, where privileges are exploding, where the number of identities is growing too much.

And in case of a breach—which happens; we see that every other day—breaches based on compromised identities and secrets: when this happens and you have observability, you can more easily evaluate the risk and fix it everywhere, which is what people would have loved to have after the Shai-Hulud attacks and similar.

John Richards
How has this impacted GitGuardian? What’s the focus? Have you adjusted to help deal with these things? Are there tools that are useful?

Gaetan Ferry
At GitGuardian we’ve been working on identities and especially secrets—before they were called identities—for a long time. We were working on this issue before it became bigger with AI. With secret detection we can at least understand how people are leaking secrets, especially in their MCP configurations for coding agents.

We had a study a few months ago around secret leaks in MCP configuration as part of coding agents. It’s currently thousands of secrets leaked every other month. I had a look just before we started, and over the last three months, 1,200 valid secrets—secrets that we could prove valid—were leaked in a file named mcp.json. That’s just over the last three months. So it’s not slowing down.

We can help. We already detect them and we alert people, which we do free of charge as part of what we call the Good Samaritan Program. Every time someone commits a secret on public GitHub, whoever the person is, we send them an email. We probably send hundreds of these emails every week for secrets leaked in mcp.json files, and we already provide that.

Obviously, if you are an enterprise, you might want a more corporate, enterprise-ready solution, which we also provide.

The topic we’ve been working on a lot lately is observability. We are developing a product to inventory and evaluate the number of credentials lying around, and how privileged they are, and things like this, which is becoming more important.

A few years back, the big topic was software bill of materials, to avoid supply chain issues because of vulnerabilities in dependencies. What we are seeing now with credentials is similar. We need inventories of identities, secrets, and their privileges to be able to react when things go wrong—exactly like we wanted to react when we had a compromised dependency somewhere.

Except exploiting a leaked credential is far simpler than exploiting a vulnerability in a third-party dependency in a product. So I would say it’s even more important today for secrets and identity.

John Richards
Your example with Salesloft and how the third-party exploit allowed them to scale up and get access to people’s Salesforce accounts really shows that kind of downstream targeting and then leveraging access is still alive and well.

Gaetan Ferry
Yeah. As I said, I think 2025 has been the year of supply chain attacks. I can’t even count how many we’ve seen. But I think it started pretty early in February or March 2025 with the TJ Actions supply chain, which was already terrible. Then we’ve seen a bunch of other ones, then the Drift attack, then the Red Hat supply chain, and then there was npm and Shai-Hulud 1, and “ghost action,” and Shai-Hulud 2. It’s been supply chain everywhere, with a focus on secrets every time.

I really feel that nowadays threat actors are hunting for secrets and credentials of all kinds. It’s going to be more and more the case because credentials are just there and give access to everything. It’s terrible. We really need to work on this.

John Richards
Gaetan, thank you so much for coming on and sharing your research and expertise. This has been fascinating. Folks, check it out.

Before I let you go, anything you want to share or promote, or how can folks follow up? You mentioned you did some research or there are papers folks should check out that we can add to the show notes.

Gaetan Ferry
If there’s one thing: at GitGuardian every year we publish what we call the State of Secrets Sprawl Report, which is a pretty big and very interesting document that summarizes what we have observed over the last year in terms of volume, how many secrets we’ve observed, what kinds of secrets, scopes, and a lot of statistics and insight on the secrets sprawl issue.

The next issue will be published in early March, so less than a month from now, and I really encourage people to have a look. It’s completely free, non-gated, so you can download it freely without even providing an email. It’s open to the world. Just have a look. That should be interesting for most people that listen to us.

John Richards
I will echo that as somebody who has read and valued that report in the past. Definitely check it out. I’ll make sure we have a link in the show notes to it.

Thank you so much for coming on here. This has been fascinating.

Gaetan Ferry
Thanks.

John Richards
This podcast is made possible by CyberProof, a leading co-managed security services provider, helping organizations manage cyber risk through advanced threat intelligence, exposure management, and cloud security. From proactive threat hunting to managed detection and response, CyberProof helps enterprises reduce risk, improve resilience, and stay ahead of emerging threats. Learn more at CyberProof.com.

Thank you for tuning in to Cyber Sentries. I’m your host, John Richards. This has been a production of TruStory FM. Audio engineering by Andy Nelson. Music by Amit Sagee. You can find all the links in the show notes. We appreciate you downloading and listening to the show. Take a moment and leave a like and review. It helps us to get the word out. It’s no April Fool’s joke that we’ll be back April 1st right here on Cyber Sentries.