An automated CI job that pushes database migrations continues to run after the contract of the developer who authored it expires. The service account it uses still holds a token that can read customer tables, and the job’s logs contain raw personal data such as names, email addresses, and CPF numbers. When auditors request proof that the organization respects Brazil’s LGPD, the team can point to the job’s existence but has no reliable, tamper‑evident record of what data was accessed, who triggered the request, or whether the operation received proper approval.
LGPD treats any processing of personal data as a regulated activity, regardless of whether the actor is a human user or an automated identity. Service accounts, CI pipelines, and AI agents all generate traffic that can expose personal information. Compliance programs therefore need to capture three things for each non‑human request: the exact data payload, the identity that initiated the request, and the policy decision that allowed it.
The first layer of control, identity federation, OIDC tokens, and role‑based permissions, decides which non‑human principal may start a session. It is essential for authentication, but on its own it cannot guarantee that the session will be logged, that sensitive fields will be redacted, or that an out‑of‑band approval will be enforced. Without a point of inspection on the traffic path, the organization lacks the continuous evidence LGPD auditors expect.
hoop.dev provides that inspection point. It sits as a Layer 7 gateway between the automated identity and the target infrastructure, whether the target is a PostgreSQL database, a Kubernetes API, or an SSH host. Every request passes through the gateway, where hoop.dev can apply just‑in‑time approval, mask configured columns such as email or CPF in real time, and record the full session for replay. Because the gateway holds the credential, the non‑human principal never sees the secret, and the organization gains an audit trail that aligns with LGPD’s requirement for continuous evidence.
hoop.dev records each session with timestamps, the identity claim extracted from the OIDC token, and the exact request and response payloads. The logs are stored outside the agent process, ensuring that even if the agent is compromised the evidence remains intact. Inline masking removes personal identifiers from response streams before they reach downstream consumers, so stored logs contain only masked values for regulated fields while preserving the rest of the data for troubleshooting. The just‑in‑time approval workflow forces a human reviewer to sign off on high‑risk operations, creating a signed approval record that appears alongside the session data.
For LGPD auditors, hoop.dev’s audit logs serve as the continuous evidence of data processing: they show who (the non‑human principal’s subject claim), what data was accessed, when the access occurred, and whether the access complied with the organization’s policy. Because the logs are retained and include masking decisions, the organization can demonstrate that personal data was protected in transit and at rest, satisfying the accountability and data‑minimization principles of the law.
In practice, deploying hoop.dev means the security team no longer relies on ad‑hoc log collection or manual ticketing to prove compliance. The gateway automates the capture of the exact evidence LGPD requires, while giving developers and automated pipelines the smooth, just‑in‑time access they need to move fast.
Why LGPD compliance matters for non‑human identities
Policy definition in hoop.dev is declarative. Administrators describe which commands or queries are considered high risk, which columns contain personal data, and which identities are allowed to run them. The gateway evaluates each request against this policy before it reaches the target. If the request matches a high‑risk rule, hoop.dev either blocks it outright or routes it to an approval queue. This fine‑grained control means that even a service account with broad database credentials cannot exfiltrate personal data without triggering the policy.