When a contractor leaves the organization, the access token they used to run automated data pipelines often remains valid for weeks. The token talks directly to Snowflake through an MCP server, and every query it issues slips past the security team because no central log captures the request or the result. The breach of confidentiality is invisible until a data-loss incident surfaces months later. The lingering token also violates the NIST requirement for continuous audit.
Teams respond by issuing short-lived service accounts and by moving the token issuance into an identity provider. The change guarantees that only a known non-human identity can start a pipeline, and it limits the window of exposure. However, the request still travels straight from the MCP server to Snowflake. The gateway that sits between the identity check and the database never sees the traffic, so there is no real-time approval, no inline data masking, and no immutable record of what was read or written. The audit gap remains, and the controls required by NIST are only half-implemented.
Why continuous evidence matters for NIST
The NIST Cybersecurity Framework and the NIST SP 800-53 families (AU, AC, IA, and IR) expect organizations to produce verifiable evidence of who accessed what, when, and why. Evidence must be collected at the point of access, retained in a tamper-evident store, and tied to an identity that can be audited later. When an MCP server talks directly to Snowflake, the only evidence is the Snowflake query log, which does not contain the originating service identity, the approval state, or any masking decisions made by policy. As a result, auditors cannot prove compliance with controls such as AU-6 (audit review, analysis, and reporting) or AC-2 (account management) without manual correlation.
To satisfy NIST, the evidence-generation process must be continuous, automated, and bound to the access path itself. Every session should be recorded, every response that contains sensitive columns should be masked before it reaches the caller, and any command that exceeds a risk threshold should be paused for human approval. Only a gateway that sits in the data path can enforce these requirements consistently.
hoop.dev as the data-path enforcement point
hoop.dev is an open-source Layer 7 gateway that proxies connections between MCP servers and Snowflake. It sits directly in the traffic flow, so it can inspect each protocol message, apply policy, and emit evidence in real time. Because hoop.dev holds the Snowflake credentials, the MCP server never sees them; the gateway authenticates to Snowflake on behalf of the request.
When a pipeline initiates a query, hoop.dev records the start of the session, the identity of the service account, and the exact SQL statement. If the statement matches a masking rule, such as returning credit-card numbers or personally identifiable information, hoop.dev redacts those fields before forwarding the result back to the MCP server. If the query attempts a privileged operation, like dropping a table or altering a schema, hoop.dev can automatically route the request to an approval workflow, requiring a security engineer to sign off before execution proceeds.
All of these actions generate audit records that include:
- Timestamped session identifiers (AU-1, AU-2)
- Service-account identity and group membership (IA-2, AC-2)
- Policy decisions made (masking, blocking, approval) (AC-3, AC-6)
- Full command and response payloads stored for replay (AU-6, IR-4)
Because hoop.dev records each session and retains the audit data in a secure log that is managed by the gateway, the evidence remains immutable and can be presented to auditors at any time. hoop.dev also collects evidence at the point of access, ensuring that every request is logged before it reaches Snowflake.