Notifications
Clear all
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.
NHIMG editorial — based on content published by Pomerium: MCP Server Security Risks: What Development Teams Need to Know in 2026
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams control MCP server access in production?
A: Security teams should enforce identity-aware policy on every MCP tool call, not just at session start.
Q: Why do MCP servers create more risk than ordinary API integrations?
A: MCP servers can expose broad internal authority to AI agents without native authentication or authorization in the protocol.
Q: What do teams get wrong about prompt injection in MCP environments?
A: Teams often treat prompt injection as a content problem when it is also an identity problem.
Practitioner guidance
- Enforce per-request authorization on every tool call Evaluate each MCP request against identity, task, source, and environment before the server acts.
- Scope every MCP server to task-bound privilege Limit access to only the files, APIs, and databases the server needs for the current workflow.
- Isolate servers from public network exposure Bind MCP services to local sockets or private networks and avoid 0.0.0.0 bindings.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Zero Trust policy design for MCP requests across humans, services, and agents
- Configuration guidance for local, containerised, and remote MCP deployments
- Detailed logging and audit trail patterns for request-level accountability
- Practical examples of per-request policy decisions based on identity, task, and environment
👉 Read Pomerium's analysis of MCP server security risks in 2026 →
MCP server security risks: what IAM teams need to fix now?
Explore further
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
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
