MCP servers are forcing a rewrite of API security assumptions

At a glance

What this is: This is an analysis of how MCP servers change the security model for AI-to-tool integration by making tools discoverable, centrally brokered, and easier for agents to use.

Why it matters: It matters because IAM, PAM, and AI security teams now have to govern runtime tool discovery, centralized credentials, and machine-driven access patterns that do not fit classic API assumptions.

By the numbers:

• In December 2025, Anthropic reported more than 10,000 active public MCP servers, showing how quickly the protocol is spreading across tool integrations.
• According to Equixly, 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Equixly also found that only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Equixly's analysis of how MCP servers challenge traditional API security models

Context

Model Context Protocol, or MCP, is a standard for connecting AI agents to tools and data sources through a common server layer. In this article, the primary security question is how that abstraction changes the assumptions behind API authentication, authorization, and auditability, especially when the caller is a machine rather than a person.

Traditional API security assumes developers know in advance which endpoint will be called, by whom, and under what workflow. MCP weakens those assumptions by letting tools be discovered at runtime, which creates a new governance problem for secrets, least privilege, and traceability across AI, IAM, and NHI programmes.

For identity and access teams, the important shift is that MCP servers can become a control point for non-human identity governance, not just another integration pattern. That makes the protocol relevant to secret management, access scoping, and monitoring of autonomous tool use across cloud and application estates.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create more risk than traditional APIs?

A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls. Traditional APIs usually expose fixed interfaces; MCP adds a broker that can widen the blast radius if credentials or permissions are too broad. The danger is delegation without enough identity governance.

Q: What breaks when MCP tool permissions are scoped too broadly?

A: Broad scoping breaks least-privilege governance because the same workload can invoke tools and reach resources far beyond its actual role. In practice, that makes audits less reliable and magnifies the blast radius of any compromise or misconfiguration. The fix is narrower claim-based policy, not looser trust in the calling identity.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

Why MCP servers change the authentication model for API access

MCP servers do more than expose endpoints. They publish tools, prompts, and resources in a manifest that an AI client can inspect at runtime, then use JSON-RPC sessions to negotiate what to call next. That makes the server behave less like a passive API and more like a policy-aware broker for machine intent. The security consequence is that authentication alone is no longer enough. If the server can enumerate capabilities without strong authorization boundaries, discovery itself becomes part of the attack surface, especially when credentials are stored close to the integration layer.

Practical implication: treat MCP discovery as a privileged function and gate it with explicit tool-level authorization, not only login controls.

How centralized MCP gateways expand the blast radius of secrets and tools

Many MCP deployments sit between AI clients and multiple downstream APIs, acting as a translation layer. That centralization makes integration easier, but it also concentrates secrets, permissions, and audit responsibility in one place. If the gateway is compromised, the attacker may inherit orchestrated access to several connected services rather than a single endpoint. This is where classic API segmentation breaks down, because the MCP layer can turn many isolated integrations into a single trust domain. The risk is especially acute when hard-coded credentials, session identifiers, or broad service tokens are embedded in server configuration.

Practical implication: segment MCP servers by trust domain and remove shared credentials from configuration files and runtime manifests.

Why tool self-description creates new NHI governance pressure

MCP is declarative: the server describes what it can do, and the model decides what to use. That is useful for flexibility, but it creates a governance gap if tool permissions, data access, and logging are not tied to a controlled identity lifecycle. In practice, the MCP server becomes an NHI control plane for AI agents, service accounts, and delegated access tokens. Without scoped entitlements, short-lived credentials, and audit trails, the protocol can expose more than it secures. The issue is not that MCP is insecure by definition, but that its runtime flexibility demands identity controls that many API programmes were never built to enforce.

Practical implication: manage MCP-connected services as non-human identities with scoped entitlements, expiration, and full audit coverage.

Threat narrative

Attacker objective: The attacker wants to turn one compromised MCP control point into access to multiple backend systems, data sources, and privileged operations.

1. Entry occurs when an attacker reaches an MCP server that auto-discovers tools or accepts weakly protected configuration and session data.
2. Escalation follows when hard-coded credentials, broad service tokens, or over-permissioned tool access let the attacker pivot into downstream APIs and connected systems.
3. Impact is orchestrated access across multiple services, with the potential for unauthorized data access, command execution, or wider environment compromise.

NHI Mgmt Group analysis

