Many think that letting an AI coding agent like Devin talk directly to a database is safe because the agent only runs vetted code, but that ignores the need for strict database access controls. In reality the agent inherits whatever permissions the underlying credential carries, and those permissions are often far broader than the single query the agent needs.
In most teams the first step is to create a static database user, grant it read‑write rights on every schema, and embed the password in the container image that runs the AI service. The credential is shared across all instances of the agent, rotated only when a breach is suspected, and never logged. When Devin sends a query, the request travels straight to the database engine, bypassing any point where a policy could inspect the SQL, mask personal data, or require a human sign‑off. The result is a wide attack surface, no visibility into which queries the agent ran, and no way to prevent accidental exposure of sensitive columns.
Why fine‑grained database access matters for AI agents
AI coding assistants are powerful, but they also amplify risk. A single malformed SELECT can pull PII, an UPDATE can corrupt production data, and a DROP can erase an entire tenant. Organizations therefore need the same controls they apply to human engineers: least‑privilege credentials, just‑in‑time granting, inline data masking, and immutable audit trails.
Identity providers such as Okta or Azure AD can verify that the request originated from a trusted service account, and role‑based access control can restrict which databases the service may contact. However, once the request leaves the identity layer it reaches the database directly. At that point there is no enforcement point to enforce query‑level policies, to hide credit‑card numbers in result sets, or to pause a destructive command for manual approval.
Placing the enforcement point in the data path
To close the gap, the access control logic must sit in the data path – the exact place where traffic flows between the AI agent and the database. This is where hoop.dev operates. The gateway runs as a network‑resident service alongside the database, and every connection from Devin is proxied through it.
hoop.dev authenticates the agent’s OIDC token, extracts group membership, and then decides whether to allow the connection. The gateway holds the database credential, so the agent never sees it. As traffic passes through the gateway, hoop.dev can:
- Apply just‑in‑time access, granting the credential only for the duration of the approved session.
- Mask sensitive fields such such as SSN or credit‑card numbers in query results, ensuring that downstream logs never contain raw PII.
- Require a human approver for high‑risk statements like DROP, ALTER, or mass DELETE, pausing execution until the request is reviewed.
- Record every statement, parameters, and response for replay and forensic audit.
- Block commands that match a deny list, preventing accidental execution of destructive operations.
Because hoop.dev is the sole point where the traffic is inspected, all of these enforcement outcomes exist only because the gateway sits in the data path. The identity verification step (the setup) decides who is making the request, but without the gateway there would be no place to enforce the policies.
How the architecture fits on Kubernetes
Deploy the hoop.dev gateway as a sidecar or a separate pod in the same namespace as the database. The Kubernetes deployment keeps the gateway close to the data plane, minimizing latency while still providing a clear boundary. The AI service (Devin) runs in its own pod, obtains an OIDC token from the cluster’s identity provider, and connects to the database via the gateway’s service name. From the agent’s perspective the connection looks like any ordinary PostgreSQL or MySQL client; the gateway transparently adds the security layer.
All configuration – which databases to protect, which columns to mask, which queries need approval – is defined in the gateway’s policy files. The policies are expressed in high‑level terms; the documentation walks through how to declare a mask for a column or a rule that requires approval for DELETE statements. For step‑by‑step instructions, see the getting‑started guide and the broader feature overview on the learn page.
FAQ
How does hoop.dev decide which query results to mask?
Masking rules are defined by column name or data type in the gateway’s policy. When a SELECT returns rows, hoop.dev inspects each field and replaces values that match a mask rule with a placeholder before forwarding the response to Devin. The original data never leaves the gateway, so logs and recordings contain only masked values.
Will routing every request through the gateway add noticeable latency?
The gateway operates at Layer 7, terminating TLS and then inspecting the protocol payload. In typical Kubernetes deployments the added round‑trip is measured in low‑single‑digit milliseconds, which is negligible compared to query execution time for most workloads.
Can existing CI/CD pipelines still run automated migrations?
Yes. Automated jobs can obtain a short‑lived token and request a just‑in‑time session from the gateway. The same approval and masking policies apply, ensuring that even automated processes are subject to the same audit and control framework.
Get started with hoop.dev
Implementing these controls begins with deploying the gateway and defining your policies. The open‑source repository provides Docker Compose and Helm charts to get a test environment running in minutes. For the full source and contribution guidelines, visit the hoop.dev GitHub repository. Once the gateway is in place, you can start protecting Devin’s database access with fine‑grained, auditable controls that scale with your Kubernetes workloads.
