When a PCI DSS auditor asks for proof that every service‑account request was authorized, you should be able to hand over a complete, log that can be reviewed and replayed: who (or which automated identity) initiated the connection, the exact time, the command or query executed, and a guarantee that any cardholder data in the response was masked according to the standard. The evidence must also show that privileged actions were approved by a human before they ran, and that no secret credential was ever exposed in clear text. In that ideal state the audit trail is a single source of truth, immutable, and can be replayed to demonstrate compliance without pulling logs from multiple disparate systems.
Why non‑human identities are a compliance blind spot
PCI DSS treats service accounts, CI/CD bots, and other non‑human identities the same as human users under Requirement 8.5 and Requirement 10.5. Those rules demand unique credentials, least‑privilege access, and comprehensive logging of every action. In practice, many organizations grant long‑lived keys to automation tools and let them connect directly to databases or SSH hosts. The connections bypass central logging, credentials are stored in scripts, and any privileged command runs without a human check. Auditors therefore see gaps: no evidence of who invoked a query, no approval record, and no guarantee that sensitive card data was protected during the session.
What auditors expect from the evidence
- Identity provenance – a token or certificate that ties the request to a specific service account.
- Just‑in‑time approval – a documented step where a qualified person authorizes a high‑risk operation before it executes.
- Command‑level audit – a timestamped log of every statement or command issued, including the response status.
- Inline data masking – proof that card numbers, CVV, or other PAN data never left the target in clear text.
- Immutable session recording – a replayable capture that can be presented as evidence of what actually happened.
Collecting these artifacts from scattered tools is error‑prone and often incomplete. The missing piece is a single enforcement point that can observe, control, and record every non‑human request before it reaches the target system.
How hoop.dev provides the required enforcement layer
hoop.dev is a Layer 7 gateway that sits in the data path between any non‑human identity and the infrastructure it accesses – whether that is a PostgreSQL database, an SSH host, or a Kubernetes API. Because the gateway proxies the protocol itself, it can apply the controls that PCI DSS expects without requiring changes to the target service.
- Session recording – hoop.dev captures the full request and response stream for every connection, storing it in a log that auditors can review and replay.
- Inline masking – before a response leaves the target, hoop.dev can redact PAN fields according to a configurable pattern, ensuring that clear‑text card data never appears in downstream logs.
- Just‑in‑time approvals – for commands that match a high‑risk policy, hoop.dev pauses execution and routes the request to an approver. The approval decision is recorded alongside the session.
- Command blocking – dangerous statements (for example, DROP TABLE or privileged sudo commands) can be denied automatically, with the denial logged.
- Identity‑driven access – non‑human identities are provisioned via OIDC or SAML tokens. hoop.dev validates the token, extracts group membership, and decides whether the request may start. The actual enforcement – logging, masking, and approval – happens inside the gateway.
Because hoop.dev is the only component that sits on the data path, the audit evidence it produces is authoritative. Removing hoop.dev would eliminate the session recordings, the masking guarantees, and the approval workflow, leaving the underlying service without any of the PCI‑required artifacts.