A newly off‑boarded contractor left a CI job that still runs a subagent with a hard‑coded database password, exposing the organization to lgpd compliance risk. The subagent spins up new queries whenever a pipeline triggers, and no human ever sees the credential. Engineers also give a service account a wildcard IAM role and let an automation bot back‑fill data nightly.
In many organizations, engineers grant subagents static secrets and broad privileges because it is the fastest way to keep pipelines moving. Engineers store the secret in a version‑controlled file, attach the role to the whole project, and let the subagent talk directly to the target database, Kubernetes cluster, or remote host. No central point can see which command runs, which rows are returned, or whether personal data is exposed.
Those practices clash with the Brazilian General Data Protection Law (lgpd). The regulation demands demonstrable accountability, the ability to audit every access to personal data, and safeguards that limit exposure of sensitive fields. Without a clear audit trail, organizations cannot answer data‑subject requests, cannot prove that only authorized processes accessed the data, and risk hefty penalties.
LGPD requirements for subagents
lgpd establishes four core technical expectations that apply to any automated actor that touches personal data:
- Accountability: The controller must attribute every processing activity to a specific identity and time.
- Data minimisation and masking: Personal data should be exposed only when strictly necessary, and engineers must redact unnecessary fields.
- Auditability: Teams must retain a tamper‑evident log of who accessed what, when, and what operation was performed.
- Just‑in‑time access: Engineers should grant privileges for the minimal duration required to complete the task.
When subagents receive blanket credentials, teams cannot demonstrate any of these guarantees. Controllers cannot prove that a particular pipeline run touched a citizen’s record, nor can they prove that the data was masked before leaving the system.
Why identity and least‑privilege alone are not enough
Most teams start fixing the problem by issuing OIDC or SAML tokens to subagents and by scoping those tokens to the smallest set of permissions possible. This step satisfies the “least‑privilege” part of lgpd, but it leaves a critical gap: the request still travels directly from the subagent to the target service.
Because the gateway is missing, the subagent’s request bypasses any central enforcement point. The target service receives the token and executes the command, but it lacks visibility into the broader policy context. The service does not capture command‑level audit, does not examine response fields for personal data, and does not invoke an approval workflow when a risky operation appears. In short, teams leave auditability and masking unimplemented.
hoop.dev as the data‑path enforcement layer
hoop.dev inserts a Layer 7 gateway between the subagent and the infrastructure it accesses. Engineers route all traffic – database queries, Kubernetes exec calls, SSH sessions, or HTTP requests – through this gateway. Because the gateway is the only place the traffic travels, hoop.dev applies the missing lgpd controls directly on the data path.
- Session recording: hoop.dev records every interaction, attaching the subagent’s identity, timestamp and the exact command issued. The record lives outside the target system, providing an audit trail that records who accessed what and when, satisfying lgpd’s accountability requirement.
- Inline data masking: When a response contains fields marked as personal data, hoop.dev redacts or replaces those values before they leave the gateway, ensuring that only the minimum necessary information is exposed.
- Just‑in‑time approvals: For high‑risk commands, hoop.dev pauses the request and routes it to a human approver. Once an approver grants permission, the command proceeds; otherwise hoop.dev blocks it, preventing accidental over‑exposure.
- Dynamic revocation: Because the gateway holds the credential, administrators revoke a subagent’s access instantly – the gateway simply refuses new connections, eliminating the lingering risk of stale secrets.
hoop.dev creates these enforcement outcomes because it sits in the data path. The identity token alone does not provide them.
Generating LGPD evidence with hoop.dev
When a subagent connects through hoop.dev, the platform automatically generates the artefacts that auditors seek under lgpd:
- Identity‑bound logs: Each log entry includes the subagent’s OIDC subject, the client IP, the exact query or command, and the response status. This satisfies the requirement to prove who accessed personal data.
- Masked data snapshots: Engineers configure personal‑data patterns; hoop.dev stores those fields in a masked form while the original value never persists outside the target system. This demonstrates data‑minimisation.
- Approval audit trails: When a request routes for human approval, hoop.dev records the approver’s identity, the decision timestamp, and the justification. This evidence shows that high‑risk processing received review.
- Retention policy: Engineers configure the gateway’s log store to retain records for the period required by lgpd, and the gateway enforces retention centrally, independent of the target’s own log rotation.
Because the logs originate from the gateway, they remain intact even if a database is compromised, giving regulators confidence that the organization can demonstrate compliance after an incident.
Getting started
Deploying hoop.dev follows three steps:
- Run the provided Docker Compose file or install the gateway in your Kubernetes cluster. The quick‑start guide walks you through the initial deployment.
- Register each subagent‑controlled resource – for example a PostgreSQL instance or a Kubernetes cluster – and configure the connection credentials that the gateway will use.
- Enable the lgpd‑focused features in the feature documentation: session recording, inline masking rules, and just‑in‑time approval workflows.
All detailed steps appear in the getting‑started documentation. Because hoop.dev is open source, engineers can inspect the code, adapt the policies, and integrate the audit store with existing SIEM or data‑retention platforms.
FAQ
Does hoop.dev replace the need for database‑level logging?
No. hoop.dev complements native logs by capturing the full request‑response cycle at the protocol layer and by adding identity context that many databases do not record.
Can I use hoop.dev with existing CI pipelines?
Yes. CI jobs simply point their client (psql, kubectl, git) at the hoop.dev endpoint. The gateway handles authentication, masking and audit without any code changes.
How does hoop.dev ensure the audit logs cannot be altered?
The gateway writes logs to a storage backend that engineers configure separately from the target resource. Because the gateway is the sole writer, tampering would require compromising the gateway itself, which presents a much smaller attack surface than compromising every downstream service.
Take the next step
Ready to generate the evidence lgpd requires for every subagent interaction? Clone the repository and start the quick‑start deployment today:
https://github.com/hoophq/hoop
