Pass Datadog's IP Allowlist From an MCP Client or AI Agent With a Static IP

Datadog now names AI agents and MCP clients in its blocked list. Turn on the org-level IP allowlist and remote connections from an AI agent or MCP client have to come from an address you registered. Datadog's own docs are blunt about it: "When the IP allowlist is enabled, only IP addresses or CIDR ranges in the allowlist can access the Datadog API and UI." Your agent runs on Heroku, Lambda, or a container, so its egress IP moves. It gets blocked. This is the same problem behind the static outbound IP for AI agents pattern, and the fix is a fixed egress IP.

Datadog's IP Allowlist Gates the API, UI, and MCP Server

The allowlist is an org-level control. It's on Enterprise plans, it needs the Org Management permission to configure, and Datadog exposes it through the UI, a dedicated allowlist API, and Terraform or Pulumi. Once it's enabled, Datadog checks the source IP on the connection before it lets the request through.

What the allowlist enforces:

• The Datadog web UI.
• The Datadog public API, both documented and unpublished endpoints, on application-key auth.
• The Datadog mobile apps.
• Third-party OAuth integrations.
• The Datadog MCP Server, including remote connections from AI agents and MCP clients.

That last line is the timely one. If your agent or MCP client talks to Datadog to read monitors, run a metric query, or manage dashboards, an enabled allowlist stands between it and the response.

Agent Telemetry Ingest Stays Exempt While Control-Plane Traffic Gets Checked

This is the part that keeps the post honest. The allowlist does not block everything that touches Datadog. Telemetry ingest is exempt, so the Datadog Agent keeps shipping metrics, traces, and logs on its API key. So does the validate-API-key endpoint, Agent flare, and public dashboards.

So the pitch here isn't "everything talking to Datadog needs a static IP." Your data pipeline is fine. The traffic that gets checked is the control plane: an app, agent, or MCP client that queries or manages Datadog. Dashboards, monitors, metric queries, and the MCP Server. That's the traffic a static IP fixes. Confirm the current scope against Datadog's IP allowlist docs before you deploy, since Datadog owns that list.

A Static Egress IP Keeps Your Allowlist Entry Stable

An allowlist is only useful if the address in it stays put. Cloud runtimes don't cooperate. On Heroku, AWS Lambda, or a container platform, your outbound IP is drawn from a shared pool and changes on deploys and restarts. You register today's IP, the box moves tomorrow, and Datadog starts refusing your agent even though the API key and app key are correct.

You can't allowlist the whole platform range either. Cloud hosts don't publish narrow CIDR blocks for egress, so trusting your platform's range means trusting every other tenant on it. That's the opposite of what an allowlist is for.

A static outbound IP closes both gaps. Your agent leaves from the same address every time, your Datadog allowlist stays two entries long, and no other tenant shares those entries. This static-egress-plus-allowlist pattern is exactly what lets AI-agent tools clear vendor allowlists elsewhere too, the same way it does for Composio and OpenRouter agent traffic.

QuotaGuard Gives Your Datadog Calls a Static IP in 2 Minutes

QuotaGuard is a proxy. Your app or agent sends its Datadog traffic through QuotaGuard, and Datadog sees one of your two fixed IPs on every request. Setup is one environment variable and a proxy config on your HTTP client.

Add the connection URL to your environment:

QUOTAGUARDSTATIC_URL="http://username:password@us-east-static-01.quotaguard.com:9293"

Then route your Datadog API calls through it. In Node.js:

const axios = require("axios");
const { HttpsProxyAgent } = require("https-proxy-agent");
const httpsAgent = new HttpsProxyAgent(process.env.QUOTAGUARDSTATIC_URL);

// Point at your Datadog API host and the endpoints your app uses.
// See Datadog's API reference for exact paths.
await axios.get("https://api.datadoghq.com/api/v1/...", {
  headers: {
    "DD-API-KEY": process.env.DD_API_KEY,
    "DD-APPLICATION-KEY": process.env.DD_APP_KEY,
  },
  httpsAgent,
  proxy: false,
});

In Python, most HTTP clients respect a proxy environment variable, so you set it once and requests follow:

import os, requests

proxies = {
    "http": os.environ["QUOTAGUARDSTATIC_URL"],
    "https": os.environ["QUOTAGUARDSTATIC_URL"],
}

# Use your Datadog API host and the endpoints your app calls.
resp = requests.get(
    "https://api.datadoghq.com/api/v1/...",
    headers={
        "DD-API-KEY": os.environ["DD_API_KEY"],
        "DD-APPLICATION-KEY": os.environ["DD_APP_KEY"],
    },
    proxies=proxies,
)

Every subscription includes two load-balanced static IPs. Add both to your Datadog org IP allowlist so a request served by either one passes. QuotaGuard's architecture is why this works: your traffic leaves the proxy from a fixed pair of addresses regardless of how often your own dynos or functions recycle. The example host above is region-specific. You pick your region at sign-up, so choose the one closest to your Datadog site, and changing it later means contacting QuotaGuard support.

MCP Clients Route Through QuotaGuard With a Proxy Setting

An AI agent or MCP client is just another HTTP caller under the hood. The fix is the same. Most MCP clients and agent runtimes honor standard proxy environment variables, so exporting them makes the client's outbound Datadog connections leave through QuotaGuard:

export HTTPS_PROXY="http://username:password@us-east-static-01.quotaguard.com:9293"
export HTTP_PROXY="http://username:password@us-east-static-01.quotaguard.com:9293"

If your agent framework configures its HTTP client in code instead of reading the environment, set the proxy on that client directly, the same way the Node and Python examples above do. Either way, the remote connection to the Datadog MCP Server now arrives from one of your two static IPs, and the allowlist lets it through. If a specific client doesn't route proxy traffic the way you expect, check its own proxy docs before you deploy.

That's the whole loop. Two QuotaGuard IPs on the Datadog org allowlist, your app or agent proxied through them, and Datadog's API, UI, OAuth integrations, and MCP Server all accept traffic from an origin you registered.

QuotaGuard Static Pricing Starts at $19/Month

Bandwidth is bundled. No per-GB overage fees. A Datadog control-plane integration or an agent polling monitors moves modest volume, so the entry tier covers most teams. Dedicated IPs are available on Enterprise and above. On lower tiers, your two assigned IPs are still static, but shared with other customers.

QuotaGuard Shield Pricing Starts at $29/Month

Shield costs slightly more than Static at each tier because SSL passthrough adds routing overhead. If your Datadog traffic carries regulated data or your architecture is under SOC 2, PCI-DSS, or HIPAA review, Shield keeps the payload encrypted end to end and is worth the difference. QuotaGuard never decrypts your data in ordinary operation.

All plans include a 3-day trial. Enterprise plans include a 7-day trial. Credit card required.

See the full pricing table at quotaguard.com/products/pricing. For the wider agent-egress picture, see QuotaGuard's static outbound IP for AI agents hub.