When Devin, an AI coding agent, queries a production database, the organization sees only the data it needs, every query is logged, and any risky operation is blocked before it runs. That is the ideal state for database access that powers automated development while keeping sensitive rows and schema safe. Achieving it requires more than a static password; it needs a control plane that can see each request, decide whether it should be allowed, and hide confidential fields in the response.
In many teams the first step is to give Devin a service account that can authenticate to the database. The account is usually granted a broad role, the credential lives in a secret manager, and the AI client connects directly with a standard driver. This solves the identity problem – Devin now has a token that the database will accept – but it leaves the request path completely open. The database receives the query unchanged, no audit trail is collected, and there is no way to intervene if a generated statement tries to drop a table or exfiltrate personal data.
The missing piece is a point in the data path where policy can be enforced. By inserting a Layer 7 gateway between the AI agent and the database, every statement can be inspected, approved, masked, or blocked in real time. The gateway also records the full session so that later reviews can reconstruct exactly what Devin asked for and what the database returned.
Designing secure database access for AI agents
To build a trustworthy pipeline, start with a least‑privilege service account for Devin. Bind the account to a role that only permits the schemas and tables the agent needs. Use OIDC or SAML federation so that the identity token carries group membership and can be refreshed without hard‑coded secrets. This setup guarantees that only an authenticated entity reaches the gateway, but it does not yet provide any guardrails on the actual queries.
Placing the gateway in the data path
hoop.dev acts as a protocol‑aware proxy that sits between the AI client and the database. All traffic from Devin is forced through this proxy, which means every database request and response passes through a single enforcement point. Because hoop.dev operates at the wire‑protocol level, it does not require changes to the client library or to the database driver.
Enforcement outcomes
- hoop.dev records each session, creating a replay log that auditors can examine.
- hoop.dev masks sensitive columns in query results, ensuring that personal identifiers never leave the gateway.
- hoop.dev blocks commands that match risky patterns, such as DROP, ALTER, or bulk deletes, before they reach the database engine.
- hoop.dev routes suspicious statements to a human approver, applying just‑in‑time approval workflows.
- hoop.dev tags every request with the originating identity, so that downstream compliance tools can attribute actions to Devin.
Getting started
The simplest way to try this architecture is to deploy the hoop.dev gateway with Docker Compose. The quick‑start pulls a ready‑made compose file, configures OIDC authentication, and enables masking and guardrails out of the box. Detailed steps are available in the getting‑started guide. Once the gateway is running, register the target database as a connection, attach the service account credential, and point Devin’s client at the proxy endpoint.
For deeper customisation, such as defining masking rules for specific columns or tailoring approval policies, refer to the learn section. The documentation explains how to model policies as JSON objects, how to bind them to groups, and how to monitor session logs from the built‑in UI.
FAQ
What if Devin needs read‑only access to multiple databases?
Define a separate connection for each database in the gateway and assign the same service account role to all of them. hoop.dev will enforce the same masking and audit policies across each connection, keeping the control surface unified.
Can I use existing IAM roles instead of a new service account?
Yes. The gateway can store an IAM role that it assumes on behalf of the connection. The role should be scoped to the minimum set of permissions required for the AI workload. hoop.dev still mediates the traffic, so the role alone does not provide masking or approval.
How does session replay work for AI‑generated queries?
Every request and response that passes through hoop.dev is written to a log file. The log includes the raw SQL, the masked result, and metadata such as the identity token and timestamp. Auditors can replay the log in a sandboxed environment to verify that the AI behaved as expected.
By placing a transparent, policy‑driven gateway in front of the database, teams can let AI agents like Devin operate at speed while keeping full visibility and control over every database access.
Explore the open‑source code, contribute improvements, or clone the repository to start your own deployment: hoop.dev on GitHub.
