You already watch your infrastructure in Datadog. The one thing missing from that view is what your AI agents actually did when they connected to it. Session recording for AI agents on Datadog closes that gap: every time an agent opens a connection to a database or a cluster, that session shows up as a Datadog event you can dashboard, alert on, and keep. The recording happens at the access layer. Datadog is where the event lands.
The framing matters, so it is worth being precise up front. hoop.dev does not sit in front of Datadog and Datadog is not something an agent connects to through it. hoop.dev is the source of the events. It records the session at the gateway and ships a structured record to Datadog, the same place your metrics and APM traces already live.
Where the recording happens
hoop.dev is an open-source Layer 7 access gateway that proxies the connection between an identity and your infrastructure. When an AI agent reaches a Postgres database, an EKS cluster, or an internal service, it goes through the gateway, and the gateway records the session: the authenticated identity, the connection, the commands issued, the approval status, and the outcome.
That record is produced on the connection, outside the agent's process, which is the property that makes it trustworthy. The agent cannot suppress or rewrite a recording it never had access to. Session recording on hoop.dev is the capture. Datadog is one of the destinations you forward the resulting events to.
Getting session events into Datadog
The path is deliberately low-friction. hoop.dev emits each session as a structured event through its webhooks plugin, and it also exposes a security audit-log API. You point a webhook at the Datadog intake endpoint, and every gateway session becomes a Datadog record.
- Stand up the gateway and put at least one connection behind it, so agent sessions are being recorded. The getting started guide walks through the first connection.
- In Datadog, get a Datadog API key and the intake URL for the events or logs API in your region.
- Enable the webhooks plugin in hoop.dev and configure the webhook destination to post to the Datadog intake endpoint, with the API key on the request.
- Have an agent run a session through a recorded connection. A session-open and session-close event should arrive in Datadog, carrying who connected, which connection, the command run, and the approval and outcome status.
From there it is ordinary Datadog work. Build a facet on the connection name, chart agent sessions over time, and set a monitor on session events you care about, for example a session against a production database outside a maintenance window, or one that ran without an approval where approval was expected.
What a session event carries
Each forwarded event describes one gateway session as structured fields: the agent or user identity that authenticated, the connection it reached, the command or query context, whether the action required and received approval, and how it ended. Because the identity is attributed at the gateway, an agent's session is never anonymous in Datadog the way a shared-credential connection would be.
For the full content of a session, the recording itself lives in hoop.dev, where you can replay the commands. Datadog holds the event for monitoring, alerting, and evidence retention alongside the rest of your telemetry. The split is intentional: the gateway is the system of record for the session, Datadog is the place you observe and alert on it.
Pitfalls to avoid
- Do not expect Datadog to be a connection target. Agents do not reach anything through Datadog here. They reach your infrastructure through hoop.dev, and the resulting session recording is forwarded to Datadog as events.
- Do not treat the Datadog event as the complete recording. It is a structured summary for monitoring. The replayable session lives in hoop.dev.
- Watch your retention on both sides. Decide how long sessions are kept in hoop.dev and how long events are kept in Datadog, especially when the events back an evidence requirement.
FAQ
Does this proxy Datadog through hoop.dev?
No. hoop.dev proxies connections to your infrastructure and records those sessions. Datadog is where the session events are sent. Nothing connects to Datadog through the gateway.
What lands in Datadog for each session?
A structured event per session: the authenticated identity, the connection, the command context, the approval status, and the outcome. The replayable recording stays in hoop.dev.
Do agents need anything installed for this?
No. The agent connects through the gateway as it normally would. The recording and the webhook to Datadog are configured at the gateway, not on the agent.
hoop.dev is open source. The webhooks plugin and the session recording path are on GitHub. Configure a webhook to your Datadog intake and watch the first agent session arrive as an event.
