MCP servers are forcing a rewrite of API security assumptions

At a glance

What this is: MCP servers are changing how APIs are exposed to AI agents by making tools and data self-discoverable, which increases the security burden on authentication, authorization, and secret handling.

Why it matters: IAM, PAM, and API security teams need to account for machine-driven discovery and orchestration, because the control point moves from manual integration to the MCP layer.

Context

MCP changes the security problem because it makes tool discovery and orchestration runtime behaviours rather than fixed integrations. That matters for API governance, since an access model built for human developers does not automatically hold when AI agents can discover tools, request resources, and trigger actions through a standardized protocol.

The article’s core point is that MCP does not remove APIs. It wraps them in a new control plane that can concentrate authentication, authorization, and secrets into a smaller number of gateways, which is a familiar governance pattern in a new form. For IAM and NHI teams, that means the trust boundary shifts to the MCP server and the credentials it brokers.

Key questions

Q: What breaks when MCP servers do not require authentication?

A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.

Q: Why do MCP tool servers create a larger blast radius than simple APIs?

A: They often combine caller input, stored credentials, and outbound network reach in one component. If the server is not tightly governed, a single request path can expose internal services, privileged tokens, or reachable metadata endpoints. The risk is delegation, not just data exposure.

Q: What are the warning signs that an MCP deployment is overexposing enterprise tools?

A: Warning signs include overly broad tool discovery, agents reaching adjacent data without a fresh policy check, and responses being reused after user permissions change. Those symptoms show the protocol is enabling reach faster than the governance model can constrain it.

Q: How should teams govern agent access when both CLI and MCP are available?

A: Govern them separately, because they expose different execution patterns. CLI is usually easier to inventory, validate, and retire, while MCP can preserve state across multiple actions and therefore needs tighter session controls. Access reviews should include interface type, exposed tools, and how state is retained or discarded.

Technical breakdown

How MCP changes API discovery and orchestration

MCP introduces a declarative layer over traditional APIs. Instead of hard-coding every integration, an AI client can ask an MCP server what tools and resources are available, then invoke them through a standard JSON-RPC session. That makes the server both a catalog and an execution broker. The security consequence is that exposure now depends on what the server advertises, not just on what the underlying API endpoint can do. In practice, this shifts risk from isolated service-to-service calls to runtime capability discovery, which is harder to govern with static API assumptions alone.

Practical implication: Treat MCP servers as an access mediation layer and review what capabilities they expose before allowing agent access.

Why MCP concentrates authentication and secret risk

The article describes MCP servers as specialized proxies that often sit in front of existing tools and APIs. That means they can become repositories for tokens, credentials, and session state needed to reach those back-end systems. When that happens, the MCP layer is no longer a thin transport wrapper. It becomes a privileged control point holding multiple access paths, which raises the blast radius of a compromise and makes secret hygiene part of protocol governance, not just backend administration.

Practical implication: Centralize token governance for MCP and eliminate long-lived secrets wherever the server brokers access to multiple systems.

Why self-discovery creates a new API security assumption

Traditional APIs assume the caller already knows the target surface and the interaction sequence. MCP flips that assumption by letting the client discover tools at runtime and then execute against them. That is useful for agents, but it also means a malicious or misconfigured client can explore capabilities that were never meant for broad use. Security teams therefore have to validate not just the endpoint but the discoverability model, because an unauthenticated or overexposed manifest can reveal more than a conventional API definition ever would.

Practical implication: Constrain discovery, require strong authentication for manifests, and test what an unauthenticated client can enumerate.

Threat narrative

Attacker objective: The attacker wants to use the MCP layer as a trusted orchestration point to reach multiple connected systems with one compromise.

