The cleanest place to ask "what has every AI agent done to our infrastructure this week" is the tool your team already lives in. If that tool is Datadog, audit logging for AI agents on Datadog means each agent action against a database, cluster, or service arrives there as a structured audit event you can query, monitor, and keep. The events are generated at the access layer. Datadog is the sink.
Be clear about the direction of the data. hoop.dev is not something an agent connects through to reach Datadog, and it does not front Datadog. hoop.dev is the source. It produces the audit record for each session at the gateway and ships that record into Datadog, next to the metrics and traces you already collect.
Why the audit record has to come from the access layer
An agent's own logs are not audit logging. An autonomous process that can write, edit, or omit its own record is not a reliable witness to its own behavior. Audit evidence has to be produced by something the agent does not control.
hoop.dev is that something. It is an open-source Layer 7 access gateway that proxies connections between identities and infrastructure, and every command an agent runs passes through it. The gateway records each session as a structured fact, attributed to the authenticated identity, outside the agent's reach. That is what makes it audit logging rather than self-reporting, and it is the record you forward to Datadog.
Wiring the audit events into Datadog
There are two ways out of hoop.dev, and both are low-friction. The webhooks plugin emits each session as a structured event in real time, and the security audit-log API lets you pull events on a schedule. For Datadog, the webhook path is the simplest.
- Run the gateway and place a connection behind it so agent activity is being audited. The getting started guide covers the first connection.
- In Datadog, create an API key and note the logs or events intake URL for your region.
- Turn on the webhooks plugin in hoop.dev and set the destination to the Datadog intake endpoint, passing the Datadog API key on the request.
- Trigger an agent action through the connection. The audit event, carrying who connected, which connection, the command run, the approval status, and the outcome, should appear in Datadog.
Once the events flow, treat them like any Datadog log source. Facet on identity and connection, build a dashboard of agent activity by target, and write monitors for the cases that should never pass silently: an agent reaching a sensitive connection, an action that bypassed an expected approval, a spike in commands from one identity.
What each audit event records
Every event is one session described in structured fields. It names the agent or user identity that authenticated, the connection it reached, the command context, whether approval was required and granted, and how the session ended. Because identity is attributed at the gateway and not derived from a shared credential, each agent's actions are distinct in Datadog, which is the whole point of audit logging for agents.
The events serve monitoring and alerting in Datadog and double as retained evidence. The fuller session, including the recorded commands, stays in hoop.dev as the system of record, while Datadog holds the audit stream alongside the rest of your observability data.
Pitfalls to avoid
- Datadog is not a connection target. Agents reach your infrastructure through hoop.dev. The audit logging is forwarded to Datadog as events, not the other way around.
- Do not rely on the agent to log itself. The point of routing through the gateway is that the audit record is produced where the agent cannot edit it.
- Set retention deliberately on both ends. If the Datadog events back an evidence requirement, make sure their retention matches what the requirement expects, and keep the source sessions in hoop.dev accordingly.
FAQ
Is this securing access to Datadog?
No. hoop.dev governs and records access to your infrastructure. Datadog receives the resulting audit events. Nothing is accessed through Datadog in this setup.
Webhook or audit-log API for Datadog?
Use the webhooks plugin for real-time delivery into Datadog. The security audit-log API is there if you prefer to pull events on a schedule or backfill.
What makes these events trustworthy as an audit trail?
They are generated at the gateway, on the connection, outside any process the agent controls, and attributed to the authenticated identity. The agent cannot alter or suppress them.
hoop.dev is open source. The webhooks plugin and the audit-log API are on GitHub. Point a webhook at your Datadog intake and confirm the first agent audit event arrives.
