A data‑science team builds a chain‑of‑thought prompt that stitches together multiple LLM calls to extract a customer’s credit‑score history. The prompt pulls raw personal identifiers from a CSV file, sends them to the model, and writes the raw response to a log file that lives on a shared drive. The pipeline does not apply masking, and no one reviews the log. The pipeline runs automatically whenever a new file lands in the bucket.
Under Brazil’s General Data Protection Law (LGPD), that workflow violates several core obligations. LGPD requires that personal data be processed only for a legitimate purpose, that any processing be logged with a clear audit trail, and that data subjects’ sensitive fields be protected through masking or encryption when stored or transmitted. Auditors expect to see who initiated each request, what data was sent, whether an approval step occurred, and a replayable record of the interaction.
Most chain‑of‑thought implementations skip a centralized control point. The orchestrator talks directly to the LLM service using the model’s public API, and the request bypasses any enforcement layer. The result is a black‑box flow: the request reaches the model, the response returns, and the pipeline records whatever it wants. Without a gate, organizations cannot enforce inline masking, cannot require just‑in‑time approvals, and cannot produce the immutable session logs that LGPD auditors demand.
What LGPD expects from AI pipelines
LGPD defines four technical safeguards that are especially relevant to chain‑of‑thought workflows:
- Accountability: Every processing activity must be traceable to an identity and a time stamp.
- Data minimisation and masking: Personal data should be reduced to the minimum necessary, and any retained identifiers must be masked before storage or further distribution.
- Access control: Only authorised subjects may trigger processing, and privileged actions should be gated by explicit approval.
- Auditability: A record of each request and response must be retained for the statutory retention period.
When a chain‑of‑thought prompt runs without a gate, none of these safeguards can be guaranteed. The pipeline’s code may log raw payloads, and any human error can expose personal data at scale.
Why a data‑path gateway is required
The missing piece is a control surface that sits on the data path between users and infrastructure. The gateway must be the only place where policy decisions are enforced, because attackers can bypass any enforcement performed upstream if they obtain the token or modify the script. By placing the enforcement in the data path, the system guarantees that every request, regardless of source, passes through the same policy engine.
Such a gateway can provide:
- Inline masking of configured fields before the request reaches the model.
- Just‑in‑time approval workflows for high‑risk prompts.
- Session recording that captures the full request‑response exchange for replay.
- Identity verification via OIDC/SAML, ensuring that only authorised identities can start a chain‑of‑thought run.
All of these capabilities together generate the concrete evidence that LGPD auditors look for.
Introducing hoop.dev
hoop.dev is an open‑source layer‑7 gateway that fulfills exactly this role. It proxies connections to infrastructure, including LLM endpoints used in chain‑of‑thought pipelines, and applies masking, approval, and recording at the protocol level. Because hoop.dev sits in the data path, every enforcement outcome, masking, approval, audit logging, happens only through hoop.dev.
In a typical deployment, the organization authenticates users and service accounts with an OIDC provider. hoop.dev validates the token, extracts group membership, and decides whether the request may proceed. The gateway holds the LLM credentials, so the orchestrator never sees them. When a chain‑of‑thought job initiates a request, hoop.dev checks the payload against masking rules, routes the request to a human reviewer if needed, and then forwards the sanitized request to the model. hoop.dev records and stores the full exchange for later replay.
Because hoop.dev records each session and the associated identity, it generates the audit evidence required by LGPD. Organizations can export the recorded logs to their SIEM or compliance platform, providing a verifiable trail of who accessed what data and when.
How hoop.dev generates LGPD evidence
When a chain‑of‑thought workflow runs through hoop.dev, the following evidence appears automatically:
- Identity‑bound session logs: Each log entry includes the OIDC subject, the timestamp, and the full request‑response payload (with masked fields applied).
- Masking audit: The log records which fields were masked and the rule that triggered the masking, satisfying LGPD’s data‑minimisation requirement.
- Approval records: hoop.dev stores the approval decision, reviewer identity, and decision timestamp alongside the session.
- Replay capability: Auditors can replay the exact interaction to verify that no unexpected data was exposed.
hoop.dev produces these artifacts without any code changes to the chain‑of‑thought orchestrator. You integrate by pointing the orchestrator’s endpoint to the hoop.dev gateway, as described in the getting‑started guide. Detailed configuration of masking rules and approval policies is covered in the learn section of the documentation.
FAQ
Does hoop.dev make my chain‑of‑thought pipeline LGPD‑compliant?
hoop.dev provides the technical evidence that LGPD auditors require, but compliance also depends on organisational policies, consent management, and broader data‑governance practices.
How does inline masking work for LLM payloads?
The gateway inspects the request at the protocol layer, replaces any field that matches a configured pattern (such as CPF numbers or email addresses) with a placeholder, and then forwards the sanitized request. The original value never reaches the model.
Can I use hoop.dev with existing CI/CD pipelines?
Yes. Because hoop.dev exposes the same network interface as the target LLM, you can point any script or CI job that calls the model at the gateway without code changes.
By placing a layer‑7 gateway in the data path, organisations can meet LGPD’s accountability, minimisation, and auditability requirements while still leveraging powerful chain‑of‑thought techniques.
Explore the source code and contribute to the project on GitHub.
