Notifications
Clear all
Topic starter
12/06/2026 9:13 pm
TL;DR: MCP servers expose a widening control gap: the protocol connects LLMs to real tools and data, but the most popular public servers still surface sensitive access patterns, according to Pomerium’s June 2025 roundup. The practical issue is not whether agents can work, but whether identity, policy, and audit boundaries exist before they do.
NHIMG editorial — based on content published by Pomerium: Best Model Context Protocol (MCP) Servers in 2025
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat MCP servers as privileged access points, not as ordinary middleware.
Q: Why do MCP servers create new identity and access risks?
A: MCP servers turn one agent connection into access across multiple tools and datasets, so a single weak credential or overbroad permission can affect many downstream systems.
Q: What do teams get wrong about secrets in MCP configurations?
A: Teams often assume configuration files are harmless because they are internal, but embedded secrets are still live credentials with real reach.
Practitioner guidance
- Inventory every MCP server and its upstream credentials Map each server to the tools, datasets, and secrets it can reach, then classify whether the access is read-only, write-capable, or administrative.
- Replace broad integration tokens with narrowly scoped identities Issue separate credentials for separate tool classes so a browser automation server, analytics server, and infrastructure server do not share the same privilege envelope.
- Block configuration-based secret storage in MCP builds Scan repositories, deployment manifests, and server config files for embedded API keys, tokens, and certificates before the first production connection.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact ranked list of GitHub MCP servers and the use cases behind each one
- The technical walkthrough of how Pomerium applies policy to AI-to-tool requests
- The webinar examples that show Zero Trust enforcement across agent workflows
- The source article's product framing and call-to-action for securing an MCP stack
👉 Read Pomerium's 2025 roundup of the best MCP servers →
MCP server security gaps: are your agent controls keeping up?
Explore further
12/06/2026 11:08 pm
MCP server security is really NHI governance under a new label. The server may be designed for agents, but the control failures are familiar: exposed secrets, broad permissions, and weak lifecycle discipline. What changes is the speed and scale at which those failures can be exercised, because an agent can invoke tools repeatedly and at runtime. For practitioners, MCP should be assessed as a machine identity and access governance problem, not as a novelty layer on top of application auth.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own MCP server risk in an IAM programme?
A: Ownership should sit across IAM, platform security, and the team operating the server, with clear accountability for credential scope, access review, and revocation. If the server can touch production tools, it should be governed like privileged machine identity infrastructure rather than a developer convenience layer.
👉 Read our full editorial: MCP server security in 2025 exposes access and secrets gaps
