Security audit
Security checks for vulnerabilities and agentic risk
This Datadog MCP skill is coherent, but users should review it because its setup can expose Datadog credentials through an unvalidated site value and an unpinned local npm package.
Prefer the remote Datadog-hosted MCP endpoint with narrow toolsets and least-privilege application keys. Avoid the local npx transport unless you pin and review the package version. Only use documented Datadog DD_SITE values, rotate keys if they may have been used with an untrusted site value, and require explicit approval before enabling or using workflow execution.
scripts/validate.sh:30Datadog Credentials Can Be Transmitted to an Attacker-Controlled Host
SKILL.md:46Unpinned Community npm Package Is Downloaded and Executed with Datadog Credentials
The README advertises access to logs, traces, incidents, dashboards, infrastructure data, and workflow execution, but does not clearly warn that these capabilities may expose sensitive production telemetry or trigger remote actions in Datadog. In this skill context, that omission matters because agents may be granted broad observability access and action permissions, increasing the chance of unintended data disclosure or operational changes.
The README instructs users to run npx datadog-mcp-server without pinning a specific package version. This creates a supply-chain risk because users may fetch whatever version is current at execution time, including a compromised or breaking release, which is especially sensitive here because the tool is expected to handle Datadog API and application keys.
The skill documents shell-based setup commands but does not declare any explicit tool scope such as permissions or allowed-tools. In an agent environment, this can cause the skill to be used with broader execution capability than intended, increasing the chance of command execution or environment secret exposure during setup.
Using npx datadog-mcp-server without pinning a version allows whatever package version is current at execution time to be fetched and run. This creates a supply-chain risk where a compromised package release or unexpected upstream change could execute arbitrary code and access Datadog credentials passed on the command line.
The security notes state that API keys grant read access, but the skill also advertises workflow automation tools that may inspect or execute workflows. This can mislead users into treating provided credentials as low-risk read-only secrets when the effective capabilities may include operational actions, increasing the risk of unauthorized changes or automation execution in production.
The setup documentation instructs users to place Datadog API and application keys into shell environment variables and to pass them on the command line as header arguments, but it does not warn that both mechanisms can expose secrets through shell history, process listings, debug logs, or inherited environments. In this skill context, the risk is elevated because the credentials grant access to production observability data, which may include sensitive operational and incident information.
This reference documents access to logs, traces, hosts, incidents, dashboards, and monitors without warning that these data sources routinely contain sensitive operational metadata, personal data, secrets, or internal topology. In the context of a production Datadog integration, omission of privacy and data-handling warnings makes unsafe use more likely and can lead to unnecessary exposure or exfiltration of sensitive information.
The documentation states that the server can infer intent from arbitrary natural-language prompts and choose tools automatically. In a skill with access to production observability data, this broad invocation model increases the chance of overbroad data access, unintended tool execution, and prompt-driven misuse because users are not guided to constrain scope, tool choice, or sensitive-query handling.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Validate API key
check "API key valid"
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
"https://api.${DD_SITE}/api/v1/validate" \
-H "DD-API-KEY: ${DD_API_KEY}")
if [ "$HTTP_CODE" = "200" ]; then pass; else fail "HTTP $HTTP_CODE"; fi
No suspicious patterns detected.