Grafana MCP session spoofing exposes the identity broker problem

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pillar Security's research: Grafana MCP accepted session-like state from unauthenticated callers and then used the server's own service account and network reach to execute tool requests.

Why it matters: IAM and NHI teams need to treat protocol state, inbound authentication, and outbound destination controls as separate problems when a tool server acts on behalf of callers.

By the numbers:

• Grafana Labs reports more than 1.5 million active installations and 25 million global users.
• This critical SSRF vulnerability was assigned CVE-2026-19516, with a CVSS score of 9.1.

Context

Grafana MCP is an AI tool server that sits between callers and operational systems, so the key governance question is not just whether the session looks valid but whether the caller is actually authenticated. In this case, the control boundary was being inferred from session state rather than established identity, which created a gap in both NHI governance and agentic tool access control.

The deeper issue is that the server performed two authority-bearing acts on behalf of the caller: it used its own service account and it reached destinations selected by the requester. That combination turns the MCP layer into an identity broker problem, where inbound trust and outbound reach must be governed separately. For AI agents and other non-human callers, that distinction is operationally material.

Pillar Security’s analysis is therefore less about one Grafana deployment and more about a recurring design failure in tool-mediated AI systems: protocol tokens are not the same thing as authentication, and network position is not the same thing as authorization.

Key questions

Q: What breaks when MCP servers rely on session-bound state or the initialize handshake?

A: Older draft patterns fail when a request lands on a different instance or when client capabilities change between calls. Session IDs can hide state dependencies, and one-time handshake logic can miss per-request context. The result is brittle routing, inconsistent authorization decisions, and migration problems that only appear under load, retries, or partial outages.

Q: Why do MCP tool servers create identity broker risk?

A: Because the server often executes with its own credentials and network reach, not the caller’s. If the server can invoke downstream systems on behalf of a request, it becomes an authority-bearing mediator rather than a passive connector. That changes governance from simple access control to delegated authority control over credentials, destinations, and request methods.

Q: What are the signs that MCP destination controls are failing?

A: A warning sign is any tool that can reach caller-selected hosts, private ranges, or metadata endpoints without an explicit allowlist. Another sign is arbitrary forwarding of methods, headers, and request bodies, because that turns the server into a general-purpose proxy. Teams should look for outbound requests that exceed the tool’s stated business purpose.

Q: How should security teams govern AI sessions that generate outbound web traffic?

A: Security teams should treat AI sessions as governed activity, not just application usage. The control model needs to bind identity, destination, action, and data handling together so that prompts, tool calls, and file movement are enforced as one session rather than separate events.

Technical breakdown

Why session IDs are not authentication

MCP session IDs are protocol state references, not proof of caller identity. They help a server correlate requests across an interaction, but they do not say who is operating the client, whether the client should be trusted, or what it may invoke. In the Grafana case, the server accepted a locally generated session-shaped value and allowed tool calls to proceed without an inbound credential. That is a boundary confusion problem: the system treated a transport artefact as an identity assertion. For NHI and agentic systems, that distinction matters because authority-bearing tools should never trust session format alone.

Practical implication: require explicit inbound authentication before any tool execution and never treat session state as an access token.

How tool servers become identity brokers

An MCP server is not just a relay. When it runs with a service account and a live network position, it can translate a caller’s instruction into an action performed under the server’s own credentials and routes. That means the security model depends on two separate controls: who may invoke the tool and where the tool may reach. Grafana MCP exposed both sides of that model, first by allowing unauthenticated tool use and then by accepting caller-selected HTTP destinations. This is the identity broker problem in practice: the server mediates trust but also amplifies authority.

Practical implication: scope server credentials narrowly and constrain every outbound destination the server can reach on behalf of a caller.

Why destination controls matter as much as authentication

Authentication stops unauthorised callers, but it does not stop authorised callers from abusing the server’s network reach. If a tool can send arbitrary HTTP requests, the target selection becomes part of the trust boundary. In the Grafana research, the server refused to forward its service-account token to a foreign host, yet still made the request and returned the response. That is still SSRF because the server’s reach was the asset being exploited. For agentic environments, this means destination policy, hostname resolution, and request method constraints are not optional extras; they are part of the control plane.

Practical implication: enforce allowlisted destinations, block metadata and private ranges by default, and validate the resolved address at connection time.

Threat narrative

