An offboarded contractor’s CI job still holds a static service‑account token that can query a production PostgreSQL instance. The token never expires, the job runs nightly, and nobody reviews the exact rows it returns. When a data‑subject request arrives under Brazil’s LGPD, the organization cannot prove who accessed the personal data, whether it was filtered, or if the access complied with the purpose‑limitation principle.
LGPD requires data controllers to demonstrate accountability, data minimization, and the ability to audit every access to personal information. The regulation expects:
- Precise logs that tie each read or write operation to a specific identity and timestamp.
- Mechanisms that prevent unnecessary exposure of personal fields, such as masking or redaction.
- Just‑in‑time approvals for operations that could affect data subjects.
- Evidence that can be presented to auditors or regulators without alteration.
Tool‑using agents, CI pipelines, deployment bots, automated backup scripts, are the most common source of hidden data access. They typically run under long‑lived service accounts, store credentials in plain‑text files, and connect directly to the target system. The result is a blind spot: the agent can read or modify rows without any per‑request audit, without any data‑masking, and without a human review step.
Why the existing setup falls short
The current model satisfies the authentication part of LGPD: an OIDC token or IAM role proves the agent is allowed to start a session. It does not satisfy the enforcement part. Because the request reaches the database or API directly, the following gaps remain:
- No record of which query was executed, which columns were returned, or which data subject was involved.
- No inline transformation that could hide identifiers such as CPF, email, or phone number.
- No workflow that asks a data‑privacy officer to approve a bulk export or a destructive command.
- No session recording for forensic analysis after a breach.
Those gaps mean an organization cannot produce the evidence LGPD demands, even though the identity system correctly restricts who may start a job.
hoop.dev as the data‑path enforcement layer
hoop.dev solves the problem by inserting a Layer 7 gateway between the agent and the target resource. The gateway acts as an identity‑aware proxy: it validates the agent’s OIDC token, extracts group membership, and then forwards the traffic to the backend only after applying policy checks.
Because hoop.dev sits in the data path, every command passes through its guardrails. The platform can:
- Log each request with the agent’s identity, timestamp, and the exact SQL statement or API call.
- Mask configured personal fields in real time, ensuring that downstream systems never see raw identifiers.
- Pause a request that matches a high‑risk pattern and route it to a human approver before execution.
- Record the entire session, including responses, for later replay and audit.
hoop.dev creates those outcomes. If you use the same OIDC setup without the gateway, the system does not generate logs, masks, approvals, or recordings.
Generating LGPD‑ready evidence
LGPD auditors look for logs that demonstrate who accessed what, when, and why. hoop.dev produces a structured audit trail that includes:
- Identity of the tool‑using agent (derived from the verified token).
- Exact operation details, such as the SQL query text or HTTP method.
- Outcome of any inline masking, recorded as “masked field X from response”.
- Approval timestamps when a human reviewer intervenes.
- Session replay files that let you reconstruct the interaction.
You can forward these artifacts to your existing logging pipeline or SIEM for retention. Because hoop.dev writes the logs at the gateway, downstream systems cannot alter the data, satisfying LGPD’s integrity requirement.
Data minimization and breach response
By masking personal identifiers before they leave the gateway, hoop.dev enforces the data‑minimization principle. Even if an agent is compromised, the attacker only sees already‑redacted data, reducing the blast radius of a breach.
When a breach is suspected, the recorded sessions give investigators a precise timeline of what the agent did, what rows were accessed, and whether any masked fields were later re‑identified. This forensic capability shortens incident‑response cycles and helps meet LGPD’s breach‑notification deadlines.
Getting started with hoop.dev
Deploy the gateway using the getting‑started guide. Register your CI runners, bots, or other automated agents as connections, define masking rules for personal fields, and enable just‑in‑time approval for bulk exports. The learn section provides deeper examples of policy configuration and audit‑log integration.
FAQ
Can hoop.dev be added to an existing CI pipeline without rewriting the jobs?
Yes. hoop.dev works as a transparent proxy. You point the pipeline’s database or API client to the gateway address, and the existing job continues to run while hoop.dev enforces LGPD policies.
How does hoop.dev ensure that personal data is masked consistently?
You define masking rules at the gateway level. When a response contains a configured column, hoop.dev replaces the value with a placeholder before forwarding it. The masking action appears in the audit trail, so auditors can verify that the rule was applied on each request.
What audit artifacts does hoop.dev produce for an LGPD audit?
hoop.dev emits logs that capture identity, operation details, masking actions, approval steps, and a full session replay. You can stream these logs to any log‑management system, and they serve as the evidence required by LGPD.
Explore the source code and contribute to the project on GitHub.
