Unauthenticated MCP endpoints can expose tool execution, data access, or internal services to anyone on the internet. That makes them high-value entry points when protections are absent or weak. They also sit in a blind spot for teams that still rely on traditional ASM coverage, which may not fully account for AI-native infrastructure.
Why This Matters for Security Teams
Unauthenticated MCP endpoints are not just another exposed service. They can become a direct path from internet reachability to tool execution, data retrieval, and downstream action in AI-powered workflows. That changes the blast radius from “service compromise” to “workflow compromise,” especially when the endpoint is wired to agents, internal APIs, or privileged connectors. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both point to the same reality: once an agent-facing control plane is exposed, the attacker does not need to break the model to cause harm. They only need to invoke the right tools.
This is why traditional attack surface management often misses the risk. An MCP endpoint may look like a normal API, yet its real function is to broker access for autonomous or semi-autonomous workloads. If that broker is unauthenticated, every connected tool inherits the exposure. NHI governance also matters here because the endpoint is typically protected, or should be protected, by workload identity and short-lived credentials rather than long-lived secrets. In practice, many security teams encounter the impact only after an agent has already used the endpoint to reach sensitive systems, rather than through intentional discovery.
How It Works in Practice
MCP is intended to standardize how AI clients discover and invoke tools, but security depends on how the endpoint is deployed. If the server accepts requests without authentication, then any internet client can enumerate capabilities, call tools, or trigger backend actions. That is especially dangerous when the tools include file access, database queries, ticket creation, code execution, or internal service calls. The exposure is not theoretical. NHIMG’s AI Agents: The New Attack Surface report shows how quickly AI-driven access can become a governance problem: only 52% of companies can track and audit the data their AI agents access, leaving a large blind spot for investigation and compliance.
Operationally, secure MCP deployments should treat the endpoint as a privileged broker, not a public demo surface. The baseline pattern is:
- Require workload identity or strong service authentication before any tool discovery or invocation.
- Authorize each request at runtime based on the agent, task, and target resource, not just a static role.
- Issue short-lived credentials or scoped tokens per session or per task, then revoke them automatically.
- Log tool calls with enough context to reconstruct which agent, prompt, user request, or workflow initiated them.
This aligns with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls, but the implementation detail matters more than the label: MCP should be bound to authenticated identities, policy checks, and least privilege. These controls tend to break down in developer preview environments, proof-of-concept deployments, and internal test clusters because teams assume “non-production” endpoints will remain undiscovered.
Common Variations and Edge Cases
Tighter authentication often increases integration overhead, requiring organisations to balance developer velocity against exposure reduction. That tradeoff is real, especially when MCP endpoints are used for experimentation or when multiple agents need shared access to the same toolset. Best practice is evolving, but current guidance suggests avoiding blanket public exposure even for internal prototypes, because internet-facing unauthenticated control planes are routinely indexed, scanned, and replayed.
Edge cases appear when teams confuse “low-friction access” with “safe access.” A public read-only MCP endpoint can still leak sensitive metadata about available tools, internal naming, or data sources. A write-capable endpoint is more severe because it can create tickets, send messages, modify records, or trigger workflows. If agents chain tools together, one weak endpoint can become an entry point into a much broader environment. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now reinforce that long-lived or unauthenticated access paths are a recurring failure mode across machine identities. The risk is highest where an MCP server sits beside internal SaaS connectors, secrets stores, or admin automation, because a single unauthenticated call can become the start of lateral movement.
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 | A01 | Unauthenticated MCP endpoints expose agent tool invocation paths to abuse. |
| CSA MAESTRO | MAESTRO addresses agent security controls around tool use and runtime trust. | |
| NIST AI RMF | AI RMF covers governance for high-impact AI workflows and downstream harms. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Unauthenticated endpoints bypass workload identity and secret protection basics. |
| NIST CSF 2.0 | PR.AC-1 | Access control failures are central when public endpoints can invoke internal tools. |
Bind MCP services to authenticated NHI identities and remove public unauthenticated access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
