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 shows that the main risk is weak access control around those tool-enabled requests.

Why it matters: It matters because MCP turns AI-facing integrations into identity and authorization decisions that must work for NHI, autonomous, and human governance models without relying on prompts or client trust.

👉 Read Aembit's walkthrough on MCP server security and AI tool access

Context

Model Context Protocol, or MCP, gives an LLM a structured way to call tools, query resources, and take action against real systems. That makes the identity question unavoidable: the security boundary is no longer the chat interface, it is the permissions behind each tool invocation.

For IAM and NHI teams, MCP is interesting because it looks like an API wrapper but behaves like an identity bridge for AI-driven workflows. The article’s core point is that loose access controls, plain-text API keys, and weak client trust create a governance gap that traditional application security alone will not close.

Key questions

Q: How should security teams govern access when LLMs use MCP servers?

A: Treat the MCP server as an authorization boundary, not a convenience layer. Identify the human, the client application, and the backend tool separately, then enforce least privilege on each tool call. If the server cannot verify who is asking and what they may do, the model should not receive access to sensitive data or actions.

Q: Why do MCP servers increase NHI governance risk?

A: MCP servers expose tools to AI clients, which turns each request into a machine identity decision. That creates risk when teams rely on broad client trust, persistent secrets, or prompt-based restrictions. The more dynamic the tool use, the more important it becomes to scope access at the server and not inside the model context.

Q: What breaks when API keys are used as the main MCP credential?

A: Persistent API keys create a standing secret that can outlive the task, the session, and sometimes the user who triggered it. If that key is copied, logged, or reused, the server has no built-in way to distinguish legitimate use from abuse. Short-lived credentials reduce that exposure window.

Q: Who is accountable when an MCP client exposes data through overbroad permissions?

A: The accountable party is the team that defined and approved the permission model, not the model itself. In practice, that means the identity, platform, and application owners must agree on client identity, tool scope, logging, and revocation. Zero Trust thinking applies here because trust must be continuously verified.

Technical breakdown

MCP tool exposure and client-server trust

MCP servers expose tools, resources, and prompts through a client-server pattern that lets an LLM act on external systems. In practice, the server becomes a policy decision point for what the model can request and what the backend will accept. That is why the security problem is not the model alone, but the combination of tool scope, client identity, and backend authority. If the server trusts the client too broadly, the model inherits capabilities it should not have, even when the underlying API is otherwise protected.

Practical implication: define tool-level authorization boundaries before connecting any MCP server to production data.

Authentication for remote MCP servers

The article distinguishes local wrappers from remote MCP servers, where HTTP authentication matters much more. OIDC and OAuth 2.0 give the server a way to identify the client, but the real control point is whether the server binds that identity to a narrow permission set. Storing API keys in environment variables or plain-text config files creates a standing secret that can be reused outside the intended session. JIT access is relevant here because it reduces the time window in which a compromised credential remains valid.

Practical implication: treat every MCP client as a separately governed identity and avoid persistent secrets where short-lived access will work.

Authorization and per-tool permission checks

Authorization failures are the highest-impact MCP issue because the server can leak information or enable privilege escalation with a single overbroad tool. The article’s advice to uniquely identify each client and check permissions on each tool is the minimum viable control, not the end state. Once LLMs can choose tools dynamically, broad backend trust turns prompt context into an authorization hazard. The correct architecture is least privilege at the tool boundary, with the backend enforcing what a model may do regardless of what it asks for.

Practical implication: enforce per-tool authorization server-side and log every privileged tool invocation for forensic review.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 creates an identity boundary problem, not just an integration problem. The article shows that MCP servers expose tools, resources, and prompts to LLM clients, which means access decisions are no longer hidden inside a single application. That changes the governance surface from application integration to identity-enabled action. For practitioners, the first question is who or what is allowed to request the tool, because the model may not be the real actor.

Plain-text secrets are a standing liability in MCP deployments. The article’s example of an API key stored in environment variables is a familiar NHI pattern, but MCP makes the failure more visible because the key sits behind an AI-facing interface. This is an NHI trust issue, not a model-quality issue. The named concept here is ephemeral credential trust debt: when teams keep relying on persistent secrets for short-lived AI interactions, they accumulate exposure that outlives the session. Practitioners should treat that debt as a structural control gap.

