Continuous, auditable evidence of data handling is the cornerstone of GDPR compliance for any AI‑driven workflow. When a single request is split across multiple micro‑services, AI agents, and human reviewers, each step touches personal data, yet organizations often lack a unified, tamper‑proof trail that proves who accessed what, for which purpose, and when.
Why continuous evidence matters for GDPR
GDPR obliges data controllers to demonstrate accountability. That means retaining records that show lawful basis, purpose limitation, data minimisation, and the ability to respond to subject‑access requests. In a decomposed task, the data may travel through a database query, a message queue, an LLM inference, and a downstream API. If each component logs locally, the logs are siloed, inconsistent, and vulnerable to tampering. Auditors then see gaps, and regulators can deem the organisation non‑compliant.
Beyond the legal requirement, continuous evidence helps engineers spot unexpected data flows, enforce masking policies, and quickly revoke access when a breach is suspected. The evidence must be collected at the point where the data actually moves – the network boundary that connects identities to the target resource.
The missing piece: a data‑path gateway
Identity providers (Okta, Azure AD, Google Workspace, etc.) can verify who a user or service account is, and they can convey group membership via OIDC or SAML tokens. That setup decides *who* may start a connection, but it does not enforce *what* the connection may do once it reaches the target. Without a gateway that sits in the data path, there is no place to apply real‑time masking, command‑level approval, or session recording.
For task decomposition, the ideal gateway must:
- Inspect each protocol transaction (SQL, HTTP, SSH, etc.) at Layer 7.
- Mask personal identifiers in responses before they leave the target.
- Require just‑in‑time approval for risky operations such as bulk data export.
- Record the entire session for replay and audit.
- Retain the evidence in a location that is independent of the target resource.
Only when these controls sit on the data path can an organisation claim continuous GDPR evidence.
How hoop.dev provides the required evidence
hoop.dev is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH endpoints, and internal HTTP services. It sits between the verified identity and the target, so every request and response passes through it.
Because hoop.dev is the data‑path component, it can:
- Record each session. Every command, query, or API call is logged with timestamp, user identifier, and outcome, creating a reliable audit trail.
- Mask sensitive fields in real time. When a response contains personal data such as email addresses or social security numbers, hoop.dev can replace those values with placeholders before they reach the client, satisfying data‑minimisation.
- Enforce just‑in‑time approvals. High‑risk operations trigger a workflow that requires a designated approver to consent before the command is executed.
- Scope access to the minimum required. The gateway can limit a session to a specific database schema or Kubernetes namespace, ensuring purpose limitation.
All of these outcomes are produced by hoop.dev alone; the underlying identity system merely tells hoop.dev who is making the request. If the gateway were removed, none of the masking, approval, or recording would occur, leaving the organization without the continuous evidence required by GDPR.
Implementing hoop.dev starts with a simple Docker Compose deployment or a Kubernetes manifest, as described in the getting‑started guide. Once the gateway is running, you register each target resource – a PostgreSQL instance, a Kubernetes cluster, an SSH host – and configure the credential that hoop.dev will use. Users then connect through hoop.dev with their usual client tools; the gateway transparently applies the controls described above.
Putting it together for task‑decomposed workflows
Consider a workflow where an AI assistant extracts customer data from a PostgreSQL database, enriches it via an external API, and writes a summary back to a different table. The steps are:
- Engineer authenticates via OIDC; the token is presented to hoop.dev.
- hoop.dev validates the token and checks group membership.
- When the engineer issues the SELECT, hoop.dev records the query, masks any personal columns in the result set, and stores the session log.
- The enrichment call is routed through hoop.dev as an HTTP proxy; any personal identifiers in the payload are masked before leaving the internal network.
- Before the INSERT, hoop.dev triggers an approval workflow; a data‑owner must consent to writing back the summary.
- All actions are logged, providing a complete, replayable evidence chain that satisfies GDPR’s accountability requirement.
This end‑to‑end view shows that the only component that can guarantee continuous evidence is the gateway that sits in the data path – hoop.dev.
Learn more about hoop.dev
For deeper coverage of masking policies, approval workflows, and session replay, explore the feature documentation. An overview of all supported connectors is available on the hoop.dev product page.
FAQ
Does hoop.dev replace my existing identity provider?
No. hoop.dev consumes OIDC or SAML tokens from your IdP. The IdP decides who may start a session; hoop.dev decides what that session can do and records what it does.
Can I use hoop.dev with existing CI/CD pipelines?
Yes. Because hoop.dev works with standard client protocols, you can point your pipeline tools (psql, kubectl, git) at the gateway without code changes. The gateway will still apply masking and logging.
How long are the session logs retained?
The retention policy is configurable in the deployment. For GDPR you typically keep logs for the period required by your data‑retention schedule, and hoop.dev stores them outside the target resource to prevent accidental loss.
By placing a Layer 7 gateway in the data path, organisations can generate the continuous, auditable evidence that GDPR demands for task‑decomposed workflows. Explore the open‑source repository on GitHub to start building a compliant data‑handling pipeline today.
