Putting access controls around ChatGPT: guardrails for AI coding agents (on CI/CD pipelines)

When every pull request is automatically enriched by an AI coding agent, the pipeline runs without surprise, secrets stay hidden, and any risky suggestion is halted before it reaches production. That is the ideal state for teams that rely on ChatGPT to write or review code as part of continuous integration.

Current practice without guardrails

Many organizations embed a static OpenAI API key directly in CI secrets stores and let the build agent invoke ChatGPT without any intermediary. The agent can generate code, refactor functions, or even write configuration files, but the request travels straight to the OpenAI service. No one sees what prompts were sent, no one reviews the responses, and there is no automatic redaction of inadvertently generated credentials. If the model is tricked into emitting a secret, the pipeline may publish it to a container registry or a public artifact repository before anyone notices.

Why guardrails are needed

The lack of guardrails leaves three critical gaps. First, there is no runtime policy enforcement – the AI can be asked to produce anything, including insecure code or disallowed libraries. Second, any sensitive data that slips out of the model response is written to logs or artifacts unchanged, exposing it to downstream operators. Third, because the request bypasses a central control point, there is no audit trail that ties a specific commit or pipeline run to the exact prompt and response that influenced it. Teams can mitigate these risks only by adding manual review steps, which defeats the purpose of automation.

How hoop.dev provides guardrails for ChatGPT

hoop.dev sits in the data path as a Layer 7 gateway that proxies the HTTP calls your CI jobs make to the OpenAI endpoint. The gateway inspects each request and response in real time. It can mask fields that match secret patterns, block prompts that contain disallowed keywords, and route high‑risk requests to a human approver before they are forwarded. Because the gateway records every session, you obtain a complete replayable log that links a pipeline run, the identity that triggered it, and the exact AI output.

When a CI job starts, it authenticates to hoop.dev using an OIDC service account token. The gateway verifies the token, extracts group membership, and decides whether the job is allowed to call the AI service at all. If the policy permits, the request is forwarded; otherwise it is denied instantly. Even when permitted, hoop.dev applies inline masking to any response fields that match patterns for API keys, passwords, or tokens, ensuring that downstream steps never see raw secrets.

For operations that exceed a predefined risk threshold – for example, generating code that touches network configuration or accesses external services – hoop.dev can pause the request and create an approval ticket. An engineer reviews the prompt and the proposed output, then explicitly approves or rejects the action. This just‑in‑time approval model prevents accidental privilege escalation while preserving the speed of automated runs for low‑risk tasks.

Implementation steps

• Deploy the hoop.dev gateway in the same network segment as your CI runners. The quick‑start guide walks you through a Docker Compose deployment that includes an OIDC verifier and the proxy agent.
• Register the OpenAI endpoint as a connection in hoop.dev, supplying the service‑level credential that the gateway will use to talk to the API. The CI job never sees this credential.
• Define guardrail policies in the hoop.dev configuration: patterns to mask, disallowed prompt keywords, and thresholds that trigger approval workflows.
• Update your CI pipeline to point its OpenAI client at the hoop.dev proxy URL instead of the public endpoint. Authentication is handled by the OIDC token you already use for pipeline identity.
• Monitor the session logs and approval queues via the hoop.dev UI. The logs give you per‑run evidence of who asked what and what the model returned.

All of these steps are described in the getting‑started documentation. The learn section provides deeper examples of masking rules and approval workflows specific to AI coding agents.

FAQ

Can hoop.dev block a prompt that tries to extract a secret?

Yes. The gateway evaluates the prompt against a configurable denylist. If the prompt matches a prohibited pattern, hoop.dev rejects the request before it reaches the model.

What happens to the AI response if it contains a secret?

hoop.dev applies inline masking based on pattern rules you define. The masked version is passed to the CI job, while the original response is stored in the audit log for later review.

Do I need to change my existing code that calls the OpenAI API?

Only the endpoint URL changes to point at the proxy. Authentication moves from embedding a static API key to using the pipeline’s OIDC token, which you likely already have for other services.

hoop.dev records each session, enforces the guardrails you configure, and provides the evidence you need to demonstrate control over AI‑generated code.

Explore the source code and contribute on GitHub: https://github.com/hoophq/hoop.