Attackers target machine accounts that run automated jobs, and a single compromised credential can expose every credit‑card record in a data warehouse.
PCI DSS expects every entity that touches cardholder data to be uniquely identifiable, to have its activity logged, and to be granted only the privileges it needs at the moment it needs them. Non‑human identities, service accounts, CI/CD runners, and AI agents, therefore must receive the same rigorous treatment as human users. The standard requires proof that each request was authorized, that sensitive fields were protected, and that any privileged operation received a review.
In many organizations the reality falls short. Teams create a service account once, store its password in a shared vault, and bake the same secret into every CI pipeline that touches Snowflake. Engineers log in directly with that secret, run ad‑hoc queries, and the system records only the Snowflake user name, not the originating automation. No inline masking protects card numbers, no high‑risk statements trigger an approval workflow, and the audit trail stops at the database log level. When a breach occurs, investigators cannot tell which automated job issued the offending query, nor can they prove that the data was masked in transit.
Bridging that gap demands more than strong identity providers. You need unique authentication for each non‑human principal, just‑in‑time privilege elevation, real‑time inspection of every Snowflake command, automatic masking of card‑holder fields, and an immutable record of who did what, when, and with what result. All of these controls must sit on the path that the request travels; otherwise a compromised service can bypass them entirely.
Identity federation (OIDC, SAML) and role‑based access control decide who may start a session, but they do not enforce what happens inside the session. Without a gateway that sits in the data path, the request reaches Snowflake directly, and you cannot guarantee session recording, inline masking, approval gating, or replay capability.
Enter hoop.dev. It is an open‑source Layer 7 gateway that positions itself between every non‑human identity and the Snowflake endpoint. The gateway authenticates the caller via OIDC, then proxies the connection while inspecting the Snowflake wire protocol. Because the gateway is the only place the traffic passes, it can apply masking policies to column values, block DML statements that violate policy, and route high‑risk queries to a human approver before they execute. Every statement, along with the caller’s identity, timestamp, and approval status, is recorded for replay and audit.
When you register Snowflake as a connection in hoop.dev, you supply the service‑level credential once. The gateway stores it securely; the automation never sees the password. Each CI job authenticates to hoop.dev with its own OIDC token, which the gateway validates and maps to a scoped Snowflake role. As the job runs, hoop.dev watches the protocol: it replaces a primary account number with a masked token in the result set, enforces that only SELECT statements run on PCI‑relevant tables, and requires a senior engineer to approve any INSERT, UPDATE, or DELETE that touches those tables. The resulting audit log contains a line‑item for every query, the exact data that was returned (or masked), and the identity of the automation that initiated it.
PCI DSS auditors need concrete evidence: who accessed cardholder data, what they did, and whether the action was authorized. hoop.dev generates logs that include timestamps and can be presented as evidence for PCI DSS requirement 10, which tracks and monitors all access. Because the gateway masks sensitive fields before they leave Snowflake, the gateway satisfies requirement 3.2 (protect stored cardholder data) without requiring schema changes.
Beyond compliance, the architecture reduces blast radius. If a credential leaks, you revoke the OIDC client or the scoped role in the gateway, and the compromised service can no longer reach Snowflake. You avoid rotating the underlying Snowflake password for every incident, which saves time and prevents accidental outages.
You can deploy the solution straightforwardly. Begin with the getting‑started guide, which walks you through launching the gateway in Docker or Kubernetes, configuring OIDC, and adding a Snowflake connection. Define masking and approval policies in the hoop.dev UI or YAML files, then grant each CI pipeline the minimal role it needs. The rest of the enforcement lives in the data path, guaranteeing that every request is subject to the same guardrails.
Ready to see the code and contribute? Explore the open‑source repository on GitHub and start building a PCI‑compliant data pipeline.
PCI DSS requirements addressed by the gateway
- Requirement 8 – Identify and authenticate access to system components: hoop.dev forces every automation to present a valid OIDC token and validates it before proxying the Snowflake connection.
- Requirement 10 – Track and monitor all access to network resources and cardholder data: hoop.dev logs each Snowflake statement with full context, satisfying the tracking mandate.
- Requirement 3.2 – Protect stored cardholder data: hoop.dev masks PANs in query results before they leave the database.
- Requirement 7 – Restrict access to cardholder data by business need‑to‑know: just‑in‑time role mapping ensures each automation receives only the privileges it needs.
FAQ
How does hoop.dev help meet PCI DSS requirement 8?
It forces every automation to present a valid OIDC token, validates the token, and only then proxies the Snowflake connection. No token, no access.
Which PCI DSS requirement does session recording satisfy?
hoop.dev fulfills Requirement 10 by logging all access to cardholder data, providing the audit trail auditors require.
Can hoop.dev mask credit‑card numbers in query results?
Yes. Inline masking policies replace PANs with masked values before the response leaves the gateway, ensuring downstream systems never see raw card numbers and satisfying Requirement 3.2.
