{
  "schema": "aaes/capability-pack/1",
  "provider": "datadog",
  "version": "1.0.0",
  "description": "Datadog: read monitors, hosts, events, and incidents; schedule downtime that suppresses monitor alerts and may send notifications.",
  "notes": "The registered host 'api.datadoghq.com' is Datadog's real US1 API host — a shared SaaS authority, not a placeholder. Datadog is per-site: if the customer's org is not on US1, substitute the site API host (api.us3.datadoghq.com, api.us5.datadoghq.com, api.ap1.datadoghq.com, api.ap2.datadoghq.com, api.uk1.datadoghq.com, api.datadoghq.eu, api.ddog-gov.com or api.us2.ddog-gov.com per the Datadog sites documentation) in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together before enabling.\n\nEvery read endpoint here is a collection read only: single-record reads (GET /api/v1/monitor/{monitor_id}, GET /api/v2/events/{event_id}, GET /api/v2/incidents/{incident_id}) are not registered.\n\nApproval classification: the downtime capability is registered as create and send at the minimum R3 tier — a downtime globally suppresses monitor notifications for its scope (suppressing alerts can hide incidents from the people who would have been paged), and the downtime object's documented message and end-notification settings can themselves notify recipients, an unrestricted notification-capable effect that cannot be un-delivered; send is one of the designated actions requiring human approval.\n\nNot every downtime has a finite end — the documented schedules include no-end and recurring forms — so self-expiry cannot justify a lower tier even though a scheduled downtime can be cancelled (DELETE /api/v2/downtime/{downtime_id}, not registered).\n\nExcluded operations: monitor creation, edit, deletion, validation or mute/unmute (including the deprecated mute_all), host mute/unmute, downtime update or cancel, incident creation, update, deletion, impacts, todos, attachments, notification rules or settings, event posting — the v2 Event Management intake (POST /api/v2/events) is served from a separate event-management-intake.<site> host that no capability here may reach, while the deprecated v1 event intake (POST /api/v1/events) is served from the registered API host and is equally not registered by this pack, monitor notification rules, configuration policies, the logs/events search APIs with caller-controlled query text (POST /api/v2/events/search), usage metering, key management, and every other Datadog API.",
  "credential": {
    "secret_ref_id": "secret-ref-datadog-api-key",
    "custody": "customer_vault",
    "inject": "header",
    "inject_name": "DD-API-KEY",
    "note": "A Datadog org API key plus a scoped application key for the customer's own org, held in the client's own secret manager. Datadog requires two headers on each of the registered operations: DD-API-KEY and DD-APPLICATION-KEY. The pack format models one injection point per credential, so this pack declares the DD-API-KEY header and the stored material under the reference is the complete header value for it — the API key itself, with no scheme prefix.\n\nThe second header is wiring the deployment must complete honestly: store the application key under its own reference and configure the HTTP connector to emit DD-APPLICATION-KEY alongside DD-API-KEY on every call; a deployment that can inject only one header fails closed (Datadog answers 403), and it must not work around the gap by embedding the application key in code or config outside custody. Application keys are scoped and are associated with the user or service account that created them, by default carrying that account's permissions: create both keys under a dedicated least-privilege service account and grant exactly the application-key authorization scopes the cited API reference pages list for these five operations — the documented read scopes for the four reads, and the documented downtime write scope only where the downtime capability is enabled — noting that scopes set on the key persist even if the owning account's role later changes.\n\nNeither key expires on its own, and the two key types have different lifecycles: an API key is an org-level value revoked by deleting it in Datadog organization settings, while an application key is owned by the user or service account that created it and is revoked by deleting that key; the cited documentation establishes that disabling a user account revokes every application key that user created (API keys created by the disabled account are not deleted and remain valid), so owning the application keys with a dedicated service account keeps user offboarding from silently breaking the pack.\n\nRestricting new key issuance does not invalidate keys already issued of either type. Renewal and rotation therefore sit with an external deployment process: the executor injects the stored values verbatim and performs no key lifecycle of its own. On newer orgs application key secrets are shown once at creation (One-Time Read mode), so capture the value into the vault at creation time.\n\nExecutor hygiene: the values must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack."
  },
  "capabilities": [
    {
      "capability_id": "datadog.monitors.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "internal",
      "egress_allowlist": [
        "api.datadoghq.com"
      ],
      "endpoint": "https://api.datadoghq.com/api/v1/monitor",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-datadog-api-key",
      "inject": "header",
      "inject_name": "DD-API-KEY",
      "actions": [
        "read"
      ],
      "resource_id": "datadog-monitors",
      "description": "List all monitors in the org: names, queries, thresholds, tags and notification targets, which reveal internal alerting topology.\n\nThe registered path covers the collection read only — single-monitor reads (GET /api/v1/monitor/{monitor_id}) and monitor search (GET /api/v1/monitor/search) are not registered by this pack.",
      "requires_review": true
    },
    {
      "capability_id": "datadog.hosts.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "internal",
      "egress_allowlist": [
        "api.datadoghq.com"
      ],
      "endpoint": "https://api.datadoghq.com/api/v1/hosts",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-datadog-api-key",
      "inject": "header",
      "inject_name": "DD-API-KEY",
      "actions": [
        "read"
      ],
      "resource_id": "datadog-hosts",
      "description": "List infrastructure hosts in the org: hostnames, aliases, apps and mute state, which reveal internal topology.\n\nThe registered path covers the collection read only — host totals (GET /api/v1/hosts/totals) and host mute/unmute are not registered by this pack.",
      "requires_review": true
    },
    {
      "capability_id": "datadog.events.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "internal",
      "egress_allowlist": [
        "api.datadoghq.com"
      ],
      "endpoint": "https://api.datadoghq.com/api/v2/events",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-datadog-api-key",
      "inject": "header",
      "inject_name": "DD-API-KEY",
      "actions": [
        "read"
      ],
      "resource_id": "datadog-events",
      "description": "List events from the event explorer within a time range: titles, text and tags, which can carry internal operational detail.\n\nThe registered path covers the collection read only — single-event reads (GET /api/v2/events/{event_id}), caller-controlled event search (POST /api/v2/events/search) and event posting (whose v2 intake is a separate event-management-intake.<site> host) are not registered by this pack.",
      "requires_review": true
    },
    {
      "capability_id": "datadog.incidents.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "api.datadoghq.com"
      ],
      "endpoint": "https://api.datadoghq.com/api/v2/incidents",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-datadog-api-key",
      "inject": "header",
      "inject_name": "DD-API-KEY",
      "actions": [
        "read"
      ],
      "resource_id": "datadog-incidents",
      "description": "List declared incidents: titles, severities, states and the user handles of commanders and creators, which identify people and are personal data.\n\nThe registered path covers the collection read only — single-incident reads (GET /api/v2/incidents/{incident_id}) and incident search (GET /api/v2/incidents/search) are not registered by this pack.",
      "requires_review": true
    },
    {
      "capability_id": "datadog.downtimes.create",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "internal",
      "egress_allowlist": [
        "api.datadoghq.com"
      ],
      "endpoint": "https://api.datadoghq.com/api/v2/downtime",
      "method": "POST",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-datadog-api-key",
      "inject": "header",
      "inject_name": "DD-API-KEY",
      "actions": [
        "create",
        "send"
      ],
      "resource_id": "datadog-monitors",
      "description": "Schedule downtime for a monitor scope. This suppresses matching monitor notifications and can hide incidents from responders. The downtime’s message and end-notification settings can also notify recipients; a delivered notification cannot be recalled.\n\nRequest limits: the body is unrestricted. Documented schedules include recurring downtimes and downtimes without an end time, so automatic expiry cannot be assumed. A cancellation endpoint exists, but it is not registered by this pack.\n\nClassification: create and send, minimum R3, covering both alert suppression and the notification-capable effect. Downtime update (PATCH), cancel (DELETE), and listing (GET /api/v2/downtime) are excluded.\n\nOn supported AAES-mediated execution paths, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.",
      "requires_review": true
    }
  ],
  "resources": [
    {
      "resource_id": "datadog-monitors",
      "kind": "api",
      "locator": "https://api.datadoghq.com/api/v1/monitor",
      "data_class": "internal",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    },
    {
      "resource_id": "datadog-hosts",
      "kind": "api",
      "locator": "https://api.datadoghq.com/api/v1/hosts",
      "data_class": "internal",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    },
    {
      "resource_id": "datadog-events",
      "kind": "api",
      "locator": "https://api.datadoghq.com/api/v2/events",
      "data_class": "internal",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    },
    {
      "resource_id": "datadog-incidents",
      "kind": "api",
      "locator": "https://api.datadoghq.com/api/v2/incidents",
      "data_class": "pii",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    }
  ],
  "review": {
    "state": "library",
    "date": "2026-09-22",
    "sources": [
      "https://docs.datadoghq.com/api/latest/monitors/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/api/latest/hosts/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/api/latest/events/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/api/latest/incidents/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/api/latest/downtimes/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/getting_started/site/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/account_management/api-app-keys/ (retrieved 2026-09-21)",
      "https://docs.datadoghq.com/resources/json/full_spec_v2.json (retrieved 2026-09-21)"
    ],
    "reviewer_id": "aaes-eng"
  }
}