Security

This page covers the security posture of the Datadog Agent itself — trust boundaries, secret handling, signing, and code-level practices. The customer-facing security products (CWS, CSPM) are documented under Cloud Workload Security.

Trust boundaries

The Agent has multiple privilege levels:

Process	Privilege
Core Agent	dd-agent user (Linux), LocalSystem (Windows service)
Trace Agent	Same as core
Process Agent	Elevated for /proc access
System Probe	root / LocalSystem (privileged kernel access)
Security Agent	Same as System Probe (cooperates closely)
Cluster Agent	dd-cluster-agent (Kubernetes service account)

Privileged data crosses process boundaries via:

• HTTP IPC over UDS sockets with file-system permission checks.
• gRPC over UDS sockets with the same.
• Auth tokens (/etc/datadog-agent/auth_token) generated at first run.

This isolates the privileged kernel access in System Probe / Security Agent from the rest of the Agent.

Secrets

The Agent processes secrets in three places:

• API keys — required to authenticate to the Datadog backend.
• Integration credentials — passwords, tokens, certificates checks need to talk to monitored systems.
• Compliance check results — may include PII or other sensitive data.

Mechanisms:

• Environment variables — DD_API_KEY and similar.
• Configuration file — api_key: in datadog.yaml. Plain text on disk; access is controlled by file permissions.
• Secret backend — secret_backend_command runs an operator-provided executable that returns a JSON map of resolved secrets. This lets customers integrate with Vault, AWS Secrets Manager, etc.
• Cloud-native secret stores — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault are first-class options through the secret backend.

Implementation: comp/core/secrets/ (component) and pkg/secrets/ (legacy).

Critical: the root AGENTS.md repeats: "Never commit API keys or secrets. Use secret backend for credentials."

Secret scrubbing

The flare component scrubs secrets out of the support archive before shipping it. Scrubbing patterns live in pkg/util/scrubber/ and pkg/redact/. They cover:

• API keys (api_key, app_key, …).
• Common passwords and tokens (password, token, passwd, key).
• AWS, GCP, Azure credential patterns.
• Hex-encoded secrets and JWTs.
• Custom user-configured patterns (process_config.custom_sensitive_words).

The Process Agent also scrubs command-line arguments before shipping them (process_config.scrub_args).

Logging discipline

docs/public/guidelines/conventions/logging.md is the canonical guide. Highlights:

• Never log API keys.
• Avoid logging the full payload of HTTP responses.
• Avoid logging container env vars wholesale.
• When in doubt, log the field name and a hash, not the value.

Signed payloads

• Remote Config payloads are signed by Datadog's RC service. The Agent ships with bundled root keys (pkg/remoteconfig/state/); verification follows a TUF-like model.
• eBPF programs are not signed by the Agent itself, but they are verified by the kernel verifier on load. Some kernels also enforce module signing on the Agent's eBPF distributions.

Build-time supply chain

• License compliance — LICENSE-3rdparty.csv lists every direct and indirect dependency. tasks/licenses.py validates it. .wwhrd.yml declares the allowed licenses.
• SBOM — cmd/sbomgen/ generates SBOMs for the Agent and its dependencies.
• Renovate — renovate.json configures Renovate Bot to keep dependencies current. .github/workflows/agent-supply-chain-newsletter publishes a periodic supply chain review.
• Static analysis — tasks/quality_gates.py, static_quality_gates/, and static-analysis.datadog.yml enforce supply chain quality gates.

FIPS mode

pkg/fips/ and the fips build tag enable FIPS-compliant cryptographic primitives. FIPS mode is a packaging variant that requires using the BoringCrypto-flavored Go toolchain.

Service hardening

The Linux deb/rpm packages ship a systemd unit with hardening directives:

• NoNewPrivileges
• ProtectSystem, ProtectHome
• PrivateDevices
• Capability restrictions where possible (the System Probe needs more capabilities than the rest)

The MSI installer installs Windows services with a least-privilege ACL.

In-process protection

• Goroutine watchdog in the Trace Agent (pkg/trace/watchdog/) terminates the process if its CPU/memory go above configured limits — protects the customer's host from runaway Agent behavior.
• Forwarder limits prevent unbounded queue growth.
• Python check timeouts isolate misbehaving Python integrations.

Code review focus areas

AGENTS.md calls out specific concerns reviewers pay extra attention to:

• Concurrency and lifecycle (send-on-closed-channel, goroutine leaks).
• Multi-platform divergence (Linux vs Windows MSI packaging is independent and prone to drift).
• Branch-conditional CI gaps (PR CI runs a subset of E2E; packaging changes need qa/rc-required).
• Stale documentation as a source of bugs.

Vulnerability disclosure

The Datadog security team's public vulnerability disclosure process is documented at docs.datadoghq.com and at datadoghq.dev. The repository has the standard .github/SECURITY.md for reports.

Related pages

• Features: Cloud Workload Security — the security product, distinct from this page's topic.
• Apps: Installer — handles signed updates.
• Systems: Remote Config — signed configuration delivery.