When every code execution request is tracked, approved, and its output sanitized, PCI DSS auditors see a complete, reliable trail without chasing missing logs.
PCI DSS expects organizations that handle payment‑card data to maintain rigorous controls over who can run code that touches that data and to retain immutable evidence of every privileged operation. Requirement 10.2 demands that all access to card‑holder data environments be logged, while Requirement 10.5 requires those logs to be protected and retained for at least one year. Auditors also look for evidence that only the minimum‑necessary privileges were granted at the moment of need (Requirement 7) and that any exposure of card data in command output is prevented (Requirement 3.2). In practice, meeting those expectations is difficult because code execution pipelines often rely on long‑lived service accounts, shared secrets, and ad‑hoc scripts that leave no reliable audit trail.
Current reality: unchecked code execution
Most teams provision a single service account for CI/CD, grant it broad database and API permissions, and embed the credential in build scripts. Engineers and automated jobs use that same account to run migrations, data‑extraction jobs, or ad‑hoc queries. The result is a noisy environment where:
- Multiple users act through the same identity, making it impossible to attribute a specific command to an individual.
- Execution logs are scattered across CI servers, shell histories, and occasional manual copy‑pastes, none of which are centrally retained or protected.
- Output containing PANs or CVVs can be printed to console or written to temporary files, leaking card data without any detection.
When a PCI DSS audit arrives, the evidence team spends days stitching together fragments, and gaps inevitably appear.
What must change before we can claim compliance
Introducing non‑human identities (service accounts) with least‑privilege scopes and enforcing just‑in‑time (JIT) grants is a necessary first step. With JIT, a job requests a short‑lived credential that is issued only for the duration of the task. However, even after that change the request still travels directly to the target system. The connection bypasses any central enforcement point, so there is still:
- No guaranteed recording of the exact command line or response.
- No inline inspection that could redact card data before it reaches a log file.
- No workflow to pause a risky command and require human approval.
Those gaps leave the PCI DSS evidence requirements unfulfilled.
hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that sits between the identity provider and the infrastructure that runs code. By placing the gateway on the data path, hoop.dev becomes the only place where enforcement can happen. It provides three core capabilities that directly generate PCI DSS evidence:
- Session recording. hoop.dev records every command issued through the gateway and the full response stream. The recordings are stored outside the target system, preserving an audit trail that satisfies Requirement 10.2.
- Just‑in‑time approvals. Before a high‑risk command (for example, a query that returns full card numbers) is executed, hoop.dev can pause the request and route it to an authorized reviewer. The approval decision, reviewer identity, and timestamp are logged, meeting the intent‑based access controls demanded by Requirement 7.
- Inline data masking. hoop.dev inspects response payloads in real time and redacts fields that match PCI‑defined patterns (such as PANs). Because the masking occurs before the data reaches any downstream log collector, the system respects Requirement 3.2’s protection of stored card data.
All of these outcomes exist only because hoop.dev occupies the data path; the underlying service account or JIT credential never sees the raw data or the final decision.
Mapping hoop.dev capabilities to PCI DSS requirements
Requirement 10.2 – Audit logs. Each recorded session includes the user identity, source IP, command text, and exact response. The logs are centrally stored and retained for the required period, giving auditors a consistent source of truth.
Requirement 10.5 – Log protection. hoop.dev’s audit store is isolated from the target system, reducing the attack surface for log tampering. Access to the logs is itself gated by the same JIT workflow.
Requirement 7 – Least privilege. The gateway enforces per‑command policies that can deny or limit operations based on the requesting identity’s role. Combined with JIT issuance of short‑lived credentials, this ensures that no process runs with more privileges than necessary.
Requirement 3.2 – Protect stored card data. Inline masking guarantees that any card data that appears in command output is redacted before it can be written to a file or sent to a log aggregator, keeping stored data within PCI‑defined protection boundaries.
Continuous evidence accrual
Because hoop.dev records every interaction in real time, evidence accumulates continuously rather than being generated after an incident. This approach simplifies audit preparation: the compliance team can pull a report for any date range and present a complete, verified view of who ran what, when, and with what data exposure.
Getting started
To adopt this model, begin with the getting‑started guide to deploy the gateway and configure an OIDC identity provider. The learn section explains how to define masking rules, set up approval workflows, and enable session replay for investigations.
FAQ
Q: Does hoop.dev replace existing CI/CD credentials?
A: No. hoop.dev consumes the short‑lived credentials issued by your JIT system, so existing pipelines keep their credential flow while gaining audit and masking capabilities.
Q: How long are recordings retained?
A: Retention is configurable in the gateway’s storage settings; you can align it with PCI DSS’s one‑year minimum.
Q: Can hoop.dev be used with on‑prem databases?
A: Yes. The gateway works with any supported database connector, whether the target runs in the cloud or on‑premises.
Explore the open‑source code and contribute on GitHub: https://github.com/hoophq/hoop.
