Splunk MCP Server Risk: AI Agents Inside Observability Data

Splunk's push to connect AI agents directly to enterprise telemetry is drawing security scrutiny. A recent analysis argues that protocol-level weaknesses in the Model Context Protocol (MCP), previously disclosed by security firm ClawSecure, also apply to Splunk's MCP Server. The analysis says those weaknesses remain unpatched by any vendor. 2 The claim matters because of what the server exposes. It does not give agents access to a marketing database or a document store. It gives them access to the logs, alerts, dashboards and searches that security and operations teams rely on to see what is happening inside their environments.

What Splunk built

Splunk introduced MCP Server support as part of its Q1 2026 observability update. The company presented it as one piece of a broader effort to modernize incident troubleshooting with AI. 3 The same update included a Troubleshooting Agent in Observability Cloud. That agent correlates metrics, events, logs and traces, identifies likely root causes and suggests next steps. Splunk also added monitoring for AI agents and AI infrastructure, which covers performance, quality, cost and security risk in LLM-powered applications. 3

The MCP Server is the connective layer in that plan. According to the analysis, it offers a standardized interface linking AI assistants, agents and LLMs to data in both the Splunk platform and Splunk Observability Cloud. 2 Its toolset reportedly covers metrics and SignalFlow queries, APM environments and service dependencies, and alerting and incident search. 2 The server reached general availability in Q1 2026. 2

Splunk's release notes show steady development through spring 2026:

• Version 1.1.0 (April 1): added support for configuring the Splunk platform as an OAuth 2.1 server for MCP connectivity, plus beta features for running saved searches. 1
• Versions 1.1.1 through 1.1.3 (April 28 to May 19): fixed a Windows bug that made the server appear inactive, improved logging, and fixed a failure in API-based custom tool creation. 1
• Version 1.2.1 (May 27): added a telemetry dashboard that tracks how MCP tools consume Splunk Virtual Compute resources. It also let Cloud administrators set their own timeout value in a "Guardrails" section without filing a support ticket. 1

The security argument

The analysis starts from MCP's scale. It cites more than 500 million monthly SDK downloads and close to 16,000 public servers, and calls MCP the de facto standard for connecting agents to enterprise data. 2 Its central point is that the vulnerabilities ClawSecure described sit in the protocol itself, not in any one vendor's implementation. If that holds, Splunk inherits them along with every other MCP adopter. The analysis says no vendor has patched them. 2

The available material does not describe the specific mechanics of those vulnerabilities, and none of it shows a direct response from Splunk. Readers should treat the claim as one outlet's assessment of how a protocol-wide issue maps onto Splunk's product. It is not a vendor-confirmed flaw specific to Splunk.

Where the accounts diverge

Splunk's own messaging and the security analysis describe two different products.

• Splunk's view: the company calls the MCP Server a "secure" interface. 2 Its release notes point to OAuth 2.1 authorization, configurable timeouts labeled as guardrails, and a dashboard that shows how tools consume compute. 1
• The analysis's view: the integration hands agents protocol-level access to the "crown jewels" of enterprise observability. 2

These positions do not directly contradict each other. OAuth controls who can connect. Timeouts and usage dashboards limit how much a session can do and show what it did. Neither addresses what the analysis describes, which is weakness in the protocol layer. None of the release notes through version 1.2.1 mentions a fix for such issues. 1

Why observability data raises the stakes

Observability platforms collect, by design, some of the most revealing data an organization holds. That includes service topology, error traces that can contain sensitive payloads, alert logic that reveals what defenders monitor, and search access across large volumes of logs. An agent with broad read access to this data effectively has a map of the environment.

The usual concern is exfiltration. A second concern is subtler. If an agent can be manipulated, it could be steered to misread incidents, suppress findings or point responders the wrong way. Splunk's Troubleshooting Agent is meant to recommend next steps automatically. 3 Its usefulness depends entirely on the integrity of the channel it reasons through.

The takeaway

The analysis offers a reasonable warning, but the evidence available here does not prove that Splunk's implementation is uniquely exposed. The core issue is architectural. Splunk is placing AI agents at the center of the system that organizations use to detect compromise, and it is doing so over a protocol that, by at least one account, carries unresolved design-level risk.

Until MCP's security model matures, teams deploying the Splunk MCP Server should:

• Scope tool permissions narrowly.
• Use the new telemetry dashboard to audit agent activity. 1
• Treat agent-generated conclusions as leads to verify, not final verdicts.

Splunk's controls address access and resource consumption. They do not yet appear to address the protocol-level concerns that critics are raising.