An offboarded contractor’s CI pipeline continues to run a script that launches a nested agent to query a customer database. The script reuses a shared service account, and no one sees the exact queries or the data that flows back. When a regulator asks for proof that personal data was protected, the team can only point to a vague list of IAM roles.
Brazil’s General Data Protection Law (lgpd) obligates organizations to demonstrate accountability, purpose limitation, and data minimization. Controllers must be able to show who accessed personal data, when, and for what reason. The law also requires that any unnecessary personal identifiers be masked or redacted before they are stored or transmitted. Without precise logs and real‑time masking, an audit can quickly turn into a compliance failure.
lgpd requirements for data access
lgpd defines several technical and procedural safeguards. Key among them are:
- Comprehensive access logs that tie every read or write operation to a specific identity.
- Evidence of prior authorization for high‑risk actions.
- Inline data masking to prevent unnecessary exposure of personal identifiers.
- Just‑in‑time (jit) privileges that limit the window of access.
When a nested agent runs inside a CI job, it inherits the permissions of the service account that launched it. That inheritance makes it difficult to attribute a specific query to an individual engineer or to a particular automated process. The result is a single point of failure: the service account can read any customer record, and the activity is invisible to auditors.
The unsanitized reality of nested agents
Most teams deploy nested agents with a single, long‑lived credential stored in a secret manager. The credential is injected into build containers, and the agents use it to connect directly to databases, message queues, or internal APIs. Because the gateway sits at the edge of the network, the request bypasses any central policy engine. The consequences are clear:
- All queries are executed with the same privilege set, regardless of the originating user.
- No session is recorded, so there is no forensic trail.
- Sensitive fields such as CPF, email, or phone numbers flow unmasked to downstream services.
- Approvals are absent; any pipeline can issue a data‑extraction command on demand.
This pattern satisfies the immediate need to automate, but it violates lgpd’s accountability and data‑minimization principles.
Partial fixes that still fall short
Organizations often respond by tightening IAM policies: they create a scoped service account that can only read a subset of tables, or they rotate keys more frequently. While these steps reduce the blast radius, the request still travels straight to the target system. Without a choke point, the following gaps remain:
- There is no place to enforce inline masking of personal identifiers.
- Approval workflows cannot be injected because the connection bypasses any policy layer.
- Session replay is impossible, so investigators cannot reconstruct what the agent saw.
- Audit logs are generated only by the target system, which may not capture the identity of the nested agent.
In short, the setup alone does not provide the evidence lgpd auditors expect.
hoop.dev as the data‑path enforcement point
hoop.dev is built to sit on the data path between any identity, human or machine, and the infrastructure it reaches. When a nested agent presents an OIDC token, hoop.dev validates the token, extracts the identity, and then proxies the request to the target database. Because the gateway is the only path the traffic can take, hoop.dev can apply the following lgpd controls:
- It records each session, capturing the user, timestamp, command, and data returned.
- It masks configured personal fields in real time, ensuring that downstream services never see raw identifiers.
- It requires just‑in‑time approval for high‑risk queries, logging the approver’s decision.
- It enforces least‑privilege scopes at the gateway, so a nested agent cannot exceed the permissions granted to the original identity.
Because hoop.dev is the sole enforcement layer, every audit outcome exists only because hoop.dev sits in the data path. Removing hoop.dev would revert the system to the unsanitized state described earlier.
Generating lgpd‑ready evidence with nested agents
When a CI job launches a nested agent, the agent authenticates to hoop.dev using the same OIDC provider that the engineering team uses for interactive logins. hoop.dev then:
- Logs the exact identity that initiated the pipeline run.
- Applies any masking rules to the response payload before it reaches the agent.
- Requires an approval step if the query touches a column marked as sensitive under lgpd.
- Stores a session record that can be exported for audit purposes.
These records satisfy the lgpd requirement for accountability and data‑minimization. Auditors can request the session log, see the approving manager’s signature, and verify that no unmasked personal data left the gateway.
Getting started
To try this approach, follow the getting‑started guide and review the learn section for details on masking policies and approval workflows. The repository contains example configurations for nested‑agent scenarios and a full list of supported connectors.
To explore the source code and contribute, visit the GitHub repository.
FAQ
Do I need to change my existing agent code?
No. Agents continue to use their standard client libraries. hoop.dev intercepts the traffic at the protocol layer, so the agent sees no difference in the API surface.
Can hoop.dev mask only specific columns?
Yes. Masking rules are defined per‑connection and can target individual fields such as CPF, email, or phone number. The gateway applies the rule before any data leaves the target system.
How long are session logs retained for audit?
The retention period is configurable in the deployment settings. Teams typically align it with their internal data‑retention policy and the lgpd requirement to keep evidence for the duration of processing activities.
