MCP server security: what IAM teams need to govern now

At a glance

What this is: This walkthrough explains how MCP servers connect LLMs to tools and data, and why weak authentication and authorization create the main governance gap.

Why it matters: IAM and security teams need to govern MCP as a new access layer because tool use, data exposure, and privilege checks now happen through AI-facing interfaces rather than traditional user sessions.

Context

MCP server security is an access-control problem, not just an integration pattern. MCP defines how LLMs and tools exchange context, then lets the server expose tools, resources, and prompts to clients that may act on behalf of people or applications.

The governance gap is that familiar IAM assumptions break down when the requesting entity is an AI client rather than a fixed human user. Loose server-level authorization can turn an integration layer into a data exposure path, especially when teams rely on prompts or client-side controls instead of enforcing permissions on each tool call.

In practice, that means MCP belongs in the same governance conversation as APIs, workload identity, and privileged access. The article’s example is a basic shopping-list server, but the security lesson is typical: once MCP is used beyond a test environment, access scope and request provenance become the control points that matter most.

Key questions

Q: What breaks when MCP servers rely on prompt-based access control?

A: Prompt-based control breaks because the LLM can describe intent, but it cannot reliably enforce policy. If the MCP server does not authenticate the caller and check permissions on each tool, the model can reach data or actions that should have stayed out of scope. The failure is at the server boundary, not in the prompt itself.

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: How should teams decide whether MCP access is safe enough to allow?

A: Teams should allow MCP access only when the agent or server can be bounded with explicit scopes, revocable credentials, and traceable client registration. If the integration depends on static secrets, shared keys, or opaque delegation, the access model is too durable for reliable governance and should be redesigned before production use.

Q: When does just-in-time access make sense for MCP-connected systems?

A: Just-in-time access makes sense when the backend permission would otherwise persist longer than the task. It is most useful for API keys, service credentials, and other non-human access paths that only need to exist briefly. The goal is to reduce standing exposure, not to replace authorization or server-side policy.

Technical breakdown

How MCP server authentication changes the trust boundary

MCP is a client-server protocol that exposes tools and resources to an LLM, but the specification leaves authentication to the HTTP layer and optional provider integrations. That means the trust boundary is not the model itself, but the server endpoint and the identity context attached to each request. If teams store API keys in environment variables or plain-text configs, they are effectively pushing trust into static secrets rather than governed identities. Remote MCP deployments make this sharper because the server is no longer a local wrapper. The security issue is not whether the client can call a tool, but whether the server can prove who is calling and under what policy context.

Practical implication: Treat each MCP server as an identity boundary and require authenticated, policy-backed access before any tool is exposed.

Why authorization must live at the MCP server layer

Authorization is the control that decides what a caller can actually do after authentication succeeds. In MCP, that matters because the same server may expose tools that touch different datasets, actions, or privilege levels, and prompt text cannot reliably enforce those distinctions. Server-side checks need to bind each client to a role or permission set and evaluate every tool invocation independently. Without that, the model can surface data it should not, or trigger actions the caller was never entitled to request. This is the same failure pattern IAM teams already know from APIs: authentication without authorization creates a false sense of control.

Practical implication: Implement per-tool permission checks and map each client to explicit roles instead of trusting prompts or the LLM runtime.

Why JIT access matters for MCP-connected credentials

The article’s JIT access reference points to a common non-human identity problem: static credentials last longer than the business task that needed them. When an MCP server relies on long-lived API keys, compromise impact is tied to secret lifetime, not session lifetime. Just-in-time access changes that by limiting when a credential exists and how long it remains usable, which reduces the window in which an exposed secret can be abused. For MCP, that is especially relevant because the server may be acting as a wrapper around other APIs and inheriting their reach. The underlying issue is secret persistence across a tool chain that now includes AI-mediated requests.

Practical implication: Shorten credential lifetime around MCP-connected workloads and prefer ephemeral access wherever the backend supports it.

Threat narrative

Attacker objective: The attacker wants to use the MCP server as a trusted bridge into data and actions that should have remained outside the caller’s authority.

