Uncontrolled AI agents are already talking to production warehouses
AI coding agents that generate SQL on the fly introduce a serious prompt-injection risk by being given direct network access to Snowflake clusters, often using long‑lived service accounts or shared API keys. The agents execute queries without any human in the loop, and the results flow straight back to the calling application.
This arrangement means a malicious prompt can cause the agent to run arbitrary statements, exfiltrate data, or corrupt tables, and there is no reliable audit trail to prove what was asked or what was returned. The risk is real, and it is invisible to most security teams because the traffic never leaves the trusted network segment.
Why existing identity controls are not enough
Most organizations have already hardened the identity side of the problem. They issue non‑human identities for CI/CD pipelines, enforce least‑privilege roles in Snowflake, and federate those identities through an OIDC provider. Those steps ensure that the agent can only connect if it presents a valid token and that the token’s scopes are limited.
However, the request still travels directly to Snowflake. The gateway that could inspect the SQL, enforce policy, or require a human approval does not exist. Without a data‑path control, the following gaps remain:
- No real‑time inspection of the generated query for prompt‑injection patterns.
- No inline masking of sensitive columns before they leave Snowflake.
- No just‑in‑time approval workflow for high‑risk statements.
- No immutable session recording that auditors can replay.
In short, the setup guarantees that the identity is correct but offers no guarantee that the command itself is safe.
Placing a Layer 7 gateway in the data path solves the problem
hoop.dev is designed to sit between the AI agent and Snowflake, acting as an identity‑aware proxy that can enforce policy on every SQL statement. Because hoop.dev intercepts traffic at the protocol layer, it can apply the missing controls without changing the agent’s code.
When an AI coding agent initiates a connection, hoop.dev validates the OIDC token, maps the token to a Snowflake role, and then forwards the request using its own credential that the agent never sees. From that point forward, hoop.dev becomes the sole place where enforcement can happen.
Enforcement outcomes that matter for prompt‑injection risk
- Query‑level audit. hoop.dev records the exact SQL string, the identity that issued it, and the response metadata. The log is stored outside Snowflake, providing a reliable trail for forensic analysis.
- Inline data masking. Sensitive columns such as credit‑card numbers or PII can be redacted in the response before they reach the agent, reducing data leakage even if a prompt succeeds.
- Just‑in‑time approval. For statements that match a high‑risk pattern, e.g., DROP, ALTER, or massive SELECTs, hoop.dev can pause execution and route the request to an authorized reviewer for manual sign‑off.
- Command blocking. Known malicious patterns identified by prompt‑injection testing are rejected outright, preventing the agent from ever reaching Snowflake with a dangerous query.
- Session recording and replay. Every interaction is captured, allowing security teams to replay a session exactly as it occurred, which is essential for compliance audits.
All of these outcomes exist only because hoop.dev occupies the data path. If the gateway were removed, the AI agent would again talk directly to Snowflake, and none of the protections would be applied.
How the architecture fits together
The overall flow looks like this:
- Developer or CI pipeline triggers an AI coding agent.
- The agent obtains an OIDC token from the corporate IdP.
- hoop.dev verifies the token, extracts group membership, and maps it to a Snowflake role.
- The gateway forwards the query using its own Snowflake credential, never exposing the secret to the agent.
- Before Snowflake executes the statement, hoop.dev applies masking, approval, or blocking policies.
- Snowflake returns the result, which hoop.dev may mask again before sending it back to the agent.
- All request and response metadata are logged for later review.
This pattern satisfies the three attribution categories:
- Setup. Identity providers, OIDC tokens, and Snowflake role assignments decide who may start a request.
- The data path. hoop.dev is the only place where policy enforcement occurs.
- Enforcement outcomes. Audit logs, masking, approvals, and session recordings are all produced by hoop.dev.
Getting started
Because hoop.dev is open source, you can deploy the gateway with a single Docker Compose file, configure Snowflake as a target, and point your AI agents at the local proxy endpoint. The getting‑started guide walks you through the minimal steps, and the learn section provides deeper coverage of masking policies and approval workflows.
FAQ
Does hoop.dev change the way my AI agent authenticates?
No. The agent still obtains an OIDC token from the existing IdP. hoop.dev validates that token and then uses its own Snowflake credential to talk to the database.
Can I selectively mask only certain columns?
Yes. Masking rules are defined in the gateway’s policy layer and apply to response payloads before they leave the data path.
What happens if an approval is denied?
hoop.dev aborts the query and returns a clear error to the agent, preventing any execution on Snowflake.
By inserting an identity‑aware proxy between AI coding agents and Snowflake, organizations can turn a blind spot into a controllable, auditable surface. The result is a practical reduction in prompt‑injection risk without sacrificing the productivity gains of automated code generation.
Explore the open‑source repository and contribute to the project.
