Many teams assume that simply enabling an MCP server for Datadog automatically gives them a complete audit trail. In reality, the server streams data without any built‑in guarantee that every command or response is captured for later review.
That misconception leads engineers to rely on ad‑hoc logging or manual screenshotting, both of which are fragile and easy to miss. Without a reliable record, investigations become guesswork, compliance evidence evaporates, and malicious activity can slip by unnoticed.
Why session recording matters for Datadog MCP servers
Datadog’s MCP (Metrics Collection Protocol) server provides a programmatic endpoint for custom metrics, health checks, and real‑time alerts. Because the server accepts arbitrary payloads, an attacker who gains access can inject false data, hide failures, or exfiltrate internal state. A solid session recording capability creates a replay of every request and response, giving security teams the ability to reconstruct exactly what was sent, when, and by whom.
Beyond incident response, auditors frequently request proof that metric pipelines have not been tampered with. Session recording satisfies that requirement by delivering per‑session logs that can be correlated with identity information.
Current practice and its gaps
Most organizations deploy the MCP server inside a private subnet and protect it with static API keys. The keys are shared among several services, and the same credential often lives in configuration files or environment variables. Engineers reach the server directly from their CI pipelines or monitoring agents. This model suffers from three critical flaws:
- Static credentials provide standing access that cannot be revoked without a full redeploy.
- There is no central point where traffic can be inspected, so dangerous payloads pass unchecked.
- Because the connection bypasses any gateway, no session is recorded for later analysis.
The result is a blind spot: the organization knows the server is running, but it cannot prove what data flowed through it.
Adding just‑in‑time access without full visibility
One improvement teams often make is to replace static keys with short‑lived tokens issued by an identity provider. This reduces the blast radius of a leaked secret, but the request still travels straight to the MCP server. The gateway that could enforce policies or record activity is still missing, so the system still lacks an audit trail.
In this intermediate state, engineers have improved credential hygiene, yet they cannot answer questions such as:
- Which user triggered a spike in a custom metric?
- Did a particular payload contain sensitive identifiers?
- Was a request approved by a human before it was processed?
Those questions remain unanswered because the enforcement outcomes – session recording, inline masking, and approval workflows – have no place to execute.
Introducing hoop.dev as the data‑path gateway
hoop.dev provides a Layer 7 gateway that sits between identities and the MCP server. The gateway receives the user’s OIDC token, validates it, and then proxies the request to the Datadog endpoint. Because all traffic passes through hoop.dev, it can apply the enforcement outcomes that were missing before.
Specifically, hoop.dev records each session. It captures the full request payload, the response from Datadog, and the identity that initiated the call. The recorded stream is stored by the gateway and can be accessed for replay, audit, and compliance reporting.
Because hoop.dev operates at the protocol layer, it can also mask any sensitive fields that appear in responses, block commands that match a deny list, and route suspicious payloads to a human approver before they reach Datadog. All of these actions happen in the data path, ensuring that the enforcement outcomes cannot be bypassed by altering the client or the server.
How the gateway integrates with Datadog MCP
The integration follows the standard pattern described in the hoop.dev documentation. An agent is deployed inside the same network segment as the MCP server. The agent holds the Datadog service credential, so users never see the secret. When a user or automation tool wants to send a metric, it connects to hoop.dev using its normal client library, presents an OIDC token, and the gateway forwards the request to the MCP endpoint after applying the configured policies.
From a setup perspective, the only required pieces are:
- A network‑resident agent that can reach the MCP server.
- A connection definition in hoop.dev that specifies the Datadog host, port, and the credential the agent should use.
- Identity configuration that maps OIDC groups to the permissions needed for each metric namespace.
All of these steps are covered in the getting‑started guide. The guide walks through deploying the gateway, registering the Datadog connection, and configuring just‑in‑time access policies.
Next steps
To start capturing session recording for your Datadog MCP servers, follow the high‑level workflow in the documentation and then clone the open‑source repository for the full implementation details.
Explore the GitHub repository to see how the gateway is built, contribute improvements, or tailor it to your environment.
For deeper insight into how hoop.dev masks data, enforces approvals, and stores audit logs, visit the learn portal. There you will find architecture diagrams, policy examples, and best‑practice recommendations.
FAQ
Is session recording enabled by default?
No. You must define a connection for the Datadog MCP server and enable the recording flag in the policy configuration. Once enabled, hoop.dev automatically captures every session that passes through the gateway.
Can I retrieve a recorded session after the fact?
Yes. Recorded streams are indexed by user, time, and connection name, allowing you to query and replay any session through the UI or API provided by hoop.dev.
Does this add latency to metric ingestion?
The gateway adds only the network hop between the client and the MCP server. In practice the overhead is negligible compared to the processing time of the metric itself, and the security benefits far outweigh the minimal delay.
