How can you prove what an AI coding assistant did during a CI/CD run? Without audit trails you have no reliable record of the agent’s actions.
Many teams have started to embed Cursor, an AI‑driven coding agent, directly into their build pipelines. The agent watches source changes, suggests snippets, and even commits code automatically. In practice the pipeline often runs under a single service account that has broad write access to the repository and to downstream environments. Because the agent uses the same credential as the rest of the pipeline, every change it makes is indistinguishable from a human‑authored commit. If something goes wrong – a malformed migration, a secret leak, or a logic error – there is no reliable way to answer who (or what) performed the action.
Teams recognize that the problem is not just about authentication. They have begun to adopt identity‑aware tokens, OIDC‑based service identities, and just‑in‑time (JIT) role grants so that the CI job only receives the minimal permissions it needs for a single run. Those steps stop the agent from holding a permanent, over‑privileged secret, but they do not close the audit gap. The request still travels straight from the pipeline to the target service – a database, a Kubernetes cluster, or a cloud API – without any point where the action can be inspected, recorded, or approved. The pipeline can invoke the target, the target executes the command, and the result is returned, all without a reliable audit log of what the AI actually sent.
What is needed is a control surface that sits on the data path between the CI job and the infrastructure it touches. That surface must be able to verify the caller’s identity, enforce the least‑privilege grant for the duration of the run, and, crucially, capture a complete, replayable record of every request and response. It also needs to support inline masking of sensitive fields – for example, redacting API keys that appear in logs – and allow a human reviewer to intervene before a dangerous operation proceeds.
Why hoop.dev is the right place for audit trails
hoop.dev provides a Layer 7 gateway that proxies connections to the supported targets – databases, Kubernetes clusters, SSH hosts, HTTP services, and more – and inserts the required controls directly into the protocol stream. When a CI job initiates a Cursor session, the job authenticates to hoop.dev using an OIDC token. hoop.dev validates the token, extracts group membership, and then grants the job a short‑lived, scoped credential that it uses to talk to the downstream resource. The credential never leaves the gateway, so the AI agent never sees a secret it could inadvertently expose.
Because hoop.dev sits in the data path, it can record every request and response, producing a full audit trail that includes timestamps, caller identity, and the exact payload that the AI sent. The recording is stored outside the target system, enabling replay for forensic analysis without affecting the production environment. If a policy requires that certain commands – such as schema‑altering statements or privileged Kubernetes exec calls – be approved before execution, hoop.dev can pause the request, forward it to an approval workflow, and only continue once a human has given the go‑ahead.