API security is no longer just about endpoints. It now includes the machine identity layer that brokers tool discovery and execution. MCP changes the trust boundary because an AI client can discover capabilities dynamically rather than operate against a fixed developer-defined path. That means access governance has to cover the server, the secret, and the delegated action together. Practitioners should stop treating MCP as a transport detail and start treating it as an NHI control point.

Centralized MCP gateways create a new form of blast-radius concentration. The article makes clear that one server can sit in front of many services and translate many APIs into a single discoverable interface. That simplifies integration, but it also means one weak control can expose an entire tool estate. The governance lesson is that segmentation and scoped delegation matter more, not less, when the interface becomes standardized. Practitioners should design for containment, not convenience.

Hard-coded secrets in MCP configuration files are a governance failure, not a deployment nuisance. Once credentials live beside auto-discoverable tools, the protocol can turn a configuration mistake into broad machine access. This is the same control gap seen in many NHI incidents: hidden persistence, weak lifecycle management, and absent scoping. Practitioners should align MCP administration with secrets governance, rotation discipline, and access review.

Named concept: the MCP trust expansion gap. MCP expands what an AI system can reach before identity controls have been fully adapted to the runtime discovery model. That gap is where tool exposure, authorization scope, and auditability fall out of sync. The practical conclusion is that AI integration teams must narrow the trust expansion gap before scaling the protocol further.

Traditional API controls remain necessary, but they are insufficient when the caller is an AI agent operating through an MCP broker. The real governance challenge is to verify not only the request, but the delegated context that allowed the request to happen. That pushes identity teams toward stronger machine identity policy, tighter service-account governance, and more explicit tool-level authorization. Practitioners should assume MCP increases the need for identity discipline rather than reducing it.

What this signals

MCP is turning AI integration into an identity governance problem. As agents move from fixed API calls to runtime tool discovery, security teams will need stronger ownership of delegated credentials, scoped permissions, and audit trails. For identity programmes, this means MCP should be reviewed alongside service accounts, workload identities, and other non-human access paths rather than treated as a separate architecture concern.

Configuration hygiene now has direct access-control consequences. When secrets live in server manifests or config files, the MCP layer becomes both an orchestration broker and a credential repository. That combination increases the value of secrets management discipline, especially where AI clients can discover tools automatically. Teams should expect tighter coupling between secret governance and agent monitoring.

OWASP Agentic AI Top 10 is a useful external lens for this category because MCP sits at the intersection of tool misuse, identity abuse, and runtime delegation. Practitioners should use that framing to challenge whether their current controls can constrain machine intent before they scale AI-assisted workflows.

For practitioners

• Inventory every MCP server and connected tool Map each server to the downstream APIs, service accounts, tokens, and data sources it can reach. The goal is to understand where one runtime broker can expand access across multiple systems.
• Remove hard-coded secrets from MCP configuration Move credentials out of server config files and into managed secret stores with rotation, revocation, and audit logging. Configuration should never be the durable home for tokens or keys.
• Scope tool permissions per use case Apply least privilege at the tool level so an agent can call only the functions it needs. If access scoping is missing, the server becomes a broad delegation layer instead of a controlled interface.
• Treat MCP servers as NHI assets Place MCP services under the same ownership, review, and lifecycle controls used for service accounts and workload identities. That includes access review, credential expiry, and logging tied to each delegated action.

Key takeaways

• MCP changes API security by making tools discoverable and brokered at runtime, which expands the trust boundary beyond traditional endpoint controls.
• The strongest evidence in the article is not theoretical: hard-coded credentials and weak tool scoping are already common in MCP deployments.
• Identity teams should govern MCP as NHI infrastructure, with scoped delegation, secret hygiene, and auditability at the center of the design.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool scoping: Tool scoping is the process of limiting which actions an AI client or service account can invoke through a protocol or platform. It is the control that prevents conversational access from becoming broad execution, and it should align with the smallest set of operations needed for the task.
• Machine Intent: Machine intent is the action an AI system chooses to take after interpreting available tools and context. In MCP architectures, security teams must govern not only the identity of the caller, but also the scope and auditability of the actions that the machine can decide to execute.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

What's in the full article

Equixly's full blog post covers the operational detail this post intentionally leaves for the source:

• Protocol-level analysis of how MCP servers translate tool discovery into runtime execution
• Specific security findings on command injection, SSRF, and path traversal in tested MCP implementations
• Practical testing guidance for validating MCP server exposure before agents are allowed to use them
• Details on early-access support for MCP testing within Equixly's platform

👉 The full Equixly post covers MCP architecture, security assumptions, and testing guidance in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It is designed for practitioners who need to connect identity controls to modern AI and infrastructure programmes.