A recently off‑boarded contractor still has a CI job that pushes logs containing personal data to a shared bucket. The team granted the service account broad write access during the project, and the job emitted fields without anyone questioning them. When the contractor left, the bucket remained writable, and the logs continued to flow unchecked.
Under Brazil’s General Data Protection Law (LGPD), organizations must document, limit purpose, and audit any processing of personal data. Regulators expect evidence that authorized identities perform every read, write, or transformation of structured output, such as JSON logs, CSV reports, or database query results, and protect sensitive fields where required.
What LGPD expects from structured output pipelines
LGPD defines several core obligations that directly impact automated data pipelines:
- Purpose limitation: Each processing activity must be tied to a clearly documented business purpose.
- Data minimisation: Only the data necessary for the purpose may be retained or transmitted.
- Accountability and auditability: Organisations must be able to demonstrate who accessed or transformed data, when, and under what authority.
- Security of processing: Sensitive fields (e.g., CPF numbers, health information) must be masked or encrypted in transit and at rest.
When pipelines are built with ad‑hoc credentials and direct connections to databases or storage services, meeting these obligations becomes a guessing game. The engineering team knows the intent, but the system does not capture the evidence required for an LGPD audit.
Why a pure‑setup approach falls short
Most teams start by tightening the setup layer: they provision service accounts with narrowly scoped IAM policies, they federate identities through OIDC, and they enforce least‑privilege roles for CI jobs. This reduces the blast radius of a compromised credential, but it does not create a visible control point where LGPD‑required checks can be enforced.
In the scenario above, the service account can still write any field to the bucket because the request reaches the storage endpoint directly. No component in the data path records the exact fields that the job writes, masks the CPF numbers, or requires a human approval before a new schema is introduced. The pipeline therefore satisfies the setup requirement, only an authorised service account is used, but it fails to provide the audit trail, inline masking, and just‑in‑time approval that LGPD mandates.
Embedding compliance in the data path with hoop.dev
hoop.dev acts as a Layer 7 gateway that sits between identities and the infrastructure they access. By placing hoop.dev in the data path, every structured‑output operation passes through a single, policy‑driven control surface.
When a request arrives, hoop.dev first validates the OIDC token, confirming the caller’s identity and group membership. It then applies LGPD‑specific policies that can:
- Record the full session, including the exact query or API call that produced the output.
- Mask configured sensitive fields (such as CPF, email, or health codes) before the data leaves the gateway.
- Require a just‑in‑time approval workflow for schema changes or bulk exports that exceed a predefined threshold.
- Block commands that attempt to write prohibited columns or delete records without explicit consent.
Because hoop.dev is the only component that can inspect and transform the payload, the enforcement outcomes, audit logs, inline masking, approval gating, and command blocking, exist solely because hoop.dev occupies the data path. Removing hoop.dev would instantly eliminate those controls, proving that the gateway is the decisive enforcement mechanism.
How the architecture maps to LGPD requirements
Purpose limitation. Approval workflows in hoop.dev tie to business‑level policies. A data‑engineer can request a bulk export, and the data‑privacy officer approves the request before the gateway forwards the query. The approval record joins the audit trail, demonstrating that the export served a documented purpose.
Data minimisation. Inline masking rules define per‑field protection. When a downstream system requests a record, hoop.dev strips or redacts any column flagged as sensitive. The downstream consumer never sees the raw value, satisfying minimisation without requiring application‑level changes.
Accountability and auditability. hoop.dev records every session in a log store. Each log entry includes the caller’s identity, the exact request payload, and the response after masking. Auditors can replay a session to verify that only authorised data was accessed and that the masking rules applied correctly.
Security of processing. Because the gateway holds the credential to the target system, the calling identity never sees the secret. This “credential‑shadowing” pattern reduces the risk of credential leakage and ensures that all data‑in‑flight passes through a controlled, encrypted channel.
Getting started
Implementing LGPD‑compliant controls begins with the standard hoop.dev deployment. The getting‑started guide walks you through deploying the gateway with Docker Compose or Kubernetes, configuring OIDC authentication, and registering a connection to your database or storage service. Once the gateway is live, you can define masking policies and approval workflows in the learn section, which provides concrete examples for common data‑privacy scenarios.
FAQ
Does hoop.dev replace existing IAM policies?
No. IAM policies still define who may obtain a token and what roles they have. hoop.dev complements those policies by enforcing LGPD controls at the point where data actually moves.
Can I audit historical data that was written before hoop.dev was installed?
hoop.dev records only activity that passes through the gateway. To bring legacy data under audit, you must migrate the ingestion pipelines to route through hoop.dev.
Is masking reversible?
Masking applies as a one‑way transformation defined in the policy. If the original value is required for a legitimate purpose, an authorized user can request a privileged query that bypasses the mask, and that request records and receives approval in the same way.
Next steps
Explore the open‑source repository on GitHub: https://github.com/hoophq/hoop. The codebase includes the full set of features described here, along with deployment scripts and policy examples that help you meet LGPD evidence requirements without reinventing the wheel.
