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

Current practice leaves AI agents unchecked

Allowing an LLM to run unrestricted database access queries against production data can expose sensitive records in seconds. In many organizations the easiest way to give ChatGPT the ability to read or write a database is to embed a static credential in the prompt, store a shared password in a config file, or grant the model a service account with broad privileges. The model then connects directly to PostgreSQL using the same network path as a human operator. Because the gateway is bypassed, there is no real‑time visibility into which tables are touched, no way to block destructive statements, and no record of what data was returned to the LLM.

This approach also encourages a false sense of security. Teams assume that because the credential is limited to a single role, the risk is contained, yet the role often has read access to every schema and write access to audit tables. When the model generates a query based on a user request, the result can be cached, logged, or even exfiltrated without any oversight. The lack of inline data masking means that personally identifiable information can flow straight into the model’s context, violating privacy policies and regulatory expectations.

Why the data path needs a dedicated gateway

The core problem is not identity – most enterprises already use OIDC or SAML to authenticate users and service accounts. The missing piece is a point where every request is examined before it reaches the database. Without a dedicated data‑path component, policies such as just‑in‑time (JIT) approval, command‑level blocking, or response‑level redaction cannot be enforced consistently. The gateway must sit between the LLM and PostgreSQL, intercepting the wire‑protocol, applying policy, and then forwarding only the allowed traffic.

Placing enforcement at the network edge also isolates the control logic from the application runtime. Even if the LLM’s execution environment is compromised, the gateway remains outside the process that holds the credential, preventing the attacker from re‑using the secret directly. This separation is the only reliable way to guarantee that every query is subject to the same guardrails that protect human operators.

Implementing controlled database access for ChatGPT with hoop.dev

hoop.dev provides the required Layer 7 gateway. It proxies PostgreSQL connections, inspects each query, and applies a configurable set of controls. The system is open source, MIT licensed, and can be deployed with a single Docker Compose file or on Kubernetes. Once the gateway is running, ChatGPT (or any AI coding agent) connects to the proxy endpoint instead of the database directly. The proxy authenticates the request via OIDC, reads the caller’s group membership, and then enforces policies that are defined once at the gateway level.

Setup: identity and least‑privilege provisioning

The first step is to configure an OIDC identity provider – Okta, Azure AD, Google Workspace, or any compatible service. Each AI‑driven job receives a short‑lived token that identifies the job’s service account. The token is never exchanged for the database password; hoop.dev validates it and maps the identity to a minimal PostgreSQL role that only allows the operations required for the task. This mapping satisfies the “who can start” question without granting the job blanket access.

The data path: hoop.dev as the only enforcement point

All traffic from the LLM to PostgreSQL passes through hoop.dev. Because the gateway terminates the client connection, it becomes the sole place where request inspection can happen. hoop.dev reads the PostgreSQL wire protocol, extracts the SQL statement, and runs it through the policy engine before forwarding it to the database. The database never sees the original client, only the proxy, which means every command is subject to the same checks regardless of where it originates.

Enforcement outcomes

• hoop.dev masks sensitive fields in query results, ensuring that credit‑card numbers or personal identifiers never reach the model.
• hoop.dev requires a just‑in‑time approval step for statements that match a risky pattern, such as DROP TABLE or ALTER USER.
• hoop.dev records each session, capturing the full request and response stream for replay and audit.
• hoop.dev blocks commands that match a deny‑list, preventing accidental data deletion or schema changes.

For a step‑by‑step walkthrough, see the getting‑started guide and the broader feature documentation at hoop.dev/learn. The complete source code and contribution guide are available on GitHub.

Common pitfalls to avoid

Do not store static PostgreSQL passwords in environment variables that the LLM can read. Static secrets bypass the gateway and make it impossible to rotate credentials without downtime. Similarly, avoid assigning the AI service account a role that includes superuser privileges; the gateway can only block what it sees, it cannot undo a privileged command that has already been executed. Finally, remember to enable JIT approval for any DDL operation – without it, a single malformed prompt could alter the schema and affect downstream applications.

FAQ

Can hoop.dev protect data at rest?

No. hoop.dev secures data in motion by inspecting queries and responses. Encryption of data at rest is handled by PostgreSQL and the underlying storage layer.

Does hoop.dev replace existing IAM policies?

It complements them. Traditional IAM decides who may obtain a token, while hoop.dev enforces additional runtime checks on every request that passes through the gateway.

Is the solution open source?

Yes. The gateway is released under the MIT license and the repository is publicly available on GitHub.