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

Many assume that giving an AI coding agent a database credential is enough to let it write code that talks to the backend. The reality is that a single token handed to ChatGPT can become a wildcard for any query, any table, and any time, without any visibility into what the model actually asks the database to do. When the credential is static and shared across pipelines, a compromised prompt or a malformed generation can issue destructive statements, exfiltrate rows, or silently poll sensitive columns. This unchecked database access creates a blind spot for security teams who cannot tell who ran what, when, or why.

Why database access needs strict controls for AI agents

AI‑driven coding assistants are increasingly embedded in CI/CD workflows, auto‑completion tools, and even autonomous bots that generate migration scripts. Their value comes from speed, but the speed also means they can issue dozens of statements per second. Without a guardrail, a single hallucination could translate into a mass update or a credential dump. Traditional role‑based access control (RBAC) on the database does not account for the fact that the request originates from a non‑human identity that can be invoked programmatically at scale. The result is a high‑risk attack surface that is invisible to audit logs because the database sees only a single service account.

Current practice and its blind spots

In many organizations, the pattern looks like this: a DevOps team creates a Kubernetes secret that contains a database user with broad SELECT, INSERT, UPDATE, and DELETE rights. The secret is mounted into the pod that runs the ChatGPT integration. The pod’s container runs the model, receives a prompt, builds a SQL string, and sends it directly to the PostgreSQL endpoint. No intermediate proxy inspects the traffic, no approval step interrupts a dangerous command, and the database logs only the service‑account name. If the model is tricked into running a DROP TABLE users statement, the database executes it without any human ever seeing the intent.

What a proper control model requires

The missing piece is a data‑path enforcement layer that sits between the AI agent and the database. This layer must be able to:

• Identify the request as coming from a non‑human identity and apply a least‑privilege profile.
• Require just‑in‑time approval for statements that match risky patterns, such as data definition language commands or mass updates.
• Mask sensitive columns in query results so that the model never receives raw personally identifying information or secret values.
• Record every statement, the requesting identity, and the response for replay and audit.

Even with these controls, the request still travels to the database after the checks. The enforcement point must be external to the pod so that a compromised container cannot bypass it.

Introducing hoop.dev as the data‑path gateway

hoop.dev fulfills the exact role described above. It is a Layer 7 gateway that proxies database protocols, inspects each packet, and applies policy before the statement reaches the backend. Because hoop.dev sits in the network, the AI agent never talks directly to PostgreSQL; every SQL command passes through the gateway first. hoop.dev records each session, masks fields that match configured patterns, and can pause execution for a human approval when a statement crosses a risk threshold. The gateway also enforces just‑in‑time access, granting a short‑lived credential that expires when the session ends.

How the architecture works for ChatGPT on Kubernetes

1. Setup: An OIDC provider such as Okta or Azure AD issues a token to the Kubernetes service account that runs the ChatGPT pod. The token proves the pod’s identity but does not contain any database credentials.

2. The data path: The pod is configured to connect to hoop.dev instead of the raw database endpoint. hoop.dev runs an agent inside the same VPC, holds the actual database password, and presents a temporary credential to PostgreSQL on behalf of the request.

3. Enforcement outcomes: When the model generates a query, hoop.dev evaluates it against a policy set that includes:

• Inline masking rules that replace credit‑card numbers or social security numbers with placeholders before the result returns to the model.
• Command‑level guardrails that block DROP, TRUNCATE, or bulk UPDATE statements unless a designated approver explicitly authorizes them.
• Session logging that captures the full request, the identity token, and the masked response, stored in an audit log.

Because hoop.dev is the only component that can see the clear‑text credential, the AI agent never has direct access to the secret. If the pod is compromised, an attacker can only issue requests that pass through the gateway’s policy engine.

Next steps

To try this pattern, start with the getting started guide that walks you through deploying the gateway in a Kubernetes cluster and registering a PostgreSQL connection. The documentation also explains how to define masking rules and approval workflows that are appropriate for AI‑generated queries. When you are ready to explore the source code or contribute, explore the open‑source repository on GitHub. For deeper details on policy configuration and audit‑log consumption, see the feature overview.

FAQ

Can hoop.dev prevent a malicious prompt from exfiltrating data?

Yes. hoop.dev can mask columns that contain personally identifying information or secrets, ensuring the model only receives redacted data. The masking happens in the data path, so the raw values never leave the gateway.

What happens if an approval step is required but no approver is available?

The gateway queues the request and returns a clear error to the calling process. The session remains recorded, so auditors can see that the request was blocked pending human review.

Does using hoop.dev add latency to database queries?

Because hoop.dev operates at the protocol layer and runs close to the database, the added latency is typically a few milliseconds, which is negligible for most application workloads. The security benefits outweigh the small performance cost.