An on‑premise deployment of a ChatGPT‑powered coding assistant is given a service account that contains the same database password used by the engineering team. The assistant can spin up queries, write rows, and even drop tables whenever a developer asks it to refactor code. Because the credential lives in a shared secret store, any compromise of the assistant’s container instantly grants unrestricted database access, and there is no record of which prompts caused the change.
That pattern is common in teams that treat AI agents as another piece of automation. They hand the model a static database user, expose the connection string through environment variables, and let the model issue SQL directly. The result is a blind tunnel: the agent talks straight to the database, bypasses human review, and leaves no audit trail of the statements it executed.
What you really need is a way to keep the convenience of on‑demand code generation while applying the same guardrails you would demand of a human engineer. The goal is least‑privilege, just‑in‑time elevation, real‑time approval for dangerous commands, automatic masking of sensitive columns, and a replayable log of every interaction. Those controls must sit on the path the query travels, not somewhere else in the stack.
Why a data‑path gateway is required
Identity providers can issue tokens that tell the system who is calling, and role‑based policies can limit which databases a service account may reach. However, those policies are evaluated before the connection is opened; they cannot inspect the actual SQL payload, block a DROP statement, or redact a credit‑card column that appears in a result set. Without a proxy that sees each packet, you cannot enforce inline masking or capture a replayable session.
hoop.dev as the enforcement layer for AI‑driven database access
hoop.dev is a Layer 7 gateway that sits between the ChatGPT coding agent and the target database. The agent authenticates to hoop.dev via OIDC, and hoop.dev forwards the request to the database only after applying policy checks. Because the gateway is the only point where traffic passes, it can:
- grant just‑in‑time access based on a request‑time approval workflow,
- block or rewrite statements that match a risky pattern,
- mask columns such as SSN or credit‑card numbers before they are returned,
- record the full session for later replay and audit.
High‑level flow
When a developer asks the AI assistant to run a query, the assistant sends the SQL to hoop.dev. hoop.dev extracts the user’s identity from the OIDC token, looks up the policy that ties that identity to the requested database, and decides whether the request can proceed immediately or needs a manager’s approval. If approved, the statement is relayed to the database; if the statement contains a prohibited operation, hoop.dev can truncate or reject it. The response travels back through the same gateway, where any configured masking rules are applied before the assistant sees the data.
Benefits for security and compliance
Because every interaction is recorded, security teams can reconstruct exactly which prompt triggered a change, which rows were affected, and which identity was involved. Masking ensures that even if the AI model logs its output, sensitive fields never leave the controlled environment. The just‑in‑time model eliminates standing credentials; the assistant only receives a short‑lived token that expires after the session, reducing the blast radius of a container compromise.
Getting started
To add this protection to your on‑prem deployment, start with the getting‑started guide. The quick‑start uses Docker Compose to launch the gateway, configure an OIDC provider, and register a PostgreSQL (or any supported) connection. Once the gateway is running, point your ChatGPT coding agent at the hoop.dev endpoint instead of the raw database host. Detailed policy examples and masking configurations are available in the Learn section.
FAQ
Does hoop.dev require changes to my existing database clients? No. The gateway speaks the native protocol, so standard clients such as psql, JDBC, or ODBC work unchanged.
Can I still use the same service account for multiple AI agents? Yes. Each session receives a short‑lived token managed by hoop.dev, and policies can differentiate agents by group membership or other token claims.
How does hoop.dev handle high‑throughput workloads? The gateway is designed to scale horizontally; you can run multiple instances behind a load balancer, and each instance records sessions independently.
Explore the open‑source repository on GitHub to get the code, read the documentation, and contribute.
