The challenge of LGPD compliance in practice
When a Brazilian e‑commerce team off‑boards a freelance developer, they discover that the contractor’s SSH key still appears in the CI pipeline that touches customer purchase records. The key grants unrestricted access to the PostgreSQL instance that stores names, addresses, and payment identifiers. Because the team has no reliable record of which queries were run, they cannot answer a data‑subject request under the Lei Geral de Proteção de Dados (lgpd) within the mandated 15‑day window.
LGPD obliges data controllers to demonstrate accountability for every operation that touches personal data. Auditors expect immutable logs that show who accessed which record, when, and under what purpose. The regulation also requires that sensitive fields be protected by masking or encryption whenever they are displayed to downstream systems. Finally, the law mandates that any privileged access be granted on a just‑in‑time basis and that each approval be traceable.
Providing those guarantees starts with a solid identity foundation: OIDC or SAML tokens, least‑privilege roles, and a clear provisioning workflow. However, identity alone does not record what the user actually does once the connection reaches the database. The enforcement point must sit on the data path so that every command can be inspected, masked, approved, or denied before it reaches the target system.
hoop.dev as the enforcement layer
hoop.dev fills that gap by acting as a layer‑7 gateway between the authenticated identity and the infrastructure resource. Because the traffic flows through hoop.dev, it can record each session, attach the user’s identifier to every query, and store an immutable audit log. It also applies inline masking to personally identifiable fields, blocks commands that violate policy, and routes high‑risk operations to an approval workflow before they are executed. In short, hoop.dev generates the evidence required by lgpd while preventing accidental exposure of sensitive data.
The gateway trusts an external IdP for authentication, so the organization can continue using its existing OIDC or SAML provider. Once the token is validated, hoop.dev injects the identity into the request metadata and then takes full control of the data path. This separation ensures that even if a compromised service account tries to bypass policy, the gateway still enforces masking and logging before any command reaches the backend.
How hoop.dev generates lgpd evidence
Every recorded session includes a timestamp, the authenticated principal, the exact SQL statement, and the masked result set. Auditors can query the log store to prove that no raw personal identifiers were returned to unauthorized users. The inline masking engine redacts fields such as CPF, email, or phone number in real time, satisfying the data‑minimization principle. When a query exceeds a predefined risk threshold, hoop.dev pauses execution and requires a manager’s approval, creating a documented decision point that can be presented to regulators.
Policy definition and dynamic control
Policy authors define rules in a declarative manifest that maps user groups to allowed operations, risk thresholds, and masking profiles. Because the manifest is evaluated by the gateway at request time, changes take effect instantly without redeploying the backend service. This dynamic approach aligns with LGPD’s requirement for purpose‑bound processing, as permissions can be tightened or broadened as business needs evolve.