Datadog from the terminal,
whether a person or an agent is typing.
Pup CLI is Datadog's command-line interface, built to be run by engineers at a terminal, by pipelines and by AI coding agents. It exposes the Datadog API as commands that return JSON by default and behave the same whoever runs them. We set it up with scoped OAuth tokens instead of long-lived keys, read-only mode where nothing should change, and a rule for when an agent may skip the confirmation prompt. Then we review what it was used for each month.
Quick facts
Related
- MCP Server, the same access for agents that speak MCP
- CI Visibility, the pipelines that will be running it
- Integrations, the API surface it wraps
The API, as commands that a person, a pipeline and an agent can all run
The deploy pipeline needs to mute a monitor for ten minutes and post a deployment event. Today that is a curl command with an API key in a secret, written by someone who has left, that nobody dares change. Pup CLI makes it one command, authenticated as the pipeline, with the output in JSON that the next step can read.
One tool, most of the platform. List monitors by tag, search a log window, query a metric, update a dashboard or trigger a Bits Investigation, each as a single command. The curl scripts in the runbooks have a replacement.
Authentication that expires. OAuth2 with PKCE is the preferred path, giving a scoped token through a browser login rather than a long-lived API key in a dotfile. API keys remain as a fallback and a bearer token covers stateless use in a pipeline.
Built for agents, with the brakes on. Pup has no separate agent mode: output and help are the same for a person or an agent. When it detects an AI coding agent it auto-approves confirmation prompts, as the yes flag does, unless the no-agent flag is passed. A read-only flag blocks create, update and delete entirely.
Output the next step can use. JSON by default, table and YAML on request. A pipeline step, a script or an agent reads the result without parsing a web page, and the same command works in all three places.
A long-lived key in the pipeline, the confirmation prompt skipped by default, and a CLI nobody listed in the access review
How it bills. Pup CLI carries no meter of its own: Datadog's documentation states none and its pricing lists none. It calls the Datadog API, and work that a product meters is metered there whichever client asked for it, so a Bits Investigation triggered from the CLI draws on AI Credits. Datadog's documentation does not state an availability status for the CLI; the project is published by Datadog on GitHub and marks some of its command groups as Preview or experimental. We publish no rates. The lever here is not cost. It is identity: which person, pipeline or agent ran which command, under which token.
The configuration traps. The CLI is installed with an API key and an application key from an engineer's own account, pasted into a pipeline secret, and the pipeline now acts as that engineer forever. The environment variable that skips confirmation prompts is set globally in a shell profile and never revisited, so the delete command that asks for confirmation does not. An AI coding agent is given the CLI and, because Pup auto-approves prompts when it detects an agent, the agent's judgement is now the only check on a remote change. The read-only flag exists and is not used anywhere. The CLI is not in the access register because it is a binary rather than an integration, so the quarterly review of who can change Datadog never lists it. Each of these is a shortcut on a tool designed to be safe when it is configured.
Field noteThe most common gap we see is the pipeline that belongs to a person. A CLI set up with a personal API key and application key, copied into a pipeline. When the engineer leaves and their account is disabled, Datadog revokes their application keys, and the pipeline fails on the next deploy with nobody sure why.
Field noteThe pattern we keep finding is the confirmation prompt disabled once and forgotten. The environment variable that auto-approves it went into a shell profile during an incident, and every destructive command since has run without asking.
Field noteAn AI coding agent is handed the CLI with the engineer's own token. The agent is well behaved and auto-approved, and the only thing preventing it from deleting a dashboard it thinks is unused is the instruction that it should ask first.
Field noteThe useful deployments are the boring ones: a pipeline that posts a deployment event and mutes the right monitors for the right window, as itself, with a token that expires. Where that exists, the curl scripts disappear and the access review gets shorter.
An identity per runner. A token that expires. Read-only unless the job writes.
We start with a Datadog HealthScan, read-only and fully automated, which reports the API keys and application keys in use, who created them, and which have been calling the API from places that look like pipelines. The setup then runs within Managed Observability onboarding.
- Inventory the scripts the CLI replaces. Every curl call to the Datadog API in the pipelines and the runbooks, with the key it uses and the person who created it. Those are the first commands to migrate.
- Set up OAuth for people. Engineers authenticate with the browser login and get a scoped token that expires. Personal API keys are retired from dotfiles and from shell history.
- Give each pipeline its own identity. A service account per pipeline or runner with the narrowest role that does the job, and a bearer token or key owned by that identity rather than a person.
- Default to read-only. The read-only flag is set in the standard configuration for every runner and every agent. It is removed only for the specific job that writes, and that job is listed.
- Write the agent rule. Where an AI coding agent runs Pup, prompts stay on and the token is read-only. The agent is instructed to request authorisation before any remote change, as Datadog's guidance says.
- Hand over the register. Every identity that runs the CLI, its role, its token type, whether it writes, and the commands it is for. The register joins the quarterly access review.
Access is admin on the Datadog organisation for keys, OAuth settings and roles. Each engineer authenticates with their own browser login and each pipeline with its own identity; we specify the configuration and hold no token of yours.
A CLI published by Datadog on GitHub gains commands faster than the register notices
New command groups arrive, some marked Preview. A pipeline is cloned with its token. An agent is handed the binary. Managed Observability is the monthly service that reviews which identities ran which commands and keeps the register true.
Every month, usage is reviewed by identity. API calls by key, token and role against the register, with new identities, write calls from read-only jobs and calls from departed users investigated.
Identities follow the pipelines. A cloned pipeline gets its own identity rather than the original's. A retired pipeline has its token revoked in the same change.
The configuration is kept honest. The standard Pup configuration, read-only by default with prompts on, is checked against what the runners actually carry. An auto-approve variable that drifted into a shell profile is a finding.
The command that broke something pages us. A monitor muted by mistake, a dashboard deleted by an agent, a deployment event that never arrived: under Critical Support our engineer takes the alert and fixes what sits in the runtime we operate.
We operate the stack. You own the product.
A command-line tool is the cheapest way to automate Datadog and the easiest place to leave a credential behind. We set it up so every runner is itself, every token expires, and every agent asks before it changes anything. An implementation partner installs the binary. A managed partner reads the usage every month and keeps the register true. We are the second kind. The identities, the configuration and the register stay in your Datadog, and you can take it in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Pup CLI, answered plainly
What is Datadog Pup CLI?
Datadog describes Pup as a comprehensive, AI-agent-ready CLI covering a wide range of Datadog product domains, and it works just as well for an engineer at a terminal or a step in a pipeline. It is published by Datadog on GitHub, written in Rust, installed with Homebrew, npm, Cargo or a binary, and returns JSON by default. It covers hundreds of commands across dozens of Datadog products, including starting a Bits Investigation from the command line. Datadog's documentation does not state a general availability status, and some command groups are marked Preview or experimental.
How is Datadog Pup CLI billed?
It is not metered on its own in Datadog's documentation. Pup calls the Datadog API, and work that a product meters is metered there whichever client asked for it: a Bits Investigation started from the CLI draws on AI Credits, as one started in the web app does. We do not publish prices. The thing we govern is identity and scope, not spend.
How does Pup authenticate?
OAuth2 with PKCE is the preferred path: pup auth login opens a browser, and the CLI gets a scoped token without a long-lived API key. API keys and application keys remain as a fallback, and a bearer token covers stateless use in a pipeline. We set engineers up with the browser login and give each pipeline its own identity with the narrowest role that does the job, so no token belongs to a person who might leave.
Is it safe to let an AI coding agent run it?
It is designed for that, with conditions. Pup behaves the same for a person or an agent, returns structured JSON in agent mode, asks for confirmation before destructive operations, and offers a read-only flag that blocks create, update and delete. Datadog's own guidance is that an agent should still get the user's explicit authorisation before any remote change. Our standard configuration for agents keeps prompts on and the token read-only, and widens that only for a listed job with a named owner.
What does Critical Cloud do with Pup CLI every month?
Under Managed Observability we review API usage by key, token and role against the register, investigate new identities, write calls from read-only jobs and calls from departed users, revoke tokens for retired pipelines and give cloned pipelines their own identity. We check the standard configuration, read-only with prompts on, against what the runners actually carry. Under Critical Support a command that breaks something in the runtime we operate pages our engineer, who fixes it.
- Datadog products: every product, and how we implement and run each one
- MCP Server: Datadog as a tool for agents that speak MCP
- CI Visibility: the pipelines that run it, observed
Every command under an identity that is its own.
Tell us which pipelines call the Datadog API today and whose keys they use. We will show you what they look like as Pup commands, which identities they should run as, and what should be read-only.