Because they extend trust into third-party tool endpoints that may be poorly maintained, over-permissioned, or carrying embedded secrets. That creates an NHI and agentic control problem at the point where machines decide what to do next, which is exactly where traditional approval models are weakest.
Why This Matters for Security Teams
Public MCP servers matter because they move access decisions out of tightly governed enterprise systems and into third-party tool endpoints that can be updated, misconfigured, or compromised without notice. Once an agent can call those endpoints, identity is no longer just about a user or service account. It becomes about what machine is allowed to do next, under which context, and with what secrets attached.
That is why static IAM controls often miss the risk. Traditional role definitions assume stable, predictable access patterns, but MCP-backed workflows are dynamic: the tool list can change, prompts can redirect execution, and a single session may chain multiple services. Current guidance from the OWASP Agentic AI Top 10 and NHI research such as the Ultimate Guide to NHIs points to the same operational reality: tool trust and identity trust are converging at the agent boundary. In practice, many security teams encounter exposure only after secrets leak through a public connector or an agent silently inherits more reach than intended.
How It Works in Practice
Public MCP servers create risk when they act as a bridge between enterprise agents and external tools that are not governed to the same standard as internal APIs. The problem is not MCP itself, but the combination of remote tool discovery, embedded credentials, broad permissions, and weak runtime controls. The most effective response is to treat each agent-tool interaction as an identity event, not a generic integration.
Practically, that means moving away from long-lived static credentials and toward workload identity plus just-in-time access. A well-controlled design gives the agent cryptographic proof of what it is, then issues short-lived tokens only for the task at hand. Standards work such as NIST Cybersecurity Framework 2.0 supports the broader governance model, while implementation patterns often align with the direction described in the OWASP NHI Top 10.
- Scope each MCP tool to the minimum action set required for the workflow.
- Issue ephemeral secrets or tokens per task, then revoke them on completion.
- Log the agent identity, tool endpoint, and runtime context for every request.
- Block embedded secrets in server configs and CI/CD pipelines.
- Apply policy at request time, not only at approval time.
A useful benchmark from The State of MCP Server Security 2025 reports that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how immature this control layer still is. These controls tend to break down when public servers are allowed direct access to production secrets stores because the blast radius expands faster than review and revocation processes can keep up.
Common Variations and Edge Cases
Tighter MCP controls often increase operational overhead, requiring organisations to balance agent agility against review, policy, and token-management complexity. That tradeoff becomes sharper in developer productivity environments, where teams want fast tool onboarding and low-friction approvals.
There is no universal standard for this yet, but current guidance suggests separating high-risk public MCP endpoints from sensitive enterprise identities unless runtime policy enforcement is mature. One common edge case is a “read-only” server that still exposes enough metadata for prompt injection, tool chaining, or credential harvesting. Another is shared MCP infrastructure across business units, where role-based access looks clean on paper but fails because agents inherit context that humans never would. The 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the same lesson: exposure usually starts with over-permissioned machine access, then becomes an incident when secrets or tokens are reused beyond their intended scope. The cleanest pattern is to minimise trust in the public server, not to assume it can be made safe by policy alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Public MCP tools expand agent attack surface and tool abuse risk. |
| CSA MAESTRO | T1 | MAESTRO covers agent tool trust, runtime policy, and secure orchestration. |
| NIST AI RMF | GOVERN | Agentic MCP use needs accountability, oversight, and lifecycle governance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Public MCP servers often leak or overuse secrets and tokens. |
| NIST CSF 2.0 | PR.AC-4 | MCP access should follow least privilege and managed entitlements. |
Inventory secrets on MCP servers, rotate them, and eliminate hard-coded values.
