MCP server security in 2025 exposes access and secrets gaps

At a glance

What this is: This is a 2025 roundup of popular Model Context Protocol servers that shows how agent tool access expands quickly while security guardrails and identity scoping often lag.

Why it matters: It matters because IAM, NHI, and platform teams need to govern AI-to-tool access before MCP becomes a default pathway into production data and actions.

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.

👉 Read Pomerium's 2025 roundup of the best MCP servers

Context

Model Context Protocol, or MCP, is the layer that lets LLMs and agents connect to tools, systems, and data sources. In practice, that means the identity problem shifts from chat access to tool access, and the security question becomes whether the agent is allowed to act on behalf of the business with bounded scope and auditable policy.

Pomerium’s roundup is less about ranking GitHub popularity than about showing how quickly MCP servers can become a new identity plane for AI-driven workflows. The issue for practitioners is not the protocol itself, but the mismatch between agent usefulness and the governance maturity needed to control credentials, permissions, and action boundaries.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat MCP servers as privileged access points, not as ordinary middleware. Give each server a narrowly scoped identity, separate read and write permissions, and attach logging to every tool call. If the server can reach sensitive systems, require the same governance discipline you would apply to a high-risk service account.

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. That expands the blast radius of both configuration mistakes and token exposure. The risk is not the protocol alone, but the identity trust model attached to it.

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. In MCP environments, that mistake is amplified because the server may sit on a direct path to production data or actions. Secrets need isolation, rotation, and revocation, not just obscurity.

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.

Technical breakdown

MCP servers turn tool access into an identity problem

MCP standardises how an LLM or agent requests real-world context and tool actions, but the server becomes the enforcement point for what the agent can see and do. That changes the control surface from application login to runtime authorisation, because the agent is no longer just reading data, it is invoking tools, querying services, and potentially chaining actions across systems. If the server inherits broad permissions or relies on static trust, the protocol becomes an access amplifier. The real design question is whether the server can constrain tool scope per identity, per task, and per session.

Practical implication: treat every MCP server as an access broker and review its tool permissions before exposing it to production data.

Why static auth breaks down in agentic workflows

Traditional authentication proves who connected, but not whether that identity should keep using a tool as the task context changes. MCP workflows often need granular, time-bounded permissions because the same agent may query logs, fetch secrets, or trigger infrastructure changes in one session. If permissions are broad or long-lived, the server cannot distinguish between a legitimate request and an overreach that was enabled by the original login. That is why static auth models, especially those built around one-time trust decisions, are weak for agent-to-tool interactions. The control problem is continuous policy enforcement, not just initial authentication.

Practical implication: enforce continuous, policy-based authorisation for each agent action rather than assuming a successful login is enough.

Hard-coded secrets make MCP deployments easy to misuse

MCP servers often sit close to configuration files, integration tokens, and environment secrets because they need fast access to upstream systems. When secrets are embedded in code or config, the server inherits standing privilege that is hard to scope and harder to revoke. That creates a direct path from convenience to exposure: anyone who finds the file, repo, or deployment artifact can inherit the same access the server uses. In NHI terms, this is classic secret sprawl, but MCP increases the blast radius because the exposed credential may sit at the center of an agent workflow rather than a single application.

Practical implication: move MCP credentials out of configuration files and verify that every token used by the server is individually scoped and revocable.

NHI Mgmt Group analysis

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.

Tool permission scoping is the missing control plane for agentic access. If only a small share of deployments scope tool permissions, then the default posture is still broad trust at the server layer. That is structurally incompatible with least privilege, because the server becomes the place where multiple downstream systems are reachable through one credential or one integration path. The implication is that identity teams must evaluate MCP servers the way they evaluate privileged service accounts: by effective access, not by intended use.

Ephemeral agent sessions do not eliminate secret risk, they concentrate it. When MCP servers depend on configuration-stored credentials, the problem is not just exposure at rest. It is that one leaked secret can unlock a whole interaction path between an agent and the systems it controls. That makes rotation, scoping, and offboarding operationally urgent, because the server can outlive the original assumption that only trusted developers or internal workflows will touch it.

Identity blast radius: the real risk is how far one MCP credential can propagate across tools, not whether the protocol is open or closed. Open standards increase interoperability, but they also make access mistakes repeatable across environments. Security leaders should measure how many systems a single MCP identity can reach, then reduce that radius before agent adoption expands.

From our research:

• 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.
• For a broader control baseline, review OWASP Agentic Applications Top 10 for agent tool and identity risks.

What this signals

MCP adoption will force security teams to decide whether AI-to-tool access belongs inside IAM, platform engineering, or a separate governance path. The organisations that succeed will define server identities, tool scopes, and audit boundaries before agents become embedded in daily workflows. The ones that delay will discover that convenience has already become access debt.

Identity blast radius: as MCP spreads, the practical metric to watch is how many downstream systems a single server identity can touch. That is the number that will determine how quickly a configuration mistake becomes an enterprise incident, especially when secrets and tool permissions are bundled into the same deployment path.

For practitioners

• 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. Do not approve deployment until the effective access path is documented end to end.
• 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. The goal is to make revocation and audit ownership discrete instead of shared.
• 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. Where possible, force retrieval from a secrets manager at runtime and verify that rotation does not require redeploying the server.
• Enforce action-level logging for every agent-to-tool request Capture which identity requested the action, which tool was called, what object was targeted, and whether the request was allowed or denied. Without this, audit trails will show that the server ran but not what the agent was permitted to do.

Key takeaways

• MCP servers are not just integration components, they are identity enforcement points that decide what agents can reach and do.
• The dominant failure pattern is familiar NHI risk in a new form: exposed secrets, weak scoping, and standing privilege in configuration.
• Teams should measure effective access, shrink the blast radius of each server identity, and treat agent-to-tool policy as a governance requirement.

Key terms

• Model Context Protocol: An open protocol that connects language models and agents to external tools, systems, and data sources. In security terms, it creates a new control point where identity, authorisation, and audit must be enforced before an agent can act on behalf of a user or workflow.
• Agent-to-tool access: The permission path that lets an AI agent call a real system, query data, or trigger an operation. Unlike ordinary application access, this path can span multiple tools in one session, so the effective privilege of the server matters as much as the agent's intent.
• Identity blast radius: The amount of downstream access that a single credential, token, or identity can unlock if it is misused or exposed. For MCP deployments, blast radius grows quickly when one server identity can reach many tools, datasets, or administrative functions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.

This post draws on content published by Pomerium: Best Model Context Protocol (MCP) Servers in 2025. Read the original.