An offboarded contractor still has a token that can pull raw video streams from the analytics platform, exposing personal data that belongs to thousands of users. The team discovers the leak only after a data‑subject request arrives, and they realize they have no record of who accessed the stream, what fields were returned, or whether any masking was applied.
What lgpd expects from streaming pipelines
Brazil's General Data Protection Law (lgpd) requires organizations to keep detailed evidence of how personal data is accessed, transformed, and transmitted. Auditors look for:
- Immutable logs that tie each read or write operation to a specific identity.
- Proof that any personal identifiers are masked or redacted when they leave the trusted environment.
- Just-in-time approvals for high‑risk queries that could expose sensitive attributes.
- Replayable sessions that demonstrate compliance during an inspection.
These controls must survive beyond the lifetime of the individual service that performed the operation. In practice, many streaming stacks rely on static credentials and direct network paths, making it impossible to satisfy the audit‑trail requirement.
Why traditional access patterns fall short
Most engineering teams connect their stream processors directly to Kafka, Kinesis, or a custom protocol using a shared secret or a long‑lived service account. The setup typically looks like this:
- Identity is established once, often by a CI job that injects a token into the container.
- The token grants blanket read access to every topic that the service owns.
- There is no gateway that can inspect the payload, so personal fields travel unaltered.
- Logging is limited to the client library, which can be disabled or tampered with.
Even if the organization adds an OIDC provider to issue short‑lived tokens, the enforcement still happens inside the streaming client. The client can be compromised, and the audit data lives inside the same process that holds the credentials. In other words, the setup decides who may start a request, but it provides no place to enforce masking, approval, or immutable logging.
How hoop.dev creates a compliant data path
hoop.dev introduces a Layer 7 gateway that sits between the identity provider and the streaming endpoint. The gateway runs a network‑resident agent close to the broker, and every client connection is forced through it. The architecture follows three distinct phases:
- Setup. Users authenticate against an OIDC or SAML provider. The token tells hoop.dev which groups the caller belongs to, but no access decision is made yet.
- The data path. The gateway terminates the client connection, inspects each protocol frame, and applies policy before forwarding the request to the broker. This is the only place where enforcement can happen.
- Enforcement outcomes. Because hoop.dev occupies the data path, it can record the full streaming session, mask any personal fields in real time, require a just-in-time approval for high‑risk topics, and store an audit log entry that lives outside the client process.
All of these capabilities are active only because hoop.dev sits in the data path. Removing the gateway would instantly eliminate masking, approval, and reliable session logs.
Key enforcement outcomes for lgpd
When a streaming client attempts to read from a topic that contains personal data, hoop.dev performs the following actions:
- Session recording. hoop.dev captures every inbound and outbound frame, timestamps it, and ties it to the caller’s identity.
- Inline masking. hoop.dev scans payloads for fields such as "cpf", "email", or "address" and replaces them with redacted values before the data leaves the trusted zone.
- Just-in-time approval. For topics marked as high‑risk, hoop.dev pauses the request and routes it to an approver defined in the policy. The session resumes only after explicit consent.
- Audit trail. hoop.dev writes an audit log entry to an external store, providing the evidence auditors expect under lgpd.
Each outcome is enforced at the gateway, not by the streaming client or the broker. This separation guarantees that even a compromised client cannot bypass the controls.
Getting started with hoop.dev for streaming
To retrofit an existing pipeline, begin with the getting‑started guide. Deploy the gateway using the provided Docker Compose file, configure the broker endpoint, and register the topics that contain personal data. Define policies that specify which fields to mask and which topics require approval. The learn section contains detailed examples of policy syntax and best practices for lgpd compliance.
Because hoop.dev is open source, you can review the code, contribute improvements, or host the gateway in your own environment. The full repository is available on GitHub: view and contribute to hoop.dev on GitHub.
FAQ
Does hoop.dev replace my existing authentication system?
No. Authentication is still performed by your OIDC or SAML provider. hoop.dev only consumes the token to make authorization decisions.
Can I use hoop.dev with managed Kafka services?
Yes. The gateway connects to any broker that supports standard client protocols, whether it runs on‑premises or in a cloud‑hosted service.
How long are session recordings retained?
Retention is a policy choice made by the organization. hoop.dev stores logs in the external store you configure, and you can set lifecycle rules that meet lgpd’s data‑retention requirements.
