What is in for me?
When Anthropic announced the Model Context Protocol (MCP) in November 2024, it solved a fundamental problem: how to give AI agents secure, standardized access to external tools and data sources.
Just over a year later, MCP has become the de facto standard for agent-to-tool communication, with implementations spanning everything from database connectors to CRM integrations. But as Astrix’s State of MCP Server Security 2025 report reveals, the security model underneath this infrastructure layer is breaking down.
MCP servers have quietly become the identity and policy choke point for entire agent environments. When security fails here, it fails everywhere downstream. Yet most organizations treat MCP servers as simple API gateways rather than the trust concentration points they actually are.
What MCP Servers Actually Do
MCP defines how AI agents discover, authenticate with, and invoke external tools through standardized servers. An MCP server acts as a bridge between an agent’s requests and the underlying systems it needs to access, whether that’s reading from a database, updating a CRM record, or triggering a workflow in a third-party service.
This architecture creates a natural control point. Instead of agents directly authenticating to dozens of services, they authenticate once to an MCP server, which handles downstream connections, translates requests into API calls, manages service credentials, and enforces access policies.
In practice, MCP servers accumulate substantial privileges. A single server might hold database credentials, SaaS API keys, OAuth tokens, and service account permissions across multiple systems. When an agent connects, it inherits access to everything the server can reach. The problem here, though, is that most implementations treat this as a convenience feature rather than a security function.
Where MCP Security Breaks Down
This convenience-first approach creates several security gaps that make MCP servers difficult to govern at scale. These problems show up across authentication, permissions, and monitoring functions:
Weak Authentication Models
Astrix’s analysis of over 5,200 open-source MCP server implementations found that 88% require credentials, but over half (53%) rely on static API keys or PATs that are long-lived and rarely rotated. Only 8.5% use OAuth, the standard for secure delegation. This creates problems when agents are compromised or decommissioned. Static credentials can’t be selectively revoked, and there’s no audit trail to determine what a compromised agent accessed.
Over-Permissioned Tool Access
Most MCP servers are configured with broad permissions and are never refined. This becomes particularly dangerous with MCP’s dynamic tool discovery capabilities. Agents can query servers at runtime to discover available tools, meaning a compromised agent can potentially access tools it was never meant to use or access at all.
Absence of Runtime Controls
Beyond controlling which tools agents can access, MCP servers lack mechanisms to govern how agents actually use the tools they can access. There’s no rate limiting to prevent excessive calls, no resource controls to cap consumption, and no behavioral policies to flag or block suspicious usage patterns. An agent making hundreds of database queries in seconds looks identical to legitimate batch operations.
Trust Assumptions and Visibility
Most MCP server deployments log basic request information but don’t provide context needed to understand agent behavior or detect security incidents. The logs show that a tool was invoked but not why, what data was involved, or whether the action was legitimate. This creates blind spots during incident response. Security teams can see actions that occurred but can’t reconstruct the agent’s decision-making or determine if behavior was malicious or misconfigured.
Why Legacy Security Tools Fall Short
The main security challenges with MCP servers point to a broader problem with securing AI agent infrastructure: traditional controls weren’t designed for dynamic, autonomous agent-to-tool communication, and trying to retrofit them creates gaps that leave the most critical risks unaddressed.
Perimeter Controls Miss the Point
Network controls that focus on blocking or allowing traffic don’t address the real risk because the traffic is legitimate, the protocols are standard, and the connections are authorized. What matters is what an agent does once it reaches an MCP server, and perimeter controls can’t distinguish between legitimate queries and data exfiltration because both look identical from a network perspective.
Identity Management Falls Short
IAM systems control which agents authenticate to which servers but can’t enforce fine-grained policies about what those agents actually do once they’re in. Once an agent has valid credentials all subsequent actions are treated as authorized, and this binary approach doesn’t match how agent ecosystems actually work. Organizations need controls that let an agent read but not write or invoke specific endpoints but not others, and most IAM platforms lack this kind of context-aware authorization.
Secrets Management Falls Short
Secrets management helps secure the credentials that MCP servers use for downstream systems but doesn’t address how agents use those systems once they’re connected. An MCP server with perfectly rotated credentials can still be exploited by a compromised agent because secrets management protects credentials at rest and in transit but goes blind the moment they’re retrieved.
The Need for a Comprehensive Approach to AI Agent Security
The broader challenge here is governing how agents use the access that MCP servers grant them. This requires visibility into every MCP server and the credentials it holds, dynamic policies that can enforce least-privilege on every agent-to-server connection, and monitoring that detects when agents step outside their intended scope. This is the Discover–Secure–Deploy framework applied to MCP infrastructure.
Discover means maintaining a real-time inventory of every MCP server, agent connection, and credential dependency, with the context needed to understand risk and business usage. Without this baseline, security teams cannot answer how many agents are running, what they can reach, or which connections carry the most risk. The 53% of MCP servers relying on static, long-lived credentials represent a blind spot most organizations don’t realize they have.
Secure means identifying and remediating excessive privileges, vulnerable configurations, and abnormal activity across MCP server connections. Ownership gets assigned, permissions scoped to least-privilege, and static tokens replaced with short-lived, precisely scoped alternatives.
Deploy means ensuring every new MCP server connection arrives provisioned with least-privilege, just-in-time credentials from day one, governed by policy rather than patched after the fact. Security scales alongside MCP adoption instead of chasing it.
This identity-first approach is what governing MCP infrastructure at enterprise scale requires. Without it, MCP servers remain ungoverned trust concentration points that expand the NHI attack surface with every new agent deployment. The next chapter looks at how this framework applies in practice.
