How can you prove that every internal tool access complies with LGPD without drowning in spreadsheets?
Why LGPD demands continuous evidence
Brazil’s General Data Protection Law requires organizations to process personal data only with authorized actors, to log every access, and to detect any leakage in near‑real time. Auditors look for immutable records that show who accessed what, when, and under what justification. The law also expects organizations to filter any data returned to a user according to consent and purpose, and to demonstrate that they applied filtering consistently.
What a typical setup looks like today
Most teams store static credentials or service‑account tokens in configuration files, CI pipelines, or shared vaults, then give them to developers. Developers then use those secrets directly against databases, SSH hosts, or internal HTTP APIs. The identity provider decides who may obtain a token, but once the token is handed to a tool there is no further gate. The request travels straight to the target, and the target logs only the end‑user identity – if it logs at all. In practice, teams end up piecing together log files, manual approvals, and ad‑hoc scripts to convince auditors that LGPD controls exist.
How hoop.dev generates LGPD evidence
hoop.dev sits in the data path between the identity provider and the infrastructure target. The gateway receives an OIDC or SAML token, validates it, and then proxies the connection to the actual resource. Because every packet passes through hoop.dev, the gateway enforces three categories of controls that directly satisfy LGPD evidence requirements.
- Session recording. hoop.dev records each interaction – query, command, or response – and stores it in an audit log that retains the full session for later review. The record includes the user’s identity, the time, the target resource, and the exact data exchanged. Auditors can replay a session to verify that only authorized fields were accessed.
- Inline data masking. Before a response leaves the target, hoop.dev redacts or transforms personal fields according to policy. The masking decision logs alongside the original payload, proving that consent rules were enforced at the point of delivery.
- Just‑in‑time approval and command blocking. hoop.dev pauses high‑risk operations and routes them to a human approver. If the approver denies the request, hoop.dev blocks it and logs the denial, giving concrete evidence of risk mitigation.
The gateway creates all of these outcomes because it is the sole enforcement point. The initial authentication step – the setup – determines who may start a session, but it does not guarantee that the session complies with LGPD. hoop.dev applies the law‑required controls at the data path.
Mapping LGPD controls to hoop.dev capabilities
LGPD Art. 6.1 requires processing to be lawful, fair, and transparent. hoop.dev’s logging makes processing transparent to auditors. Art. 7.2 mandates purpose limitation; inline masking enforces that the system returns only purpose‑aligned fields. Art. 9.2 demands that organizations protect special‑category data; hoop.dev can mask or block such fields automatically.
Because the gateway records every request, organizations can generate the continuous evidence that regulators expect, rather than assembling point‑in‑time snapshots after the fact.
Getting started with hoop.dev for LGPD evidence
Deploy the gateway using the official getting started guide. Configure your identity provider (Okta, Azure AD, Google Workspace, etc.) so that hoop.dev can verify OIDC tokens. Register each internal tool – a PostgreSQL database, an SSH host, an internal HTTP API – as a connection in the dashboard. Define masking policies for personal columns, set up approval workflows for risky commands, and enable session recording. The documentation on feature details walks you through policy creation without exposing any code snippets.
FAQ
- Does hoop.dev replace my existing secrets manager? No. hoop.dev still relies on a secret store for the target credentials, but it never hands those credentials to end users. The gateway presents a short‑lived, internal credential to the target on behalf of the user.
- Can I audit historical sessions that occurred before hoop.dev was deployed? hoop.dev can only record sessions that pass through it. For legacy data you will need to import logs from your existing systems, but future compliance will be continuous.
- Is hoop.dev itself LGPD‑certified? hoop.dev does not claim certification. It simply generates the evidence that helps your organization meet LGPD obligations.
Ready to see how continuous audit evidence can simplify your LGPD program? Explore the open‑source repository and start building a compliant data path today.