1. Entry occurs when an attacker or unauthorized client reaches an MCP endpoint that exposes tools or resources without strong authentication.
2. Credential access happens when that endpoint relies on stored API keys or weakly controlled secrets to reach downstream APIs or data stores.
3. Escalation follows when the server lacks per-tool authorization and the caller can invoke actions beyond its intended scope.
4. Impact is unauthorized data exposure or unintended action execution through the MCP-connected application layer.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP server security is really a governed-access problem, not an AI novelty problem. The protocol exposes a new control plane for tools, data, and actions, but the control failures are familiar: weak authentication, weak authorization, and unclear request provenance. The difference is that the caller may now be an LLM-driven client rather than a stable human user, which changes how access should be modeled. Practitioners should treat MCP as a new enforcement boundary, not a convenience layer.

Loose authorization becomes the default failure mode when tool scope is not enforced server-side. Prompt instructions and client-side trust are too brittle to separate harmless tool use from privileged action. That is why per-tool authorization is the real governance control, and why access decisions need to be made where the request is executed, not where it is described. The practitioner conclusion is straightforward: if the server does not enforce it, the policy does not exist.

Long-lived secrets are a poor fit for AI-facing integration layers. MCP-connected systems often rely on wrapper services, API keys, and downstream credentials that outlive the session or task that triggered them. That creates credential persistence across a tool chain that may span multiple clients and runtime contexts. The implication is that secret lifetime, not just identity proofing, becomes a first-class governance concern for AI-enabled access.

Ephemeral credential trust debt: The more an MCP server depends on static secrets to stand in for session-aware identity, the more security debt accumulates in the integration layer. Each additional tool, client, and backend adds another place where entitlement can drift away from the original user intent. The practitioner takeaway is to govern the bridge, not just the model.

Identity policy for MCP will converge with API governance and workload identity. As MCP adoption grows, the interesting question is not whether it is an API-like surface, but how much of the API governance stack must be made identity-aware at the tool boundary. That pushes IAM teams toward stronger inventory, tighter tool scoping, and more explicit client trust decisions. The practical conclusion is that MCP governance belongs in the core identity programme, not in a side project for AI tooling.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Ephemeral credential trust debt: MCP adoption is creating a new layer where static secrets, client trust, and downstream API permissions meet. That combination raises the cost of every access decision because a weak control at the MCP boundary can inherit the reach of the services behind it.

MCP governance should now be treated as part of the identity control plane, not an isolated AI integration concern. Teams that already manage workload identity, API access, and privileged connections have the right control patterns, but they need to apply them at the tool boundary where the LLM actually acts.

For practitioners

• Enforce server-side authentication for every MCP endpoint Require a verifiable identity layer before any tool or resource is exposed, and do not rely on local deployment assumptions or prompt behavior to establish trust.
• Apply per-tool authorization checks Bind each client to explicit roles and permissions, then evaluate access on every tool invocation so the server, not the model, decides what is allowed.
• Replace static API keys with ephemeral access Move MCP-connected workloads toward short-lived credentials and task-scoped access so a leaked secret cannot be reused across unrelated sessions.
• Inventory MCP clients and restrict trusted connections Track which desktop apps, agents, or services can connect to MCP servers, and block unreviewed clients from reaching sensitive tools or datasets.
• Audit tool-level activity and downstream calls Log who invoked each tool, what data path was used, and which backend services were reached so access reviews can focus on actual runtime behavior.

Key takeaways

• MCP servers introduce a new access layer where authentication, authorization, and secret handling decide whether AI tools stay within scope.
• The main failure mode is not the protocol itself, but the assumption that prompt-level controls can substitute for server-enforced policy.
• Treat MCP governance as identity governance, with tighter client inventory, shorter credential lifetime, and per-tool authorization checks.

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.
• Per-tool authorization: A control model that grants access to specific actions inside a service rather than opening the whole service at once. For MCP, this matters because tool-level access is the difference between limited delegated use and broad session-wide privilege.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.