Notifications
Clear all
Topic starter
06/06/2026 2:16 am
TL;DR: MCP servers are becoming the connector layer between LLMs and live applications, but the main security risk is loose authentication and authorization, according to Aembit. The governance problem is that existing IAM assumptions about stable users, fixed clients, and human-paced review cycles do not hold when AI tools can act through exposed server interfaces.
NHIMG editorial — based on content published by Aembit: MCP server security, tool integration, and access control for LLMs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Enforce server-side tool authorization Apply permission checks on every tool invocation inside the MCP server, not in the prompt layer or desktop client.
- Replace persistent secrets with short-lived access Move away from plain-text API keys in environment variables and use short-lived credentials where possible.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step FastMCP example code for building tools and exposing them through a local server.
- Claude Desktop configuration details for connecting an MCP server to an AI client.
- Practical authentication examples using OIDC, OAuth 2.0, and FastMCP auth providers.
- Implementation notes on JIT access and when to replace static API keys with short-lived credentials.
👉 Read Aembit's walkthrough on MCP server security and AI tool access →
MCP server security and access control: are your controls keeping up?
Explore further
06/06/2026 3:50 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server security: what IAM teams need to govern now
