Every day a compromised service account can turn a harmless Snowflake query into a data exfiltration vector, dramatically raising prompt-injection risk for any LLM-driven agent. The prompt-injection risk is amplified when the attacker can impersonate the agent and send malicious prompts.
Current practice: unchecked Snowflake access
Most teams grant their automation agents static Snowflake credentials that are stored in CI pipelines or configuration files. The agents use these secrets to run queries on behalf of downstream services, data pipelines, or scheduled jobs. Because the credential is static, any process that can read the secret can impersonate the agent and issue arbitrary SQL. In many organisations the connection is made directly from the application container to Snowflake, bypassing any audit log or approval workflow. The result is a blind spot: the platform cannot tell whether a query originated from a legitimate job or from a malicious actor that has taken over the agent.
Why agent impersonation matters for prompt‑injection risk
Prompt‑injection attacks target language‑model‑driven agents that generate Snowflake queries from natural‑language prompts. If an attacker can hijack the agent’s identity, they can feed crafted prompts that cause the model to produce destructive or data‑leaking statements. This directly increases prompt-injection risk because the malicious query reaches the database without any barrier.
Two factors make this scenario realistic:
- Agents often run with privileged roles to simplify data pipelines, so a single compromised credential can read or write large tables.
- Prompt‑injection techniques can embed malicious SQL fragments inside seemingly benign natural‑language input, tricking the model into generating harmful queries.
Without a control point that can inspect, approve, or mask the generated SQL, the organization loses the ability to stop a prompt‑injection from reaching Snowflake.
The missing enforcement layer
Identity providers (Okta, Azure AD, Google Workspace) can verify who is calling the agent, but they do not see the actual query payload. The setup – OIDC tokens, service‑account roles, and least‑privilege grants – decides who may start a request, yet it cannot enforce what the request does once it reaches Snowflake. The enforcement point must sit on the data path, between the impersonating agent and the database, where the SQL traffic can be examined.
How hoop.dev secures the data path
hoop.dev implements a Layer 7 gateway that proxies every Snowflake connection. The gateway runs a network‑resident agent inside the same VPC as Snowflake, and all client traffic is forced through this proxy. Because the proxy is the sole data path, hoop.dev can apply three critical controls:
- Just‑in‑time approval: When the model generates a query that matches a high‑risk pattern, hoop.dev pauses execution and routes the statement to a human reviewer for explicit consent.
- Inline masking: Sensitive columns such as PII or financial identifiers are redacted in the response before they leave the gateway, reducing exposure even if a malicious query succeeds.
- Session recording and replay: hoop.dev captures the full request and response stream, providing a reliable audit log that can be reviewed later and supports forensic analysis.
All of these outcomes exist only because hoop.dev sits in the data path. The identity provider still decides who may initiate a connection, but hoop.dev is the only component that can block, mask, or record the actual Snowflake traffic.
Putting the pieces together
To protect against prompt‑injection risk, organisations should adopt the following high‑level workflow:
- Configure Snowflake credentials as a static secret that only the hoop.dev gateway can access.
- Enable OIDC authentication so that each agent presents a verified token to the gateway.
- Deploy hoop.dev in the same network segment as Snowflake, ensuring all traffic flows through the gateway.
- Define masking policies for sensitive columns and approval policies for high‑impact queries.
- Monitor the session logs that hoop.dev generates for anomalies and audit purposes.
These steps create a clear separation: the setup authenticates the caller, the gateway enforces policy, and the enforcement outcomes protect the database from malicious prompts.
Getting started with hoop.dev
hoop.dev is open source and MIT‑licensed. The project provides a Docker‑Compose quickstart that launches the gateway with OIDC support, masking, and guardrails out of the box. Detailed instructions for registering a Snowflake connection, defining masking rules, and enabling just‑in‑time approvals are available in the getting‑started guide. For deeper exploration of features such as session replay and policy configuration, see the learn section. The full source code and contribution guidelines live on GitHub.
