Putting access controls around Devin: database access for AI coding agents (on internal SaaS)

How can you let an AI coding assistant run queries without giving it unrestricted credentials for database access?

Many teams hand the same static database user to an LLM‑driven agent, assuming convenience outweighs risk. The agent then talks directly to the production database, reusing the same password it was trained on. No one sees which tables the agent touches, no one knows whether a query exfiltrated data, and there is no way to stop a dangerous command before it hits the engine. The result is a blind spot: the organization cannot prove that the AI behaved responsibly, nor can it intervene when a query threatens compliance.

What you really need is a way to limit the AI’s ability to read or write, while still allowing it to reach the database. The request must still travel to the target, but the connection should be mediated so that every statement can be inspected, approved, or masked. Without a mediation layer, the AI retains full rights and the audit trail remains empty.

Why database access for AI agents needs a dedicated gateway

AI agents like Devin are non‑human identities. They do not have a business justification that a manager can review each time they need to run a query. Traditional role‑based access control (RBAC) assumes a human requests access, receives approval, and stays accountable. With an LLM, the same token can be used thousands of times per minute, making per‑request review impossible.

At the same time, the data stored in relational systems is often subject to privacy regulations, intellectual‑property rules, and internal policies that require fine‑grained control over which columns can be returned. Inline masking of sensitive fields, command‑level approval for risky operations, and immutable session logs become essential controls. These controls must sit where the traffic flows, not in a separate logging system that can be bypassed.

Implementing database access controls with hoop.dev

hoop.dev provides a Layer 7 gateway that sits between the AI agent and the database. You deploy the gateway inside the same network segment as the database, and a network‑resident agent runs locally to forward traffic. Identity is still handled by an OIDC or SAML provider, so the AI can be represented by a service‑account token that conveys the agent’s purpose.

When the request reaches the gateway, hoop.dev inspects the SQL payload before it reaches the backend. It can:

• Block statements that match a deny list, such as DROP DATABASE or SELECT * FROM secrets.
• Require a human approver to sign off on queries that touch high‑risk tables.
• Mask columns that contain personally identifiable information, ensuring the AI never sees raw values.
• Record the full request and response, producing a replayable session for audit.

Because hoop.dev is the only point where the traffic is examined, every enforcement outcome originates from it. hoop.dev records each query, masks sensitive fields, and enforces approvals before the database ever sees the command.

The setup phase still relies on proper identity configuration. You provision a service account in your IdP, grant it the minimal role needed to reach the gateway, and configure the gateway to trust tokens from that provider. This setup decides who the request is, but it does not enforce any policy on its own.

All policy enforcement lives in the data path, where hoop.dev resides. By placing the gateway directly in front of the database, you guarantee that no bypass is possible without going through the same inspection point.

Getting started

To try this approach, deploy the hoop.dev gateway using the official Docker Compose quick‑start. The compose file pulls the gateway image, configures OIDC authentication, and starts a network‑resident agent. After the gateway is running, register your PostgreSQL (or MySQL) connection in the hoop.dev UI, specifying the host, port, and a credential that the gateway will use internally. The AI agent then connects to the gateway using standard client tools – no code changes needed.

For detailed steps, see the getting‑started guide. The learn section also explains how to define masking rules, approval workflows, and audit retention policies.

Why this matters for compliance and risk

Regulators often ask for evidence that only authorized users accessed sensitive data and that teams logged every privileged operation. hoop.dev generates that evidence automatically: each session stores the identity that initiated it, the exact SQL statements, and the masked results. Because the gateway sits on the data path, the evidence cannot be forged or omitted.

The ability to block or mask queries also reduces the blast radius of a compromised AI token. Even if an attacker gains the service‑account token, they cannot issue destructive commands without triggering hoop.dev’s guardrails.

FAQ

Can I use hoop.dev with any database?

hoop.dev supports the major relational and NoSQL databases listed in its documentation, including PostgreSQL, MySQL, and MongoDB. For each supported target, the gateway knows how to speak the wire protocol and apply policy checks.

Do I need to change my application code?

No. The AI agent uses the same client libraries (psql, mysql, etc.) and simply points them at the gateway’s address. hoop.dev forwards traffic to the real database after applying the configured controls.

How do I grant the AI just‑in‑time access?

You define a policy that requires an approval step for any query that exceeds a defined risk threshold. When the AI issues such a query, hoop.dev pauses the request and notifies a designated approver. Once approved, the query proceeds; otherwise hoop.dev rejects it.

Where can I find the source code?

All components are open source. Visit the GitHub repository to explore the implementation, contribute, or file issues.