All posts

Putting access controls around ChatGPT: database access for AI coding agents

A ChatGPT-driven agent that can write SQL is useful right up until it runs a query nobody reviewed against a database it should not have reached. This guide sets up database access for that agent the right way, step by step, so the connection is scoped, named, and recorded from the first query. Before the steps, one boundary worth stating clearly. hoop.dev does not sit between you and ChatGPT and does not read the model's prompt or output. It governs the database connection the agent drives. Th

Free White Paper

AI Model Access Control + Vector Database Access Control: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

A ChatGPT-driven agent that can write SQL is useful right up until it runs a query nobody reviewed against a database it should not have reached. This guide sets up database access for that agent the right way, step by step, so the connection is scoped, named, and recorded from the first query.

Before the steps, one boundary worth stating clearly. hoop.dev does not sit between you and ChatGPT and does not read the model's prompt or output. It governs the database connection the agent drives. The control surface is the SQL that leaves the agent and reaches Postgres or MySQL.

What you are setting up

The goal is a connection where the agent reaches the database through a gateway that authenticates it, limits what it can touch, can pause risky writes, and records every query under a named identity. The database credential never lives inside the agent.

Why the boundary sits outside the agent

A rule the agent stores is a rule the agent can change. Database access has to be decided at a point the agent does not control. hoop.dev is an open-source Layer 7 gateway: an agent runs near the database and dials out to the gateway, the ChatGPT agent connects to the gateway, and queries pass through at the protocol level where policy is enforced.

Because the gateway's agent dials out, there is no inbound port to open on the database and nothing exposed to the public internet. The database keeps its existing network posture. What changes is that the ChatGPT agent now reaches it through a single, governed path instead of holding a direct connection string of its own.

Continue reading? Get the full guide.

AI Model Access Control + Vector Database Access Control: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Before you start

You need three things in place. First, a database you can register, with a role you are willing to scope down rather than the admin login. Second, an identity provider the gateway can authenticate against, so the agent gets a real principal instead of a shared key. Third, a clear idea of what this particular agent's task actually requires, because least privilege only works if you know the floor you are aiming for. Spend a few minutes on the third item; most over-grants happen because nobody asked what the task genuinely needed and the broad credential was simply easier.

Step-by-step setup

  1. Install the gateway and run an agent near your database. The agent opens an outbound connection, so the database stays unexposed.
  2. Register the database connection with a least-privilege role rather than an admin account.
  3. Connect your identity provider and give the agent its own principal through OIDC.
  4. Set just-in-time access so the agent gets database access for the task and loses it after.
  5. Add an approval gate on writes and schema changes.
  6. Point the agent at the gateway and run a query to confirm it appears in the session record.
# the ChatGPT agent connects to the gateway, not the database
export DATABASE_URL="postgres://chatgpt-agent@gateway.internal:5432/app"
# gateway: authenticate, authorize, record, proxy to Postgres

Verification

Run a read that is in scope and confirm it succeeds and is recorded. Then attempt a write you have gated and confirm it pauses for approval. If both behave, the boundary is real, not aspirational.

Pitfalls

  • Embedding credentials in the agent. Keep them on the connection so rotating or revoking does not touch the agent.
  • Skipping per-agent identity. Without it, you cannot attribute a query to this agent.
  • Open-ended access. Scope it to the task window.

FAQ

Does hoop.dev read what ChatGPT generates?

No. It governs the database connection the agent uses and records the queries that run. The model prompt and output are out of scope.

Can I require approval for writes only?

Yes. Route writes and schema changes to a human approver while letting in-scope reads run directly.

What if the agent already has a direct connection string?

Remove it. As long as the agent can reach the database directly, the gateway is optional and the controls are bypassable. The point of routing through the gateway is that it becomes the only path, so scope, recording, and approvals always apply.

Walk the setup with the open-source project on GitHub. The getting started guide covers the first connection, and hoop.dev explains the gateway model.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts