For years, authenticating to Datadog APIs meant managing two separate credentials: an API key and an application key. That model worked well when most API activity came from developers running scripts or a small number of integrations. But modern infrastructure looks very different. Today, Datadog APIs are accessed by CI/CD pipelines, Terraform workflows, autonomous systems, and increasingly, AI agents operating across teams and environments.
To support those new access patterns, Datadog is introducing a new authentication model built around four purpose-specific approaches: Personal Access Tokens (PATs), Service Access Tokens (SATs), workload identity federation, and customer-managed OAuth clients. Together, these capabilities provide scoped, identity-aware authentication designed for both human users and non-human workloads.
In this post, we’ll discuss:
Why Datadog is updating its API authentication
Datadog’s new API authentication model
What happens to existing application keys
How to choose the right authentication model for your use case
The original Datadog authentication model separated telemetry ingestion from API authorization. API keys identified the Datadog organization receiving data, while application keys identified the user performing an action. This dual-key model worked well when user identities mapped to individual developers. However, this model did not map cleanly to automated workflows such as CI/CD pipelines, which do not have a single human owner.
AI agents acting on behalf of human users introduced another challenge for the existing model. When the Datadog MCP Server calls an API to retrieve a monitor’s status, how do we determine who authorized the request, what scope was granted, and how long that access should last? Security and compliance teams also need to know exactly who accessed what data, and when that access occurred. Application key usage alone does not provide enough context for detailed audit attribution.
To address these challenges, Datadog is introducing authentication models designed around specific access patterns. Instead of relying on a single credential type for every workflow, teams can now use credentials tailored to developers, automation systems, cloud-native workloads, and delegated application access. In the following sections, we’ll look at how each authentication model works and where it fits best.
Our updated authentication model replaces the application key with four targeted alternatives, each designed for a specific access pattern.
PATs are designed for developers who directly interact with Datadog APIs. They are intended for user-driven workflows such as building CLI tools, writing scripts against the API, or pulling data from Datadog into custom applications and dashboards.
PATs are scoped to the permissions of the user who creates them and require an expiration window to avoid reliance on long-lived credentials. Because PATs are tied directly to a user identity, Audit Trail logs can attribute API activity to a specific user. When a user loses access to an organization, their PATs are revoked alongside their account access.
SATs are designed for automation systems and non-human workloads that need persistent access to Datadog APIs. Common examples include CI/CD pipelines, Terraform runs, infrastructure automation, and autonomous AI agents operating without a human in the loop.
SATs are tied to a service account, not an individual user. The service account has its own permissions, independent of any individual on your team. Like PATs, SATs are scoped and support configurable expiration policies. Unlike old application keys, SATs include readable prefixes (ddsat_) and identifiable public portions, making credentials easier to track and manage.
If your workload runs on AWS, it already has an IAM identity. Workload identity federation, a system that establishes trust between two parties for user authentication and resource access, enables AWS workloads to authenticate directly to Datadog by binding an AWS IAM role to a Datadog service account. Instead of creating and storing static Datadog credentials, the workload uses its existing cloud identity to access Datadog APIs.
This removes the need to store API credentials in secrets managers, CI/CD pipelines, or configuration files for workloads such as Terraform runners and the Datadog Agent. Teams can manage access through existing IAM policies rather than rotating and distributing long-lived credentials.
Workload identity federation is generally available for AWS workloads, with support for additional cloud providers planned for the future.
OAuth clients are designed for AI agents that need temporary, scoped access to Datadog APIs. OAuth supports both delegated access, where an application acts on behalf of a user, and machine-to-machine (M2M) access for autonomous systems operating without a human in the loop.
In delegated workflows, users explicitly approve the scopes an application or AI agent can access before the application receives a short-lived token. This gives organizations more granular control over who authorized the request, what permissions were granted, and how long that access should last.
For autonomous systems, Datadog is actively investing in M2M OAuth support built around dedicated agent identities rather than long-lived shared credentials. OAuth clients also provide a foundation for emerging interoperability standards such as Okta Cross-App Access, helping AI agents operate across enterprise tooling without accumulating standing access. OAuth client support is planned for release later this year.
Application keys will continue to work after Q3 2026, but they will be considered legacy features and no new capabilities will be added. There will not be a forced migration or any immediate impact on existing integrations. Our new authentication model covers almost every use case application keys previously handled, with better scoping, clearer identity, and proper time-to-live (TTL) support. We encourage customers to migrate to the new authentication model as soon as possible to begin taking advantage of these added benefits.
With multiple authentication options available, the right credential depends on who is accessing Datadog APIs, how long that access should last, and where the workload is running.
1. Who is authenticating?
A developer directly accessing Datadog APIs → PAT
A Datadog first-party client (e.g., pup-cli, Datadog MCP Server) → OAuth
An automated pipeline or service → SAT
An autonomous AI agent operating without a human in the loop → SAT today; M2M OAuth support planned
A cloud-native workload running on AWS → workload identity federation
An application or AI agent acting on behalf of a user → OAuth
2. How long does access need to last?
Short-lived or interactive → PAT
Long-running service → SAT
Temporary delegated access → OAuth client
Ephemeral AWS workloads without stored credentials → workload identity federation
3. What are they accessing?
Datadog APIs (configuration, querying, management) → PAT, SAT, OAuth, or Workload Identity Federation
Intake endpoints (metrics, logs, traces, agent data) → API key (this remains the same)
4. From what environment?
Developer laptop or local tooling → PAT
CI/CD system or pipeline → SAT
AWS infrastructure → workload identity federation
You can also refer to the following reference table to help you get started:
| Use Case | Credential | Why |
|---|---|---|
| Developer script / CLI tool | PAT | Tied to your identity, scoped, short-lived |
| CI/CD pipeline / Terraform | SAT | Service account identity, fully auditable |
| Autonomous AI agent (headless, no user in the loop) | SAT (today) → M2M OAuth (coming) | SATs support persistent automation today; OAuth supports temporary per-run access |
| Datadog Agent or Terraform on AWS (more providers coming) | Workload Identity Federation | No credentials to manage |
| A Datadog first-party client | OAuth client | Delegated, no credentials to manage |
| AI agent acting on behalf of a user | OAuth client | Delegated, user-authorized, scoped |
| Submitting metrics, logs, or traces | API key | Unchanged, optimized for high-throughput intake |
Modern infrastructure requires authentication models designed for both human users and automated systems. With PATs, SATs, workload identity federation, and upcoming OAuth support, Datadog’s new authentication model gives teams more granular control over identity, credential scope, and access life cycles across developer workflows, automation systems, and AI agents.
To learn more about PATs and SATs, check out our documentation. If you’re new to Datadog, sign up for a free 14-day trial to get started.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。