When a contractor leaves a project, a lingering CI job continues to spin up temporary containers that call internal APIs, pull secrets, and write logs to a shared bucket. The organization assumes the job will stop, but the orchestration layer never records which personal data fields were read or who authorized the run.
Brazil’s General Data Protection Law (LGPD) treats that uncertainty as a compliance risk. The regulation requires organizations to demonstrate who accessed personal data, when the access occurred, and that the access was limited to the purpose defined by the data subject. It also mandates the ability to mask or redact personal identifiers in logs that are retained for audit purposes. In practice, teams that rely on agent‑driven orchestration often miss these controls because the orchestration engine talks directly to resources using static credentials.
What LGPD expects from automated agents
LGPD defines personal data broadly, covering any information that can identify an individual. To satisfy the law, a system must provide:
- Granular identity verification for every request.
- Just‑in‑time (JIT) approval when a request touches sensitive fields.
- Immutable evidence that shows the requestor, the resource, the command, and the data returned.
- Inline masking of personal identifiers in responses that are stored for later review.
- Ability to revoke access instantly when a data subject withdraws consent.
These controls are easy to describe, hard to enforce when the orchestration layer bypasses any enforcement point.
Why the usual orchestration model falls short
Most agent orchestration platforms authenticate once, acquire a long‑lived service account, and then forward commands straight to the target – a database, a Kubernetes cluster, or an SSH host. The setup phase (identity, OIDC or SAML tokens, service accounts) decides who may start a job, but it does not enforce policy on the data path. The result is a system where:
- Every command runs with the same privilege, regardless of the data it touches.
- There is no central point to inspect the payload and apply masking.
- Audit logs are generated by the target, not by the orchestration engine, making it difficult to correlate a user’s identity with a specific query.
- Approval workflows are external to the request, so a rogue job can bypass them entirely.
In other words, the precondition of having identity‑aware agents is satisfied, but the request still reaches the target directly, leaving the organization without the evidence LGPD demands.
hoop.dev as the data‑path enforcement layer
hoop.dev inserts a Layer 7 gateway between the orchestrating agent and the target resource. The gateway is the only place where enforcement can happen. It verifies the caller’s OIDC token, checks group membership, and then decides whether the request may proceed. Because the gateway sits in the data path, it can apply all LGPD‑required controls:
- Session recording: hoop.dev records each orchestration session, capturing the user identity, the exact command, and the full response.
- Inline masking: hoop.dev inspects response payloads and redacts personal identifiers before they are written to logs or storage.
- Just‑in‑time approval: When a command matches a policy that touches protected fields, hoop.dev pauses execution and routes the request to an approver.
- Command blocking: Dangerous operations, such as bulk deletes or privilege escalations, are rejected automatically.
- Replay capability: Recorded sessions can be replayed to demonstrate compliance during an audit.
All of these outcomes exist only because hoop.dev is positioned in the data path. If the gateway were removed, the orchestration engine would again talk directly to the resource, and none of the LGPD evidence would be generated.
How to integrate hoop.dev with existing agent pipelines
The integration starts with the usual setup: configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) and issue a service account that the orchestration engine can assume. Next, deploy the hoop.dev gateway using the getting‑started guide. The gateway runs as a Docker container or in Kubernetes, and an agent is installed close to each target resource. Once the gateway is registered, the orchestration pipeline points its client commands (psql, kubectl, ssh, etc.) to the hoop.dev endpoint instead of the raw host.
From that point forward, every request flows through hoop.dev, where the policies you define enforce LGPD requirements. The learn section provides detailed policy examples for masking personal identifiers, requiring approvals for data‑export queries, and limiting the scope of each session.
FAQ
Does hoop.dev replace my existing identity provider?
No. hoop.dev consumes the identity token issued by your provider. It adds enforcement on top of the authentication you already have.
Yes. The only change is the endpoint address. Your existing scripts continue to run, and hoop.dev applies the LGPD controls transparently.
How long are the audit logs retained?
Retention is configurable in the gateway settings. The logs are stored in a location you control, and hoop.dev ensures they contain masked data only.
Explore the source code and contribute to the project on GitHub.
