Putting access controls around ChatGPT: session recording for AI coding agents (on GCP)

Many assume that AI coding agents like ChatGPT automatically log every interaction, but the reality is far less reassuring. In practice, session recording is not guaranteed by the model itself.

In many organizations the model is given a service‑account key, a long‑lived JSON credential, and then asked to run gcloud commands, open SSH sessions, or query Cloud SQL instances. The key lives in an environment variable, the AI‑driven script calls the cloud CLI, and the team relies on the provider’s audit logs to prove what happened. Those logs capture the request at the API surface, but they do not record the exact command line, the intermediate prompts, or the data that flowed back to the model. If the model misinterprets a prompt and issues a destructive command, the evidence is fragmented and often lost.

The immediate fix many teams reach for is tighter IAM: they create a dedicated service account, grant it the minimum set of roles, and rotate the key more often. This is a necessary step – it decides who the request is and whether it may start – but it does not close the audit gap. The request still travels straight from the AI runtime to the target service, bypassing any point where the command can be inspected, approved, or recorded. Without a dedicated enforcement layer, there is no way to guarantee that every AI‑generated command is captured for later review.

Enter a Layer 7 gateway that sits in the data path between the AI runtime and the GCP resources. By proxying the connection, the gateway can enforce session recording, apply inline masking to sensitive response fields, and require just‑in‑time approvals for high‑risk operations. The gateway holds the credential, so the AI agent never sees the secret. Every byte that passes through is logged, and a replayable session file is stored for auditors or incident responders.

Why session recording matters for AI‑driven workloads

AI agents generate code and commands on the fly. A single misinterpreted token can lead to a DROP DATABASE or an accidental exposure of secrets. Traditional cloud audit logs tell you that cloudsql.instances.update was called, but they do not show the exact SQL statement that was sent, nor the exact sequence of prompts that led to it. Session recording captures the full dialogue – from the model’s request, through the gateway’s policy checks, to the final response from the target service. This continuity is essential for:

• Forensic analysis after a breach.
• Compliance evidence for standards that require command‑level audit.
• Root‑cause debugging when an AI‑generated script behaves unexpectedly.

A gateway that sits in the data path

The gateway is deployed as a network‑resident agent close to the GCP resources. It registers each target – Cloud SQL, GKE exec, Compute Engine SSH – and stores the service‑account credential internally. Users and AI runtimes authenticate to the gateway with an OIDC token issued by their corporate IdP. The gateway validates the token, extracts group membership, and then decides whether the request may proceed.

Because the gateway is the only point where traffic is inspected, it can enforce the following outcomes:

• Session recording: hoop.dev writes a complete, replayable log of every command and response.
• Inline masking of sensitive fields such as passwords or API keys returned by a database query.
• Just‑in‑time approval workflows for commands that match a high‑risk pattern.
• Blocking of disallowed commands before they reach the target.

All of these enforcement outcomes exist only because hoop.dev sits in the data path. If the gateway were removed, the AI runtime would connect directly to the resource and none of the above controls would be applied.

How hoop.dev implements session recording for ChatGPT agents

When an AI‑driven process wants to run a command, it contacts the gateway using a standard client – for example the psql binary for Cloud SQL or kubectl for GKE exec. The gateway terminates the protocol, records the inbound request, and then forwards it to the target after applying any configured policies. The response is captured, optionally masked, and streamed back to the client. The entire exchange is stored as a session file that can be replayed in a web UI or exported for downstream analysis.

Because hoop.dev holds the service‑account key, the AI agent never sees the secret. The gateway also enforces least‑privilege IAM at the token level, ensuring that the AI identity can only request the specific resource it was granted. If a new command pattern is detected, the gateway can automatically trigger an approval request to a human operator before forwarding the command.

Getting started with session recording on GCP

To protect your AI‑driven workloads, start by deploying the gateway in the same VPC as your GCP resources. Follow the getting‑started guide to spin up the Docker Compose stack, configure OIDC authentication, and register a Cloud SQL connection. Once the gateway is running, point your ChatGPT‑driven scripts at the proxy endpoint instead of the raw Cloud SQL host. The gateway will begin recording every session automatically.

For deeper insight into policy configuration, masking rules, and approval workflows, explore the learn section. All of the implementation details – Docker compose files, Helm charts, and IAM role bindings – are available in the open‑source repository.

Visit the GitHub repository to clone the code, submit issues, or contribute enhancements.

FAQ

Does session recording add latency to AI‑driven commands?

The gateway records traffic as it passes through, which adds only a few milliseconds of overhead. The impact is negligible compared with the round‑trip time to the target service.

Can I retain recordings for compliance without storing raw secrets?

Yes. hoop.dev can mask or redact sensitive fields before writing the session file, ensuring that audit logs remain useful while protecting confidential data.

What happens if the AI model tries to bypass the gateway?

Because the credential is stored only inside the gateway, the model cannot establish a direct connection. Any attempt to connect without the proxy will fail authentication.