Agent impersonation: what it means for your blast radius (on Snowflake)

When a contractor leaves the company, the service account they used for nightly ETL jobs often stays active, instantly expanding the blast radius of any future queries. The next day a data engineer runs a Snowflake query through that same account, unaware that the credentials are still tied to the former contractor’s permissions. The result is a query that can read every customer table, export raw data, and write to a staging bucket, all under the guise of a legitimate pipeline.

Agent impersonation occurs when a non‑human identity (a CI runner, a service account, or an automation bot) presents the credentials of another identity without explicit approval. The impersonating agent inherits the source identity’s privileges, and the target system sees only the original user’s token. This indirection makes it difficult to trace who initiated a request, and it inflates the potential impact of any mistake.

Why impersonation expands blast radius

The term blast radius describes the amount of damage a single compromised or misused credential can cause. In a Snowflake environment, a single privileged role can read, copy, and delete data across many schemas. When an agent is allowed to impersonate that role, the blast radius grows in two ways. First, the agent can act on behalf of multiple users, effectively multiplying the number of privileged operations it can perform. Second, because the impersonation happens behind the scenes, the organization loses visibility into which automated process actually executed the operation.

Typical deployments place the service account’s secret directly on the host that runs the ETL job. The agent connects straight to Snowflake using that secret, bypassing any intermediate control point. The setup usually includes an OIDC‑based identity provider that authenticates the host, but the provider only decides whether the host may start a connection. Once the connection is established, Snowflake sees a single user token and has no knowledge of the agent that originated the request.

This model satisfies the basic requirement of authentication, but it does not provide enforcement. There is no place to examine each SQL statement, no way to mask sensitive columns in query results, and no audit record that ties the activity to the originating automation. Consequently, if the impersonating agent is compromised or misconfigured, the blast radius can span the entire data warehouse.

Placing enforcement in the data path

To limit blast radius, the enforcement point must sit where the traffic actually flows. A Layer 7 gateway that proxies every Snowflake connection provides that control surface. By routing all agent traffic through a single proxy, the organization can apply consistent policies on every request, regardless of which service account originated it.

hoop.dev fulfills this role. It sits between identities and Snowflake, inspecting each SQL command before it reaches the database. hoop.dev can block dangerous statements, require just‑in‑time approval for high‑impact queries, mask personally identifiable information in result sets, and record every session for later replay. Because the proxy holds the Snowflake credential, the agent never sees the secret directly.

When an agent attempts to impersonate a privileged role, hoop.dev evaluates the request against the current policy. If the query exceeds the allowed scope, hoop.dev either rejects it or routes it to an approver. Every approved or denied action is logged with the true identity of the agent, the impersonated role, and the full SQL text. This audit trail turns an opaque impersonation into a traceable event.

The surrounding setup still matters. OIDC or SAML authentication determines which agents are allowed to request access, and role‑based assignments limit which Snowflake roles an agent can request. However, those mechanisms only answer “who may start?” – they do not answer “what may the request do?” hoop.dev provides the answer by being the only place where policy enforcement occurs.

By recording each session, hoop.dev gives security teams the evidence needed to investigate anomalies. If a data engineer notices an unexpected export, the replay feature shows exactly which agent issued the command, what role it was using, and which columns were returned. Inline masking ensures that even approved queries cannot exfiltrate raw PII unless explicitly permitted.

Deploying the gateway is straightforward. The quick‑start guide walks through launching the Docker Compose stack, configuring Snowflake as a connection, and linking the proxy to an OIDC provider. Once in place, all Snowflake traffic flows through the proxy, and the organization gains a single, auditable control point for every automation job.

FAQ

• Does hoop.dev replace Snowflake’s native role management? No. Snowflake roles continue to define what actions are permissible. hoop.dev adds a runtime guard that can further restrict or approve those actions on a per‑request basis.
• Can existing CI pipelines use the proxy without code changes? Yes. The proxy works with standard Snowflake clients, so pipelines can point to the proxy endpoint instead of the direct Snowflake host.
• What happens to data that is masked? The masking is applied in‑flight by the proxy before the result reaches the client. The original data remains unchanged in Snowflake.

For a hands‑on walkthrough, see the getting‑started guide. Detailed feature documentation is available on the learn page.

Explore the source code on GitHub to see how the gateway enforces policies and records sessions.