Many assume that simply assigning a service account to a server satisfies PCI DSS, but the standard demands continuous evidence of who accessed what and when, even for machines. In reality, most on‑prem environments still rely on static passwords, shared SSH keys, or long‑lived API tokens for automation. Those credentials are often copied across servers, never rotated, and the actions they perform are invisible to auditors.
This lack of visibility creates two problems. First, the organization cannot prove that non‑human identities are limited to the functions required for payment‑card processing. Second, without a central point of control, any rogue command can run unchecked, and there is no reliable log that ties a specific service account to a specific database query or configuration change.
Why PCI DSS needs evidence for non‑human identities
PCI DSS requirement 7 calls for restricting access to cardholder data to only those individuals and systems that need it. Requirement 10 requires that all access to system components be logged, and that logs be retained for at least one year. Requirement 12 mandates that security policies be maintained and that they cover all users, including service accounts and automated processes.
When an organization treats a service account like a human user, the same evidence is required: a record that shows the identity, the time of access, the resource touched, and the outcome of the operation. Unfortunately, most traditional tooling captures only the human side of the equation. Service accounts often authenticate directly to the target system, bypassing any audit layer, and the resulting logs are either incomplete or stored in a location that is difficult for auditors to access.
What the audit artifact set must contain
- Identity‑bound session recordings – a replayable capture of every command issued by a service account, linked to the token that authenticated the request.
- Command‑level audit logs – structured entries that include the service account name, the exact query or command, the timestamp, and the success or failure status.
- Inline data masking logs – records that show which fields were redacted in responses, proving that sensitive cardholder data never left the protected boundary in clear text.
- Just‑in‑time (JIT) approval trails – when a high‑risk operation is requested, the system logs the approval request, the approver’s identity, and the decision outcome.
- Retention policy enforcement – guarantees that all of the above artifacts are kept for the PCI‑required retention period without manual intervention.
Each of these artifacts directly maps to a PCI DSS control. Together they form a complete evidence package that can be handed to an auditor without having to chase logs across multiple systems.
How hoop.dev delivers the required evidence
hoop.dev places a Layer 7 gateway in the data path between non‑human identities and the target infrastructure. Because every request flows through the gateway, hoop.dev can apply the enforcement outcomes needed for PCI DSS.
When a service account initiates a connection, hoop.dev validates the OIDC or SAML token, extracts the group membership, and then forwards the request to the target. While the traffic passes through the gateway, hoop.dev records the entire session, masks any cardholder fields in responses, and, if the command matches a high‑risk pattern, routes it to a human approver before execution. The gateway also writes a structured audit entry for every command, tying it to the original token.