Do you worry that an AI coding assistant could run unrestricted queries against your production database?
When you grant an AI model the ability to connect, you must enforce strict database access controls from the start.
ChatGPT‑driven agents are increasingly embedded in internal SaaS platforms to write code, generate migrations, or troubleshoot data problems. They reach for the same database endpoints that human engineers use, but they do so without the contextual awareness that a person brings. When a language model issues a SELECT that pulls customer PII, or a CREATE TABLE that alters schema, the organization often has no guardrails to stop the operation, no record of who (or what) caused it, and no way to hide sensitive columns from the response.
In many teams the default setup is a shared static credential stored in a secret manager and handed to the AI runtime. The credential grants full read‑write access to the database. The agent connects directly, bypassing any approval workflow. Because the connection is direct, there is no audit trail of individual statements, no inline masking of confidential fields, and no ability to block destructive commands. The result is a high‑risk blast radius that is invisible until something goes wrong.
The missing piece is a non‑human identity that can be granted the least privilege it needs, plus a policy enforcement point that can inspect each query before it reaches the database. Even with a scoped service account, the request still travels straight to the database engine. The request arrives with the right token, but there is no checkpoint that can enforce masking, require a human sign‑off for schema changes, or record the exact query for later review.
hoop.dev provides that enforcement point. It sits as a Layer 7 gateway between the AI agent and the database. The gateway terminates the client connection, authenticates the agent’s OIDC token, and then proxies the traffic to the target database. Because the gateway is in the data path, it can apply policy decisions on every statement.
Setup begins with an OIDC identity that represents the ChatGPT agent. The identity is issued by your existing IdP and includes group membership that identifies the agent as a “code‑assistant”. You then register the PostgreSQL or MySQL instance with hoop.dev, supplying the service credentials that the gateway will use. The agent never sees those credentials; it only presents its OIDC token to the gateway.
The data path is where hoop.dev enforces control. As each SQL packet passes through, hoop.dev can inspect the command, compare it against a policy set, and take one of several actions. It can mask columns that contain PII before the result is returned, block commands such as DROP DATABASE, or route DDL statements to a just‑in‑time approval workflow where a human reviewer must approve the change. Because the gateway operates at the protocol level, these controls work for any client – psql, a JDBC driver, or the AI runtime’s database library.
Enforcement outcomes are guaranteed by hoop.dev. It records every session, preserving the full request and response stream for replay. It masks sensitive fields in real time, ensuring that downstream logs never contain raw PII. It blocks destructive commands unless an explicit approval is granted, and it requires just‑in‑time approval for schema‑altering statements. The recorded session can be replayed by auditors to demonstrate compliance with internal policies or external standards. All of these outcomes exist only because hoop.dev sits in the data path; removing it would return the system to the original unrestricted state.
By centralising database access through hoop.dev, teams gain continuous visibility, reduce the risk of accidental data exposure, and enforce least‑privilege principles for AI agents without rewriting application code. The approach also simplifies compliance evidence collection, because the gateway supplies audit logs that record each query and the originating identity.
Explore the open‑source repository on GitHub to see how the gateway is built and to contribute.
For a step‑by‑step walkthrough of installing the gateway and registering a database, see the getting‑started guide. Detailed policy configuration, masking rules, and approval workflows are covered in the feature documentation.
Implementing database access controls for ChatGPT agents
The core of the solution is three layers:
- Identity provisioning: Create a service account in your IdP that represents the AI assistant. Assign it only the roles it needs to run SELECT statements on approved schemas.
- Gateway deployment: Deploy hoop.dev near the database, either with Docker Compose for a quick test or via Kubernetes for production. The gateway holds the database credentials and enforces policies.
- Policy definition: Define masking rules for columns that contain personal data, specify which statements require approval, and list commands that are automatically blocked.
When the AI runtime initiates a connection, it presents its OIDC token. hoop.dev validates the token, checks the policy, and then forwards the query. If the query matches a masking rule, the gateway redacts the column values before sending the response. If the query attempts a prohibited operation, the gateway rejects it and logs the attempt. For actions that need human sign‑off, hoop.dev pauses the request and notifies the designated approver; once approved, the gateway resumes the flow.
FAQ
Can I use hoop.dev with existing database credentials?
Yes. hoop.dev stores the credentials it needs to talk to the database, while the AI agent authenticates only with its OIDC token. This separation eliminates credential leakage.
Does hoop.dev record every query?
hoop.dev records the full session stream, which includes each request and the corresponding response. The logs are available for replay and audit.
What happens if a query is blocked?
The gateway returns an error to the client and logs the event. If the block is policy‑driven, the log includes the rule that caused the rejection, giving developers clear feedback.
