The Datadog Agentless Scanning API provides visibility into risks and vulnerabilities across hosts, running containers, and serverless functions without requiring teams to install agents. It is one of 290 APIs that Datadog publishes on the network, tagged Agentless Scanning, Cloud Security, and Vulnerabilities.
An agentless API from the company whose name is a synonym for the agent is worth a look.
What the product concedes
Datadog built a business on a daemon running on every host. Agentless scanning is the acknowledgement that a meaningful share of infrastructure will never have that daemon installed: a serverless function that lives for 200 milliseconds, a container image nobody owns, a subsidiary’s AWS account acquired last quarter, a machine some team stood up outside the platform group’s reach.
The security question in all those cases is the same — what is running, and is it vulnerable — and the agent-based answer is unavailable. So the API reads the cloud provider’s own control plane and storage layer instead of the guest OS.
That is a real architectural trade, not a marketing distinction. Agentless gets you breadth and gets it fast; it cannot see runtime process behaviour. Both readings are legitimate and they answer different questions, which is why the endpoint exists alongside the agent rather than replacing it.
Why this belongs to the API surface, not the console
The scanning configuration is exposed as an API because the accounts being scanned are themselves managed programmatically. If your AWS accounts are created by Terraform, then enrolling each new account into scanning has to be a call, not a click — otherwise coverage drifts the day someone provisions an account on a Friday.
This is the general rule for security tooling, and it is the one most vendors miss. A security control that can only be configured in a console guarantees the gap between “what we own” and “what we scan” grows monotonically. Datadog exposing enrollment as an operation is what makes coverage an invariant instead of an audit finding.
The artifact gap
The catalog entry’s published artifact set is API documentation and an API reference — no OpenAPI specification.
For a provider with 290 API entries and an otherwise deep artifact practice, that is a notable omission on this particular endpoint. It is also a common pattern: newer product surfaces ship documentation first and get into the machine-readable definition later. The consequence is concrete. An agent resolving Datadog’s surface from the catalog alone can find and read this API, and cannot generate a client for it or verify a request against a schema before sending it.
Documentation tells a human what to do. A specification tells a machine what is valid. On a security API being wired into account-provisioning automation, the second one is the one you want.
Takeaway
An agentless API from the agent company, exposed as configuration-by-call so scanning coverage tracks infrastructure that is itself created by code. The reasoning is right and the artifact set is one file short of complete.
Read the reference at docs.datadoghq.com, and the provider entry at apis.io/providers/datadog/.