Grafana MCP session spoofing exposes the identity broker problem

At a glance

What this is: Pillar Security shows that Grafana MCP combined unauthenticated tool execution with caller-controlled outbound requests, turning the server into an identity broker with exposed authority.

Why it matters: IAM and NHI teams need to treat MCP servers as credential-bearing intermediaries, because weak caller authentication and unconstrained egress can convert a tool gateway into a lateral-movement bridge.

By the numbers:

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

👉 Read Pillar Security’s analysis of Grafana MCP session spoofing and SSRF

Context

MCP security fails when a server treats a session token as proof of identity rather than as protocol state. In Grafana MCP, that distinction mattered because the server could act with its own service-account credential and network reach, which are both identity-security concerns for NHI governance and tool access.

For identity teams, the central issue is not just whether a tool is reachable. It is whether the server that exposes the tool can authenticate the caller, constrain the action, and limit the authority it exercises on behalf of that caller. That is the governance gap this case makes visible.

This is a typical failure pattern in delegated machine access, where the intermediary has more privilege than the caller and the policy boundary is assumed rather than enforced. In MCP deployments, that assumption is structurally unsafe.

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 a larger blast radius than simple APIs?

A: They often combine caller input, stored credentials, and outbound network reach in one component. If the server is not tightly governed, a single request path can expose internal services, privileged tokens, or reachable metadata endpoints. The risk is delegation, not just data exposure.

Q: How should security teams measure whether MCP egress controls are working?

A: They should test whether the server can reach only approved destinations, whether resolved IPs are rechecked at connect time, and whether requests to private or metadata ranges are blocked. A passing control produces denied attempts, not just logged ones, when an unapproved destination is requested.

Q: Who is accountable when an MCP server authorises the wrong action?

A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.

Technical breakdown

Why session IDs are not authentication in MCP

MCP session identifiers help a server maintain protocol state, but they do not prove who the caller is. In the Grafana case, a reachable caller could generate a valid-looking session value and still invoke tools using the server’s stored service-account identity. That means the server accepted protocol continuity without establishing caller identity or authorising the tool execution itself. The security boundary existed in format, not in trust. Practical implication: treat session tokens as state references only, and require explicit inbound authentication before any authority-bearing tool runs.

Practical implication: require explicit caller authentication before the server exposes any authority-bearing MCP tool.

How caller-controlled destinations turn a tool into an SSRF proxy

The grafana_api_request tool accepted a destination parameter, which let the caller choose where the server sent the outbound request. Even when the server withheld its Grafana token from foreign hosts, it still connected to the attacker-selected destination and returned the response. That is the core SSRF risk: the server’s network position becomes a proxy for the caller, including reach into internal services and metadata endpoints. Practical implication: outbound request tools need strict allowlists and address-revalidation controls, not just credential protection.

Practical implication: constrain tool egress with allowlists, resolved-address checks, and explicit blocks on metadata and private ranges.

Why MCP servers behave like identity brokers, not simple API wrappers

An MCP server does not merely relay requests. It translates a caller’s instruction into actions performed with the server’s own credentials, permissions, and network placement. That makes the server an identity broker in practice, even if the protocol does not describe it that way. Once you recognise that role, the governance model changes: the broker must authenticate the caller, authorise the action, and constrain downstream reach. Practical implication: review MCP deployments as credential-bearing intermediaries with their own blast radius.

Practical implication: assess MCP servers as credential-bearing intermediaries with their own blast radius and governance requirements.

Threat narrative

Attacker objective: The attacker objective is to use the MCP server’s own identity and network position to reach systems, credentials, or internal data that the caller could not access directly.

1. Entry occurred when a reachable caller generated a valid-looking session identifier and interacted with the MCP server without authenticating. Escalation followed because the server executed tools using its own Grafana service-account identity, not the caller’s identity. Impact came from the server’s network reach, which let the caller direct requests to internal services and metadata-style targets through an SSRF primitive.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Session spoofing is not the real failure. The failure is treating protocol state as identity. In MCP deployments, a session identifier can organise requests without proving caller legitimacy. That assumption breaks the moment the server can act with its own credentials, because the tool boundary becomes a trust boundary by accident. The practical conclusion is that tool exposure and caller authentication must be designed as one control plane, not two separate checks.

