An offboarded contractor still has a lingering SSH key on a production server, and a nightly CI job runs with a service account that can read every employee file. When a data‑subject request arrives, the security team scrambles to prove who accessed the personal data and whether any unauthorized copy was made. The Brazilian General Data Protection Law (lgpd) expects organizations to demonstrate precise control over who can use a computer to process personal data, to keep reliable records of every access, and to limit exposure of sensitive fields.
Most teams start by centralising identity in an IdP and granting the smallest set of permissions possible. That step eliminates shared passwords, but the request still travels straight to the target host. The gateway that sits between the user and the server is missing, so there is no real‑time enforcement, no automatic redaction of personal identifiers, and no guaranteed audit record that survives a breach of the host itself.
Why lgpd demands a data‑path control layer
lgpd’s accountability principle requires evidence that access decisions were made according to policy. Evidence must include:
- Who initiated the session, with a verifiable identity.
- When the session started and ended.
- What commands or queries were executed.
- Any data that left the system, especially personal identifiers.
These items are only trustworthy if they are captured outside the process that the user controls. A logging agent that runs on the same host can be tampered with, and plain‑text logs do not satisfy the purpose‑limitation rule because they expose the very data they are meant to protect.
Introducing hoop.dev as the enforcement point
hoop.dev sits in the data path between the authenticated identity and the target computer resource. Because the gateway inspects traffic at the protocol level, it can enforce lgpd‑required controls without the user ever seeing the underlying credentials. hoop.dev records each session, timestamps every command, and stores the logs in a location that is separate from the target host. When a query returns a column that contains a personal identifier, hoop.dev can mask that column in real time, ensuring that downstream viewers only see redacted data.
In addition to masking, hoop.dev can require a human approver before a high‑risk operation proceeds. The approval workflow is tied to the user’s identity, so the audit log shows not only the request but also the explicit consent from an authorized reviewer. This satisfies lgpd’s requirement for purpose‑based justification of data processing.
Because hoop.dev is an open‑source layer‑7 gateway, the same enforcement logic can be applied to databases, SSH sessions, RDP connections, and internal HTTP services. The policy engine lives in the gateway, guaranteeing that every computer‑use event is observed, controlled, and recorded consistently across the entire infrastructure.
How the evidence fits an lgpd audit
During an audit, the compliance team can extract session recordings from hoop.dev’s audit store. Each record includes the user’s identity token, the exact command string, timestamps, and any masking actions that were applied. The logs are retained and can be exported in a format that matches lgpd’s documentation requirements. Because the gateway never exposes raw credentials to the user, the risk of credential leakage is eliminated, further supporting the security of personal data.
For organizations that already use OIDC or SAML for authentication, hoop.dev acts as a relying party. It validates the token, extracts group membership, and maps that to fine‑grained access policies. The setup step, defining who may connect, what resources they may reach, and for how long, covers the “setup” category. The actual enforcement, masking, approval, recording, happens exclusively in the data path, which is the only place lgpd‑required outcomes can be guaranteed.
Getting started
To begin generating lgpd‑compatible evidence, deploy hoop.dev using the getting started guide. The documentation walks through registering a target computer, configuring OIDC authentication, and defining masking rules for personal identifiers. Detailed policy examples are available in the learn section, where you can see how to express “mask email addresses” or “require manager approval for bulk exports.”
FAQ
Does hoop.dev replace existing logging agents?
No. hoop.dev complements existing agents by moving the audit and enforcement plane out of the target host. It provides a single source of truth for lgpd evidence, while traditional agents can continue to collect host‑level metrics.
Can I use hoop.dev with on‑premise databases that are not cloud‑hosted?
Yes. hoop.dev proxies any supported database protocol, whether the server runs in a data centre, a private cloud, or a hybrid environment. The gateway sits in the network segment that can reach the database, so the same masking and approval policies apply.
What happens if a user tries to bypass hoop.dev?
Because hoop.dev holds the credentials needed to reach the target, users cannot connect directly without those secrets. The gateway is the only path that possesses the valid credential, so any attempt to bypass it fails at the authentication step.
Start building lgpd‑ready computer‑use controls today by contributing or trying the project on GitHub: https://github.com/hoophq/hoop.
