A CI pipeline that pushes nightly data extracts into a reporting database runs under a service account whose password lives in a shared vault. When the contract with a third‑party analytics vendor ends, the vault entry is simply deleted, but the credential remains cached on the build server for weeks. The same pattern appears when an off‑boarded contractor’s SSH key is left in a bastion host, allowing lingering read‑only queries against production PostgreSQL tables that contain personal identifiers.
From a gdpr perspective, those lingering machine identities create a blind spot. Personal data can be returned to a script, logged, or accidentally re‑exported without any human review. Regulators expect organizations to demonstrate that every access to personal data is justified, limited, and recorded. When machines act as the primary actors, the audit trail often evaporates because the connection bypasses any central enforcement point.
Organizations have begun to replace static passwords with OIDC‑backed service accounts and to assign the minimum set of database roles required for a job. The identity provider now knows which CI job is making the request, and the database enforces row‑level permissions. However, the request still travels directly from the build agent to PostgreSQL. No gateway sits in the data path to inspect the query, mask returned identifiers, or require an approval before a bulk export. Consequently, the system still lacks the continuous evidence that gdpr auditors demand.
Why a data‑path gateway is required for gdpr evidence
gdpr’s accountability principle obliges controllers to be able to prove that personal data is processed lawfully. Proof is not a one‑time snapshot; it must be generated for every access event. A gateway that sits between the non‑human identity and the database can enforce three essential controls:
- Session recording. Each query and its result set are captured, creating a log that records which service account accessed which rows.
- Inline data masking. When a query returns columns that contain personal identifiers, the gateway can replace those values with pseudonyms or redacted placeholders before they reach the machine.
- Just‑in‑time approval. For high‑risk operations, such as exporting an entire table, the gateway can pause the request and route it to a human reviewer for explicit consent.
Because these controls live in the data path, they cannot be bypassed by re‑configuring the identity provider or by granting broader roles in PostgreSQL. The enforcement point is the only place where the traffic is observable.
hoop.dev as the gdpr‑focused data‑path gateway
hoop.dev is an open‑source Layer 7 gateway that proxies PostgreSQL connections. When a machine presents an OIDC token, hoop.dev validates the token, extracts the service‑account identity, and then forwards the request to the database using credentials that the gateway alone stores. The gateway becomes the sole authority that can apply masking, approvals, and recording.
In practice, hoop.dev records each session, masks personal fields in query results, and can require a human to approve bulk exports. Those outcomes are generated **by hoop.dev**; the underlying identity system or the PostgreSQL instance does not provide them on its own. The continuous stream of logs, approvals, and masked responses forms the evidence base that gdpr auditors look for when they ask for:
- Proof of purpose limitation – the gateway logs the reason attached to each request.
- Data minimisation – masked responses demonstrate that only necessary fields are exposed.
- Accountability – the session record links the service account, the user who triggered the CI job, and the exact data accessed.
Integrating non‑human identities with hoop.dev
To adopt this model, teams first configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) and create service accounts that represent CI jobs, bots, or third‑party services. Those accounts receive narrowly scoped PostgreSQL roles. hoop.dev is then deployed with its agent colocated on the same network segment as the PostgreSQL instance. The agent handles the low‑level TCP connection, while the gateway enforces the gdpr‑related controls.
Because the gateway holds the database credentials, the database secret stays inside the gateway and is never exposed to the calling process. The only secret the machine presents is the OIDC token, which the gateway validates on each request. This separation eliminates credential sprawl and ensures that every data access passes through the same enforcement point.
Continuous evidence accrual for gdpr
gdpr audits often stumble over point‑in‑time evidence. hoop.dev solves that by generating logs for every interaction, not just when a regulator knocks on the door. The logs are written in a structured format that can be streamed to a SIEM, fed into a data‑retention pipeline, or archived for the statutory period required by gdpr. Because the gateway applies masking in real time, the stored logs contain only the masked view, protecting personal data while still proving that the request occurred.
When a data‑subject request arrives, the organization can query the hoop.dev audit store to retrieve the exact session that accessed the subject’s record, demonstrate that the data was masked according to policy, and show any human approvals that were required. This end‑to‑end traceability satisfies the gdpr principle of demonstrable compliance.
Getting started
Deploying hoop.dev is straightforward. The quick‑start guide walks you through a Docker Compose deployment that includes OIDC authentication, masking rules, and guardrails out of the box. For production environments, the documentation covers Kubernetes and AWS deployment patterns, as well as how to place the agent next to your PostgreSQL cluster.
All of the configuration details, such as defining which columns are considered personal data, are described in the learn section. The getting‑started guide shows how to register a PostgreSQL target, bind it to a service account, and enable the gdpr‑focused controls.
FAQ
Do I need to modify my existing CI pipelines?No. The pipelines continue to invoke psql (or your preferred client), but the connection string points to the hoop.dev gateway instead of the raw PostgreSQL host.How does hoop.dev help with data‑subject access requests?Because every session is recorded, you can retrieve the exact query that accessed a subject’s row, see the masked result that was returned, and provide that as evidence of compliance. The audit trail also shows any human approvals that were required for the request.Can I keep using my existing PostgreSQL roles?Yes. hoop.dev works with the roles you already assign to service accounts. The gateway does not replace PostgreSQL’s native RBAC; it augments it with gdpr‑specific controls that sit in the data path.
Ready to see how continuous audit evidence can become a core part of your gdpr program? Explore the open‑source repository on GitHub and start building a compliant machine‑access layer today.
