Putting access controls around ChatGPT: audit trails for AI coding agents (on Kubernetes)

When a contract developer leaves a project, the CI pipeline often keeps a secret token that still allows the automated ChatGPT coding agent to push snippets directly into a Kubernetes pod. Without audit trails, the lack of visibility makes it impossible to answer simple questions like “who generated this function?” or “was the AI prompted to expose a credential?”. The next engineer pushes a change, the AI agent runs, and a new library lands in production without anyone seeing who asked for it or what was generated.

AI‑assisted coding agents are valuable, but they also introduce a new attack surface. The agent talks to a language model over HTTP, receives code, and then executes it inside a container. If the request is not recorded, any misuse, whether accidental or malicious, disappears into the logs of the container, which are often rotated or inaccessible to auditors.

Why audit trails matter for AI coding agents

Regulatory frameworks and internal policies increasingly require evidence of who performed what action on production systems. For traditional human operators, command‑level logging and session recording satisfy that demand. For an AI‑driven workflow, the same evidence must include the prompt, the model’s response, and the resulting execution. Without a dedicated audit trail, organizations lose the ability to:

• Trace the origin of generated code back to a specific identity or service account.
• Detect patterns of risky prompts that request credential extraction or insecure code.
• Provide replayable sessions for post‑incident investigations.
• Demonstrate compliance during audits that ask for per‑request visibility.

Most Kubernetes deployments already have a setup that authenticates service accounts via OIDC or SAML, and they grant the minimum permissions needed to start a pod. That setup decides who may initiate a request, but it does not enforce any guardrails on the request itself. The AI agent still reaches the language‑model endpoint directly, and the pod runs the code without any intermediate check.

The missing enforcement layer

The precondition for an effective solution is clear: the identity system must be in place, and the pod must be able to start on demand. What remains open is the lack of a data‑path control that can observe, approve, or block each interaction with the language model. In other words, the request still travels straight from the Kubernetes service account to the external ChatGPT API, bypassing any audit or policy enforcement.

This is where a Layer 7 gateway becomes essential. By inserting a proxy between the service account and the AI endpoint, every HTTP request and response can be inspected, recorded, and optionally gated by a human approval workflow. The gateway also has the ability to mask sensitive fields, such as API keys that might appear in a model’s response, before they reach the container.

hoop.dev as the data‑path gateway

hoop.dev is designed to sit in exactly that position. It authenticates the caller using the same OIDC token that the Kubernetes service account presents, then proxies the request to the ChatGPT service inside the cluster. Because all traffic passes through hoop.dev, it can:

• Generate a complete audit trail for each prompt and response, tying the activity to the original identity.
• Record the full session so that a replay can be reviewed later.
• Apply inline masking to redact secrets that the model might return.
• Require a just‑in‑time approval step for prompts that match a risky pattern, such as requests for credential extraction.

Each of these outcomes exists only because hoop.dev occupies the data path. The setup (identity, least‑privilege service accounts) decides who can start the request, but hoop.dev is the only component that actually enforces audit trails, masking, and approval before the request reaches the AI model.

Architectural walk‑through

1. Identity provisioning: A Kubernetes service account is federated with an OIDC provider. The account receives a short‑lived token that proves its identity.

2. Gateway deployment: hoop.dev runs as a container in the same network as the ChatGPT proxy. The gateway holds the credential needed to call the external language‑model API, so the pod never sees the secret.

3. Request flow: When the CI job or an internal tool wants to generate code, it sends an HTTP request to the local endpoint exposed by hoop.dev. hoop.dev validates the token, records the incoming prompt, and checks policy rules.

4. Policy enforcement: If the prompt matches a rule that requires human sign‑off, hoop.dev pauses the request and routes it to an approval workflow. Once approved, the request proceeds to the external model.

5. Response handling: The model’s answer is received by hoop.dev, which can mask any discovered secrets, record the full response, and finally forward the sanitized result to the Kubernetes pod.

6. Audit storage: All request and response pairs, together with identity metadata, are stored in an audit log that can be queried for compliance reports or forensic analysis.

Benefits of a centralized audit trail

Because hoop.dev captures every interaction, security teams gain a single source of truth for AI‑driven code changes. The audit trail can be exported to SIEM tools, correlated with other Kubernetes events, and used to trigger alerts when anomalous patterns appear. The approach also reduces the blast radius of a compromised service account; even if an attacker obtains a token, every action they take will be recorded and can be reviewed.

Performance impact is minimal because hoop.dev works at the protocol layer and streams data without full buffering. Organizations that have already invested in OIDC or SAML for their clusters can adopt hoop.dev without changing existing identity providers, only by adding the gateway to the network topology.

Getting started

To try this pattern, follow the getting‑started guide that walks through deploying the gateway, registering a ChatGPT connection, and configuring a simple approval rule. The full source code and contribution guidelines are available on the GitHub repository. For deeper details on masking, approval workflows, and session replay, explore the learn section of the documentation.

FAQ

Will hoop.dev introduce latency for AI requests?
hoop.dev operates at the wire‑protocol level and streams data, so the added latency is typically measured in milliseconds, far below the round‑trip time to the external model.

Can I retain audit logs for a specific compliance window?
The gateway stores each request and response with identity metadata, and the logs can be retained for any period required by your organization’s policies.

What happens if an approval step is pending?
The request is held at the gateway until a designated approver grants permission. No code is executed in the pod until the approval is recorded, ensuring that risky prompts never reach the runtime.