When every machine‑to‑machine request is fully traceable, approved, and automatically redacts any personal data it returns, GDPR auditors see a clear, tamper‑evident audit trail. That end state satisfies the regulation’s accountability and data‑protection principles without requiring manual log stitching or after‑the‑fact justification.
What GDPR expects for machine identities
GDPR treats any processing of personal data, whether performed by a human or a service‑account‑driven automation as a data‑processing activity that must be documented. Articles 30 and 32 require controllers to maintain records of processing, demonstrate purpose limitation, and apply technical safeguards such as pseudonymisation, encryption, and access control. For non‑human identities, the regulator looks for:
- Per‑request justification that a specific automation needed the data.
- Evidence that a data‑owner authorized the request.
- Logs that show which service accessed which records, when, and what was returned.
- Guarantees that any personal fields returned to a downstream system are filtered or masked unless explicitly allowed.
Why traditional approaches fall short
Most organizations provision service accounts with long‑lived credentials and blanket permissions. Those accounts often connect directly to databases, APIs, or Kubernetes clusters. The typical stack provides static secrets stored in configuration files or secret managers, network‑level firewalls that limit where a service can connect but not what it can do once connected, optional application‑level logging that runs on the same host as the service, and no inline data‑redaction, so any personal field returned by a query can flow to downstream systems unchecked.
Because enforcement lives inside the service process, auditors cannot prove that a particular request received approval, that sensitive fields were masked, or that the session was recorded in an immutable store. The gap between identity provisioning (the “setup”) and actual enforcement (the “data path”) is where GDPR compliance breaks.
How hoop.dev creates audit evidence for GDPR
hoop.dev places a Layer 7 gateway between the non‑human identity and the target resource. The gateway is the only point where traffic can be inspected, approved, masked, or recorded. This architecture satisfies the three categories required by the compliance‑explainer rules:
- Setup: Identity providers such as Azure AD issue OIDC tokens for service accounts. hoop.dev validates those tokens and decides whether a request may start.
- Data path: The gateway itself serves as the data path. No traffic reaches the database, Kubernetes API, or SSH daemon without passing through hoop.dev.
- Enforcement outcomes: hoop.dev records every session, masks configured personal fields in responses, requires just‑in‑time human approval for high‑risk commands, and stores the audit trail for later review.
Because hoop.dev enforces policies in the gateway, the evidence it generates remains independent of the service’s own logging. Auditors can query the hoop.dev audit store to see exactly which service account ran which command, the time of execution, the approval chain, and the redacted result that left the gateway.
Key enforcement outcomes that map to GDPR articles
- Session recording: hoop.dev captures each request from start to finish, providing the “record of processing” required by Article 30.
- Just‑in‑time approval: A data‑owner signs off high‑impact operations before they execute, satisfying purpose‑limitation and accountability.
- Inline data masking: Configurable field‑level redaction removes personal identifiers from responses before they reach downstream services, meeting the pseudonymisation requirement of Article 32.
- Access scoping: hoop.dev grants permissions per‑request, reducing the blast radius of a compromised credential.
Getting started with hoop.dev on Azure
Deploy the gateway using the official getting‑started guide. The quick‑start runs Docker Compose locally, and you can run production deployments in Azure Kubernetes Service. Register each Azure‑hosted resource (Azure Database for PostgreSQL, Azure Kubernetes clusters, etc.) as a connection, and configure the gateway to hold the service‑account credentials. Once the gateway runs, any non‑human identity authenticates via Azure AD, receives an OIDC token, and then talks to the target through hoop.dev. The feature documentation details how to define masking rules, approval policies, and audit‑store configuration.
FAQ
Does hoop.dev replace my existing Azure RBAC?
No. Azure RBAC decides which service account can request a session; hoop.dev enforces per‑request policies, records the session, and applies masking.
How does hoop.dev help with GDPR’s right‑to‑access requests?
Because hoop.dev stores every session with the exact query and redacted response, you can retrieve the precise data that was processed for a given service account, satisfying the regulator’s transparency requirement.
Can hoop.dev work with existing service‑account credentials?
Yes. The gateway stores the credential and never exposes it to the caller. You can import existing secrets without code changes, and hoop.dev will begin enforcing the GDPR‑aligned controls immediately.
For the full source code, contribution guidelines, and issue tracker, visit the hoop.dev repository on GitHub.
