AI agents are transforming businesses, but who’s really pulling the strings? As the Model Context Protocol (MCP) becomes the go-to bridge between AI models and tools, security and IAM teams are uncovering a few unexpected bumps in the road. 

At Astrix, conversations with customers, partners, and industry experts have surfaced key lessons about MCP’s early challenges and, more importantly, the solutions that turn risk into reward. But let’s not get ahead of ourselves. 

This will be a series where we’ll tackle both sides: first, the MCP security challenges we’ve observed, and then (in part 2) how MCP’s own structure might also be the solution. In the last post (Part 3), we’ll see if MCP is the future or a fad – and we’re going to ask you to help out. If you want to help your peers see into the future of MCP, please take our 5 question, no hassle, multiple choice survey.

The goal is to be candid about the pitfalls, but optimistic and constructive in solving them. (Spoiler: Done right, MCP can become the linchpin of AI identity governance rather than a roadblock.)

AI Agents = Exploding Identities

The rise of AI agents is truly astounding – in some organizations, they now vastly outnumber human employees. AI “coworkers” book meetings, write code, and handle data, and each of these agents acts with a form of identity and access. Naturally, these are the Non-Human Identities (NHIs) Astrix has always been focused on. This AI Agent surge is exciting, but we’re being told it brings unprecedented security and governance challenges. 

How do you manage what all these autonomous agents are allowed to do? If you’re a security or IAM professional suddenly responsible for an army of bots, you’re not alone in feeling anxious.

Early Blind Spots in AI Identity Governance

Credential risks in MCP implementations

The Astrix Research team analyzed over 5,200 unique, open-source Model Context Protocol (MCP) server implementations to understand how they manage credentials and what this means for the security of the growing AI agent ecosystem. The research findings were eye-opening: the vast majority of servers (88%) require credentials, but over half (53%) rely on insecure, long-lived static secrets, such as API keys and Personal Access Tokens (PATs). Meanwhile, modern and secure authentication methods, such as OAuth, are lagging in adoption at just 8.5%, confirming a major security risk across the ecosystem. Learn more here –> State of MCP Server Security 2025.

Dev-friendly, security-lite

MCP’s early design took a very developer-friendly approach to connecting AI models with tools, essentially using bearer tokens (API keys) everywhere for simplicity. Made by developers for developers. Unfortunately, what is easy for developers can create headaches for security. 

Customers are telling us they’re seeing a proliferation of API keys and other credentials spread across AI agents and scripts in MCP deployments. Each new integration often meant yet another static token floating around, or even worse, the same static token being used again and again. 

The result? A sprawling attack surface of secrets with little centralized control. Since the design of MCP made these tokens the only choice at first, they simply became the default.

Mixed adoption over risk concerns

Not everyone we spoke to jumped on the MCP bandwagon at first. In highly regulated environments, teams were (and still are) wary of adding a new abstraction layer they can’t confidently attest to auditors. 

We’ve heard “If it’s just some random thing the devs pulled off the internet, how do we trust it?” more than once. Some early AI adopters even skipped MCP and built their own integration layers, citing security as the reason. Of course, they also say they’re struggling with the adoption of their own integration platforms and are being pressured to use MCP. 

Others run MCP in limited ways (for newer, less sensitive apps) while keeping legacy direct API calls for critical systems. This patchwork means inconsistent security controls and a lot of confusion for identity governance.

Supply chain & third-party fears

Some of the most savvy folks we spoke with point out that relying on external or open-source MCP implementations introduces supply chain risk. Remember Heartbleed?  Now imagine a bug, backdoor, or vulnerability like that in a widely used MCP server component turning every AI agent using it into a double agent.

Security teams instinctively worry that a compromised MCP could become a single point of failure or a new attack vector. This has made some CISOs pump the brakes on MCP until it’s proven and hardened. The people thinking that maybe MCP could be part of the solution (as we’ll talk about in part 2) are not alone. It’s a classic security catch-22: adding a control layer can increase risk if that layer isn’t secure itself.

Identity blind spots

Perhaps the trickiest issue is that MCP initially did little to distinguish or manage identities. An AI agent using MCP calls a tool with a token, but out-of-the-box, there was no concept of “which agent (or which human on whose behalf) is doing this?” Again, our savvy customers are quick to point out that there’s work going on in the standards world to address this, but also fear it won’t come quickly enough to stop the current bad practices in MCP from cementing themselves into a long legacy of technical debt.

The protocol lacks built-in identity context and granular authorization – too many agents are essentially a super-user with a key. As a result, many security teams report lost visibility into who or what is performing actions through MCP. No fine-grained audit trails tying actions to a specific non-human identity (NHI) means potential misattribution and difficulty enforcing least privilege. 

We’ve already seen mishaps like leaked API keys and agents inadvertently (or maliciously) overreaching their permissions – all due to this lack of identity governance in MCP’s first iterations. Remember, you don’t need MCP to have these leaked keys cause issues – but since attackers know to look for them already, it’s destined to happen again if it proliferates.

On the flip side: A solution too convenient to ignore

Given the issues above, one might expect MCP to be shunned, yet we see the opposite. MCP adoption is mixed but undeniably rising. Even the most cautious people we spoke to say it’s rising for them. Why? Because it solves a massive pain point. Organizations were facing wasted time for scarce AI developers in cycles building bespoke integrations for each AI tool; MCP swooped in and “collapsed the M×N integration mess into a one-to-many standard”, to quote one insightful analysis. 

In practice, teams using MCP report dramatic reductions in complexity and faster time-to-market for new AI capabilities. When something makes developers happy and productive, it’s going to get used, even if security has to play catch-up.

Conclusion

MCP’s momentum builds as more success stories emerge, which in turn motivates vendors and open-source projects to invest in securing MCP, which then makes new adopters more comfortable. In fact, from what we’re seeing, there could be a tipping point soon – a moment where MCP adoption accelerates rapidly and “everyone” jumps on board, simply because the standard becomes ubiquitous. 

Despite some hesitations, we might be closer than ever to that critical mass. The takeaway for security and IAM teams is clear: MCP isn’t going away, so it’s time to turn those initial security challenges into an opportunity, which is exactly what we’ll discuss in our next chapter. Don’t forget to help yourself and your peers see into the future of MCP by taking our 5 question, no hassle, multiple choice survey today! 

Continue to part 2 to learn how MCP’s own structure might also be the solution, and Part 3, where we’ll see if MCP is the future or a fad – and we’re going to ask you to help out. If you want to help your peers see into the future of MCP, please take our 5 question, no hassle, multiple choice survey.