An AI coding agent is tasked with automatically generating monitoring dashboards in Datadog based on recent deployment metrics. The agent runs as part of a CI pipeline, authenticates with a hard‑coded Datadog API key, and pushes dashboards without any human review. Because there is no session recording, the team cannot see who triggered which change, and when the pipeline fails, the resulting dashboards contain stale or erroneous queries that flood the team’s alerts.
Because the API key is shared across multiple pipelines and even across teams, any compromise gives unrestricted write access to every Datadog resource. There is no record of who triggered which dashboard change, and if an unexpected alert surge occurs, the team cannot trace the exact request that caused it. The organization tries to mitigate risk by rotating the API key periodically, but the rotation process is manual and often delayed, leaving windows of exposure. Engineers also rely on ad‑hoc scripts that embed the key directly in source control, making revocation difficult.
A more disciplined approach would replace the static key with a service account that obtains short‑lived OIDC tokens from the CI system’s identity provider. The token grants the agent permission to call only the Datadog dashboard‑write endpoint. The token is validated by Datadog, and the request still travels straight from the CI runner to the Datadog API. At this point the request is scoped, but there is still no visibility into the exact payload, no ability to pause a suspicious change, and no immutable replay of the interaction.
The missing piece is a layer that sits between the agent and the Datadog API, inspecting every request and recording the full exchange. hoop.dev provides exactly that. It acts as an identity‑aware proxy for Datadog, holding the service‑account credential and presenting a short‑lived token to Datadog on behalf of the agent. Because the proxy is the only component that can see the traffic, it can enforce policies and generate audit evidence.
Why the data path matters for session recording
Setup determines who the request is. In this scenario the CI system authenticates to an OIDC provider, receives a token that identifies the pipeline, and forwards the token to the proxy. That identity step is necessary, but it does not provide any enforcement on its own. The real control point is the data path – the gateway that all HTTP calls to Datadog must traverse.
hoop.dev sits in that data path. It terminates the inbound connection from the AI agent, inspects the HTTP method, URL, and body, and then forwards a sanitized request to the Datadog endpoint. Because the gateway is the sole observer, it can record each request and response verbatim, preserving the exact sequence of API calls made by the agent.
How session recording works for Datadog
When the AI agent initiates a dashboard‑creation call, hoop.dev captures the full request payload, including any JSON that defines the dashboard layout. After the request is forwarded, the proxy also records the Datadog response, which contains the newly created dashboard ID and any error messages. The entire exchange is stored as a replayable session that can be retrieved later for forensic analysis or compliance reporting.