Many assume that giving an AI coding agent a permanent database password is safe because the model generates code snippets, but the reality is that the agent can issue any query it chooses. In practice this means uncontrolled database access: the agent can read, modify, or delete data without oversight. In most teams, an agent like Devin is granted a static credential baked into the deployment pipeline and used to open a connection to Snowflake warehouse. That connection bypasses any policy engine, so every SELECT, INSERT, or DROP runs with the same privilege regardless of the task. Because the credential never changes, compromised code or a misbehaving prompt can expose rows, alter tables, or exfiltrate data without a trace. The lack of per‑request approval, real‑time masking, or audit logs means security and compliance teams cannot answer questions about who accessed what and when. To protect sensitive datasets, organizations need a plane that can enforce database access policies at the moment a query is issued, not after the fact.
Why database access matters for AI coding agents
AI agents that generate and execute SQL are effectively autonomous users. Their workload can shift from read‑only analysis to data modification in seconds, and the underlying model does not distinguish between benign and destructive intent. Without a gate that evaluates each request, a single errant prompt can alter production tables, leak personally identifiable information, or trigger costly queries that impact service performance. Auditors also demand evidence of who accessed which data and when, a requirement that static credentials cannot satisfy.
Implementing database access controls with hoop.dev
hoop.dev provides the data‑path enforcement that bridges identity and infrastructure. The gateway sits between the AI agent and Snowflake, acting as a Layer 7 proxy that inspects every wire‑protocol message. Identity is verified through an OIDC or SAML token, so the system knows exactly which service account or user the request originates from. The gateway holds the Snowflake credential; the agent never sees it, eliminating credential sprawl.
Setup: identity and provisioning
The first step is to configure an OIDC provider (for example, Okta or Azure AD) and map groups to access policies. Each group receives a scoped role that defines which Snowflake databases, schemas, or tables the members may touch. These roles are stored in the gateway’s policy store and are consulted on every request. Because the gateway validates the token before any traffic reaches Snowflake, only correctly authenticated identities can proceed.
The data path: where enforcement lives
All traffic from Devin to Snowflake passes through hoop.dev’s gateway. The gateway parses the SQL payload, applies policy checks, and then forwards the request to the target. Because enforcement happens in the data path, a compromised agent cannot bypass controls, and any attempt to tamper with the request is blocked before it reaches the database.