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

Imagine a contractor who left the company last week but still has a copy of the shared PostgreSQL password used by an internal ChatGPT‑powered code assistant. The assistant runs nightly jobs that generate SQL statements, writes data, and occasionally pulls back customer records for analysis. Without session recording there is no reliable way to prove what the AI did during those runs. Because the password lives in a plain‑text configuration file, the AI can continue to issue queries long after the contractor’s access should have been revoked. No one can tell which statements were generated by the assistant, which were issued by a human, or whether any sensitive rows were inadvertently exposed.

In many teams, the shortcut is to grant the AI service a static credential and let it connect directly to the database. The connection bypasses any audit layer, and the database logs only show the service account name, not the intent behind each statement. When a breach is discovered, investigators are left piecing together raw logs that lack context, timestamps, or any indication of who authorized the operation. The lack of visibility makes compliance audits painful and erodes confidence in AI‑driven automation.

Why session recording matters for AI coding agents

Session recording captures every request and response that travels between a client and PostgreSQL. For an AI coding agent, this means a complete, replayable transcript of every generated query, the exact parameters used, and the resulting rows. The transcript becomes forensic evidence, a debugging aid, and a compliance artifact. It also enables downstream tools to mask or redact sensitive columns before they ever reach a downstream system.

The missing piece in a token‑based setup

Most organizations already use OIDC or SAML to issue short‑lived tokens for service accounts. Those tokens answer the question, “Who is calling?” but they do not answer, “What is being called?” When an AI agent presents a valid token, the request still travels straight to PostgreSQL. The database sees a well‑authenticated client, yet there is no place in the data path where policies such as session recording, inline masking, or command‑level approvals can be enforced. The authentication layer alone is necessary but insufficient for a secure AI‑driven workflow.

hoop.dev as the enforceable data path

hoop.dev solves the gap by inserting a Layer 7 gateway between the AI agent and PostgreSQL. The gateway validates the OIDC token, extracts group membership, and then proxies the protocol‑level traffic to the database. Because the proxy sits in the data path, hoop.dev can record each client command, apply real‑time masking rules, and store a replayable audit trail. The AI agent never sees the database credentials; hoop.dev holds them securely and presents a temporary session token to PostgreSQL on behalf of the client.

How session recording works

When the AI assistant opens a connection, hoop.dev creates a session record that includes the identity of the caller, the start time, and the target database. Every SQL statement that passes through the gateway is logged with its exact text, parameters, and the response payload. After the session ends, the record is retained for later review, ready for replay in a forensic tool or for inclusion in an audit package. Because hoop.dev performs the recording at the protocol layer, it captures both successful queries and any rejected commands, giving a full picture of intent and outcome.

Policy enforcement beyond recording

In addition to session recording, hoop.dev can mask columns that contain personally identifiable information, block dangerous commands such as DROP DATABASE, and route high‑risk queries to a human approver before they reach PostgreSQL. These controls are defined once in the gateway configuration and apply uniformly to every client, whether a human operator or an AI coding agent.

Deploying the gateway for AI workloads

Deploy the hoop.dev gateway close to the PostgreSQL cluster, using the provided Docker Compose quick‑start or a Kubernetes manifest. An agent runs on the same network segment and holds the database credentials. Once the gateway is up, register the PostgreSQL target, bind it to the OIDC client that issues tokens for the AI service, and define a session‑recording policy. From the AI side, the code continues to use the standard PostgreSQL client library; the only change is the host name, which now points at the hoop.dev proxy.

The deployment is open source, MIT‑licensed, and can be scaled horizontally for high‑availability workloads. Because the gateway is the single point where traffic is inspected, you gain a unified audit surface without scattering agents across multiple services.

Next steps

Start with the getting‑started guide to spin up a local instance and register a PostgreSQL connection. Review the feature documentation for details on session recording, masking, and approval workflows. When you are ready to contribute or customize the gateway, the full source code is available on GitHub.

FAQ

• Does hoop.dev record every query issued by an AI agent? Yes, hoop.dev records each command and its response, producing a replayable session log.
• Can I hide sensitive columns from downstream systems? Yes, hoop.dev can apply inline masking rules so that protected fields never leave the gateway.
• Do I need to modify my AI code to use hoop.dev? No, the AI agent continues to use the standard PostgreSQL client; only the connection endpoint changes to the hoop.dev proxy.