Why database access is risky for AI coding agents
When AI coding agents like ChatGPT can query production databases safely, every query is scoped, approved, and recorded, and any sensitive fields are hidden from the model. That level of control prevents accidental data leakage, limits the blast radius of a mis‑prompt, and gives security teams the evidence they need to answer audit questions. In practice, however, many teams hand the model a static credential that can read entire schemas, and they never see what the model actually asked the database to do.
What the current practice looks like
Most organizations expose a service account to the LLM, store the password in an environment variable, and let the model issue SQL statements directly against the target instance. The credential is often scoped to a broad role that can read every table, and there is no gate that can intervene if the model tries to drop a table or exfiltrate customer PII. Because the request goes straight from the model to the database, there is no central point that can log the exact query, mask returned columns, or require a human to approve a risky operation. The result is a blind spot: security teams cannot tell whether a query was benign or malicious, and compliance evidence is missing.
Introducing a data‑path gateway
To close that blind spot, the request must pass through a component that sits on the network edge, inspects the wire‑protocol, and enforces policy before the database sees the command. The gateway becomes the only place where enforcement can happen, while the identity system simply decides whether a request is allowed to start. This separation of concerns makes it possible to add just‑in‑time approvals, inline masking, command blocking, and full session recording without changing the database or the LLM code.
How hoop.dev enforces database access for ChatGPT
hoop.dev is built exactly for this pattern. It runs a lightweight agent inside the same VPC as the database and exposes a Layer 7 proxy that AI agents connect to using their normal client libraries. The gateway validates the OIDC token presented by the model, determines the groups the token belongs to, and then applies a policy that is defined per‑database, per‑table, or even per‑column. Because the policy engine lives in the data path, hoop.dev can intervene on every request.
Setup: identity and least‑privilege for the agent
The first step is to create a non‑human service account in your identity provider and grant it only the permissions required for the specific database role the LLM needs. That account is used by the hoop.dev agent to authenticate to the gateway, but the token never reaches the database directly. This setup decides who the request is and whether it may start, but it does not enforce any fine‑grained rule on its own.
The data path: hoop.dev sits between the AI model and the database
All traffic from the model to the database is forced through hoop.dev. Because the gateway terminates the protocol, it can examine SQL statements, redact sensitive columns in the response, and pause execution for a human approver when a query matches a risk pattern. The database sees only the filtered, approved request, and the model never sees the underlying credential.