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

Many assume that simply deploying an on‑prem ChatGPT instance automatically gives you a complete audit trail. In reality, the model runs code behind the scenes without any built‑in session recording, leaving every command and response invisible to security teams.

Today, engineering groups often expose a local LLM endpoint and let developers or automated scripts invoke it directly. Credentials are stored in plain configuration files, and the traffic bypasses any central control plane. When a coding agent generates a database migration or modifies a configuration file, there is no immutable log of what was asked, what was returned, or who initiated the request. The result is a blind spot that defeats compliance, incident response, and even basic debugging.

What organizations really need is a way to capture every interaction, every prompt, every code snippet, every execution result, while still allowing the LLM to talk directly to the underlying resources. In other words, the request must still reach the model and the downstream services, but the path must be observable and enforceable. Without a dedicated enforcement point, session recording cannot be guaranteed.

Why session recording matters for AI coding agents

AI‑driven coding agents can issue commands that alter production databases, rewrite configuration files, or trigger deployments. Each of those actions carries risk: a malformed suggestion could corrupt data, expose secrets, or open a security hole. Session recording provides a replayable record that auditors can review, engineers can debug, and incident responders can reconstruct. It also creates a deterrent, knowing that every interaction is logged discourages careless or malicious use.

Architectural requirement: a gateway in the data path

To guarantee session recording, the control mechanism must sit where the traffic actually flows. Identity and token verification (the setup) can decide who is allowed to start a session, but it cannot inspect or store the payload without being in the data path. The only place to enforce recording, masking, or command approval is a transparent proxy that intercepts the LLM’s protocol traffic before it reaches the model or any downstream service.

Introducing hoop.dev as the identity‑aware gateway

hoop.dev fulfills the data‑path requirement. It acts as a Layer 7 gateway that sits between users, AI agents, and the on‑prem ChatGPT endpoint. When a developer or an automated workflow authenticates via OIDC or SAML, hoop.dev validates the token, extracts group membership, and then forwards the request to the LLM. Because the gateway is in the path, it can record every request and response, store a replayable session log, and make that log searchable for auditors.

All enforcement outcomes, session recording, inline masking of sensitive outputs, just‑in‑time approval for high‑risk commands, exist only because hoop.dev resides in the data path. The underlying LLM never sees the credentials needed to access downstream resources; hoop.dev holds them and presents them only when the policy permits. This separation ensures that even a compromised AI agent cannot bypass the recording requirement.

From a setup perspective, you still provision OIDC clients, define least‑privilege roles, and configure the on‑prem LLM as a resource. Those steps decide who can initiate a connection, but they do not provide the audit guarantee. Once the gateway is deployed, every interaction is automatically captured, and the logs can be exported for compliance reporting or incident analysis.

For a step‑by‑step walkthrough of deploying the gateway, registering the ChatGPT service, and enabling session recording, see the getting‑started guide. The broader feature set, including masking and approval workflows, is documented in the learn section.

FAQ

Does hoop.dev modify the responses from ChatGPT?
No. The gateway records the raw response and can optionally mask predefined patterns, but it does not alter the model’s output unless a policy explicitly requires it.

Can I restrict recording to only high‑risk sessions?
Recording is enforced for every session that passes through the gateway. You can combine it with just‑in‑time approval policies to limit when high‑risk commands are allowed, but the audit trail remains complete.

Is the recorded data stored securely?
hoop.dev writes session logs to a storage backend that you control. The platform does not prescribe a specific store, allowing you to apply your organization’s encryption and retention policies.

To explore the implementation, visit the GitHub repository and start contributing or adapting the code for your environment.