Why uncontrolled database access is dangerous
Devin, an AI coding assistant, can generate queries on the fly and send them directly to a CloudSQL instance. In many teams the agent runs with a service‑account that holds a static database user and password. That credential is shared across all CI jobs, feature branches, and experimental notebooks. The result is a single point of failure: anyone who compromises the agent or the secret can read, modify, or delete production data without any visibility.
Beyond the obvious data‑leak risk, the lack of per‑request audit means security teams cannot answer who ran which query, when, or whether the result contained personally identifiable information. Compliance frameworks expect evidence of who accessed what, and without a guardrail the AI agent can inadvertently expose sensitive columns, violating privacy policies.
Architectural pattern for AI‑driven database access
The safe way to let an autonomous agent talk to a database is to place an identity‑aware proxy between the agent and the database. The proxy becomes the sole holder of the database credential, so the agent never gains access to that secret. The agent presents an OIDC token that proves its identity and group membership. The proxy validates the token, checks a policy engine, and decides whether to allow the query, mask parts of the response, or require a human approval step before execution.
This pattern satisfies three essential requirements. First, it enforces least‑privilege at the moment of request, allowing only the statements that the policy permits. Second, it provides a complete audit trail that cannot be altered, since every session passes through the proxy. Third, it protects sensitive data in‑flight by applying inline masking to columns that are marked as confidential.
How hoop.dev implements database access controls
hoop.dev is the open‑source gateway that embodies the proxy pattern described above. It sits at layer 7, intercepting the PostgreSQL wire protocol (or MySQL, MSSQL, etc.) before the request reaches the actual database. Because hoop.dev is the data path, it can enforce all the outcomes required for secure database access.
- Just‑in‑time approval: When Devin asks for a query that exceeds its baseline permissions, hoop.dev pauses the request and routes it to an approver defined in the policy. The query proceeds only after explicit consent.
- Inline masking: Sensitive columns such as SSN or credit‑card numbers are replaced with masked tokens in the response stream, ensuring that downstream consumers never see raw values.
- Command‑level audit: Every statement, its parameters, and the identity that issued it are recorded by hoop.dev. The logs are stored outside the database so that even a compromised database cannot erase evidence.
- Session recording: hoop.dev captures the full interactive session, enabling replay for forensic analysis or training purposes.
Because hoop.dev holds the database credential, the AI agent never receives the database secret. The gateway validates the OIDC token issued by the organization’s identity provider (Okta, Azure AD, Google Workspace, etc.) and maps groups to fine‑grained database roles. This separation of authentication (setup) from enforcement (data path) guarantees that the security outcomes exist only because hoop.dev is in the request flow.
Deploying hoop.dev for Devin on GCP
To protect Devin’s database access, deploy the hoop.dev gateway inside the same VPC as the CloudSQL instance. An agent runs as a sidecar near the database and maintains a persistent connection to it. Register the CloudSQL endpoint in hoop.dev, configure the database credential that the gateway will use, and enable OIDC authentication pointing at your IdP.
Next, define a policy that grants Devin read‑only access to the analytics schema but requires approval for any DDL or data‑exfiltration queries. Mark columns that contain personal data as masked. Once the policy is in place, any request from Devin must travel through hoop.dev, where the enforcement outcomes are applied automatically.
Getting started
Review the step‑by‑step guide to spin up the gateway, connect it to a GCP database, and configure OIDC authentication in the getting‑started documentation. For deeper insight into policy language, masking rules, and approval workflows, explore the learn section. The source code, contribution guidelines, and issue tracker are available on the GitHub repository.
FAQ
Does hoop.dev store my database passwords?
No. The gateway holds the credential in memory only for the duration of the connection. The AI agent never receives the password, and the secret is not persisted in the database itself.
Can I retroactively view what Devin queried yesterday?
Yes. hoop.dev records every statement with the associated identity, so you can query the audit log for any time range and replay the exact session.
Is masking configurable per column?
Exactly. You define which columns are sensitive in the policy, and hoop.dev applies the mask on every response that contains those fields.
