Topic starter
10/06/2026 12:16 am
TL;DR: MCP servers connect AI agents to databases, APIs, and file systems without built-in authentication or authorization, creating prompt injection, confused deputy, and over-permission risks that traditional security tools were not built to handle, according to Pomerium. The real issue is not just exposed interfaces, but an access model that assumes agent requests are predictable and human-paced.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “MCP Server Security Risks: What Development Teams Need to Know in 2026”.
Key questions
Q: What breaks when an MCP server does not verify identity claims on each tool call?
A: The server loses the ability to distinguish a permitted request from a reused or forged one.
Q: Why do MCP servers increase the risk of agentic access abuse?
A: MCP servers connect agents to real systems, so a weakly controlled server becomes a privilege bridge rather than a simple integration layer.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows.
Practitioner guidance
- Enforce per-request authorization Require every MCP tool call to be evaluated against identity, task, source, and policy before the server can execute it.
- Scope MCP server privileges tightly Grant each server only the files, tools, APIs, and datasets required for the specific workflow it supports, and remove broad standing access.
- Isolate server execution environments Run MCP servers in containers or restricted runtimes so a compromised server cannot freely reach adjacent systems or network interfaces.
Bottom line: MCP server risk is fundamentally an identity control gap because the server can act with broad permissions without native request verification.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 hours ago by NHI Mgmt Group
11/06/2026 1:59 am
Policy gaps, not protocol novelty, are the real MCP risk. MCP does not create a new identity category, it exposes an old one in a more dynamic form. The protocol gives agents a route to tools, but the security failure appears when teams assume the route itself implies authorisation. Practitioners should treat MCP as a governance boundary that must be mediated by identity-aware policy, not by transport assumptions.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- That same research shows 97% of NHIs carry excessive privileges, which is why broad MCP server authority is a governance problem, not just an application hardening issue.
A question worth separating out:
Q: How do Zero Trust controls apply to MCP server security?
A: Zero Trust applies by forcing each tool call through policy, context, and revocation rather than trusting an established session. For MCP, that means per-request authorization, isolated execution, and continuous auditability so a compromised agent or server cannot keep acting unchecked.
👉 Read our full editorial: MCP server security risks are exposing identity control gaps
12/06/2026 3:33 am
Identity does not stop at authentication when MCP becomes the control plane: the real governance problem is whether every tool call is re-authorized in context. MCP servers collapse the line between request and execution, so access control has to move from session admission to per-action enforcement. That changes how IAM, PAM, and NHI programmes define a protected request, not just a protected account.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: Should organisations treat MCP security differently from traditional API security?
A: Yes. Traditional API security often assumes predictable, application-defined calls, while MCP must cope with prompt-driven behavior and autonomous tool selection. That means continuous authorization, tighter server scoping, and stronger auditability are required because the decision to act can change at runtime, not just at login.
👉 Read our full editorial: MCP server security risks are exposing identity control gaps
This post was modified 7 hours ago by NHI Mgmt Group