Machine accounts with static passwords are a prime vector for lateral movement.
In many organizations the default approach is to create a service account, grant it a broad set of privileges, copy the credential into scripts, and never rotate it. The credential lives in version‑control, on developer laptops, and in CI pipelines. Because the connection goes straight from the script to Snowflake, there is no record of which identity issued which query, no way to hide credit‑card numbers in result sets, and no human checkpoint before a destructive command runs.
NIST SP 800‑53 spells out a clear set of expectations for non‑human identities. It requires that each machine identity be assigned the minimum privileges needed for its function, that every access be auditable, that privileged actions be approved, and that sensitive data be protected at rest and in transit. The standard also calls for continuous monitoring and the ability to replay activity when an incident is investigated.
Most teams satisfy the first part of the requirement by using IAM policies or Snowflake roles that limit what a service account can do. Those policies, however, stop at the point of authentication. They do not enforce runtime guardrails, they do not capture the exact SQL statements that were executed, and they cannot mask personally identifiable information that slips out of a query result. In other words, the setup alone does not produce the evidence NIST expects.
hoop.dev fills the missing enforcement layer. It sits in the data path between the machine identity and Snowflake, acting as an identity‑aware proxy. Because every request passes through hoop.dev, it can record each session, apply inline masking to response fields, require just‑in‑time approval for high‑risk statements, and block commands that violate policy before they reach the database. The gateway never exposes the underlying credential to the calling process, so the secret remains confined to the agent inside the trusted network.
Mapping hoop.dev capabilities to NIST controls
- AC‑2 Account Management: hoop.dev creates a unique, short‑lived session token for each machine request, ensuring that no long‑lived password is reused.
- AC‑6 Least Privilege: The gateway enforces role‑based policies at the query level, preventing a service account from executing statements outside its assigned scope.
- AU‑2 Auditable Events: Every Snowflake query, including parameters and timestamps, is logged by hoop.dev and retained for audit outside the target system.
- AU‑6 Review and Analysis: Recorded sessions can be replayed in a sandbox, giving auditors a complete view of what the machine did during a given window.
- SC‑13 Cryptographic Protection: Sensitive columns are masked in‑flight by hoop.dev, so downstream consumers never see raw PII or credit‑card numbers.
- IR‑4 Incident Handling: When an anomalous command is detected, hoop.dev can pause execution and route the request to a human approver, providing a built‑in containment step.
Why the data path matters
The enforcement outcomes, recording, masking, just‑in‑time approval, and command blocking, are only possible because hoop.dev sits in the data path. Identity verification (the setup) tells the gateway who is making the request, but hoop.dev is the only component that can actually intervene on the traffic before it reaches Snowflake.
Getting started with non‑human identities
Deploy the hoop.dev gateway using the quick‑start Docker compose file, configure Snowflake as a connection, and bind the gateway to your OIDC provider. Once the gateway is running, any service account that authenticates via OIDC will automatically have its requests inspected and logged. Detailed steps are available in the getting‑started guide and the broader feature overview at hoop.dev/learn.
FAQ
Does hoop.dev replace Snowflake’s native role system?
No. hoop.dev complements Snowflake roles by adding runtime enforcement and audit evidence. Existing role assignments remain in place; the gateway simply validates each statement against additional policy rules before it is executed.
Can I use hoop.dev with existing service accounts?
Yes. Existing credentials can be imported into the gateway configuration, after which all traffic from those accounts will flow through hoop.dev, gaining the same recording and masking benefits.
What evidence does hoop.dev provide for an auditor?
Auditors receive session logs, approval records, and masked result sets that together satisfy NIST requirements for auditable events, privileged‑action approval, and protection of sensitive data.
Implementing end‑to‑end governance for non‑human identities is not a matter of adding a policy file; it requires an identity‑aware proxy that can observe and control traffic. hoop.dev is built exactly for that purpose, turning every machine request into a traceable, policy‑enforced event.
Explore the open‑source repository to see the code, contribute, or spin up your own instance.