Attacker objective: The attacker’s objective is to use the MCP server’s authority to reach internal systems, extract responses, and potentially pivot through higher-privilege network paths.

1. Entry occurred when a reachable caller generated a valid-looking session value and invoked Grafana MCP without authenticating.
2. Credential abuse followed when the server executed tool requests using its own service account, giving the caller authority it did not possess.
3. Escalation happened when the HTTP-request tool accepted a caller-chosen destination and forwarded method, path, body, and headers from the server’s network position.
4. Impact was a critical SSRF path that could expose internal services, metadata endpoints, and broader infrastructure reach through the MCP server.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

Session state is not an identity control: Grafana MCP shows that a protocol token can correlate requests without authenticating the caller. That is a foundational governance mistake because it encourages teams to treat transport state as proof of authority. The implication is that NHI and agentic tool access programmes must separate session management from authentication and authorisation.

MCP servers act as identity brokers when they carry their own credentials: the server’s authority, not the caller’s, is what ultimately touches downstream systems. Once a tool server can issue requests with a service account, it becomes part of the trust boundary rather than a neutral bridge. Practitioners need to govern the server as an authority-bearing identity, not as a passive integration layer.

Identity broker risk is now a first-order control problem for agentic workflows: tool servers can amplify both credentials and network position in ways classic API controls do not fully capture. That means AI agent and MCP governance cannot stop at caller authentication; it has to account for the credentials, destinations, and methods the server may use on the caller’s behalf. The practical conclusion is that session validation alone is insufficient.

Outbound reach is a governance domain, not a routing detail: the Grafana case shows that an authenticated or unauthenticated caller may still abuse the server’s network adjacency if destination policy is loose. That makes destination allowlisting, address revalidation, and metadata blocking part of identity governance for non-human systems. Practitioners should treat network reach as delegated authority that must be explicitly bounded.

Named concept: identity broker problem: a tool server becomes an identity broker when it converts caller input into actions performed with its own credentials and network access. Grafana MCP illustrates that this pattern can fail at both the inbound authentication layer and the outbound destination layer. The practitioner implication is to govern the broker itself as a privileged non-human identity.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust for AI Agents

What this signals

Identity broker problem: MCP servers that carry their own credentials turn tool execution into delegated authority, which means session validation alone cannot protect the downstream systems they can reach. The governance task is to bound both the caller and the brokered reach, because either side can expand blast radius when treated as trusted by default.

AI agent workflows make this worse because the control point shifts from human-paced requests to server-mediated execution. Access review processes are weakest when they assume the actor is visible only at provisioning time; here the live decision is happening inside the broker layer, so outbound policy and credential scope have to be designed as one control domain.

For practitioners

• Separate session state from authentication Require a real inbound credential before any MCP tool can run, and treat session identifiers only as protocol correlation values.
• Constrain the server’s own authority Review the service account assigned to each MCP server and remove any permissions that are not strictly required for the enabled tools.
• Lock down outbound destinations Allow only approved hosts and ranges, block loopback, private, link-local, and metadata endpoints by default, and revalidate the resolved address at connection time.
• Restrict arbitrary request forwarding Disable free-form method, path, body, and header forwarding unless the tool genuinely needs it for a defined operational task.

Key takeaways

• Grafana MCP exposed a control failure where session-like state was accepted without authentication and then used to invoke authority-bearing tools.
• The same server could also be directed to caller-chosen destinations, creating an SSRF path that extended beyond the caller’s own reach.
• The control that would have limited the impact is explicit inbound authentication plus strict outbound destination policy, not session validation alone.

Key terms

• Identity broker: An identity broker is a component that translates a caller’s instruction into action using its own credentials, permissions, or network reach. In NHI and agentic AI environments, the broker’s authority becomes the real security boundary, so both caller identity and downstream destination controls must be explicit.
• Output Spoofing: Output spoofing is the act of feeding a system false command results so it behaves as if a trusted process produced them. In AI workflows, the model may accept spoofed output as ground truth and take the wrong next step. This becomes dangerous when the output channel is predictable, unverified, or shared.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Outbound Destination Control: Policy that restricts where a server may connect when it acts on behalf of a caller. For AI tool servers and other NHIs, this is a core identity safeguard because destination reach is part of delegated authority, not merely a networking detail.

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 building or maturing an IAM programme, it is worth exploring.