An offboarded contractor left a CI job that still runs nightly, spawning a Snowflake session which in turn launches a second session to copy tables to an external stage, creating a covert data exfiltration path. The first session never touches a human, but the chain of automated agents creates a hidden pathway for data to leave the warehouse.
Nested agents are simply agents that create other agents as part of their workload. In Snowflake, a script or stored procedure can open a new connection, invoke the Snowflake API, or even call an external function that itself talks back to Snowflake. Each hop inherits the original credentials unless the workflow explicitly rotates them. The result is a cascade of sessions that are difficult to trace with traditional audit tools.
When a nested agent chain is used for data exfiltration, the attacker, or a careless automation, can bypass normal human review. The first session may appear innocuous, running a routine SELECT. The second session can issue a COPY INTO command that writes large volumes of data to an external S3 bucket, a cloud storage account, or a partner‑hosted endpoint. Because the activity originates from a machine‑to‑machine flow, alerts that focus on direct user logins often miss the event.
What should you watch for?
- Unusual patterns of session creation: a single client IP or service account that opens multiple Snowflake connections within a short window.
- Large result sets that are immediately written to external stages or cloud storage.
- Stored procedures or tasks that invoke external functions with network access.
- Audit log entries that show a chain of "CALL" statements followed by "COPY INTO" or "PUT" commands.
- Service accounts that have broader privileges than required for the job they run.
These signals are often buried in Snowflake’s QUERY_HISTORY and ACCESS_HISTORY tables. Correlating them requires a dedicated analytics pipeline or a gateway that can inspect traffic in real time.
Why a gateway in the data path matters
hoop.dev sits in the data path as an identity‑aware proxy for Snowflake connections. Every request from a user or an automated job passes through the gateway before reaching the Snowflake service. Because hoop.dev is the only place where traffic can be inspected, it can enforce policies that would otherwise be impossible to apply.
When a session is initiated, hoop.dev verifies the OIDC token, extracts group membership, and decides whether the request is allowed to proceed. Once the connection is established, hoop.dev records each command, captures the full response, and stores a replayable session. If a query returns a column marked as sensitive, hoop.dev can mask the values before they reach the client. For large data movements, hoop.dev can require a just‑in‑time approval step, pausing the operation until a human reviewer signs off.
Because the gateway sits between the agent and Snowflake, it can also block suspicious patterns. If a service account that normally runs small analytics queries suddenly issues a COPY INTO that targets an external bucket, hoop.dev can intervene, log the event, and prevent the data from leaving the warehouse. The same mechanism can be used to throttle the size of result sets, enforce row‑level security, or require multi‑factor approval for any operation that touches personally identifiable information.
All of these enforcement outcomes, session recording, inline masking, just‑in‑time approval, and command blocking, exist only because hoop.dev occupies the data path. Without the gateway, the nested agents would communicate directly with Snowflake, and the organization would lose visibility into the chain of calls.
Getting started with hoop.dev for Snowflake
To protect Snowflake workloads from nested‑agent exfiltration, begin with the getting started guide. Deploy the gateway in your network, register the Snowflake connection, and configure the credential that the gateway will use to talk to Snowflake. The gateway holds the credential, so users and automated jobs never see it.
For deeper technical details, see the hoop.dev learn portal. There you can explore policy examples, masking configurations, and approval workflow designs.
Next, define policies that match the signals described earlier. For example, create a rule that requires approval for any COPY INTO that writes more than 10 GB, and enable masking for columns that contain credit‑card numbers or social security numbers. The policy engine lives inside hoop.dev, and the rules are enforced on every request that passes through the gateway.
Finally, integrate with your identity provider. hoop.dev acts as a relying party for OIDC or SAML, so you can map groups to Snowflake roles and enforce least‑privilege access for each service account. This setup ensures that only the right identities can start a Snowflake session, and that every nested call is still subject to the same guardrails.
FAQ
How can I detect a chain of nested agents?
hoop.dev records each session and correlates them by the originating identity and source IP. By querying the replay logs, you can see when a single client spawns multiple Snowflake connections within a short period. The gateway also surfaces alerts when a downstream command exceeds a size threshold or targets an external stage.
What does hoop.dev do to stop data exfiltration?
When a risky command is detected, hoop.dev can block the operation, require a human approval step, or mask sensitive fields before they leave Snowflake. Because the gateway is the only point where traffic can be inspected, it can enforce these controls consistently, even for automated jobs that create nested agents.
Do I need to change my existing Snowflake scripts?
No. hoop.dev works with standard Snowflake clients and drivers. Your scripts continue to use the same connection strings; the only change is that they point at the hoop.dev endpoint instead of the Snowflake endpoint directly.
Explore the source code on GitHub.
