When every function call is recorded, approved, and its sensitive output masked, you can demonstrate to auditors that no unauthorized code ever touched cardholder data and that each access is traceable to an individual identity.
PCI DSS requirements for function calling
PCI DSS expects three core controls around programmatic access. Requirement 10 mandates that all access to cardholder data be logged with user identification, timestamps, and the nature of the operation. Requirement 3 requires that stored cardholder data be protected, which includes masking or truncating data in transit. Requirement 7 limits access to the minimum privileges needed for a specific task. Together these controls create a verifiable chain of custody for every request that touches payment information.
In many modern stacks, function calls are issued by long‑lived service accounts or by AI agents that hold static credentials. The call travels directly to the target service, be it a database, an API, or a container, without an intervening checkpoint. When you omit the gateway, the platform fails to produce per‑call logs, cannot mask fields on the fly, and cannot pause execution for a manual review. Auditors therefore see only coarse‑grained metrics such as container uptime or aggregate API traffic, which fall short of PCI DSS evidence requirements.
The first step toward compliance is to create a non‑human identity and grant it just‑enough permissions for the specific function. This solves the least‑privilege problem, yet the request still reaches the target directly, so the audit, masking, and approval gaps remain.
hoop.dev acts as a Layer 7 gateway that sits between the identity provider and the function‑calling endpoint. The gateway validates the OIDC token, then inspects each request at the protocol level. It records the full session, applies inline masking to any field that matches a card‑number pattern, and can pause execution until a designated approver authorizes a risky operation.
Because the gateway resides in the data path, every interaction is recorded and retained as evidence. hoop.dev logs the authenticated user, the exact time of the call, the request payload, the masked response, and any approval identifiers. The masking step ensures that raw card numbers never appear in logs, satisfying the protection clause of Requirement 3 while still providing enough context for auditors.
hoop.dev covers Requirement 10.1 and 10.2 by identifying who performed the action and when it occurred. It satisfies Requirement 10.5 by logging both approved and blocked calls, because the real‑time decision engine records every access attempt. The gateway meets Requirement 3.2 by redacting sensitive fields before they are persisted. Finally, hoop.dev enforces Requirement 7 by granting only the minimal privilege to the non‑human identity and preventing any privilege escalation without detection.
The result is continuous, automated evidence that aligns with every relevant PCI DSS control. Teams no longer need to build custom logging pipelines or rely on manual log extraction after an audit. Instead, hoop.dev collects the evidence in real time, stores it in a secure location, and makes it instantly queryable when auditors request it.
How hoop.dev creates continuous evidence
When a function call originates, hoop.dev first validates the caller’s OIDC token, extracting the user’s group membership and any role attributes. The gateway then forwards the request to the target only after applying policy checks. hoop.dev records each step, authentication, policy evaluation, masking, approval, and execution, as a single session record. You can replay the record in a sandbox to reproduce the exact call, providing a clear audit trail for any investigation.
Inline masking happens before the response leaves the target, ensuring that raw card numbers never appear in storage or monitoring tools. Approval workflows are configurable; for example, a call that attempts to write a new credit‑card record can be routed to a compliance officer for manual sign‑off. If the officer declines, the gateway blocks the command and logs the denial, satisfying the “deny‑by‑default” posture expected by PCI DSS.
Frequently asked questions
- Does hoop.dev replace my existing identity provider? No. hoop.dev consumes OIDC or SAML tokens from your IdP and uses the identity information to enforce policies. The IdP remains the source of truth for who can request access.
- Can I use hoop.dev with existing function‑calling frameworks? Yes. The gateway works with standard clients such as HTTP libraries, gRPC, or any language‑specific SDK. No code changes are required; the client simply points to the gateway endpoint.
- How long are the audit logs retained? Retention is configurable in the deployment; the logs are stored outside the function runtime, allowing you to meet the minimum six‑month requirement of PCI DSS while keeping them immutable.
Ready to turn function calling into a PCI DSS‑ready audit surface? Explore the open‑source repository on GitHub, follow the getting‑started guide, and learn more about gateway features on the hoop.dev learn page or the hoop.dev product page.
