An offboarded contractor still has an API token embedded in an MCP server that queries Snowflake for sales reports, exposing the system to gdpr risk. The token never expires, and every night the server pulls rows that include customer names, email addresses, and purchase histories. When the contractor leaves, the token remains active, and there is no log that shows which queries returned personal data or who approved them.
In many organizations, MCP servers connect directly to Snowflake using static credentials stored in configuration files or environment variables. Those connections bypass any central policy engine, so the system cannot prove who accessed personal data, when, or for what purpose. GDPR requires that data controllers maintain detailed records of processing activities, demonstrate lawful basis for each access, and be able to produce that evidence quickly during audits or data‑subject requests. Without a reliable audit trail, companies risk non‑compliance, fines, and loss of customer trust.
Teams recognize the need to tighten tool access: they want short‑lived, least‑privilege identities for MCP servers, and they want to enforce approval workflows for queries that touch sensitive fields. Yet the usual approach, rotating credentials or adding manual checks, still leaves the data path open. The request travels straight to Snowflake, and there is no point where the organization can inspect, mask, or record the traffic. The gap remains between improved identity controls and the continuous evidence GDPR demands.
Generating gdpr evidence with an access gateway
Placing a Layer 7 gateway between the MCP server and Snowflake closes that gap. The gateway authenticates the MCP server’s identity via OIDC or SAML, which is the setup phase: the identity provider vouches for the server, and the gateway learns the server’s group membership and attributes. Once the identity is verified, the gateway becomes the sole conduit for all Snowflake traffic. Because the gateway sits in the data path, it can enforce policies and produce enforcement outcomes.
hoop.dev records every query that passes through, capturing the exact SQL statement, the user or service account that issued it, and the timestamp. Those logs are retained for the period you configure, giving a continuous chain of custody that satisfies GDPR’s requirement for processing records. hoop.dev masks personal identifiers in query results in real time, ensuring that downstream tools only see sanitized data unless an explicit approval is granted. For high‑risk queries, such as those that retrieve email addresses or payment details, the gateway can pause execution and route the request to a human approver before allowing it to proceed.
Because the gateway enforces just‑in‑time access, the MCP server never holds privileged credentials longer than needed. The server presents an OIDC token, the gateway validates it, and then forwards the request using its own short‑lived Snowflake credential. This separation means that even if the server is compromised, the attacker cannot reuse the credential to query raw personal data without passing through the gateway’s guardrails.