Applying guardrails to an AI coding agent is essential, yet many assume that simply giving an AI coding agent a Snowflake credential is enough to keep data safe. The reality is far more complex: a credential alone does not stop the agent from pulling raw tables, exposing secrets, or executing destructive queries.
The current reality of AI agents accessing Snowflake
Teams that experiment with coding assistants like Devin often start by provisioning a static Snowflake user or service account and embedding the password or key in the agent’s configuration. From the agent’s perspective the connection is just another JDBC/ODBC session. No additional policy layer checks each query, no real‑time review of results, and no audit trail that ties a specific piece of generated code to a human operator. If Devin misinterprets a prompt or a downstream developer asks it to “dump all customer PII”, the request flies straight to Snowflake, returns the raw rows, and disappears into logs that are owned by the Snowflake account itself. The organization loses visibility, cannot enforce least‑privilege at query time, and has no way to redact sensitive columns before they reach downstream systems.
What guardrails need to address – and what remains missing
Guardrails for an AI coding agent must satisfy three core requirements:
- Real‑time masking of sensitive fields such as credit‑card numbers or social security numbers so that the agent never sees raw values.
- Just‑in‑time approval for high‑risk operations like bulk exports, schema changes, or queries that touch regulated data.
- Immutable session recording that can be replayed by auditors or security engineers to reconstruct exactly what the agent asked Snowflake to do.
Even when an organization puts an OIDC identity provider in front of Devin, those three guardrails still do not materialize automatically. The identity system can tell hoop.dev who the request originates from, but without a data‑path enforcement point the request still reaches Snowflake directly. In other words, the request is authenticated, but it is not inspected, approved, or logged in a way that is independent of Snowflake’s own logging. The missing piece is a gateway that sits between the AI agent and the database, capable of applying the guardrails on every wire‑level operation.
hoop.dev provides the data‑path guardrails that matter
hoop.dev is a Layer 7 gateway that sits on the network edge, right where the AI agent’s traffic flows to Snowflake. The architecture follows a clear separation of concerns:
- Setup: Identity is managed through OIDC or SAML providers such as Okta, Azure AD, or Google Workspace. The gateway verifies the token, extracts group membership, and decides whether the request may proceed. This step determines who is making the call but does not enforce any data‑level policy.
- The data path: hoop.dev proxies the Snowflake protocol, inspecting each query and response. Because the gateway is the only place the traffic passes, it can enforce masking, trigger approval workflows, and record the full session.
- Enforcement outcomes: All guardrails are realized by hoop.dev itself. It masks sensitive columns before they are returned to Devin, routes high‑risk queries to a human approver, and writes an immutable audit record that can be replayed later. Without hoop.dev in the path, none of these outcomes would exist.
When Devin initiates a connection, the agent contacts hoop.dev with its standard Snowflake client. hoop.dev presents the stored Snowflake credential to the database, so the AI never sees the password. As queries travel through the gateway, hoop.dev applies a configurable masking policy, e.g., replace any column named ssn with a string of asterisks, ensuring that Devin only ever receives redacted data. If a query matches a high‑risk pattern such as selecting all rows from a payments table without a WHERE clause, hoop.dev pauses execution and forwards the request to an approval channel where an engineer can approve or reject it. Every command and response is streamed to a secure log that the security team can query later, providing the evidence needed for audits.
Masking sensitive data in real time
Masking is defined once in hoop.dev’s policy store. The gateway then rewrites result sets on the fly, preventing accidental leakage of personally identifiable information and satisfying compliance expectations without requiring developers to remember to scrub columns manually.