Tool-level authorization must be the policy frontier. MCP servers that rely on prompts or client-side trust allow the model to reach beyond the permissions the user intended. That is exactly where NHI governance and Zero Trust architecture intersect: identity must be checked at the tool boundary, not inferred from the conversation. The implication is that server-side enforcement becomes the only reliable way to limit damage when AI clients are granted dynamic access.

JIT access is useful here because it narrows the privilege window, but it does not solve identity ambiguity. The article rightly points to just-in-time access as a mitigation for static credentials, yet the deeper issue is that AI-driven tool use often blurs whether access belongs to the human, the client app, or the model workflow. That makes lifecycle governance part of the control plane. For practitioners, the task is to separate human entitlement, client entitlement, and tool entitlement before scaling MCP beyond test environments.

MCP will force IAM teams to rethink how they audit machine action. The article notes that LLM desktop apps may process conversations in ways that can leak data across users, which makes auditability and client governance just as important as authentication. This aligns with OWASP NHI and Zero Trust principles: access must be provable, scoped, and observable. Practitioners should assume that without explicit policy, an MCP server becomes a broad entitlement bridge rather than a controlled interface.

From our research:

• 92% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% say the problem is critical to enterprise security.
• For a deeper control model, see OWASP NHI Top 10 for tool-use, identity, and access risks in agentic environments.

What this signals

Ephemeral credential trust debt: MCP deployments tend to preserve the convenience of API wrappers while importing the governance burden of AI-facing tool access. That means the access model must be designed for short-lived, auditable, server-enforced privilege, not for static keys hidden in local configuration.

As teams move MCP beyond local testing, the operational question becomes whether the client can be trusted as a control point. The answer should usually be no. Authentication, authorization, and logging need to sit at the server boundary, aligned to the least-privilege pattern described in the OWASP NHI Top 10.

The governance signal is simple: if a model can reach production systems through a tool interface, the organisation has created a non-human identity path that must be reviewed like any other privileged connection. That includes entitlement review, client inventory, and revocation discipline for every MCP integration.

For practitioners

• Separate human, client, and tool identities Define which principal is being authenticated at each hop, then map the human user, the MCP client, and the backend tool to distinct permissions. Do not let one identity implicitly inherit another identity’s access.
• Enforce server-side tool authorization Apply permission checks on every tool invocation inside the MCP server, not in the prompt layer or desktop client. Deny access by default when the requested action cannot be tied to an explicit entitlement.
• Replace persistent secrets with short-lived access Move away from plain-text API keys in environment variables and use short-lived credentials where possible. Use just-in-time access for higher-risk connections so the access window is narrow if a key leaks.
• Audit tool usage like privileged activity Log tool calls, denied requests, and unusual client behavior so investigators can reconstruct what the model attempted and what it reached. Treat each tool call as a privileged event, not a routine application request.

Key takeaways

• MCP turns AI integration into an identity governance problem because tool access is only as safe as the permissions behind it.
• Persistent API keys, loose client trust, and prompt-level restrictions are weak controls when models can call real tools.
• Server-side authorization, short-lived access, and auditable tool calls are the controls that change the risk profile.

Key terms

• MCP Server: An MCP server is the application layer that exposes tools, resources, and prompts to an LLM through the Model Context Protocol. In security terms, it becomes a control point where machine-accessible actions must be authenticated, authorized, and audited just like any other privileged interface.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the exposure created when teams keep using persistent secrets for interactions that should be short-lived and tightly scoped. The debt grows when access survives beyond the task, making revocation harder and abuse more likely if the secret leaks or is reused.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Just-in-time Access: Just-in-time access is a provisioning pattern that grants permission only when needed and removes it after the task is complete. For AI-facing workflows, the value is a narrower exposure window, but it still requires clear identity binding, logging, and revocation discipline.

Deepen your knowledge

MCP server security, tool authorization, and short-lived credential design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending AI clients into production systems, it is worth exploring.

This post draws on content published by Aembit: MCP server security, tool integration, and access control for LLMs. Read the original.