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.
At a glance
What this is: This is Pomerium’s roundup of leading MCP servers in 2025, highlighting that the protocol now connects agents to sensitive tools and data across development, cloud, analytics, and operations workflows.
Why it matters: It matters because IAM and NHI teams need to treat MCP servers as governed access surfaces, not just integration endpoints, especially when agents can trigger real actions against sensitive systems.
Context
MCP server security is a governance problem before it is a tooling problem. Once an MCP server exposes real tools and real data to an LLM or agent, the question becomes who can act, under what policy, and with what audit trail.
For identity teams, the issue is not whether agents are useful. It is whether the access path behind the agent is bounded by identity, privilege, and logging controls before the server is put into production.
Pomerium’s article frames the current state of MCP servers as a growing access surface rather than a finished security model. That is a typical pattern whenever a new protocol reaches real operational use faster than governance catches up.
Key questions
Q: What breaks when MCP servers expose all tools to every agent session?
A: Overexposure breaks least privilege and makes delegated action harder to contain. If every session sees every tool, the agent can inherit capabilities that exceed the user intent, which increases the chance of unauthorized approvals, deletions, or data access when policy is not checked before execution.
Q: Why do MCP-enabled agents increase risk in multi-system workflows?
A: MCP-enabled agents increase risk because they can move from analysis into action across repositories, databases, APIs, and internal tools. Once a tool can execute commands or change systems, standing permissions, hardcoded secrets, and weak scoping can turn a convenience layer into an attack path. The main risk is uncontrolled delegation across trust boundaries.
Q: What do security teams get wrong about shadow MCP servers?
A: They often treat them as developer convenience rather than identity-bearing infrastructure. In reality, local MCP servers can have full filesystem and system privileges while escaping central visibility. That makes them an unmanaged perimeter, so discovery, owner assignment, and policy enforcement have to extend to endpoints as well as platforms.
Q: How should teams govern MCP servers across GitHub, cloud, and observability tools?
A: They should classify each server by data sensitivity, action scope, and owner, then decide whether the server is read-only, write-capable, or production-impacting. That classification should determine policy, approval, and logging requirements. One broad agent trust model is too weak for mixed-use environments.
Technical breakdown
How MCP servers expand the agent access surface
MCP is an open protocol that lets an LLM or agent connect to real tools and data sources through a server interface. In practice, the server becomes the control point between model output and external action. That matters because the security boundary is no longer the model itself, but the credentials, permissions, and request handling behind the server. If the server can reach GitHub, cloud APIs, analytics systems, or observability tools, it can also expose those systems to misuse if access is not tightly scoped.
Practical implication: Treat every MCP server as an identity boundary and require explicit authorization policy before connecting it to production systems.
Why traditional auth patterns are insufficient for agentic tool use
Traditional authentication proves a user or workload once, then assumes a stable session with predictable intent. Agentic workflows break that assumption because the actor may chain tool calls, switch context, and execute actions at runtime. OAuth alone does not describe which tool the agent may call, what data it may retrieve, or which actions are safe in a given context. That is why the article stresses Zero Trust policy and request-level enforcement rather than static login success as the control boundary.
Practical implication: Move from session-level trust to request-level authorization and constrain each tool action by role, source, and context.
What sensitive data exposure looks like in MCP server deployments
The article shows MCP servers linked to GitHub issues and pull requests, browser automation, AWS documentation and billing data, Terraform modules, dbt graphs, Sentry telemetry, and MongoDB access. Each of those integrations can surface secrets, internal metadata, or operational data that was never meant for broad agent access. The risk is not only exfiltration. It is also overbroad read access that allows an agent to infer, combine, or act on data beyond the original task.
Practical implication: Inventory every MCP integration by data class and privilege scope before allowing agents to use it in live environments.
Threat narrative
Attacker objective: The objective is to reach sensitive tools and data through an agent-facing server path and use that access to exfiltrate information or trigger unsafe actions.
- Entry occurs when an MCP server is connected to a tool or data source and made reachable by an agent without sufficiently granular policy.
- Credential or access abuse follows when the server inherits permissions that exceed the task it is meant to support.
- Impact appears when the agent can retrieve sensitive data or trigger actions across connected systems without meaningful human review.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP server governance fails when access is treated as a feature layer instead of an identity layer: The article shows that MCP servers are now the practical boundary between language models and real systems. That means policy, privilege, and audit must be designed around the server interaction itself, not around the model or the user alone. Practitioners should treat the MCP server as a governed access plane, not an integration convenience.
Secret exposure is the first control signal, not the last incident stage: When configuration files, server manifests, and hosted environments leak secrets, the protocol stops being a neutral transport and becomes an exposure multiplier. The 24,008 exposed secrets figure from the wider MCP ecosystem illustrates that secret handling is already a material governance concern. The field should read that as evidence that inventory and offboarding discipline matter before agent rollout, not after.
Identity blast radius is the right concept for MCP adoption: Once agents can reach GitHub, cloud billing, analytics, or observability systems through the same protocol pattern, a single trust decision can span multiple sensitive domains. That widens blast radius in a way conventional app onboarding does not capture. The implication for practitioners is to map every MCP server to the exact data and action scope it can touch, then govern that scope as a first-class identity asset.
Zero Trust for agentic access is no longer a future model, it is the operating baseline: The article’s emphasis on gating every request with identity and policy reflects where the market is heading. Static trust in an authenticated session is too coarse for tool-using agents, especially when the server itself is exposing operational APIs. Teams should expect MCP security to converge with Zero Trust identity patterns, request-level policy, and continuous audit expectations.
Model Context Protocol authorization is becoming the missing control layer: MCP adoption makes it clear that authentication alone does not answer authorization, delegation, or logging questions. The protocol is useful precisely because it connects models to real systems, but that usefulness becomes risk without an authorization model that is explicit about action scope. Practitioners should align MCP design decisions with governed request authorization, not with generic API access assumptions.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Identity blast radius: MCP adoption is pushing teams to think beyond authentication success and toward the full reach of each server. A single server can expose code, cloud data, observability context, and operational actions, so governance has to track what the agent can touch, not just whether it is signed in.
Agentic access becomes controllable only when teams treat each request as a policy decision. That shifts MCP design toward request-level authorization, explicit ownership, and environment-specific boundaries instead of broad trust in a connected session.
For practitioners
- Map every MCP server to an identity owner Assign a named owner for each server, the tools it reaches, and the data it can expose so there is accountability before rollout.
- Scope tool access by request, not by login Enforce policy at the point of each AI-to-tool action using role, source, and context rather than trusting a completed authentication event.
- Inventory secrets in MCP configuration and runtime paths Review server manifests, environment files, and deployment pipelines for exposed credentials, then remove secrets that the agent does not strictly need.
- Separate read-only and action-capable servers Keep discovery or reporting servers isolated from servers that can modify issues, infrastructure, or production data so a compromise does not cross operational boundaries.
Key takeaways
- MCP servers are turning agent access into a governed identity problem because they connect models to tools, data, and operational actions.
- The article’s core warning is that secrets and permissions can spread quickly once MCP servers are deployed without clear policy boundaries.
- Practitioners should map server scope, narrow access per request, and keep read-only integrations separate from action-capable ones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly warns that MCP servers and configs expose sensitive secrets. |
| NHI-04 — Insecure Authentication | The article argues that traditional auth is not enough for agentic tool access. | |
| NHI-05 — Overprivileged NHI | MCP servers inherit broad tool and data access when permissions are not tightly scoped. | |
| Recommendation — Scan MCP configurations and runtime paths for leaked secrets and revoke exposed credentials immediately. Enforce request-level authentication and authorization for every MCP tool call. Reduce MCP server privileges to the minimum data and actions each server actually needs. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-to-tool workflows can be abused when privileges are broader than intended. |
| Recommendation — Map agent actions to explicit privilege boundaries and block capability reuse across tools. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust access to resources — Zero Trust access to resources | The article explicitly calls for Zero Trust policy across AI-to-tool actions. |
| Recommendation — Apply Zero Trust request evaluation to each MCP interaction rather than trusting the session. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The main issue is whether agents are authorized to reach each tool and dataset. |
| Recommendation — Review and restrict MCP entitlements so each server can only reach approved resources. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed secrets and overbroad server access enable credential abuse and spread across tools. |
| Recommendation — Map MCP exposure to credential access and lateral movement paths in your detection pipeline. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
- Request-level Authorization: Request-level authorization means access is decided for each request rather than once at login or network entry. It lets operators scope permissions by route, method, and identity, which is far more precise than broad network access and better suited to distributed systems and NHIs.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org