An AI team hands a LangChain‑driven assistant to an external contractor, then discovers the contractor can pull raw user prompts and model responses without any oversight. The organization now faces a breach of Brazil's General Data Protection Law (LGPD) because it cannot prove who accessed personal data, how it was used, or whether it was masked.
What LGPD expects from AI applications
LGPD requires data controllers to demonstrate accountability. The law asks for:
- Clear records of every access to personal data, including the identity of the requester and the timestamp.
- Evidence that only the minimum necessary data is processed, with any excess masked or redacted.
- Just‑in‑time approvals for operations that could affect data subjects, such as bulk exports or model fine‑tuning.
- Ability to reconstruct a session for audit or incident response.
Without a single point that observes the traffic between LangChain components and the services they call, an organization cannot collect the logs LGPD demands.
Why identity alone is not enough
Most teams already federate LangChain workloads with an OIDC provider. The identity platform decides who may start a request and can enforce token scopes. However, once the request leaves the identity check, the system sends credentials directly to the target service. At that point the organization loses visibility: the request bypasses any audit, no data is masked, and no human can intervene before a risky command runs.
In other words, the setup grants access but leaves the data path uncontrolled. LGPD compliance still requires a guardrail that sits where the traffic actually flows.
hoop.dev as the enforceable data path
hoop.dev provides the missing layer. It sits between LangChain agents and the external resources they query, databases, LLM APIs, or internal HTTP services. By proxying every connection, hoop.dev can:
- Record each request and response, tying it to the authenticated user identity.
- Apply inline masking rules so that personal identifiers never leave the gateway in clear text.
- Require just‑in‑time approval for operations that match a risk policy, such as exporting large result sets.
- Scope the underlying service credentials to the duration of the session, ensuring they are never exposed to the LangChain process.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. The identity system supplies the who, hoop.dev supplies the how.
Teams can start with the getting‑started guide to deploy the gateway, then define masking and approval policies in the learn section. The open‑source repository on GitHub contains the full implementation.
Mapping LGPD controls to hoop.dev capabilities
Each LGPD control has a direct counterpart in hoop.dev:
- Access logs – hoop.dev writes a structured entry for every request, including the OIDC subject, client IP, and the invoked endpoint.
- Data minimization – masking policies rewrite responses before they leave the gateway, guaranteeing that only allowed fields are visible downstream.
- Approval workflow – risk rules trigger a human approval step; the decision is recorded alongside the request.
- Session replay – the recorded stream can be replayed verbatim, letting auditors see exactly what the LangChain agent saw and sent.
Designing a masking policy for personal identifiers
Imagine a prompt that contains a Brazilian CPF number. A masking rule can be defined to replace any 11‑digit pattern with "***‑***‑***" before the response is sent to the caller. Because hoop.dev performs this transformation at the protocol layer, the LangChain code never receives the raw identifier, and the audit log stores only the masked version. This satisfies the LGPD requirement to protect sensitive personal data in transit.
Just‑in‑time approval workflow example
Suppose a LangChain chain attempts to export a CSV of all customer records. A policy can flag any query that returns more than 1,000 rows. hoop.dev intercepts the request, pauses execution, and notifies a designated reviewer. The reviewer’s decision, approve or deny, is logged with their identity and timestamp. If approved, hoop.dev forwards the request; if denied, the operation is aborted and the user receives a clear error. The entire decision trail becomes part of the LGPD evidence package.
Retention and replay for auditors
hoop.dev stores session recordings in a durable backend that can be retained for the period required by your data‑retention policy. Auditors can query the backend for a specific user, date range, or resource, then replay the exact sequence of calls and responses. Because the recordings contain only masked data, they demonstrate compliance without exposing the underlying personal information.
Operational considerations
Deploying hoop.dev does not require changes to existing LangChain code. The gateway runs as a Docker Compose service or in Kubernetes, and the LangChain client simply points to the proxy address. Credential management stays inside hoop.dev, so secret rotation is handled centrally. Monitoring the gateway itself is straightforward: health checks and metric endpoints are exposed, and any policy violation appears in the same audit stream used for LGPD reporting.
FAQ
Does hoop.dev make LangChain LGPD‑compliant?hoop.dev supplies the technical evidence required by LGPD, but compliance also depends on organizational policies and how you configure the gateway.Can I see the raw data that was masked?No. hoop.dev applies the masking rule before the response leaves the gateway, and the stored audit record contains only the masked version.How does session replay help with incident response?Because hoop.dev records every request and response, you can replay a full interaction to understand exactly what data was processed and how the model behaved.
Explore the open‑source code on GitHub: https://github.com/hoophq/hoop
