Across enterprise environments in 2026, a significant portion of active MCP server connections carry no authentication requirement at all. The MCP authentication spec only formalized OAuth requirements for remote servers in mid-2025, leaving a long tail of legacy implementations, community-default configurations, and developer-built servers that still accept connections from any process that can reach them.
Knowing the spec requires auth for remote servers does not explain why most enterprise deployments still have unauthenticated connections. The gap between specification and implementation is where the real risk lives.
Legacy implementations predate the auth requirement. Any MCP server built before mid-2025 was built to a spec that did not mandate authentication. Those servers are still running. Operators who did not actively track the spec revision have no reason to know their configuration is now non-compliant with current standards.
Local-only assumptions that broke. Developer tooling drove the initial MCP adoption wave. Tools like Cursor and similar AI coding assistants connected to MCP servers running locally. That worked safely in isolation. Then organizations started centralizing those servers, moving them to shared infrastructure so multiple developers could use the same tools. The local-trust model traveled with the server into a remote deployment context where it no longer applies.
Community server configurations ship without auth by default. The open-source MCP server ecosystem grew faster than security guidance could keep up with. Most community-published server configurations include no authentication setup. Developers clone a repository, follow the quickstart, and have a running server in minutes. Auth configuration requires additional steps that the quickstart does not include. The default state is unauthenticated.
Remote MCP is genuinely new for most enterprise teams. Organizations that started MCP deployments in late 2024 or early 2025 built on the spec available at that time. Their infrastructure teams are not necessarily tracking protocol specification updates. The June 2025 revision created a compliance gap for every deployment that predates it, and most teams do not have a process for retroactively auditing protocol-level configuration changes.
The result is a population of MCP servers in production that were never designed to be secured, were deployed under assumptions that no longer hold, and exist in environments where no one has a complete inventory of what is running. This is the shadow MCP server problem at its most concrete: not theoretical configuration risk, but real unauthenticated endpoints accepting tool calls from any process that can reach them.
Incident response teams investigating an MCP-related event face a consistent problem: the logs exist, but they do not answer the questions that matter.
What should be logged. A complete MCP audit trail requires: the identity of the calling agent (not just the process name), the specific tool called, the parameters passed to that tool, the response payload or a hash of it, timestamps with sufficient precision to reconstruct action sequences, and the outcome of each call. This is the minimum needed to answer "what happened, who did it, and what did they access?"
What is actually logged in practice. Most MCP server implementations log successful tool execution at the application level. They record which tool ran and whether it succeeded. They do not record caller identity because, in an unauthenticated deployment, no identity exists to record. They do not capture payload content because no logging standard requires it. The result is a log that confirms the tool ran but cannot tell you who called it or what data moved.
Why the audit trail is broken. The MCP specification does not define a logging standard. Each server implementation makes its own choices about what to record. Community servers often log nothing beyond startup and error events. Enterprise deployments that do implement logging rarely integrate those logs into SIEM pipelines, because MCP servers are still treated as developer infrastructure rather than security-relevant systems. The audit log value demonstrated in major breach investigations depends entirely on logs that contain identity context. MCP logs typically do not.
The incident response consequence. When an MCP-connected agent is involved in a data exposure event, the investigation starts from a position of near-zero visibility. Security teams can confirm that a tool was called. They cannot confirm which agent called it, what parameters were passed, or whether the call was part of a broader action chain. Ghost chasing static configuration signals without runtime evidence is the structural problem that MCP audit gaps make worse, not better.
Closing the MCP authentication gap requires work at three distinct layers. Framing this as a single control misses how the problem is distributed.
Server-side: implement auth per current MCP spec. Remote MCP servers must implement OAuth 2.1 token validation using a separate Authorization Server. This is not optional for any server accessible outside a single-user local context. Server operators need to audit every deployed instance against the June 2025 spec requirements, identify which servers predate the auth requirement, and prioritize remediation based on the tools each server exposes and the data it can reach.
Agent-side: verify auth requirement before connecting. Agents and the platforms that orchestrate them should refuse connections to MCP servers that do not present a valid authentication requirement. This is a platform-level control. Security teams evaluating AI agent platforms should confirm whether the platform enforces authenticated-only MCP connections or whether it allows unauthenticated connections by default.
Vendor evaluation criteria. Before adopting any MCP server or AI agent platform, security teams should confirm three things: Does the server require OAuth 2.1 for remote connections? Does the server log caller identity with each tool call? Does the server propagate identity context to downstream systems so the audit trail survives action chaining? Vendors who cannot answer these questions have not addressed the MCP authentication spec requirements in their implementation.
Infrastructure inventory as the prerequisite. None of the above controls can be applied to servers that security teams do not know exist. The first step is surfacing which agent connections in the environment lack authentication. This is where runtime visibility into agent infrastructure becomes operationally necessary. Obsidian's agent inventory surfaces authentication status as a visible attribute of each MCP server connection, classifies servers as sanctioned or unsanctioned, and includes missing authentication as a risk factor in toxic combination scoring. Security teams use that inventory to prioritize which unauthenticated servers to remediate first based on the tools they expose and the agents connected to them. Obsidian does not act as an authentication proxy or enforcement layer for MCP connections. The remediation work is server-side. The inventory is what makes that work tractable at scale.
For teams building out their AI agent governance framework, the AI guardrails framework and broader AI agent security risks overview provide framework-level context for where MCP authentication fits within the broader agentic risk model.
The MCP authentication spec has matured significantly since the protocol launched. OAuth 2.1 requirements for remote servers represent a real improvement in the security model. The problem is that specification progress and deployment reality are not synchronized. Most enterprise MCP servers running today were built before the June 2025 revision, operate under local-trust assumptions that no longer apply, and produce audit logs that cannot support incident response.
Security teams cannot close a gap they cannot see. The immediate action items are concrete:
Configuration is not reality. An MCP server that appears secured in your architecture diagram but runs without authentication in production is an open endpoint. Runtime truth means knowing which one you actually have.
The Model Context Protocol originally launched without strong authentication requirements, relying on local-socket trust for single-user deployments. The June 2025 spec revision (version 2025-06-18) formalized OAuth 2.1 as the required authentication mechanism for remote MCP servers, delegating token issuance to a separate Authorization Server rather than the MCP server itself.
The spec requires authentication for remote servers built to the current standard. It does not retroactively enforce compliance on legacy implementations. Servers built before mid-2025 operate under the prior model unless operators actively upgrade them. Community-published server configurations also still ship without auth setup by default, meaning new deployments can start unauthenticated if operators follow the quickstart without additional hardening.
An unauthenticated MCP server accepts tool calls from any process that can reach its network endpoint. Depending on which tools the server exposes, an attacker can read files (including credential stores and environment files), execute commands, query databases, or chain tool calls across connected systems. No identity check occurs at any point in this sequence.
Complete MCP audit logging captures the identity of the calling agent (via token subject claim), the specific tool invoked, the parameters passed, the response payload or a hash of it, timestamps, and the outcome. Most current implementations log only successful execution without identity context, which makes incident response investigation nearly impossible.
Obsidian surfaces authentication status as a visible attribute of each MCP server connection in the agent inventory. It classifies servers as sanctioned or unsanctioned and includes missing authentication as a risk factor in toxic combination scoring. This gives security teams a prioritized view of which unauthenticated connections represent the highest risk based on the tools exposed and the agents connected. The remediation work itself is server-side. Obsidian provides the inventory visibility that makes that remediation tractable.