MCP servers create an identity broker pattern that many teams have not yet governed explicitly. The server can hold service-account authority, network reach, and tool invocation rights at the same time. That concentration of authority means a single gateway can become a lateral-movement bridge if its inbound and outbound controls are separated. Practitioners should treat this as delegated machine access with its own lifecycle, not as a convenience layer.

Identity blast radius expands when the intermediary owns both the credential and the route. The Grafana case shows that credential protection alone does not neutralise SSRF if the server still reaches arbitrary destinations on the caller’s behalf. That is a governance gap in destination control, not just a vulnerability in request handling. The implication is that NHI governance must model where a server can go, not only what secret it presents.

Runtime authority in MCP must be bounded by both caller and destination policy. A tool that can issue HTTP requests is effectively an outbound identity decision engine, because it chooses where organisational authority is exercised. Once that is true, session validation, host validation, and origin validation are supporting checks, not the core control. Practitioners should reframe MCP security around authority containment, not transport correctness.

Valid, but never issued is the right concept for this failure mode. The server accepted a session-like value, but that value was never issued as proof of identity. That distinction matters because many identity programmes still assume that a valid protocol artefact implies an authorised actor. It does not. The practitioner takeaway is that issuance, binding, and authorisation must be separable in every delegated tool path.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why practitioners should also review OWASP NHI Top 10 for agentic tool-use, identity, and privilege abuse patterns.

What this signals

The practical risk is that MCP deployments will increasingly sit inside the same control debates as workload identity and privileged access. Once a server can authenticate requests, hold a service account, and decide where to connect, it needs explicit governance around both inbound trust and outbound reach.

Identity broker gap: MCP servers that combine protocol state, service credentials, and network reach create a control gap that many programmes will overlook until they start reviewing delegated access paths. Teams should map these servers into their NHI lifecycle processes now, not after an incident.

As autonomous and semi-autonomous tool use expands, the governance question becomes whether the intermediary can be trusted to mediate authority at runtime. That pushes security teams toward tighter destination policy, stronger caller binding, and better inventory of every credential-bearing tool bridge.

For practitioners

• Separate session state from authentication Require a real caller identity before any MCP tool with authority-bearing access can execute. Do not let session-format validation stand in for inbound authentication, and reject unauthenticated tool requests before they reach the service account or the tool dispatcher.
• Lock down tool egress destinations For any HTTP-request capability, maintain a strict allowlist of approved origins and revalidate the resolved address at connection time. Block loopback, private, link-local, and metadata ranges by default so the server cannot be used as a proxy into internal networks.
• Minimise MCP service-account authority Give the server only the Grafana permissions required for the enabled tools, and separate read-only telemetry access from any action-capable path. If a tool can forward methods or headers, remove that capability unless the workflow genuinely requires it.
• Review MCP as an identity broker lifecycle Map each MCP server to the identities, credentials, and network paths it can exercise on behalf of callers. Reassess onboarding, offboarding, and recertification for these servers as delegated access objects rather than as ordinary application components.

Key takeaways

• Grafana MCP exposed a classic delegated-access failure: the server accepted session-like state without proving caller identity.
• The same component also acted as an SSRF proxy, so one trust mistake created both credential exposure risk and network reach expansion.
• MCP security now needs identity binding, destination control, and lifecycle governance for the server itself, not just the secrets it stores.

Key terms

• Signal spoofing: The act of fabricating or manipulating a sensor or communications signal so a system believes a false state is real. In navigation and automation, spoofing can alter decisions even when the underlying device has not been fully compromised.
• 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.
• 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.
• Delegated access lifecycle: Delegated access lifecycle is the governance of non-human components that act on behalf of others, including onboarding, permission scoping, recertification, and offboarding. For MCP servers, it means treating the server itself as a governed identity object with a defined blast radius.

What's in the full report

Pillar Security's full research covers the technical detail this post intentionally leaves at the governance level:

• The exact session-spoofing behaviour observed in Grafana MCP and how the server accepted tool calls without authenticating the caller
• The SSRF request-flow details, including destination control behaviour and why token protection did not eliminate proxy risk
• The controlled demonstration findings that show how the server’s own authority can be reused against internal and metadata-style endpoints
• The specific release and fix behaviour in Grafana MCP v1.1.0, including the added bearer-token option and logging changes

👉 The full Pillar Security post covers the attack chain, destination-control details, and remediation context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.