Audit logging for MCP servers on Datadog

How can you get reliable audit logging from your MCP servers into Datadog without exposing secret keys? Most engineering teams reach for a static API token, embed it in CI pipelines, and let the server push metrics directly to Datadog. The token lives in configuration files, environment variables, or secret stores that are rarely rotated. When a request is made, the server talks straight to Datadog’s endpoint; there is no central point that can see *what* was sent, *who* initiated it, or *when* it happened. The result is a blind spot: you have observability on performance, but you lack a trustworthy audit trail.

Regulatory frameworks, internal security policies, and incident‑response teams all demand immutable audit logging. Without a record of each request, you cannot answer questions like “Which service queried customer data at 02:15 UTC?” or “Did an automated job accidentally exfiltrate logs?”. The lack of a unified log source also makes it hard to correlate MCP activity with other infrastructure events in Datadog dashboards.

Many organizations mitigate credential leakage by moving to non‑human identities, service accounts, OIDC‑issued tokens, or short‑lived IAM roles. This reduces the blast radius of a compromised secret, but the core problem remains: the request still travels directly from the MCP server to Datadog, and the path offers no place to enforce or record audit logging. In other words, the setup solves credential exposure but does not give you the visibility you need.

Integrating audit logging with Datadog through a gateway

Enter hoop.dev. The product acts as a Layer 7 gateway that sits between the MCP server and Datadog’s API. Identity verification happens up‑stream via OIDC or SAML; the gateway trusts the token, extracts group membership, and decides whether the request may proceed. The actual network‑resident agent runs inside your trusted environment, holds the Datadog credentials, and forwards traffic only after applying policy.

Because the gateway is the only point where traffic is inspected, hoop.dev records every request, method, endpoint, payload size, and the identity that originated it. Those records are streamed to Datadog as structured events, giving you a searchable, time‑ordered audit log that lives alongside your existing metrics. The gateway can also mask sensitive fields in responses before they reach the MCP server, ensuring that downstream logs never contain raw secrets.

All enforcement happens in the data path, not in the MCP server or the identity provider. hoop.dev enforces just‑in‑time access by checking each request against policies that can require human approval for high‑risk operations. If a request violates a rule, the gateway blocks it before it ever reaches Datadog, preventing accidental data exposure.

Why the gateway model matters

• Immutable session records: Every interaction is captured at the protocol layer, providing a reliable audit trail.
• Real‑time visibility: As soon as a request passes through the gateway, a corresponding audit event appears in Datadog, enabling live dashboards and alerts.
• Policy‑driven masking: Sensitive fields (API keys, personal identifiers) can be redacted on‑the‑fly, reducing downstream exposure.
• Just‑in‑time approval: High‑privilege actions trigger an approval workflow, adding a human decision point without changing the MCP server code.

Getting started

To put this architecture into production, start with the getting‑started guide. The guide walks you through deploying the gateway with Docker Compose or Kubernetes, configuring OIDC authentication, and registering a Datadog connection. All of the policy definitions and masking rules are managed through hoop.dev’s web UI or API, so you never need to embed secrets in your MCP server code.

For a deeper dive into feature capabilities, such as how audit events are formatted for Datadog, or how to define masking policies, visit the learn section. The documentation includes best‑practice patterns for structuring audit logging pipelines and integrating with existing observability stacks.

FAQ

Q: Do I need to change my MCP server code to use the gateway?
A: No. The server simply points its Datadog endpoint to the gateway address and continues using its existing client libraries.

Q: How are credentials protected?
A: The gateway stores the Datadog API key internally; the MCP server never sees it, and the key is never written to disk by the server process.

Q: Can I retroactively query audit logs?
A: Yes. Because events are streamed to Datadog, you can use Datadog’s log search and analytics to explore historical request data.

Ready to see the code in action? Explore the open‑source repository on GitHub and start building a secure audit logging pipeline for your MCP servers today.