TL;DR: Datadog's MCP server is read-only by design, with over a hundred tools that read every observability pillar and write nothing. That genuinely eliminates a class of risk: no agent is deleting your monitors or paging your on-call at 3am. It does not eliminate exfiltration, because exfiltration is a read followed by a forward, and the read surface here is your production logs, traces, topology, incident history, and security findings.
The safety story is real, and it is only half the problem#
Credit where it is due. Most MCP servers hand an agent a mixed bag of read and write verbs and leave containment to you. Datadog made a deliberate architectural choice: read everything, write nothing, across more than a hundred read-only tools spanning logs, APM, metrics, RUM, alerting, infrastructure, and security signals.
That decision removes the failure mode teams fear most when they imagine an agent in their observability stack. An agent cannot mute an alert, break a monitor, or take an action that wakes somebody up. For a class of tool where the worst case is usually "the agent did something irreversible", designing the write path out entirely is the strongest possible answer.
It is also an answer to the wrong half of the question, and the half it does not answer is the one that matters more for security.
Exfiltration is a read#
The write restriction constrains what the agent can do to Datadog. It says nothing about what the agent does with what it read.
An agent session typically has several MCP servers connected at once. Datadog reads telemetry into the context window. Some other connected tool, a ticketing system, a code host, a messaging integration, a browser, has outbound capability. The data moves from the first to the second through the agent, and at no point does the read-only server do anything other than exactly what it was designed to do.
We demonstrated precisely this shape in our research on multi-turn MCP error hypnosis: customer PII left a trusted, correctly-functioning server and arrived at an untrusted one, with the agent as courier. The two servers never communicated. The trusted server was not compromised and had no vulnerability. It was a source, and sources do not need to be broken to leak.
Read-only makes a server a source. It does not make it a boundary.
Blocking writes to Datadog is a real control. It sits on the path the data was never going to take.
What your telemetry actually contains#
The argument above only matters if the read surface is worth stealing. It is, and probably by more than your data classification says.
Logs. Application logs carry email addresses, session tokens, internal hostnames, and request bodies. Every team intends to scrub these. Every team has lines from 2023 that nobody scrubbed.
Traces. APM spans carry query parameters, user identifiers, and the shape of internal calls between services.
Topology and service maps. This is an architecture diagram that is always current. An attacker doing reconnaissance would otherwise spend weeks assembling it, and here it is available through a documented tool call.
Incident history. Postmortems describe how systems fail, which controls were missing, and what the workarounds were.
Security findings. A ranked list of your unremediated vulnerabilities, which is close to the single most useful document an attacker could obtain.
Handed to a human on-call engineer, that is a debugging environment. Handed to an agent operating at machine speed, often with nobody watching the individual calls, it is a queryable export of how your production estate works.
Logs are attacker-writable, which nobody expects#
There is a second issue that gets overlooked because observability data feels like machine output rather than user input.
It is not. Log lines routinely contain strings an outsider chose: user agents, request paths, submitted form values, error messages echoing back input. If an agent reads and acts on log content, then anyone who can make your application log something can put text in front of your agent.
That is prompt injection with a more technical costume than an issue tracker, and the same reasoning applies to the GitHub MCP server's attacker-writable issue bodies. The difference is that nobody thinks of a 404 log line as user-generated content, so nobody treats it as untrusted.
Controls that actually fit this shape#
Scope the app key narrowly. Use a read-only application key limited to the services actually being debugged rather than a full-access key. Datadog's own guidance says the same. The temptation is to issue one broad key so the agent never hits a permission error, and that convenience is what converts a debugging aid into a telemetry export.
Redact on the response path. Filtering has to happen before data enters the context window, not after. Once a token or a customer email is in context, it is available to every other tool in the session and travels with the conversation.
Control what else is connected. The risk is the pairing of a rich read surface with an outbound-capable tool. Auditing servers one at a time will never surface it, because neither one is dangerous alone.
Monitor at the session level. No individual read looks anomalous when reading is the entire purpose of the integration. What is detectable is the pattern: a session that pulls security findings, then service topology, then production logs, then calls an outbound tool. That is a behavioural signature, not a policy violation, and per-action checks will not see it. This is the same argument we make about MCP security generally and about agentic AI threats: the unit of analysis has to be the session.
FAQ#
Is the Datadog MCP server safe?#
It is safe against the risk it was designed for. The server is read-only by construction, so an agent cannot silently modify a monitor, delete a dashboard, or page your on-call rotation. It is not safe against data movement, because the read surface is your production telemetry: logs, APM traces, infrastructure topology, incident history, and security findings. Read-only prevents damage to Datadog. It does not prevent data leaving through the agent.
Why does read-only not solve the security problem?#
Because exfiltration is a read operation followed by a forward. The agent pulls telemetry into its context legitimately, and any other connected tool with outbound capability can then carry that data somewhere else. The write restriction applies to Datadog's own API, not to the agent's other tools. In a session with several MCP servers connected, the read-only one is a source, not a boundary.
What sensitive data does the Datadog MCP server expose?#
Whatever your telemetry contains, which is more than most teams assume. Application logs routinely include email addresses, tokens, internal hostnames, and request bodies. APM traces carry query parameters and user identifiers. Infrastructure topology and service maps describe your architecture in a form an attacker would otherwise spend weeks reconstructing. Security findings enumerate your unremediated vulnerabilities in priority order.
How should I scope the Datadog app key for MCP?#
Use a read-only application key scoped to the specific services being debugged rather than a full-access or admin key. Datadog's own guidance points the same way. The default instinct is to issue one broad key so the agent never hits a permission error, and that instinct is what turns a debugging integration into a full telemetry export.
What should sit in front of a Datadog MCP deployment?#
Inline redaction on the response path, so PII and secrets in log lines are stripped before they enter the agent's context rather than after. Egress control over what else is connected in the same session, since the risk is the combination of a rich read surface and an outbound tool. And session-level behavioural monitoring, because no individual read looks anomalous when reading is the entire job.
Is prompt injection a real concern for observability data?#
Yes, and it is under-appreciated because logs feel like machine output rather than user input. Log lines frequently contain attacker-controlled strings: user agents, request paths, form field values, error messages echoing submitted data. An agent summarising those logs is reading text an outsider wrote, which is the same untrusted-content problem as an issue tracker with a more technical costume.
The risk is the combination, not the server#
Neither a read-only telemetry source nor an outbound tool is dangerous on its own, which is exactly why auditing servers one at a time never surfaces this. Workstation Lens shows which MCP servers are connected alongside each other on every developer machine, so the pairing that makes exfiltration possible is visible before somebody uses it.
