GDPR for non-human identities: governing machine access end to end (on GCP)

Many assume that GDPR only applies to personal data held by humans, and that service accounts are invisible to the regulation. In reality, GDPR treats any data that can be linked to an identified or identifiable natural person as in scope, even when automated jobs, CI pipelines, or AI agents process that data.

GDPR requirements for non‑human identities

Regulators expect organizations to demonstrate three things when personal data is touched by machines: (1) who initiated the processing, (2) what data was accessed or transformed, and (3) how the operation complied with purpose limitation, data minimisation, and security safeguards. Articles 5, 30 and 32 of the regulation turn these expectations into concrete record‑keeping duties. For a typical GCP workload, teams store the raw facts in three places: IAM policies that grant a service account access, audit logs emitted by the cloud platform, and any application‑level logs that developers choose to write.

The unguarded reality of machine‑to‑machine access

In many teams, developers check a service account key into a repository, a CI job pulls the key and talks directly to Cloud SQL, BigQuery, or a Kubernetes API server. The key remains static, shared across pipelines, and the connection bypasses any runtime gatekeeper. Engineers can see the credential, but the cloud audit log only records that "service‑account‑xyz" made a request – it does not capture which pipeline step issued the command, whether the query contained personal identifiers, or whether a human approved a risky operation. The result is a compliance blind spot: auditors receive a list of service accounts but no evidence of the precise data flows that GDPR demands.

Adding a runtime enforcement layer

Introducing OIDC‑federated identities and least‑privilege scopes reduces the blast radius, but the request still reaches the target directly. The cloud platform does not see a request‑level approval workflow, nor does it mask returned rows that contain personal identifiers. Without a central data‑path proxy, the organization cannot prove that each access was authorised, recorded, and, when necessary, scrubbed.

hoop.dev as the GDPR‑focused data‑path gateway

hoop.dev sits in the data path between every non‑human identity and the GCP resources it talks to. Because hoop.dev inspects the wire‑level protocol, it enforces the following GDPR‑relevant controls:

• hoop.dev records every session with the exact identity, timestamp, command, and response payload.
• hoop.dev masks fields that match a personal‑data pattern before they leave the target, ensuring that downstream systems never see raw identifiers.
• hoop.dev requires a human approver for queries that exceed a risk threshold, creating a documented approval record.
• hoop.dev blocks commands that attempt to export entire tables or delete rows without explicit justification.

hoop.dev produces each of these outcomes, not the underlying IAM configuration. If you remove the OIDC token, the enforcement disappears, proving that hoop.dev is the source of the audit evidence.

How hoop.dev satisfies specific GDPR articles

Article 5 – data minimisation and purpose limitation. By configuring inline masking rules, hoop.dev ensures that only the fields required for a given job are returned. The gateway also rejects requests that ask for data outside the declared purpose, and the gateway logs the rejection.

Article 30 – records of processing activities. hoop.dev automatically generates a processing log that includes the service account, the OIDC user (if any), the exact query, and the outcome. You can export this log to a SIEM or a compliance data lake, giving auditors a ready‑to‑use record.

Article 32 – security of processing. The gateway enforces just‑in‑time access, so credentials never leave the agent that runs inside the private network. Because hoop.dev never exposes the underlying secret to the caller, hoop.dev eliminates credential leakage risk.

Deploying on GCP

Teams start by deploying the hoop.dev gateway in a VPC that has network‑level reach to Cloud SQL, BigQuery, GKE, and any other target. The deployment can be done with Docker Compose for a quick test or with a Helm chart for production clusters. Teams source identity from an OIDC provider – for example, Google Workspace or an external IdP – and the gateway validates the token before granting any downstream connection. The gateway stores the actual GCP service‑account key, so downstream workloads never see it.

For step‑by‑step guidance, see the getting‑started guide. The broader feature set, including masking patterns and approval workflows, is documented in the learn section.

What auditors receive

When an audit request arrives, the compliance team pulls the hoop.dev session archive. The archive provides:

1. A chronological list of every machine‑initiated request, tied to a human‑owned OIDC identity.
2. Evidence that personal data was masked according to the organisation’s data‑classification policy.
3. Signed approval records for any high‑risk operation, showing who granted permission and when.

These artifacts directly answer the regulator’s “show us how you control and record personal data processing” question, turning a vague set of service‑account logs into a concrete, auditable trail.

FAQ

Does hoop.dev replace existing IAM policies? No. hoop.dev complements IAM by adding runtime governance. IAM still defines who may obtain a token; hoop.dev decides what that token can actually do at the protocol level.

How are the session logs protected? hoop.dev writes logs to a storage backend that you can configure for immutability and encryption, as described in the documentation. The gateway never stores raw credentials, so even a compromised instance cannot reveal secrets.

Can hoop.dev automatically detect personal data in responses? Yes. By defining field‑level patterns or using schema hints, hoop.dev masks or redacts values that match GDPR‑defined personal data categories before they leave the target.

Explore the open‑source repository to see how the gateway is built and contribute improvements: https://github.com/hoophq/hoop.