An offboarded contractor still has a personal access token embedded in a CI pipeline, and the pipeline continues to push data to a self‑reflection service. The service stores user‑generated insights alongside raw logs, but no one can tell which token accessed which record or whether personal identifiers were ever returned. When a data‑subject requests deletion under the Brazilian General Data Protection Law (lgpd), the organization struggles to prove who saw the data, when it was masked, and whether the request was honored.
Why lgpd matters for self‑reflection services
lgpd requires controllers to demonstrate accountability for personal data. The law obliges organizations to keep a precise record of every access, to apply data‑minimization, and to mask or redact identifiers when they are not needed for the business purpose. Auditors expect evidence that an individual’s data was only viewed by authorized identities, that any exposure was logged, and that masking policies were enforced at the point of retrieval.
Typical gaps in current implementations
Most teams rely on static credentials or service‑account keys that are shared across pipelines, scripts, and developers. Those credentials give standing access to the underlying database or API, so any request bypasses a central control plane. Because the gateway is missing, the system receives the request without any inspection, masking, or logging. The result is a blind spot: the system records that a query ran, but it cannot prove which fields were returned, whether personal identifiers were redacted, or whether an approval step was required. Without a unified audit log, the organization cannot answer a regulator’s request for a complete access trail.
How a non‑human identity and least‑privilege model fixes part of the problem
Introducing OIDC‑based service identities and assigning them the minimum set of permissions eliminates the need for long‑lived shared secrets. Each CI job now authenticates with a short‑lived token that the identity provider can revoke instantly. This setup decides who the request is and whether it may start, satisfying the "who" part of lgpd. However, the request still travels directly to the self‑reflection backend, where the backend receives the request without any inspection, masking, or logging. The gap that lgpd highlights – evidence of what data actually moved – remains open.
hoop.dev as the data‑path enforcement point
hoop.dev sits between the identity provider and the self‑reflection service. It acts as a layer‑7 gateway that proxies every request, inspects the protocol, and applies policy before the backend sees the payload. Because hoop.dev alone alters traffic, it becomes the sole location for enforcement.
Administrators configure OIDC or SAML authentication, define least‑privilege roles for each CI job, and register the self‑reflection endpoint in the gateway. hoop.dev holds the credential needed to talk to the backend, so the client never sees it.