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

Many teams assume that because an AI model generates code, the resulting database activity is automatically observable, but they lack audit trails. In reality, ChatGPT‑driven agents often run with static credentials and leave no reliable record of what was read or written.

When a developer hands a prompt to ChatGPT and lets the model execute the suggested SQL directly against a PostgreSQL instance, the request bypasses any central logging or policy enforcement. The credential is usually stored in a shared configuration file, and every query flows straight to the database engine. If the generated statement unintentionally drops a table or leaks customer data, the organization has no built‑in audit trail to reconstruct the event.

Audit trails are essential because they tie each AI‑initiated transaction back to a specific token, timestamp, and result set. Without that provenance, forensic analysis becomes guesswork, internal governance loses credibility, and external auditors cannot verify that every data‑access request was authorized.

What teams really need is a way to capture audit trails for every AI‑initiated transaction while still allowing the model to reach the database. The missing piece is a control surface that sits on the connection path, inspects each command, and records the interaction. Without such a surface, the request still reaches PostgreSQL directly, with no inline masking, no just‑in‑time approval, and no way to block dangerous statements.

Why audit trails matter for ChatGPT coding agents

Audit trails give visibility into who invoked a query, what data was accessed, and when the operation occurred. For AI coding agents, this visibility is essential because the originating prompt may be ambiguous, and the generated SQL can evolve over time. A complete log enables forensic analysis, satisfies internal governance, and supports external compliance requirements that expect per‑user evidence of database activity.

How hoop.dev inserts a data‑path gateway for PostgreSQL

Setup begins with an identity provider that issues OIDC or SAML tokens for engineers, service accounts, and AI agents. These tokens define who may request access, but they do not enforce any runtime policy. The gateway, implemented by hoop.dev, occupies the data path between the token‑bearing client and the PostgreSQL server. When the AI agent initiates a connection, hoop.dev validates the token, extracts group membership, and then proxies the traffic at the PostgreSQL wire protocol.

Because the gateway sits in the middle, hoop.dev can apply policy checks on every statement before it reaches the database. The agent never sees the actual database credential; hoop.dev presents its own service identity to PostgreSQL, keeping secrets out of the AI runtime.

Enforcement outcomes you get

hoop.dev records each query and response, creating an audit trail that ties every action back to the originating token. It can mask sensitive columns in result sets, ensuring that downstream logs never expose personal data. When a statement matches a high‑risk pattern, such as DROP, ALTER, or mass delete, hoop.dev can pause the request and route it for human approval. If the policy dictates, the gateway blocks the command outright, preventing accidental data loss.

All of these outcomes, session recording, inline masking, just‑in‑time approval, and command blocking, exist only because hoop.dev resides in the data path. Without that placement, the same OIDC token would simply authenticate to PostgreSQL and the database would execute the statement unchecked.

Getting started

To protect your PostgreSQL instance from untracked AI activity, deploy the gateway using the official Docker Compose quick‑start, or follow the Kubernetes deployment guide. Register the PostgreSQL target in the gateway configuration, enable query‑level logging, and define masking rules for any columns that contain regulated data. The full step‑by‑step process is documented in the getting‑started guide and the broader feature reference on the learn site. Once the gateway is running, any client, including the AI‑driven code executor, connects through hoop.dev, and every interaction is captured as an audit trail.

Because hoop.dev stores session data outside the target database, you can retain logs for as long as your compliance window requires without impacting database performance. Monitoring dashboards can be hooked into the audit store to surface suspicious patterns in real time.

FAQ

Does hoop.dev require changes to existing PostgreSQL client code? No. The AI agent continues to use the standard PostgreSQL client libraries; the gateway intercepts traffic transparently.

Can I still use my existing database credentials? The gateway holds its own service credential for PostgreSQL. Your original credentials remain private and are not exposed to the AI runtime.

What happens if an approval request is denied? hoop.dev aborts the statement and returns an error to the client, leaving the database unchanged.

How long are audit records retained? Retention is configurable in the gateway’s policy store; you can align it with any regulatory window you need.

Explore the open‑source repository on GitHub to review the code, contribute enhancements, or spin up your own instance: https://github.com/hoophq/hoop.