The Grafana MCP server lets Claude, Cursor, and AI agents query dashboards, logs, and metrics in plain English. Here's the setup, the real risk of PII and secrets hidden in observability data, and how to govern it with redaction at the MCP layer.
.webp)
--disable-write flag for read-only. It authenticates with a service-account token and can also create and modify alerts, incidents, and dashboards.The Grafana MCP server is a Model Context Protocol implementation that exposes a Grafana instance to AI agents as standardized tools — searching and reading dashboards, listing and querying datasources, running log and metric queries, and managing alerts and incidents.
The official mcp-grafana, maintained by Grafana Labs (Apache 2.0, written in Go), works against both self-hosted Grafana and Grafana Cloud. It's read/write by default, with a --disable-write flag that restricts it to read access while preserving querying. It authenticates with a service-account token and supports multi-organization access. Tool categories are configurable, and RBAC requirements are documented per tool.
The crucial thing to understand: Grafana is not itself the data store — it's a window onto your datasources. So the Grafana MCP server queries through Grafana into Prometheus, Loki, ClickHouse, CloudWatch, Elasticsearch, and Snowflake. One connection reaches many backends.
From the on-call engineer's seat, the agent suddenly understands the observability stack — it pulls logs, correlates metrics, and explains an incident. From the security seat, you've handed an AI client a query path into logs full of PII and secrets, and a pivot into every connected datasource.
That's the value. It's also exactly where a control layer belongs.
Point an agent at the Grafana MCP server and it works the observability stack directly, bounded by the service-account token. In practice it can:
Every one of those runs with the service-account token's permissions — which is what makes it useful, and exactly why the data those queries return needs an inspection layer in the tool-call path.
Observability data is sensitive data that no one labels as such. Five categories every security team should price in:
1. Logs are full of unclassified PII. Application and access logs routinely contain user emails, IP addresses, request bodies, and identifiers — PII that flows into Loki and is one query away from the model context, even though nobody ever classified it as regulated.
2. Secrets leak into logs. Tokens, API keys, and connection strings get logged accidentally all the time. A Loki query through the MCP server can surface those secrets straight into an AI agent.
3. Grafana is a pivot into every datasource. Because Grafana proxies queries to Prometheus, CloudWatch, Elasticsearch, and Snowflake, the MCP server's reach isn't limited to Grafana — it extends into the regulated data living in those backends. One connection, many blast radii.
4. Read/write means an agent can change alerting. The server is read/write by default; a prompt-injected agent could modify or disable alert rules — turning a monitoring tool into a way to create a security blind spot, not just read data.
5. Service-account tokens are broad. A Grafana service-account token can carry wide permissions across orgs and datasources. The --disable-write flag and per-tool RBAC are opt-in controls, not the default posture.
Grafana's own controls — RBAC, --disable-write, scoped service accounts — are all about access; none redact the PII and secrets inside the log lines an allowed agent queries. The DLP a company already runs doesn't sit between an agent and Grafana's datasource proxy. That reach is precisely why each agent's access must be governed: controlled (which datasources it can reach, and whether it can modify dashboards or alerts), the sensitive data it returns protected, and every query audited. That is where Strac Grafana MCP DLP lives.
Strac's Grafana MCP DLP is the governance layer that sits between AI agents and the Grafana MCP server. Strac governs every query: it sees exactly what each agent runs, controls what it can reach and do, protects the log and query content it touches, and logs every call as audit evidence. In-policy, non-sensitive queries flow through untouched.
What this looks like in practice, mapped to See / Control / Protect / Prove:
The same Strac MCP DLP layer covers the datasources behind Grafana, too — Snowflake MCP, Postgres MCP, and the AWS MCP surface — one control plane across every place AI agents reach your regulated data. See the MCP DLP pillar and the broader MCP data security discipline for the full model.
MCP DLP governs the AI-agent surface. Strac's data discovery governs the data itself — continuously finding and classifying PII, PHI, PCI, and secrets across your environment, including the unclassified data that ends up in logs. Most teams run both: discovery to map and label, MCP DLP to govern how agents reach it.
What Strac's discovery includes:
For the broader practice, see AI data governance and DSPM for AI. For every surface Strac covers, see strac.io/integrations.
The screenshot below shows Strac's MCP DLP redacting sensitive data from a real Claude session — customer emails, identifiers, and credit card numbers tokenized inline before the model received them. The same inspection pattern runs on every Grafana MCP query routed through Strac, applied to the log lines and query results returned.
Setup is agentless and takes under 10 minutes.
json
"mcpServers": {
"grafana": {
"url": "https://mcp.strac.io/grafana",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, and custom agents — same endpoint, same auth.The same Strac Grafana MCP DLP control produces evidence mapped to every major compliance framework.
For the broader AI-data-governance program this sits inside, see AI DLP.
Yes — Grafana Labs maintains the official mcp-grafana server (Apache 2.0, written in Go), which works with self-hosted Grafana and Grafana Cloud. It covers dashboards, datasource queries, alerts, incidents, and OnCall, and authenticates with a service-account token. It's read/write by default, with a --disable-write flag for read-only.
Not by default — it's read/write, with a --disable-write flag you can set to restrict it to read access (disabling dashboard, alert, incident, and snapshot changes while keeping queries). Even in read-only mode, it still returns raw log lines and query results, so scoping prevents writes but doesn't redact the PII and secrets inside the data an agent reads.
Yes — the same thing. The MCP specification says server; Claude and Cursor surface it as the Grafana connector. Both let an agent query dashboards, logs, and metrics, and Strac's Grafana MCP connector redacts regulated data at the tool-call boundary regardless of the label.
Because logs and traces are full of sensitive data that no one classifies. Application logs carry user emails, IPs, and request bodies; secrets like tokens and keys get logged accidentally. A single Loki query through the MCP server can surface all of it into the model. And since Grafana proxies queries into Prometheus, CloudWatch, Elasticsearch, and Snowflake, the exposure extends into those datasources too. The fix is a layer that redacts PII and secrets from log lines and query results before the model sees them.
Yes. Strac inspects the call before it executes. Write actions — creating or modifying dashboards, alert rules, and incidents — can be blocked outright, allowed only on specific resources, or routed for human approval, so an injected prompt can't disable your monitoring.
PII (SSN, driver's license, passport, address, phone, email, IP addresses), PHI (clinical identifiers), PCI (full and partial card numbers via Luhn check), credentials (API keys, AWS / GCP / Azure access keys, OAuth tokens, JWTs, connection strings — 48+ patterns), and custom detectors — including your own regex — trained on your internal classifications. Detection runs on raw log lines and query results across every connected datasource.
Under 10 minutes. Connect Strac with a least-privilege service-account token, paste the Strac MCP endpoint into your AI client's config, pick a policy template, done. No application changes.
The Grafana MCP server is fast becoming the way AI agents read your observability stack — dashboards, metrics, and the logs where PII and secrets quietly accumulate. It's read/write by default, and because Grafana proxies into Prometheus, CloudWatch, and Snowflake, one connection reaches far beyond Grafana itself. Running Grafana MCP in 2026 without an MCP-layer governance control isn't a question of if a logged secret reaches a model it shouldn't; it's when.
Strac Grafana MCP DLP gives you the control plane — see every query, scope every agent, block dashboard and alert changes, redact every logged secret and PII, prove every call — so your team can use Grafana with Claude, Cursor, ChatGPT, and any future AI client without making each one a separate security exception.
If you are running — or about to run — Grafana MCP in production, book a 30-minute demo. We'll walk through the architecture, the datasource-scope decision, the log-redaction policy, and a deployment plan for your stack and AI clients.
For the broader MCP DLP control plane across every data surface, see the MCP DLP pillar. For more data-platform deep dives: Snowflake MCP, Postgres MCP, AWS MCP.
.avif){kind=icon}
.gif)
