When a CI pipeline triggers an MCP server that still runs an offboarded contractor's credentials, Snowflake queries appear under an unknown user.
That situation violates SOC 2 expectations for traceability and controlled access. The team scrambles to discover who issued the query, whether any sensitive rows were exposed, and how to stop the same mistake from happening again. The root cause is a classic pattern: a tool connects directly to Snowflake using a static credential stored in a configuration file. The credential never rotates, the connection bypasses any central policy engine, and Snowflake logs only the service‑account name, not the individual job that launched the query.
Most organizations first move the secret into an identity provider and require each request to carry an OIDC token. That step tells the gateway who is making the call, but the request still travels straight to Snowflake. Because the gateway does not see the traffic, it cannot mask column values, block dangerous DDL, or require a human to approve a bulk export. Without a point of inspection, the audit log that Snowflake produces fails to satisfy SOC 2 evidence requirements.
SOC 2 auditors expect continuous proof that every access to sensitive data is authorized, that risky commands receive review, and that a tamper‑evident trail exists for the entire session. Those expectations cannot be met by identity alone; the enforcement point must sit on the data path, where the request is actually forwarded to Snowflake.
hoop.dev as the data‑path enforcement layer
hoop.dev implements an identity‑aware proxy that sits between the MCP server and Snowflake. It authenticates the OIDC token, resolves the user’s group membership, and then applies a set of guardrails before the request reaches the database. Because hoop.dev is the only component that sees the traffic, it can enforce the controls required for SOC 2 evidence.
- Session recording: hoop.dev captures the full request and response stream for each connection. The recorded session can be replayed later, giving auditors a concrete view of what data was returned.
- Inline masking: hoop.dev redacts configured columns, such as credit‑card numbers or PII, before they leave the database, ensuring downstream tools never see raw values.
- Just‑in‑time approval: when a query matches a high‑risk pattern, such as a SELECT on a table flagged as sensitive, hoop.dev routes the request to an approver. The approver’s decision logs alongside the session.
- Command blocking: hoop.dev rejects DDL or data‑deletion statements that fall outside the policy, preventing accidental or malicious schema changes.
Each of these outcomes occurs because hoop.dev occupies the data path. If the MCP server bypasses hoop.dev, none of the above happens, and the SOC 2 evidence remains incomplete.
Continuous evidence that satisfies SOC 2
SOC 2 auditors look for three categories of evidence: who accessed the system, what they did, and whether the action complied with policy. hoop.dev supplies all three in real time.