By ByteBot
Datadog’s application keys are going legacy this quarter — and Q3 2026 closes in weeks. At DASH 2026, Datadog announced it is replacing the old API key + application key pair with four new credential types: Personal Access Tokens, Service Access Tokens, Workload Identity Federation, and customer-managed OAuth clients. Application keys won’t break immediately. But after Q3 2026, they stop evolving: no new permission scopes, no new API capabilities. Every new Datadog feature will require the new auth model to access it.
If your team has been copying the same application key across CI pipelines for three years, now is the time to fix that — before the gap between what you can do and what the new model enables starts to compound.
Why Application Keys Were Always a Problem
The old model had a structural flaw: an application key inherits the full permissions of whoever created it. There’s no built-in TTL, no granular scoping, and when that developer leaves the company, you’re either stuck with an orphaned credential or scrambling to recreate it under a new account. Datadog doesn’t transfer application keys between users for security reasons, which means every team transition becomes a manual credential audit.
The new model fixes all of this at the design level. Every credential type has a specific identity, explicit permission scopes, and proper expiration semantics. That’s what you get with PATs, SATs, Workload Identity Federation, and OAuth clients.
The Four New Credential Types, Briefly
Personal Access Tokens (PATs) are for individual developers doing interactive work — running local scripts, testing API calls, one-off automations. They’re tied to your Datadog user account, require at least one permission scope, and expire between 24 hours and one year. Once created, you can’t change the TTL; revoke and recreate if you need a different lifetime. Authentication is a single Bearer token in the Authorization header — no API key needed alongside it.
Service Access Tokens (SATs) are the right choice for anything running unattended: CI/CD pipelines, Terraform automation, monitoring scripts that fire on a schedule. They’re attached to a service account, not a person, so they survive team changes without becoming orphaned. You choose the expiration (1 day, 1 month, 1 year, never, or custom) and scope them to the minimum permissions your pipeline requires.
Workload Identity Federation eliminates stored credentials entirely for cloud workloads. If you’re running Terraform or the Datadog Agent on AWS, you can authenticate through IAM without putting a Datadog credential in your secrets manager at all. Datadog validates your AWS identity via STS and issues a temporary JWT. GCP and Azure support is planned.
Customer-managed OAuth clients cover the agentic and integration use cases: AI agents that need Datadog access, third-party apps that act on behalf of a user, or any system that needs delegated authorization. It supports both delegated flows (the user approves specific scopes) and machine-to-machine (M2M) for autonomous agents that operate without a human in the loop.
Which Credential to Use: A Quick Decision Guide
Running scripts locally or testing from your machine? Use a PAT. Set a short TTL — one month is enough for most dev work, and a shorter window limits your exposure if the token leaks.
Running automation that doesn’t require a human to kick it off? Use a SAT. Attach it to a service account so it doesn’t vanish when a team member leaves. Scope it to only the permissions your pipeline actually needs.
Running Terraform or the Datadog Agent on AWS? Use Workload Identity Federation. Zero credentials to store, zero rotation to manage.
Building an integration, a third-party app, or an AI agent that calls Datadog APIs? Use OAuth. If your agent operates autonomously, use the M2M flow. This is the correct answer for agentic workflows — giving an AI agent a developer’s application key is an audit and accountability problem waiting to happen.
The Agentic Angle Is the Real Reason to Care Now
Here’s the sharper version of why this matters in 2026 specifically: AI coding agents are now calling Datadog APIs directly. Claude Code, Codex, and similar tools can create dashboards, query metrics, and set up monitors — all without a human in the loop. If those agents authenticate with a developer’s application key, every agent action looks like that developer in the audit log. You can’t tell whether a human or an autonomous agent made a change.
SATs and OAuth M2M give agents their own identity. That distinction matters for compliance, for incident response, and for auditors who want to know what changed and who — or what — changed it. Non-human identities already outnumber human identities by 45:1 or more in most enterprises. An auth model that doesn’t account for non-human workloads is already outdated.
What “Legacy” Means — and Why You Should Move Now Anyway
Application keys won’t stop working when Q3 ends. Datadog has been clear: no forced migration, no immediate breaking changes. But “legacy” has a practical meaning over time. Any new Datadog feature that requires new permission scopes will only be accessible through PATs or SATs. Teams that stay on application keys will hit capability walls as Datadog ships new API surface.
The migration itself is not painful when you have time to do it deliberately. Audit which application keys you have, identify whether each use case maps to a PAT, SAT, or Workload Identity, and swap them out. The Bearer token authentication pattern is the same across all new types — it’s a drop-in replacement for most integrations.
# Old: API key + application key
curl -X GET "https://api.datadoghq.com/api/v2/users" \
-H "DD-API-KEY: <YOUR_API_KEY>" \
-H "DD-APPLICATION-KEY: <YOUR_APP_KEY>"
# New: PAT as Bearer token (no API key needed)
curl -X GET "https://api.datadoghq.com/api/v2/users" \
-H "Authorization: Bearer <YOUR_PAT>"The teams that will regret waiting are the ones who discover, six months from now, that a new Datadog feature they need requires a SAT — and then spend a weekend migrating under pressure. Start with Workload Identity Federation if you have AWS workloads — it’s the cleanest migration and eliminates an entire class of credential management problems.