1. Entry occurs when an MCP server exposes tools, prompts, or resources without strong authentication, allowing a client to enumerate capabilities at runtime.
2. Credential access follows when the server brokers tokens or other secrets to reach multiple back-end APIs from a single privileged layer.
3. Escalation happens when a compromise of the MCP gateway expands into orchestrated access across connected tools, data sources, and system interfaces.
4. Impact is centralized abuse of the AI tool layer, including unauthorized data access, command execution, or broader service compromise.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Centralized orchestration becomes the new identity boundary: MCP does not just standardize tool access, it concentrates trust into the server that brokers discovery and execution. That makes the server’s authentication model, secret handling, and authorization decisions more important than the underlying APIs alone. For practitioners, the question is whether the MCP layer is now the real control plane for machine access.

Self-discovery creates governance debt: When tools are discoverable at runtime, the old assumption that security can be enforced only at integration time no longer holds. Capabilities can appear, change, or be exposed faster than manual reviews can track them. For identity and access teams, that means discovery itself has to be governed, not just the API behind it.

MCP turns machine identity into a policy problem: The article’s architecture is fundamentally about agents acting through a mediated identity path, which means access scope, session control, and credential lifecycle are now NHI concerns, not just application concerns. If the MCP server can speak for many tools, then one weak policy decision can widen the effective privilege of every connected agent. Practitioners should treat MCP governance as part of NHI and API control design.

API security must absorb agentic intent: Traditional API controls focus on caller identity and request structure, but MCP adds a layer where the caller is an AI system selecting tools dynamically. That means the control set has to account for both the prompt-driven decision and the resulting API action. For practitioners, the shift is from protecting endpoints in isolation to governing the decision path that produces those calls.

One named concept matters here: orchestration blast radius: MCP reduces integration sprawl, but it also creates a larger failure domain when the gateway or its secrets are compromised. That is the real governance trade-off the article surfaces. Security leaders should evaluate MCP by how much privilege it concentrates, not by how much convenience it adds.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Orchestration blast radius: MCP reduces connector sprawl, but it also concentrates privilege into the server that brokers discovery and execution. For practitioners, that means the control problem is no longer only API hardening, it is limiting how much of the environment one agent-facing gateway can reach.

A mature MCP programme should assume discovery is adversarial as well as helpful. If a low-trust client can enumerate too much, the architecture has already handed out the attack surface before any business action begins.

For identity teams, the most important shift is that machine identity and authorization now intersect at the orchestration layer. That is where access scope, session state, and downstream credential use need policy control, not just logging.

For practitioners

• Define the MCP trust boundary Map every tool, prompt, resource, and back-end API that the MCP server can expose, then classify which ones require stronger authentication or separate approval paths.
• Reduce secret concentration Move away from embedded tokens and shared credentials in the MCP layer, and assign each server the narrowest possible access to downstream systems.
• Test unauthenticated discovery Verify what an unauthenticated or low-privilege client can enumerate from the MCP manifest, because capability exposure can become a reconnaissance path.
• Audit agent-to-API authorization Check whether the MCP server can trigger actions that exceed the agent’s intended scope, especially where multiple back-end APIs share one orchestration point.

Key takeaways

• MCP changes API security by making tools self-discoverable to AI agents, which moves risk from static integration to runtime orchestration.
• The biggest governance issue is not whether MCP replaces APIs, but how much privilege and secret exposure the MCP server concentrates.
• Teams need to treat the MCP layer as a control plane for machine access and verify discovery, authentication, and authorization together.

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.
• Agentic Orchestration Layer: The governing layer that decides when an AI agent should act, what it may access, and when another system should take over. It is the policy and routing function above the agent, not the agent itself. In mature environments, this layer defines scope, confidence thresholds, and revocation boundaries.
• Runtime Discovery: The process by which an AI agent asks a server what capabilities exist before using them. Unlike static documentation, runtime discovery creates a moving target for security review because new tools can appear without code changes on the client side.
• Orchestration Blast Radius: Orchestration blast radius is the amount of downstream access exposed when a central control layer is compromised. In MCP environments, it describes how much damage one gateway, token set, or policy decision can create across connected tools and data sources.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management for practitioners building controlled access paths. It helps security teams align machine identity decisions with the wider identity and access programme.