When an AI coding agent like ChatGPT writes or modifies code during a CI/CD run, the pipeline gains speed but also loses visibility, making session recording essential. Without it, if a generated snippet introduces a secret, a vulnerability, or a licensing violation, the damage can spread before anyone notices, and the organization may struggle to prove who approved the change.
Most teams hand the ChatGPT API key to every build agent, store it in a shared secret manager, and let any job call the service without a gate. The request travels directly to OpenAI’s endpoint, bypassing internal controls. No log captures the exact prompt, the model’s response, or the identity of the runner that triggered it.
Without a reliable audit trail, security reviews become guesswork, and developers cannot prove that an automated change complied with policy. Incident response teams waste hours replaying logs, and compliance auditors ask for evidence that does not exist.
Session recording means capturing the full request‑response exchange for each AI interaction, attaching the runner’s identity, timestamp, and any approval metadata. The logs become a single source of truth that can be queried later to verify that generated code met security standards.
The missing piece is a place where that capture can reliably happen. Identity providers can assert who the CI job is, and service accounts can limit which resources the job may touch, but they do not sit on the traffic path. Enforcement must occur where the data flows.
Why session recording matters for AI coding agents
CI/CD pipelines run automatically, often on a schedule or in response to a pull request. When an AI agent is given free rein, a single erroneous prompt can rewrite configuration files, expose credentials, or introduce insecure dependencies. Capturing each exchange lets teams trace the exact input that produced a change, answer forensic questions, and demonstrate compliance with internal policies or external regulations.
Where enforcement must happen
The enforcement point must be a gateway that all traffic passes through. The setup, OIDC or SAML tokens, service‑account roles, and least‑privilege grants, decides who is making the request, but it does not guarantee that the request is observed. Only a data‑path component that sits between the CI runner and the ChatGPT endpoint can apply controls consistently.
hoop.dev as the data‑path gateway
hoop.dev provides that gateway. It runs a network‑resident agent inside the same environment as the build runner and proxies every HTTP call to the ChatGPT service. Because the request must travel through hoop.dev, the platform can record the full session, attach the authenticated identity from the OIDC token, and write the log to a secure audit store.
When a pipeline step initiates a ChatGPT request, hoop.dev verifies the caller’s token, checks any just‑in‑time approval policy, and then forwards the request. While the response streams back, hoop.dev writes the prompt and answer to the session log. The log includes metadata such as the pipeline ID, the Git commit hash, and the user who triggered the run. This creates an immutable audit trail.
Because hoop.dev sits in the data path, it can also mask sensitive fields in the model’s answer before the data reaches the runner, or block a request that matches a risky pattern. Those enforcement outcomes exist only because hoop.dev intercepts the traffic; the identity system alone cannot block or mask anything.
How the pieces fit together
- Setup: Configure OIDC/SAML integration with your identity provider. Assign service‑account roles that allow the CI runner to request a token for the ChatGPT scope.
- The data path: Deploy hoop.dev’s gateway and its agent alongside your build infrastructure. Register the ChatGPT endpoint as a connection so that all calls are routed through the gateway.
- Enforcement outcomes: hoop.dev records each session, applies inline masking if needed, and can require a human approval step for high‑risk prompts. The recorded sessions can be replayed in a browser for audit or forensic analysis.
This architecture satisfies the three‑beat arc: it replaces the unsafe practice of direct, unlogged API calls, it adds a control point that still lets the request reach the model, and it uses hoop.dev as the sole place where session recording and related guardrails are enforced.
Getting started
To try this in your own pipelines, follow the getting‑started guide. The documentation walks you through deploying the gateway with Docker Compose, configuring OIDC, and registering the ChatGPT connection. All of the heavy lifting lives in the open‑source repository, so you can inspect the code and adapt it to your environment.
For deeper details on how session recording works and how you can query the logs, see the feature documentation. The repository on GitHub contains the full source and examples: hoop.dev on GitHub.
FAQ
Does session recording capture the raw API key?
No. hoop.dev never exposes the ChatGPT credential to the CI runner. The gateway holds the secret and uses it only to forward the request, while the recorded log contains only the prompt, response, and metadata.
Can I disable recording for a specific pipeline?
Yes. Recording is controlled by policies attached to the connection. You can create a policy that disables recording for low‑risk jobs, but the decision still passes through hoop.dev, ensuring the rule cannot be bypassed by the runner.
How long are the session logs retained?
Retention is a configuration of the logging backend you choose. hoop.dev simply writes each session to the backend; you decide the retention period according to your compliance needs.
