An off‑boarded contractor’s AI‑driven data‑pipeline continues to run nightly jobs that pull customer records from a production database. The team never sees which rows the pipeline accessed, what transformations the pipeline applied, or whether the pipeline exposed any personal identifiers. When the regulator asks for proof that the organization respects GDPR’s accountability and data‑minimisation obligations, the team replies with a vague statement that the pipeline uses a service account with limited permissions.
This scenario is common. Companies embed AI agents directly into their infrastructure stack, handing them static credentials that allow unfettered read‑write access to databases, message queues, or internal APIs. The agents operate behind the scenes, often without a human in the loop, and the surrounding tooling rarely captures a detailed record of each interaction. As a result, auditors lack the concrete artifacts required to demonstrate compliance with GDPR articles that demand transparent processing logs, purpose‑bound access, and the ability to audit every personal data transaction.
GDPR obliges data controllers to maintain a clear record of processing activities (Article 30), to implement data‑minimisation (Article 5), and to be able to provide evidence of who accessed what data and when (Article 32). In practice, this means an organization must be able to answer questions such as:
- Which AI agent initiated the query that returned a user’s email address?
- Did the system mask the data before it left the internal network?
- Did a human approve a high‑risk operation that could affect a data subject’s rights?
- Can the exact sequence of commands be replayed for a forensic review?
Most existing setups address only part of the problem. Rotating service‑account keys, applying role‑based access controls, or limiting network reachability are all valuable steps (the setup layer). They decide who may start a connection and what baseline permissions are granted. However, they do not provide a point where the traffic can be inspected, altered, or logged. The request still travels straight to the target database, and the system records at most a connection start‑time in a cloud‑provider audit log. The system does not capture any inline data masking, command‑level approval, or replayable session data.
Why the data path must host enforcement
The missing piece is an enforcement layer that sits on the actual data path. Only a gateway that intercepts the protocol stream can apply GDPR‑aligned controls in real time. This layer must be able to:
- Identify the caller via a federated token, tying every request to a human or service identity.
- Inspect each query or command before it reaches the backend.
- Apply masking policies to personal fields such as email, phone, or national‑identification numbers.
- Route high‑risk actions to an approval workflow, ensuring intentional processing.
- Record the full request‑response exchange for later replay.
When these capabilities reside in the data path, the organization gains the concrete evidence required by GDPR. hoop.dev produces the enforcement outcomes, session recording, inline masking, just‑in‑time approval, and identity‑bound logging, because the gateway sits between the AI agent and the infrastructure.
How hoop.dev provides the GDPR evidence layer
hoop.dev is a layer‑7 gateway that proxies connections from AI agents to supported targets such as PostgreSQL, MySQL, Kubernetes, SSH, and internal HTTP services. The gateway authenticates callers with OIDC or SAML, reads group membership, and then enforces policy on the traffic that passes through it. Because the gateway is the sole conduit, hoop.dev can: