An offboarded contractor still has a script that sends raw customer records to an AI assistant for quick troubleshooting. The script builds a large prompt, often called a context window, and the assistant returns a response that the team copies back into production. No one sees what data left the network, no audit trail records the exchange, and the organization cannot prove that personal information was handled according to lgpd requirements.
Why lgpd matters for AI context windows
lgpd obliges data controllers to limit the processing of personal data to the minimum necessary, to retain clear evidence of who accessed what data, and to demonstrate that any sharing of that data follows a documented purpose. When developers embed raw PII in prompts, they create a processing activity that is invisible to the organization. Auditors will ask for:
- Proof that each request containing personal data was authorized.
- Records of the exact data that entered the AI model.
- Evidence that any response leaking PII was either masked or reviewed before distribution.
Without a control point, the organization cannot answer these questions, putting it at risk of fines and reputational damage.
Current practice – the unsanitized state
Most teams treat the AI endpoint as a regular HTTP service. A developer runs curl or uses an SDK, passes a JSON payload that includes full user records, and receives a response. The request travels directly from the workstation to the model provider. The only logs are generic network metrics; no field‑level view of the payload is kept, and no approval workflow exists. The setup provides identity verification (the developer’s API key) but offers no enforcement on the data that crosses the wire.
What must change before compliance is possible
The first step is to place a gate that can see every request before it reaches the AI service. That gate must be able to:
- Identify the caller using OIDC or SAML tokens (the setup layer).
- Inspect the request payload at the protocol level (the data path).
- Apply lgpd‑driven policies: mask PII fields, require a just‑in‑time approval for any request that contains sensitive attributes, and record the full request and response for later audit (the enforcement outcomes).
Even with strong identity, the enforcement cannot happen on the client side because the client controls the payload. The gate must sit between the caller and the AI model.
How hoop.dev fulfills the data‑path requirement
hoop.dev is an open‑source Layer 7 gateway that proxies connections to AI services. When a request is sent through hoop.dev, the gateway performs three critical actions that directly satisfy lgpd evidence needs:
- Inline masking: hoop.dev can redact or hash fields that match a PII pattern before the request reaches the model, ensuring that the model never sees raw personal data.
- Just‑in‑time approval: if a payload contains a flagged attribute, hoop.dev routes the request to a human reviewer. The reviewer can approve, modify, or reject the request, and that decision is logged.
- Every request and response pair is recorded in an audit log that cannot be altered.
Because hoop.dev sits in the data path, none of these outcomes can be achieved by identity setup alone. If you removed hoop.dev, the masking, approval, and recording would disappear, leaving the organization non‑compliant.
Mapping lgpd controls to hoop.dev features
lgpd defines several technical and organizational measures. The table below shows how hoop.dev maps to each control:
| lgpd control | hoop.dev implementation |
|---|
| Purpose limitation | Approval workflow forces a documented reason before any PII‑containing request is sent. |
| Data minimization | Masking rules automatically strip unnecessary personal fields from the prompt. |
| Accountability | Full request/response audit trail tied to the caller’s identity. |
| Security of processing | Gateway runs inside the customer network; credentials never leave the agent. |
Getting started with hoop.dev for lgpd‑ready AI usage
Deploy the gateway using the documented Docker Compose quick‑start, configure an OIDC provider so that each developer authenticates with a token, and register the AI endpoint as a connection. Define masking policies that target common PII patterns (names, email addresses, CPF numbers) and enable just‑in‑time approvals for any request that matches those patterns. The getting‑started guide walks you through the steps, and the learn section contains deeper explanations of masking and approval workflows.
FAQ
Does hoop.dev store the raw personal data?
No. The gateway masks or removes PII before the request reaches the AI model, and only the masked payload is persisted in the audit log. This satisfies lgpd’s requirement to avoid unnecessary retention of raw personal data.
Can I use hoop.dev with any AI provider?
hoop.dev supports generic HTTP‑based LLM endpoints, including Claude Code, Cursor, and custom MCP servers. As long as the provider speaks HTTP/HTTPS, the gateway can proxy the traffic and apply lgpd controls.
What if a developer needs to see the full response for debugging?
Approvers can grant a temporary exemption that logs the full response for a limited time window. The exemption itself is recorded, providing the audit trail required by lgpd.
Start exploring the code and contribute improvements by visiting the GitHub repository. hoop.dev gives you the data‑path control you need to turn AI context windows into a compliant part of your lgpd program.
